The suggestion came from a capable engineer on the new supplier development team at the fictional Magaliesberg Provincial Supplier Desk. "Coding agents can scaffold a whole service in an afternoon now," she said. "The cost argument against microservices was about writing all that plumbing. If the agent writes it, why not give every module its own service and get the independence for free?"
It was a fair question, and Thabo Molefe did not dismiss it. He opened the ledger from Part 6 and asked her to mark every line an agent would make cheaper. She marked two: writing pipeline definitions and writing contract tests. The minimum instances, the observability bill, the certificates, the on-call rota, the environments that had to stay in step and the incidents at 02:00 stayed exactly where they were.
The Magaliesberg Provincial Supplier Desk is a fictional provincial supplier-support platform. Its people, systems and figures are illustrative. This final part looks at what coding agents change about the architecture choice, and what they do not.
Cheaper code, unchanged operations
Most of the distributed-systems tax is not code. It is running, observing, protecting and owning software. Coding agents reduce the cost of producing the code part. They do not reduce, and often increase, the cost of the rest, because more code produced faster means more to review, operate and understand.
That shifts the balance in a direction many people do not expect. When writing code was the main cost, the operational premium of a distributed design was a smaller share of the total. As writing code gets cheaper, the operational premium becomes a larger share. An architecture that must earn its complexity has to earn it against a bill that is now dominated by operations.
Claims about agent productivity themselves need care. METR's randomised controlled trial published in July 2025 found that 16 experienced open-source developers took 19% longer on their own repositories when AI tools were allowed, while believing they had been faster. METR stated clearly that the result was a snapshot of one setting and did not show that AI slows developers in general, and its page now notes that those results are out of date (checked on 5 November 2026). METR's February 2026 update, covering 57 developers, estimated that returning developers were about 18% faster with AI (95% confidence interval from 38% faster to 9% slower) and new recruits about 4% faster (from 15% faster to 9% slower), but METR called its data "only very weak evidence" because of selection effects and is redesigning the study. The lesson for architects is not that agents are slow or fast. It is that productivity evidence is moving quickly, while the architecture you choose will be operated for years. Do not choose a structure on the strength of a productivity claim.
Agents amplify the structure they are given
A coding agent works inside a context: the files it can see, the instructions it is given and the checks that run on its output. The architecture largely determines that context.
In a well-bounded modular monolith, a task can be scoped to one module. The agent sees the module's internals, its contract and the contracts it is allowed to call. The fitness functions from Part 8 reject any change that reaches into another module. The agent's context is small and relevant, which tends to produce better changes, and the boundary holds even when the agent would prefer a shortcut.
In a monolith with folders but no enforced boundaries, the same agent can see and use everything. If the quickest way to finish the task is to query another module's table, nothing stops it. Boundary erosion that took a human team years can happen in weeks, one plausible pull request at a time.
In a sprawl of services, the agent faces the opposite problem. A change that crosses three services needs three coordinated pull requests, compatible contract versions and a deployment order. Agents can draft all of that, but every one of those artefacts is something people must review and operate. And because scaffolding a new service is now cheap, the number of services can grow faster than the number of owners, which is the organisational failure described in Part 5.
The pattern is the same in all three cases. Agents do not choose good or bad architecture. They make whichever architecture you have move faster.
Two new failure modes
The Supplier Desk named the two ways agents could hurt its architecture.
Erosion at speed. An agent working on a task in Cases finds that the Documents contract lacks an operation it needs. It adds a direct reference to a Documents internal class. The build would once have accepted that. With structure fitness functions in place, the build rejects it, and the agent's output either adds a proper contract operation in Documents, which needs the Documents owner's review, or stops and reports the gap.
Sprawl at speed. An agent asked to "improve the performance of supplier development" proposes a new caching service, with its own deployment, infrastructure code and pipeline. The code is good. The proposal skips the evidence gate entirely. Our Agents on the Night Shift episode describes how a team discovered this kind of operating bill in a morning review. The Supplier Desk's answer is the same in principle, applied as a standing rule rather than a lesson learnt.
Five rules for agents in the Supplier Desk codebase
- Scope agent tasks to a module. Every agent task names one module it may change. The module has its own instruction file describing its contract, its owned data and the dependencies it may use. A task that needs changes in two modules is split, or done by a person.
- Run the same fitness functions on agent changes as on human changes. No separate, weaker path. The structural and contract checks run on every pull request whoever wrote it, and a failure blocks the merge.
- Agents may draft architecture evidence; people decide. An agent can draft the evidence gate from Part 1, the call conversion register from Part 3 and the tax ledger from Part 6, but the decision and the owner named in it belong to the people who will run the result.
- No new deployable unit without a decision record. Agent tasks may not create new services, databases, queues or pipelines. Repository permissions, infrastructure policy and, since the gap described below, a fitness function enforce this, not instructions alone.
- Measure what agents do to the boundaries. The team tracks how often agent pull requests trigger fitness function failures, by module and by rule. A rising rate on one module usually means its contract is missing something people and agents both need.
These rules sit inside the wider delivery controls described in Claude, Codex and Copilot are tools inside a delivery system and Harness engineering has grown up. The architecture-specific point is that module boundaries, contracts and fitness functions are part of the agent's harness. A well-bounded system gives agents a smaller, clearer world to work in.
Where agents genuinely change the economics
Agents do shift some parts of the decision, and it is worth being precise about which.
| Activity | Effect of coding agents | Architecture consequence |
|---|---|---|
| Writing module code and tests | Cheaper | Modular structure is easier to maintain |
| Adding a contract operation | Cheaper | Less temptation to reach into internals |
| Drafting fitness functions | Cheaper | Enforcement is easier to adopt early |
| Drafting extraction code (seams, clients) | Cheaper | Stages 1 and 2 of an extraction go faster |
| Shadow running, cohort cut-over, retirement | Unchanged | Extraction calendar time is mostly evidence gathering |
| Running, observing and securing services | Unchanged or higher | Each new service costs the same to operate |
| Owning and understanding services | Harder if code grows faster than understanding | Cognitive load becomes the binding constraint |
Read together, the table supports the series' default rather than overturning it. Agents make a modular monolith cheaper to keep healthy and make a well-prepared extraction quicker to code. They do nothing to make an unjustified service cheaper to run.
Answering the engineer's question
Thabo's reply to the supplier development engineer was not "no". It was a proposal. Use agents to strengthen the supplier development module: write its contract tests, draft the fitness functions for its boundaries, and keep its documentation current. If supplier development later shows evidence for its own deployment, use agents to draft the evidence gate, the ledger and the seam. Then let the team decide with the numbers in front of it.
She took the proposal, and three months later wrote a fitness function for a gap the existing checks missed: an agent task had added a new queue definition and a pipeline file inside the supplier development module, which no structural or schema rule looked at. The new check fails any pull request that adds infrastructure for a deployable unit without a linked decision record. The figures and events are illustrative. The sequence is the one this series recommends: boundaries first, evidence before extraction, and automated enforcement that applies to every contributor, human or not.
Key points
- Coding agents make code cheaper to write, not systems cheaper to run; the operational premium of distribution becomes a larger share of the cost.
- Agents amplify the structure they are given: clear modules get easier to change, loose boundaries erode or sprawl faster.
- Scope agent tasks to one module, and run the same fitness functions on agent and human changes.
- Agents may draft the evidence gate, call register and ledger; people decide and own the result.
- Do not choose an architecture on the strength of a productivity claim; the evidence is moving faster than the system's lifespan.
This is the final part of Architecture Must Earn Its Complexity. For the wider discipline of keeping a codebase healthy when code is cheap, read Keeping systems fit.
How CloudNala can help
CloudNala helps teams introduce coding agents into codebases without losing architectural control. We scope agent tasks to module boundaries, write module instruction files, put the same fitness functions in front of agent and human changes, and set the permissions that keep new deployable units behind a decision record, so that agents strengthen the architecture you chose rather than replacing it with the one that was quickest to generate.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Complexity Review or write to us at consult@cloudnala.co.za