There are two reasons to change software: to make it do something new, and to keep it doing what it already does. Most conversations about coding agents focus on the first. The second is where most engineering budgets quietly disappear, and it's the subject of this article.
This is Part 4 of our series on Chris Ford's O'Reilly Early Release book Agentic Engineering at Scale. Parts 1, 2 and 3 covered the harness framework, reverse engineering and spec-driven development. This piece is about staying fit for purpose once a system is live — and why coding agents change the calculus more than most teams have registered.
The Red Queen problem
Software with real business value is coupled to a world that keeps moving: tax rates, regulation, market expectations, the libraries it depends on, the cloud APIs it calls. None of that holds still. A system that was well-architected for 2019 isn't automatically well-architected for 2026 — not because anyone did anything wrong, but because its context moved and the system, by construction, didn't move with it.
Lewis Carroll's Red Queen put it better than any engineering textbook has managed since: "It takes all the running you can do, to keep in the same place." The book calls the compensating work software homeostasis — the change a system needs just to keep its actual behaviour aligned with its intent as the ground underneath it shifts.
This is a genuinely different thing from refactoring. Refactoring, in Martin Fowler's original sense, preserves observable behaviour while improving internal design — if you can detect a difference from outside the component, it isn't refactoring. Homeostasis is the opposite kind of constant: it doesn't promise the same observable behaviour — your latency profile, your security posture, your scaling characteristics can and should change — what it holds constant is intent. The system keeps doing its job even though almost everything about how it does that job has moved.
Why organisations under-invest in this, structurally
If homeostatic work is this important, why do so many South African organisations we work with still find themselves facing a full platform replacement instead of a string of smaller corrective changes?
Two structural reasons, both worth naming honestly:
First, paying down technical drift is an indirect payoff. It doesn't show up as a feature the business asked for. It shows up, eventually, as the absence of an outage, or the presence of a migration that didn't take six months longer than planned. That's a hard case to make in a budget meeting against a competing feature request with a visible revenue number attached.
Second, the cost profile is genuinely uneven. Mary and Tom Poppendieck's observation from Lean Software Development still holds: "not all change is equal." Foundational decisions — language choice, how you layer your architecture, whether multiple services share a database — carry what they estimated as roughly a 100-to-1 cost escalation between making the decision well early and unwinding it later. Teams rationally avoid touching those decisions, because touching them has historically been enormously expensive. Cheap, easy fixes get made. Expensive, structural ones get deferred indefinitely, and deferred debt compounds.
What coding agents actually change
Here's the honest version, not the hype version: coding agents don't make every kind of change cheap. They change which decisions are cheap, and understanding the difference is the whole game.
The book gives a useful two-axis way to think about any technical change you're facing.
Local versus distributed. A local change is contained — you can validate it against the purpose of one function, module or file, with no cascading consequences elsewhere. A distributed change ripples outward — think a magic number for VAT scattered across forty files instead of one constant, or a language migration that touches everything. Local changes are forgiving, for humans and agents alike. Distributed changes require far more context to make correctly and far more context to verify.
Mechanical versus interpretive. A mechanical change can be done by deterministic tooling — an IDE rename, a codemod, a language-server refactor — and if the tool completes without error, the change is correct by construction. An interpretive change requires judgement about what the new structure should actually look like, and running it twice might produce two different (both individually defensible) answers.
If you can make a change mechanically, do that — with or without an agent in the loop to orchestrate the tool. Coding agents are genuinely valuable for the interpretive, judgement-heavy changes that used to require a coordinated human effort across a team, but they're context-bound: they're noticeably better at a queue of individually cheap, well-scoped decisions than at one holistic, sprawling decision that requires reasoning across the whole system at once.
That's the real shift: non-local, interpretive change has gotten cheaper — but only for systems designed so that it can be decomposed into a queue of context-cheap decisions. A poorly modularised system doesn't get this benefit for free. It has to earn it through the same modularity discipline that's been good architectural practice for thirty years — information hiding, clear interfaces, things that change together living together.
The architect's job has moved
If Poppendieck's foundational decisions used to carry a 100-to-1 cost escalation, and coding agents lower that cost for a meaningful subset of them, the practical implication is that the last responsible moment — the point at which you actually have to commit to a decision — moves later for those decisions. You can defer language choices, framework choices, and some layering decisions longer than you used to, because reversing them is no longer automatically catastrophic.
Not every decision gets this treatment. Data formats, public API contracts, security models, and database-level persistence schemas still propagate without an easy, cheap way to reverse them. Those remain genuinely high-stakes, agents or not.
What follows is a real change in what "good architecture" means day to day. The job used to be mostly about getting foundational decisions right the first time, because getting them wrong was so expensive to fix. Increasingly, the job is about making those decisions revisable at low cost — designing boundaries and modularity so that when (not if) a decision needs to change, that change can be a queue of local, context-cheap edits instead of a company-wide six-month programme.
Two patterns worth deliberately designing for, both borrowed from architecture that already worked before agents existed:
- The strangler fig — grow the replacement around the old system, routing functionality across slice by slice, with the old system as a live fallback until each slice is proven. Coding agents improve the economics here specifically because each slice is what the book calls an "after-dinner mint": stable, well-defined interfaces to the outside (the brown edge), full freedom to regenerate on the inside (the green centre) — exactly the shape agents handle best.
- Plug-in and extension architectures — CMSes, browsers, IDEs and mobile platforms have all converged on this pattern for a reason: it makes the unit of modularity also the unit of deletion. Microservices promised this and rarely fully deliver it in practice; extension systems, empirically, do.
Practical starting points
For most of the platform engineering and DevSecOps work we do locally, this translates into a short, honest set of questions worth asking about any system carrying real technical debt:
- Which of our foundational decisions are actually still expensive to reverse, versus which ones we've just assumed are expensive because they always used to be?
- Where is our modularity strong enough that a coding agent could safely make a distributed change as a queue of local edits — and where would it have to reason across the whole system at once to get it right?
- Are we treating homeostatic work as a line item with a business case, or hoping it happens as a side effect of feature work? (It rarely does.)
- Do we have the Checks — tests, characterisation tests, backtests against real production traffic — that would let us trust an agent-generated change without a slow, manual review of everything it touched?
None of this is exotic. It's the same engineering discipline that's always mattered — modularity, clear interfaces, deferring commitment until you actually need to make it — applied with a sharper understanding of exactly which parts of that discipline coding agents now make cheaper to sustain.
How CloudNala can help
CloudNala helps teams work out which technical debt is genuinely urgent, which is safe to defer, and how to structure the modernisation work so coding agents can carry more of the load — without turning a manageable backlog into an unplanned rewrite.
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.
Assess My Technical Debt or write to us at consult@cloudnala.co.za