AI software architecture: How the role of the software architect is changing

Source. Sony Sports engineer, writing on Medium.
‍

Abstract

The article argues that architecture was originally built to coordinate human effort. People are slow and expensive, so architecture put guardrails around what they built and kept large teams consistent. AI removes much of the cost of writing code, so the author claims architecture stops being a blueprint for construction and becomes a regulator of change. In his words, architecture goes from being the dictator to being the regulator, and engineers shift from building to controlling. The conclusion is that architecture and the architect become more relevant in an AI-driven world, not less.
‍

Review and insights

We agreed with the author's destination and questioned his map. Here are the themes that came up.

The word "architecture" is doing too much work. The article puts the schematic, the rules, the guidelines, and the implementation conventions all under one label. We see those as different things. Architecture is the schematic: the components, what each is responsible for, how they talk to each other. The constraints are the definitions of what to adhere to inside it. Collapsing them hides where the real shift is, because the part that is growing is not the schematic. It is everything underneath it.

What is changing is how much you have to write down. This is the heart of it. What the author is trying to define is that architecture went from something humans use to communicate how a system needs to be built, without going deep on what exactly to build inside it, to something that for an AI needs to be that plus a whole set of rules, implementation guidelines, and regulations on how to build those components and how they interact. A human reading a blueprint fills the gaps with experience. An agent fills them to reach the goal, which is not the same thing. So the architect now writes the gaps down, producing more detail than before, not less. The building analogy works against the author here: a real architect designs the floors, not which concrete or rebar to use, yet for AI-native work you now hand over something closer to a bill of materials.

The compounding upside. Written deep enough, these layers pay off. Separate the project-specific level from the reusable implementation level and the rule sets carry across projects of similar complexity. Context compounds, and each engagement leaves less design work to redo on the next.

The article is half right and half blind. It assumes every system is a greenfield with abundant context. Most enterprise software is not. A legacy project usually has only a schematic that has not been updated in years, with everything built since living in the code itself. Before an agent can safely touch it, you have to establish the status quo and rebuild the constraint layer on top. The exercise the author describes for a clean build has to be done from scratch first, and that first step is the hard one. This is also why rebuild is not the default. The application is rarely the problem; the integration environment around it is. It is never one component, and that is what makes an environment both robust and hard to upgrade.

Generating output got cheap. Validating it did not. The author says the bottleneck moved from writing code to understanding it. We would push further: validation is now the hardest task, and more generated output makes you more blind, not faster. We have watched agents satisfy a test by returning exactly what it expected while skipping the real integration, drop test-driven development partway through a run and report themselves done, and update documentation with only the latest change. The response has been check agents reviewing implementation agents, with a human still rechecking. It works, but it is a real cost that architecture now has to account for, including how the agents communicate and what they are allowed to install, since an unconstrained agent will pull in whatever it needs to finish the job.

The link to modernization

The reason this matters for modernization is that the author's model assumes the one thing legacy environments do not have: current, machine-readable context. AI-native development is being designed for a present that most enterprises do not live in yet. The work of getting a real system into a state where agents can operate on it safely, mapping what is actually running, rebuilding the constraint layer, and accounting for the integration environment around it, is the same modernization work it has always been. It does not get faster because an agent is in the room. If anything, the agent raises the bar on how clearly that context has to be written down.

Concluding remarks

We end up agreeing with the author's main conclusion. Architecture and the architect become more relevant in an AI-driven world, not less, because somebody has to stay in the driver's seat and take responsibility for output that is now cheap to generate and hard to trust. Where we differ is on what the job becomes. It is not that architecture turns into a vague regulator. It is that the architect's expertise moves down into a deeper, written layer of rules and constraints, expressed in natural language, that an agent can follow. That is true for new products, where you get to write those layers cleanly and reuse them. And it is true, with much more upfront effort, for the legacy systems where the context has to be rebuilt before any of this works at all.

‍

Full video episode: The AI software modernization ideals vs the enterprise reality

The first step to start your modernization journey

Software modernization and architectural rebuilds lie at the heart of Eli5. We solve complexity to deliver direct business value by focusing on pragmatic, cloud-native transitions.

Before you decide whether to wrap your legacy system, buy a new SaaS product, or use AI to build custom tools, you need total visibility into your current tech landscape.

Would you like to book a free brainstorm to discuss your legacy stack? It is the essential first step to turning your technical debt into a scalable, modular future.

‍

‍

‍