The thing that builds the thing. It's another phrase that makes me wince, right up there with harness. It was one of the first AI projects I was ever handed, and unsurprisingly, it failed. The pitch was simple: feed in a bunch of prompts and, poof, working software comes out the other side. The glaringly obvious problem is that software doesn't get built in a vacuum. It gets built from messy ideas sitting in people's heads, and those only surface through conversation. Worse, those people rarely agree on what the software is for, which features matter most, or how it should be built, deployed and hosted. No pile of prompts settles that. But like with harnesses, here I am at it again: building the thing that builds the thing.

When I first wrote about building software with AI a year and a half ago, the worry was quality: AI code read like a junior developer's. The models have largely fixed that. What hasn't caught up is how we work around them. We still run teams on development philosophies designed for a world where people wrote every line.

Code review is the obvious one. In an article 2 months ago I said it would buckle under the volume, and it has. One engineer with agents can push more change in a day than a team used to in a sprint, and the senior who signs off every pull request becomes the bottleneck.

The popular fix is an AI agent reviewing each change, and it makes things worse. Every system carries technical debt, mature ones especially. It's a natural consequence of building software at speed and scale, and how much we carry is something we manage. An AI reviewer can't tell which debt is deliberate, so it red flags everything. Engineers trawl through false alarms instead of doing real work, and even when they point Claude Code at fixing them, those tokens are better spent on features. Claude, in overbearing nanny-assistant mode, is particularly bad at this. People also get biblical about AI code in a way they never do with humans, expecting it to be cleaner than anything they'd accept from a person. That sends teams straight into the death spiral of over-optimisation.

Review doesn't need to go away. It needs to change scale. When I review someone's work, or they review mine, the reviewer points their Claude at the whole codebase to make sense of it: an engineer applying their skill across a repository instead of one function at a time.

But this isn't really about AI writing code. It's about how seniors and leaders orchestrate an ensemble of mid and junior developers, each with their own agents. That starts with a scaffold.

Every repo I work in opens with a working agreement Claude Code reads first: how the code is laid out, what goes where, what it may never do. A code checker then runs on each change, judges it against that repo's written architecture, and fixes what it finds. The standard lives in code, not in one reviewer's head, so it holds at any speed. Each new repo is born from the last, so what worked becomes the blueprint for the next.

Keep it simple, though. I've watched people over-engineer scaffolds until they strangle Claude Code. The goal isn't an engineering monoculture, and you couldn't have one if you tried: AI output is shaped by the hands that use it, and that can't be fully delegated, nor should it be. People's styles still come through, and developers doing things differently isn't a bug, it's a feature. When the whole team is involved, their shared mental model of the system gets grafted into the code.

I've also seen scaffolds tuned obsessively around token usage. If you hit the limit on a $100 Claude subscription by the middle of the month, you're doing something wrong. Worse are scaffolds that try to outsource the developers' thinking and come up with the design for you. The ideas come from people. Let them do that.

That includes the mids and juniors. Contributing to the scaffold should be part of their development. To write a rule an agent can follow, you have to articulate why the code is shaped the way it is: where a responsibility belongs, what a layer may and may not do. That's system design and architecture. A year ago I asked how juniors would build the skills it took seniors decades to learn. This is part of the answer.

Orchestration isn't just the senior's job. Every developer should work this way. Claude runs several sessions at once, so while one handles a task, you're shaping the next. The limit is your own cognitive bandwidth. When something demands your full attention, give it that. The rest of the time, run as many as you can keep track of. And with a swarm inside a human-agent harness, you can delegate till the cows come home.

So the senior engineer's job changes: less checking every line, more orchestrating the ensemble, setting the rules, growing the scaffold with the team and lifting everyone's grasp of the system. AI didn't make engineering less important. It moved the craft from writing the code to shaping the thing that builds the thing. And that thing isn't AI. It's a collaboration of foundation models, harnesses and people.