/ Developer / Your agent writes the code. You still own the architecture

Your agent writes the code. You still own the architecture

Code Quality Team
Code Quality Team Oct 22, 2026 / 56 min read

Episode 6

Link: https://thenextcommit.substack.com/p/episode-six-matt-erman?utm_campaign=post-expanded-share&utm_medium=web

When an agent generates an implementation at speed, it is easy to forget that responsibility for a coherent architecture still belongs to the developer. Matt Erman explains why that responsibility is as important as ever. Agents know an enormous range of architectural patterns, but without sufficient constraints they can combine valid ideas into a system that works while becoming progressively harder to maintain.

Matt treats architecture as a repeatable process rather than a catalogue of patterns. He explains how evidence-led investigation, engineering guidance and small verified phases constrain his agent workflow; why architectural fundamentals matter more as implementation accelerates; and how fitness functions operate twice, first as an executable specification that guides the agent and then as deterministic verification of the result.

About Kesha

Matt Erman is a senior software engineer at Blackboard, LLC, and the author of Grokking Software Architecture, a practical introduction for developers and aspiring architects published through Manning’s Early Access Program. His work focuses on architectural decision-making, agent-assisted development and the verification systems needed to keep rapidly generated software within deliberate technical boundaries.

In this episode

  • 00:34 – Introducing Matt and Grokking Software Architecture
  • 01:19 – Treating AI agents as a first-class architectural concern
  • 02:19 – Matt’s coding-agent setup and whole-workspace context
  • 04:23 – Adapting specification-driven development for agents
  • 06:18 – Skills, hooks, fitness functions and evidence-led investigation
  • 08:22 – Why AI agents can be “too smart” without architectural constraints
  • 09:30 – Why human code review cannot scale with generated output
  • 11:25 – Protecting architectural boundaries with fitness functions
  • 13:36 – What an architectural fitness function tests
  • 15:52 – The “-ilities” that architecture must preserve
  • 16:59 – Architecture as a responsibility shared across the team
  • 20:47 – Trust the verification system, not the agent
  • 21:45 – Planning work as small phases and commit boundaries
  • 24:31 – How incremental checkpoints confine failures
  • 25:51 – Reading fitness functions as an executable specification
  • 27:22 – Refactoring, rewriting and the limits of the strangler fig pattern
  • 30:39 – Why agents move engineers towards design and architectural judgement
  • 32:35 – Pair development for consequential decisions
  • 33:49 – What new developers need to learn in an agentic world
  • 36:07 – Architecture as a repeatable process of asking better questions
  • 37:54 – Architectural awareness, alignment and accountability
  • 41:33 – Engineers move towards end-to-end ownership
  • 44:15 – The book’s progress and the Clean-CTX project
  • 46:56 – Why agents may not need human-readable source code as context

Key ideas

  • An unconstrained agent can combine valid patterns into an incoherent system. Architectural boundaries narrow the solution space so its broad knowledge becomes useful rather than chaotic.
  • Human review does not scale simply by adding more reviewers. As generated output grows, fatigue and attention become failure modes, so the scalable investment is the automated feedback loop around the agent.
  • Architectural fitness functions test structural rules that unit and integration tests often miss, such as dependency direction, layer boundaries and prohibited database access.
  • A significant escaped defect should improve the system that allowed it through. Recording the invariant and adding a regression check gives both people and agents durable evidence about the boundary.
  • Fitness functions can serve two roles: they reject violations after implementation and act as an executable specification that shapes the agent’s plan before coding begins.
  • Large tasks should be split into independently verified phases with clean commit boundaries. When a regression appears, the team can confine its cause to the latest increment instead of reconstructing one enormous change.
  • Architecture is not a title or a single high-level decision. Every change to a class, dependency, table or service is an architectural decision made at a different scope.
  • As agents take on implementation, engineers must exercise their existing responsibility for intent, constraints, trade-offs, design and evidence more deliberately. Strong fundamentals provide a repeatable way to ask the right questions when the technology changes.
  • Architectural growth moves from awareness of a change’s wider effects, through alignment with the system and its rationale, to accountability earned through consistently sound decisions.

People and links

Tools mentioned