I stopped writing code.
Now I run a factory.

The problem

Writing code was never the bottleneck

I had one skill that took a plan and built it test-first. It worked. Not sometimes. Reliably, on real work, often enough that I stopped reading the code it produced line by line.

So I used it more. An agent comes back with a red test. Is that a real bug or a broken container? Nobody knows, so I go find out. Twenty minutes gone. An agent says it's done, and I have no idea what "done" meant to it, so I go check. Twenty more. Multiply by every piece of work, every day.

Code generation was the solved part. Everything on either side of it wasn't, and that's where all my time went.

Then reliability created its own problem. Once each piece lands, the limit becomes how fast I can hand out the next one. I was the queue. Sitting there dispatching work one item at a time, which is a bad job for a person and a worse one for the person meant to be deciding what gets built.

I call it a factory and it is not really one. Nothing here is a stamped part. The code is bespoke every time, and when something bigger goes wrong I still have to open the thing up, think like a developer, and guide it out. What actually resembles a factory is the discipline around the work: every run measures itself, every bit of friction gets written down, and each one becomes a fix before the next run starts. That is kaizen, not mass production. The line is worth copying. The idea that the parts are interchangeable is not.

How I got to the fix

Every fix moved the problem somewhere else

I didn't design this. Each part exists because the part before it worked and the bottleneck slid somewhere new.

• Kill the environment questions. Every workspace gets built fresh and runs its test suite before any agent touches it. Whatever is already failing gets written down by name. Now a red test is either on that list or it's real. No investigation.
• Stop arguing about proof. What counts as evidence comes from what the change touched, decided before the work starts. The agent doing the work doesn't get to pick. Sounds bureaucratic. It killed a conversation I had several times a day.
• Get myself out of the dispatch loop. Runs, manifests, a ledger that survives between sessions. A coordinator hands out the work now. It helped that plans got good enough to write for every open issue, which turned a pile of vague bugs into an actual queue.

Three fixes in. All three are working, and together they are the thing below.

Still the fix

One run is never the answer

That's the part I had wrong for a while. A run doesn't produce a finished thing. It produces something worth testing. I smoke it, that finds real problems, those become the next run. Repeat until it holds.

How many rounds depends on the work. Logic settles fast. Screens don't. I find them hard to specify well, so they take more passes.

• Round one. Full run. Many units, a manifest, a ledger.
• Then I smoke it. I use the real thing and find what the gates missed. Smoke isn't the last gate. It's what generates the next round.
• Round two onward. Mostly single units. I talk one fix through, dispatch it, same gates, no manifest.

What is next

Testing is the bottleneck now

Code, setup and dispatch are all handled. What is left is the part where I find out whether any of it is good. Single units still have no ledger entry either, so the mode I use most is the one leaving the least trace.

Testing is the part I still picked by hand, out of memory, before every run. I wrote the rules down and ran them properly for the first time in July. The run found real problems and three failures that were not real, which turned out to be the more useful result.