Development agents have transformed the way we think about building software.Over the last few months I have spent tens of thousands of pounds on tokens to command armies of development agents. With their help, I've been able to take on projects that would have been out of reach a few years ago. 

I have always maintained control of the architecture though. I write the initial specs by hand, decide on the main abstractions, and work with agents to perfect them. This is important, as delegating design to agents can lead to false confidence in the quality of the system. Code might look clean and pass all the normal quality gates while serious problems lurk undiscovered. 

It can be tempting to leave these problems to coding agents with a "you build it, you fix it" shrug, but agentic-driven code bases are no strangers to technical debt. They can become bloated with unnecessary structures which slow development down and send token costs spiralling. That productivity bump you discovered with agents can disappear as progress coagulates in AI-generated gloop.

You need to maintain a tight grasp over the shape of a system. Otherwise you may find that the system drifts away from a coherent domain representation into a strange distortion of good architecture practice. It might look like a system, it may even deliver features successfully, but underneath the hood will be something impenetrable.

There is a strangeness to AI-driven design which is hard to articulate. The components have plausible explanations, but the boundaries don't always connect. Minor features have bloated implementations. The terms used to describe the domain somehow don't land fully. The shape somehow seems a little… off.

Fluency without judgement

Good design is about communicating ideas and building a shared mental model that allows us to reason about a system. AI-driven architectures tend not to have the immediacy and coherence of a model that a human has sweated over. This may be because they are often a facsimile of good design practices based on pattern matching rather than something produced through reasoning.

The outputs may seem superficially on point, but the use of thoughtful language can often feel performative. It is not grounded in real world experience or genuine understanding. There's no judgement, and little sense of engagement or empathy with a target audience. 

There's an artificial tidiness as everything is resolved just a little too neatly, with none of the awkward loose ends that are a normal part of any solution. The details are always competently expressed, but this polished presentation can conceal a tendency towards uneven treatment where some ideas receive undue emphasis, while core questions remain largely unresolved.

This façade of coherence means that individual components might appear to make sense, but they won't stack together. Everything is described with the same absolute sense of confidence, which can make it difficult to identify inconsistencies. It's easy to bury some serious misunderstandings among all that confident-sounding presentation.

We usually assume that the very existence of a design is some evidence of effort. The words have been chosen for a reason, backed up by years of experience and systems thinking. This is not the case for AI driven architecture. The chosen terms and patterns don't always fit, leading to strained abstractions that don't survive prolonged contact with reality.

The "AI can fix it" myth

Why does this matter? Surely we can just spend more tokens or build a better harness?

Throwing more tokens at a problem can become a money pit. AI-generated architectures can become surprisingly brittle in the face of simple enhancements. All the architectural smells associated with sloppy design come to pass - shotgun surgery, divergent change, premature decomposition, leaky boundaries - and each of them incurring ruinous token bills.

Can a well-built harness really mitigate against this? Only up to a point. You can hone an architecture over time with continuous review rounds through different combinations of agents, skills, rules, and models, but you cannot replicate nuanced human judgement in a bunch of markdown files.

Besides, nobody has the luxury of an inexhaustible supply of tokens. Eventually the music stops and the token budget dries up. What then? If you are left with a system that only an AI can understand then you are making a big bet on the future availability of high quality inference. 

Treating agents as design partners

AI can help you to build a complex system, but only a human can ever be accountable for it. Agents can propose and develop designs, but the people responsible for the system must retain the ability to evaluate those designs and explain any decisions.

My own experience is that AI can help you to yield more sophisticated outputs, but you need to maintain ownership and treat the AI as a partner. An unreliable partner at that, with a tendency to over-elaborate solutions and get stuck in unnecessary detail.

One of my favourite (and most conceited) maxims for architecture reviews are that "if I am struggling to understand this then it's probably bullshit". You should challenge the outputs of AI and look for the chinks in all that convincing-looking output. You can simulate diversity of thought by trying different models and harness configurations to encourage more varied outputs. This does depend on your willingness to take control of agents rather than being overwhelmed by the outputs.

Filed under AI, Agents, Architecture and Development process.