The Architect’s Pivot: Steering the Ship When Agents Manage the Sails
I’ve been writing about software architecture since 2008. In all those years of writing, I would say there has been a consistent theme: control. For years, the role of the software architect was to impose order on chaos. We were the guardians of understandability, deployability, and runnability.
Before the rise of Agentic AI, our mandate was clear. We managed technical debt to keep "accidental complexity" low, ensuring that the software remained readable. Why? Because if a developer couldn't understand the code, they couldn't predict how it would behave when they changed it. This unpredictability was—and still is—a direct risk to the people funding us.
We also owned the Software Development Lifecycle (SDLC). We built the paved roads that allowed code to move from a developer’s laptop to production easily, quickly, and repeatedly. We evangelized cloud-native philosophies, insisted on test automation, and locked down our GitOps workflows. And once that software was live, we ensured it ran profitably—secure, efficient, scalable, and compliant with the dizzying array of industry standards and laws.
But now, in 2026, the ground has shifted. AI agents write most of the code. They generate the tests. They even suggest the deployment configurations.
Does this mean the architect is obsolete? Far from it. As Stephan Schwab reminds us, the industry has long harbored a "recurring dream of replacing developers" with tools—from 4GLs to low-code. AI is the latest iteration of this dream. But as the coding burden lifts, the architectural burden shifts the center of gravity.
Here is how our three core responsibilities—Understandability, Deployability, and Runnability—have evolved in the age of Agentic AI.
1. Understandability: From "Clean Code" to "Clean Boundaries"
In the past, I harped on clean code conventions because humans had to read the logic. Today, an AI agent can read messy code in milliseconds and refactor it in seconds. Does readability still matter?
Yes, but the definition has changed, and humans still need to read and understand the code, but not precisely for the same reasons.
As Chris Richardson points out in his recent post On the duality of GenAI-based development tools, these tools are a double-edged sword. They accelerate feature development and developer productivity for what he calls fast flow organizations with a sociotechnical architecture (i.e. desire to learn with fast feedback loops). For slow flow (i.e. bureaucratic) organizations, what generative AI accelerates is tech debt. Perhaps the role of the software architect would be to advocate for fast flow. Chris also quips about generative AI being some kind of mind virus due to all of the hyperbole around it. The software architect may find themselves in the position of offering a more balanced and sane perspective to some of the wilder claims around AI.
If we let AI generate code without constraints, we get a system that works but is impossible to reason about globally. The architect’s responsibility shifts from code-level hygiene to system-level boundaries. We must define strict module interfaces and service boundaries that the AI cannot cross.
We are no longer editors of prose; we are zoning commissioners. We define the districts (services) and the building codes (interfaces), and we let the agents build within those walls. If we fail to manage the "accidental complexity" at the macro level, the AI will create a labyrinth that no human can debug when the inevitable hallucination occurs.
2. Deployability: The Reviewer's Dilemma
It was human typing speed and context switching that limited the "developer laptop to production" pipeline. Now, agents can flood the CI/CD pipeline with Pull Requests.
The bottleneck is no longer writing the change; it is verifying the change.
There are plenty of blogs that cover what happens when AI writes almost all code. The answer is that developers become reviewers. But for the architect, this presents a terrifying risk: Review Fatigue. If developers stop understanding the software because it is too complex and they didn't write it, they cannot effectively review it. Review fatigue could negatively impact your change failure rate, undermining release confidence and slowing feature velocity with high-ceremony deployments. Since human coders must still review the generated code, managing technical debt is more critical than ever. Nothing can blow up code cruft like an LLM, and review fatigue is more likely if the code is hard to read. LLMs can also refactor code faster than humans, so technical debt is more about structural debt than code smells. Must a human coder still review the code changes? More on this later.
The cloud-native answer to this problem is to "automate all the things." So we write unit tests and integration tests to verify that the service code is working correctly. In this new world, the AI writes both the application code and the tests. What happens if the same hallucination occurs in both places? Did the AI misunderstand the requirement in both the implementation and the tests that verify it? Could we maintain a guardrails-style validator on the LLM's generated code? Have a different LLM review the first LLM's output. What is the likelihood that both LLMs will suffer from the same hallucinations? You want this kind of vetting process to be repeatable and deterministic, which is not what you get with LLMs. What I have seen so far with LLMs doing code reviews has not been very impressive. Maybe you could set it up as a figurative second pair of eyes but you should not depend on it as any kind of quality gate. Perhaps that could eventually change.
The DevOps trend has been wildly successful for many reasons. One reason is that it reduces the time to restore service. The reason is that the developers who wrote the code are also the ones on-call when the software fails in production. They are most familiar with the code, so they are more likely to find the issue and fix it more quickly. In the agentic world, developers no longer write code, but they can still be effective during on-call duty if they understand it. Having them be responsible for code reviews forces them to understand the code. Either that or somehow you get the LLM to be the dev on-call. Good luck with that. I have yet to have seen any viable offering of that capability.
Here is another reason why human engineers should still be in the review loop. Whenever an incident occurs that inflicts significant material harm and human suffering, there is a human need to find someone to blame. Acts of God are not very emotionally satisfying. If any company released software with bugs that caused such harm, people would want a human sacrifice (figuratively speaking). The narrative of “we found the SoB and fired him” would tend to land better than “we changed LLM providers.”
The worst-case scenario is that we have human engineers still writing some of the code, not because the AI cannot do it, but because it keeps the engineers more actively focused on understanding their apps' behavior. The software architect would manage the mix of human-and machine-generated code and its verification.
3. Runnability: Governance in the Black Box
Finally, we examine the runtime characteristics of our systems with respect to profitability, security, and compliance.
When humans wrote SQL queries, we could train them to analyze execution plans and tune the queries to be more efficient. When humans wrote algorithms, we could train them to explore their code using big O notation to understand and make trade-offs between space and time complexity. An AI agent, optimizing for "solving the ticket," might generate functional but horribly inefficient code that blows up the cloud bill. Or worse, it might hallucinate a security vulnerability by pulling in a non-existent or compromised dependency. You can instruct the AI also to pay attention to efficiency, but LLMs still have difficulty dealing with conflicting instructions in the prompt.
As discussed in the InfoQ article on Architects in the AI Era, the architect's role expands to include AI Governance. We are responsible for the constraints we feed the models. We must design architectures that are resilient not just to server failures, but also to logic failures. Easier said than done. Should software architects influence what goes into the CLAUDE.md file or under the .github/instructions folder? Sure, but be advised that there is more to it than that and that prompt engineering the so-called "ilities” or non-functional requirements is currently hit-or-miss at best.
We need "bulkheads" not just for traffic, but for trust. We can no longer assume the code inside our perimeter is benevolent. The architect must implement Zero Trust principles even for the code we (or our agents) wrote. Compliance with laws and standards is no longer just a checklist; we must bake it into the prompts and RAG (Retrieval-Augmented Generation) context that guide our agents.
These quality gates cannot be completely automated. The architect can also help the organization set what the standards for due dilligence are. What is the right amount of professional human oversight that assures quality yet doesn't bottleneck the process?
That InfoQ article also catalogs how software architects interact with AI. Sometimes the architect guides the AI and sometimes the architect uses AI for guidance. See this product as an example of the latter.
We also need to avoid the dystopian possibility Cory Doctorow called a reverse centaur future, where humans toil in the service of AI tooling rather than the other way around. Asking human developers to review unmanaged code without sufficient time or tooling, so they alone can bear the blame for any errors, would be an example of such a dystopia.
The Verdict
The recurring dream of replacing the human element is just that—a dream. The tools have become agentic, but they still lack agency in the business sense. They do not care about shareholder value, user happiness, or legal compliance.
Finding the right mix of automation and human oversight, deciding on the best ways to guide and be guided by AI, and nurturing an engineering culture most likely to achieve the benefits of AI are how software architects must adjust how they improve the understandability, deployability, and runnability of the systems that are under their care. That is still our job. We just stopped laying bricks and started designing the blueprints for the machines that will do it.
If you found this coverage of the topic to be intriguing and your organization is currently struggling with how software architects must change to remain relevant, then feel free to get in contact and we can continue the conversation with your specific needs in mind.
Reach out Via Email