I have been building a software factory: a system in which agents take a piece of work from an idea to a change that is ready to merge. What follows isn’t a blueprint. It’s a few things that surprised me, and that I’d probably mention to anyone setting out to do the same
The model was rarely the problem#
I had assumed most of the effort would go into the model: choosing it, prompting it, working round its mistakes. A fair amount did, and that work is real. But there were times when the model was doing perfectly reasonable work and very little of use came out the other end.
The reasons tended to sit around it. The work going in wasn’t quite clear enough to act on. The work coming out had no obvious next step. The parts in between didn’t let anyone know what they were waiting for. Each of these took rather more effort to put right than anything I did with prompts.
Agents turn vagueness into confidence#
Give a person an unclear request and they will usually ask a question. An agent tends to fill the gap with a guess and carry on, and the result looks every bit as finished as if the request had been clear.
So I found myself paying more attention to how a piece of work is described, and to whether its “done” can be checked by something other than a person reading it. If I couldn’t say how I’d know it was right, it seemed unfair to expect the agent to.
It’s cheaper to stop early than to catch late#
The obvious place for a human in AI coding is at the end: read what was produced, accept it or not. It’s also the most expensive place to discover that the work was wrong, since everything has already been spent.
I’ve gradually moved checks towards the start. Is the starting point healthy? Is the ask clear? Has someone agreed on what we’re actually trying to do? Most of these don’t need a model at all. They’re ordinary code, quick and predictable, and stopping a poor piece of work before it begins costs very little.
Trust shouldn’t rely on the agent behaving#
It’s tempting to make the system safe by telling the agent what not to do. That works, more or less, until it doesn’t.
I’ve come to prefer safety that doesn’t depend on the agent at all: permissions it doesn’t have, checks it can’t edit, steps it can’t skip. If an agent can change the test that grades it, the test doesn’t tell you a great deal. If it can approve its own work, nor does the approval. Those properties have to come from the structure rather than from instructions.
Broken and idle look much the same#
One of the less comfortable lessons was how quiet failure can be. When something broke, it often looked exactly like a factory with nothing to do. No errors, no alerts, simply nothing happening.
I’ve learnt to treat silence as something to be explained rather than enjoyed. Anywhere work can wait ought to say what it’s waiting for, and on whom.
Measure it honestly#
There was a point at which the honest numbers were rather humbling: plenty of activity, not much that actually landed. Reporting the activity would have been easy.
Writing down the real figure, however unflattering, mattered more than I’d expected. It’s difficult to improve something you’ve been quietly rounding up.
Where I’ve landed#
I’ve written before that my work has moved from coding to directing. Building a factory made that rather more concrete. Directing isn’t writing better prompts. It’s deciding what’s worth building, making “done” something a machine can check, and arranging things so that I can trust work I didn’t watch being made.
Models will keep improving, and that will help. It won’t make an unclear ask clear, or persuade a quiet failure to speak up. That part, I suspect, is still ours.