Monowai

writing - ai & engineering

AI amplifies the architecture it finds

AI has no opinion on your architecture. It amplifies whatever structure it finds. Programming was the hard part for a lot of people and AI has largely solved it - not because language is the easy part, but because code is verifiable. Anyone can now experience the thrill of making software work, and that shift should be celebrated. But programming was never the whole of engineering. Delegating the disciplines before the constraints are written down is an optimistic strategy: it produces the illusion of rapid delivery and no signal when it is wrong. Two questions survive delegation: which business capability is being fulfilled, and how that function operates at runtime.

Mike Holdsworth · Singapore

Point an AI agent at a codebase with rigorous boundaries, explicit contracts and a robust pipeline that fails when it should, and delivery moves predictably. Point it at a tangle and you get more tangle, faster, in more styles than you ever wanted. Where no structure exists to amplify, an agent happily invents a fresh one per prompt, occasionally sliding an entire unvetted tech stack into your organisation.

An agent is probabilistic. Delivery needs to be deterministic. What sits between them is the context you supply.

That is what I took away from APIDays Bangalore. The hallway track was confident that AI will close that gap through loop engineering or specialised harnesses. They are not wrong about the mechanism - I have built one of those harnesses, and it works. Yet I have watched a team vibe a business capability into existence: the demo looked great, but nothing shipped. It was too slow, too tricky to test and too expensive to put into production. Engineering is far more than rapid feature development. Each feature requires many disciplines, and if you don't ask, AI won't offer.

I am an optimist about AI - as a tool. Agents will take real work off teams, and some of it should go today. What I don't accept is the sequencing on offer: delegate now, bank the velocity this quarter, then leave the resulting ball of mud with engineers to clean up later - without budget, without an architecture decision record, and often without the people who authorised it still on the project. Responsibility delegates. Accountability does not. You can hand an agent the work. You cannot hand it the accountability for what the work did to your system.

AI answers the questions you ask

Turning intent into syntax that compiles is a solved problem now. It works because code is checkable - the compiler, the types and the tests tell the model when it is wrong, and it iterates against that. The feedback loop is not a property of language. It is manufactured, by the disciplines listed below. If our jobs were purely about programming, we would be done and I'd be off to go diving. But it is transformative, and I'd encourage anyone to give it a go - it will let any product manager prototype in an afternoon.

We don't deploy prototypes to production. Engineering a feature means answering questions a prototype never had to:

  • Linting - enforced, or advisory?
  • Mono repo or multi repo - what did that choice cost the next team?
  • Pipeline - does it fail when it should?
  • Tests - written first, or generated after to agree with the code?
  • Design patterns - which ones let it scale past the demo?
  • Telemetry - wired in before first deploy, or after the first incident?

AI does not pose the questions you did not think to ask. It answers the ones you did, probabilistically, from patterns it was trained on. Consider my async broker reference implementation - lightweight asynchronous handoffs backed with distributed tracing. A prototype will never need that. An engineer with an eye on production will. Pair the product manager with the engineer and the afternoon prototype might be in production inside the week. The engineer is not there to type. They are there to ask what the prompt did not. That distinction is the whole job.

The median architecture

What you get when you don't ask is the median. The internet is authored - every page had someone behind it making a call. Training keeps the words and loses the decisions: you can ask for any voice, you cannot ask who decided and why. Without a brief, an agent writes the most likely book.

Median answers are fine for a spike, and for most code, which is not where operational risk lives. What it will not give you is the relationship between the pieces. The median answer is not an architecture. An architecture is a set of capabilities and the constraints - what the system can do and how it does it. The median gives you the first and almost none of the second. The same holds when something breaks: a stack trace gets you the median explanation, not necessarily the one for your system.

Design decisions haven't disappeared because typing got cheap - they've moved into the prompt, and the code repository, which is now the strongest signal the model has about what "good" looks like. Your existing, or accidental, architecture is your style guide, whether you wrote it down or not.

At the APIDays Bangalore unconference, Giles Edwards-Alexander put a number on this. He refactored a 17,000-line Rust data access layer in 15 steps, measuring the token cost of the same feature change at each one. Input tokens fell from 159k to 27k - an 83% saving, for a task that did not change. One refactor is not a law, but the number is not the interesting part. The method is. Measure the cost of the same change either side of a structural decision and you find out which boundaries pay for themselves. What the refactor bought was context: the same change in fewer, higher-signal tokens. That is context engineering done in the repository instead of the prompt. Structure stops being an aesthetic argument and becomes a line item in your architecture.

The rebuttal runs the other way: if refactoring is now this cheap, let the mess accumulate and clean it up later. It has more merit than I would like. Measurement needs a baseline, and a codebase with no boundaries has none - no comparison, and no signal to amplify but its own accidents. And cleaning up later assumes someone is still there who knows what was decided and why.

The second assumption is the weak one, and the one we know how to fix. A design decision used to leave a trace: an author, an argument, someone you could go and ask. Is that happening with your vibe-coded work?

Spec-driven development is a reasonable response, and you should be using it - write the spec, review it, version it, have the agent implement against it. That restores the artefact. Where it is versioned is a boundary decision: a spec for how one service is built belongs beside that service's code; one other teams integrate against belongs where they can find it. A spec records what was decided and rarely what was rejected, and a spec the agent generated from the prompt is output wearing an input's clothes. Both are fixable - an ADR beside the spec, a human name on the review - and neither fix arrives with the tooling. A discipline is not a feature.

What changed is the reader. A human successor could ask around, infer from the code, or track down whoever decided. An agent does none of that - it fills the gap with the median. Documentation calibrated for people who could ask underspecifies for a reader that cannot.

The MicroContext

Before you can govern the disciplines, you have to see them. At APIDays, Mehdi Medjaoui introduced the term MicroContext. Analogous to MicroServices - instead of one agent that does your job, a small agent that holds one slice of context and does one useful thing with it. Most of these are workflows rather than agents: a model inside a predefined code path, rather than one directing its own process. The predefined part is what makes them gates.

So I mapped what happens in my head when someone proposes a feature, and ran it through the contexts traced below. Each one is a context switch, and the switching is not sequential.

one feature · inside an engineer's head

where the attention went

elapsed →
  1. 1. Problem framing
  2. 2. Boundary design
  3. 3. Naming
  4. 4. Data model
  5. 5. Problem framing
  6. 6. Failure modes
  7. 7. Test design
  8. 8. Programming
  9. 9. Contract check
  10. 10. Test design
  11. 11. Programming
  12. 12. Naming
  13. 13. Security
  14. 14. Programming
  15. 15. Test design
  16. 16. Observability
  17. 17. Boundary design
  18. 18. Release gate
  19. 19. Ownership & docs
Illustration of context switching when I think about a feature. This kind of staircase is the argument. Programming is the one lane AI answers without being asked - and the one lane most of the agentic discussion is about.

Before the term existed, on my last project, I was experimenting with an OpenAPI spec review task - a feedback gate for a workflow. I wanted clean interfaces, no spelling mistakes, a sound object model, something easy to change. It took perhaps 15 days of effort to produce a harness that could tell a good spec from a bad one. Testing probabilistic outcomes is not easy. That harness was an eval before I had the word for it, and the cost holds whatever you call it: its own fixtures, its own written definition of good and bad, and a way to fail that isn't a vibe.

That harness covered a thin slice of my working week, maybe two hours: contract review across the federated integration services. What changed was where the feedback landed - submissions came back largely right first time, because the gate told the submitter what was wrong before it reached me.

The arithmetic: 15 days to save two hours a week breaks even in a bit over a year, and only if the spec format holds. As a personal productivity trade that is marginal, at best institutionalising some knowledge. It is also the wrong sum: the two hours saved were mine, and the rework the gate prevented was everyone else's.

Most of those 15 days went on the three things above - the fixtures, the written definition of good and bad, the way to fail. Those are the asset. The harness code around them was the cheap part, and the next gate does not pay for them twice. A marginal personal trade and a durable shared asset are not the same calculation at different scales; they are different calculations. As a shared asset it amplifies that slice of the job into a consistent, reusable action. And it scales up contributions to the central contract repo, letting people of varying skills work on the platform safely, because a workflow does the enforcing. Start with a well-defined problem, automate that, then take the learning somewhere larger.

That is a partial answer to the harder question: how a decision made once comes to hold for every agent in the estate, and how you know it held. A harness with an owner makes one decision hold in one place, and you know it held because the gate failed. Going from one gate to an estate of them is the open problem. It is not that the answer is unknown - it is that it needs an owner, and most shops buy their platform rather than staff one. You have seen this shape in a versioned SDK: valuable because many teams consume it, worthless the moment maintenance stops. The hallway track is right about the mechanism and wrong about the scope. A harness holds a constraint. It does not decide which constraints an organisation should have.

Nor does it reliably outlive its author, and the reason is altitude. A delivery team owns delivery. A constraint that binds every team is not theirs to hold, so it lasts exactly as long as the person who happened to care about it. A new broom sweeps clean for a reason: a gate whose definition of good was never written down cannot be inherited, only guessed at, and rebuilding is the cheaper bet. Governance of what good means sits a layer above the team implementing against it, and that is the layer where my harness never had an owner. The saving was never in the harness code. It was in the write-up, and a write-up only transfers when someone at the right altitude is accountable for it. That is the agent's failure mode run by a human: with no brief to read, they rebuild what they think worked where they came from.

Capability and function are the review

Those contexts do delegate. My spec harness held one and posted its findings as a PR comment. What does not delegate is the definition of good it checked against. An architect does not have to write what the agent wrote, and will not keep up if they try. They do have to answer two questions about it: which capability does this fulfil, and how does that function operate at runtime? Capability is what it does. Function is how it behaves while doing it, its fitness function, which is where the constraints live - the half that has to come from the brief. Neither question is answerable by reading a diff for style. An hour with the team that built it will tell you whether anyone has answered them, and the answers themselves come from evidence you can run.

The capability question is boundary work. Does this belong here, does something already do it, what does it expose to the next team, and what may it not do while doing it? Get it wrong and you have a second implementation of an existing capability with its own opinion about the data - which an agent will produce without hesitation, because nothing in the prompt told it the first one existed. Domain boundaries are how you stop paying for the same capability twice.

The function question is production work. What happens under load, what happens when the dependency it calls is down, what it costs per invocation, how you would know it was misbehaving and who gets notified when it is. That is where the broker example earns its distributed tracing, and where the vibed capability I watched fell over: too slow, too tricky to test, too expensive to run. The capability was fulfilled in the demo. The function had never been designed.

The same review runs one level up. Team boundaries and ownership are structure too, written down - where they were written at all - for people who could ask. An agent estate reads them the way an agent reads a codebase, and guesses the rest. It is the same amplification problem one layer higher, and it repeats for as long as the governance layer stays something we were promised rather than something we built. That is its own argument.

None of this is an argument for waiting. It is an argument for order, and for ownership. Write down what good looks like - which capability it fulfils, and how that function has to operate - make it executable, give it an owner, delegate against it and measure the feedback. In that order agents accelerate, and what they accelerate is observable. Reverse it and the mud arrives faster. Good structure gets faster. Bad structure gets faster too, because AI amplifies the architecture it finds.

It pays to know what you are amplifying before you scale the delegation.

References & further reading

← All writing