The Software Architect in the Age of AI-Enabled Engineering

Software architecture has always been shaped by scarcity.

When changing software was expensive, experienced engineers spent considerable effort deciding what should be built before committing teams to implementation. Architects designed components, interfaces, deployment models and technology choices partly because implementation mistakes were costly to discover and unwind.

AI is changing that economic equation.

We are moving quickly from coding copilots toward agents that can explore codebases, propose plans, modify multiple files, generate tests, run tools, diagnose failures and iterate on their own work. Google’s experience with AI-assisted engineering already shows the direction of travel: software engineers increasingly review and direct machine-generated implementation rather than manually producing every line themselves.

That raises an uncomfortable question for software architects. If implementation becomes progressively cheaper, what happens to architecture?

The obvious answer is that architects will still be needed because AI sometimes produces poor code. I think that is the wrong argument. AI-generated code will improve. In controlled research, even vendor-sponsored studies such as GitHub’s work on Copilot and code quality already provide evidence that AI assistance can produce perfectly respectable implementation.

The more interesting question is what happens even if AI eventually produces excellent code.

Because excellent code is a local property.

An excellent system is a systemic property.

When implementation stops being scarce

Software engineering is progressing from autocomplete to copilots, conversational assistants and increasingly agentic systems that can plan, implement, test and revise software. As Martin Fowler describes in agentic programming, developers increasingly direct and evaluate agents rather than manually producing every implementation step.

This changes what is scarce.

Generating code, prototypes and implementation alternatives becomes easier. But deciding whether a solution fits an organization’s regulatory constraints, operating model, platform strategy, economics and long-term direction does not become proportionately easier.

As implementation becomes abundant, judgment becomes relatively more valuable.

For architects, the shift is therefore not simply away from code. It is from designing individual implementations toward designing the decision environment in which implementations are created.

Architecture was never really about the diagram

This distinction becomes clearer when architecture is separated from some of its traditional artefacts. Architecture is often represented through diagrams, reference architectures, standards and review documents. But these are representations of architecture, not architecture itself.

Architecture exists in consequential decisions:

• where system boundaries are drawn;
• which dependencies are allowed;
• where consistency is required and where eventual consistency is acceptable;
• which failures must be tolerated;
• what data may cross which jurisdictions;
• how much complexity is acceptable;
• where teams can act independently;
• and which quality attributes matter enough to constrain other choices.

Research from the Carnegie Mellon Software Engineering Institute on GenAI and software architecting provides a useful way of thinking about this. Generative AI is well suited to activities such as generating alternatives, summarising information, applying known patterns and helping prepare architectural artefacts. It becomes less reliable as architectural work depends on system-specific context, interacting decisions, stakeholder priorities and trade-offs between competing quality attributes.

This is not evidence that AI will never perform these activities. Today’s limitations should not be mistaken for permanent human advantages. But it highlights something more fundamental. The difficult part of architecture is rarely knowing that several valid patterns exist.

The difficult part is deciding which consequences this organization is willing to live with.

The danger of invisible architecture

Agentic engineering introduces another problem. When a developer writes software manually, many design decisions remain visible simply because the engineer has to think through them. An agent can compress that process dramatically. Give an agent a requirement and it may choose abstractions, introduce libraries, define interfaces, create persistence models, establish dependencies and distribute responsibilities across components—all while apparently completing a single implementation task.

The result may work.

But architecture has happened.

The Design-First Collaboration discussion from Thoughtworks highlights this risk: AI assistants can move rapidly from a requirement to implementation while silently embedding design decisions that were never separately examined.

The danger of AI-assisted engineering therefore isn’t only bad code. It is invisible architecture.

Not every implementation decision deserves architectural ceremony. Trying to approve everything centrally would destroy the very autonomy AI can create. The useful distinction is consequence and reversibility. The more difficult a decision is to reverse—and the wider its potential impact—the more explicitly it should be surfaced.

Future coding agents may therefore need to do more than generate code. For consequential changes, they may need to expose:

• architectural decisions they intend to make;
• constraints affected by those decisions;
• alternatives considered;
• expected quality-attribute consequences;
• exceptions required;
• and rationale worth preserving.

This is architecture as decision provenance, not architecture as documentation after the fact.

Architecture becomes context for machines

AI agents cannot follow architectural intent they cannot access. Today that intent is often fragmented across ADRs, standards, wikis, diagrams, repositories and people’s heads. That was already inefficient for humans; it becomes a larger problem when machines begin making engineering decisions.

Work on context engineering for coding agents and Google’s research on desired agent behaviour both point toward the importance of explicit standards, processes and contextual guidance.

This does not mean putting every architecture document into an LLM context window. It means making architectural knowledge structured, current, scoped, discoverable, versioned and, where practical, executable.

Architecture documentation may not become more important. Architecture knowledge does—and its audience increasingly includes machines as well as humans.

Generation velocity requires validation velocity

There is an important operational consequence. DORA’s 2025 research describes AI as an amplifier of the engineering environment around it rather than a technology that automatically improves delivery outcomes. That matters because AI can accelerate implementation while exposing bottlenecks in review, testing, integration, deployment, security and tightly coupled architecture.

If software-generation capacity rises while governance still depends on periodic manual reviews, governance becomes the bottleneck.

Generation velocity must therefore be matched by validation velocity.

That increases the importance of architecture fitness functions, policy-as-code, automated dependency and security checks, contract validation, resilience testing and platform guardrails. It also increases the importance of platform engineering. A good internal platform does not merely make infrastructure easier to consume. It encodes accumulated engineering judgment into paved roads: approved deployment patterns, observability, security defaults, operational standards and reusable capabilities.

This is where the role of the architect begins to change substantially. Instead of reviewing the same architectural concern repeatedly, the architect can help convert the decision into an environment where the compliant path is the easiest path. A recurring architectural judgment can become:

lesson → principle → constraint → automated validation → inherited behaviour

The scalable form of architectural judgment is therefore not repeated human review.

It is judgment converted into engineering structure.

From gates to guardrails

This suggests a different operating model for architecture.

Traditional activity	AI-enabled direction	Emerging architectural role
Produce boilerplate architecture documentation	Increasingly automated	Curate architectural intent and decision-relevant views
Research patterns and technologies	Strongly AI-assisted	Evaluate strategic fit, ecosystem risk and organizational consequences
Define code-level designs	Increasingly agentic	Define boundaries, constraints and architectural invariants
Review every solution	Routine checks automated	Focus on exceptions, uncertainty and difficult-to-reverse decisions
Publish standards	Standards increasingly executable	Design and evolve guardrails
Maintain architecture repositories	Machines become consumers	Engineer trustworthy architectural context
Assess quality attributes	AI assists analysis	Own prioritisation and trade-off decisions
Model business domains	AI assists modelling	Align business meaning, ownership and system boundaries
Govern platform usage	Platforms encode decisions	Create safe defaults for autonomous engineering
Review implementation conformance	Continuous automation	Build architectural fitness functions and observability
Manage coding-agent behaviour	New responsibility	Define agent decision rights, escalation boundaries and constraints
Preserve design rationale	Increasingly important	Maintain decision provenance across human and AI-generated change

This is not an argument for more centralized architecture. In fact, the opposite may be necessary.

As agents increase engineering capacity, centralized decision-making becomes even less scalable. Architects need to design constraints within which teams and agents can make more decisions autonomously.

Guardrails rather than gates. But guardrails create their own danger. A bad architectural rule encoded into automation can be enforced at machine speed too.

Executable architecture therefore needs ownership, observability, versioning, exceptions and retirement mechanisms. The goal is not to freeze architecture. It is to make architectural intent capable of evolving safely.

Domain and socio-technical architecture matter more

AI also changes the relative value of technical knowledge. Generic technology knowledge becomes easier to obtain. An agent can explain the trade-offs between message brokers, generate Kubernetes configurations, compare database technologies and propose several caching strategies in seconds. Knowing the options is no longer the differentiator it once was.

Knowing what matters here becomes more important.

Architecture requires understanding business capabilities, domain boundaries, regulatory obligations, operational realities and organizational structure. A locally elegant implementation can still create a globally incoherent system. A technically sensible service boundary may be disastrous if three teams must coordinate every time it changes. A highly scalable design may be economically irrational. A theoretically clean platform architecture may fail because the organization does not possess the operating capabilities required to sustain it.

These are socio-technical questions.

DORA’s emphasis on platforms, loosely coupled architectures, feedback systems and the broader engineering environment reinforces the idea that AI outcomes depend heavily on organizational and architectural conditions, not simply model capability. AI may therefore make one of architecture’s oldest lessons more visible:

systems inherit the structure, constraints and incentives of the organizations that build and operate them.

The future software architect needs to reason across both sides of that equation.

Architecture as search-space design

There is another way to think about this transformation. An unconstrained AI agent has an enormous space of technically plausible choices. Good architecture reduces that space. A domain boundary eliminates inappropriate dependencies. A platform eliminates unnecessary infrastructure decisions. An approved technology portfolio removes irrelevant technology choices. An API standard eliminates multiple incompatible interface styles. A security policy prevents unsafe implementation paths. A quality-attribute requirement tells an agent which trade-offs matter.

Architecture therefore increasingly acts as search-space design.

The architect does not need to make every implementation decision. The architect helps shape the environment so that teams and agents face fewer bad decisions in the first place. That may be one of the highest-leverage forms of architecture in an AI-enabled engineering organization.

So does the software architect disappear?

Perhaps parts of the role should.

Architects who primarily create diagrams, manually research technology alternatives, produce boilerplate documentation or act as approval gates should expect substantial automation. Some architectural work may migrate into engineering teams. Some may be embodied in platforms. Some may be performed by AI.

That does not mean architecture becomes less important.

It means we need to stop equating architecture with the activities architects happened to perform when implementation was expensive. As software creation becomes increasingly automated, architectural value moves elsewhere: toward context, constraints, trade-offs, quality attributes, domain boundaries, platform capabilities, decision provenance and socio-technical coherence.

The architect’s highest leverage may no longer come from designing every solution. It may come from designing the environment in which thousands of good design decisions can be made safely—by humans and machines alike.

AI makes implementation abundant. It does not automatically make systems coherent.

And as implementation becomes abundant, coherence becomes scarce.