Skip to content
Back to Blog

The Software Architect in the Agentic Era: Designing Boundaries Agents Can't Cross

AI Transformation Lead
  • AIDLC
  • Software Architecture
  • Agentic
  • AI Engineering
  • Software Lifecycle
  • System Design

The architect's leverage moved from drawing the design to building the constraints that make agent-generated code safe. Speed is no longer the problem; an agent will produce the wrong abstraction fast, so the architect's job is the scaffold, contracts, and boundaries the agent physically cannot cross.

Abstract monochrome visualization of structural boundaries and contracts constraining flowing geometric forms into an ordered architecture

The architect used to be the person with the whiteboard. Boxes, arrows, a sequence diagram, a decision record, then weeks of engineers turning that design into code while the architect reviewed pull requests and corrected drift.

Agents compressed the middle of that into hours. And in doing so they exposed an uncomfortable truth: a beautiful diagram does nothing to stop a coding agent from generating the wrong abstraction at high speed.

From drawing the design to enforcing it

Speed is not the architect's problem anymore. Constraint is. An agent will happily produce a tangled module, a leaky boundary, or a clever shortcut that quietly breaks an invariant, and it will do it faster than any human could review.

So the architect's leverage moved from producing the design to making the design unbreakable. In the AIDLC method this is the Scaffold phase, and it comes before a single feature is generated. Repo conventions, type contracts, module boundaries, and the eval harness all stand up first, so the agent generates inside a structure that already enforces the rules rather than inventing its own.

A well-designed scaffold is worth more than a well-drawn diagram, because the scaffold is load-bearing. The agent cannot ignore a type error. It can ignore a Confluence page.

The new architectural decisions

Where do the boundaries sit so an agent cannot leak state across them? Which contracts are typed strictly enough that a violation fails the build? What does the smallest runnable surface look like so the first generated slice proves the structure works? These are the questions that now define the role.

The architect also owns a question that barely existed before: what behaviour must the eval suite guard so the agent stays inside the boundary as it iterates? Design and verification stopped being separate disciplines.

If your architecture still lives in diagrams while your team generates code with agents, the gap between intent and output is where your bugs come from. Closing it is what AIDLC is built to do.

The architects who win

They write contracts, not just diagrams. They build the scaffold first. They treat the eval harness as part of the architecture. And they measure their work by how little the agent can do wrong, not by how elegant the picture looks.

Questions about this piece

Follow-ups readers ask most often about the argument above.

  • Agents can generate an entire module in minutes, including the wrong abstraction. The architect's leverage shifts from producing designs to designing the constraints that make agent output safe: type contracts, module boundaries, the scaffold, and the eval harness. In Pooya Golchian's AIDLC method this is the Scaffold phase, built before any feature code exists.

  • Agents work best inside a structure that already enforces the rules. If conventions, type contracts, and the eval harness exist first, the agent generates against guardrails instead of inventing its own. Standing up that scaffold early is the highest-leverage architectural decision in the AIDLC lifecycle.

  • The scaffold. A diagram cannot stop a coding agent from generating the wrong abstraction at speed, but a typed scaffold can: the agent cannot ignore a type error or a failing build. In AIDLC the architect's design becomes load-bearing only when it is enforced by code, not drawn on a whiteboard.

  • Where boundaries sit so an agent cannot leak state across them, which contracts are strict enough that a violation fails the build, what the smallest runnable surface looks like, and which behaviours the eval suite must guard. Pooya Golchian treats design and verification as one discipline in agentic architecture.