The AI software factory still needs someone to say no

Will Larson wrote about trying the software factory pattern at Imprint. It is a month-by-month log of their year: every engineer on Claude Code daily in January, everyone else by March, a move from Jira to Linear in June, an orchestrated "Agent Fleet" in July. The latest step is an agent skill that reads a Linear project, checks it has a goal, an RFC and a way to measure progress, and then keeps working toward that goal: opening pull requests, updating them, pinging for review.

I liked it a lot, and it is one of the most concrete accounts of this shift I have read so far.

But reading it with my operations hat on, I kept waiting for one question that never really comes up. If an AI software factory can produce pull requests all day, who is on the other side of those pull requests?

The bottleneck moves, it doesn't disappear

I've built an engineering team from scratch twice: the internal dev team at GreatPixel, and a division of 15+ people at Bakeca. In both cases writing code was rarely the thing that made us late. What made us late was the stuff around it: waiting for a review, a UAT round where the client (or the product owner) found out they wanted something else, a release nobody was confident about on a Friday afternoon.

When PRs become cheap, that part doesn't get cheaper. It gets more crowded. The code review bottleneck is the obvious one: an agent can open ten PRs before lunch, and a senior engineer can seriously review maybe a few of them without their brain turning into soup. Then there is testing with real humans, which does not scale with tokens. And then the hardest one: deciding what not to build.

Larson's loop actually does something smart here. It refuses to run without a goal and a metric, and if they are missing it iterates with you to create them. That is the right instinct. A factory without a goal is just a very fast way to fill a backlog. But a metric tells you if you are moving, not whether the next ticket is worth doing at all. Somebody still has to kill ideas, and "the agent added this issue to the project" is exactly the kind of sentence that should make a product person nervous.

Boring process matters more, not less

At GreatPixel the things I introduced were not glamorous: OKRs, capacity planning, UAT, production checklists. Nobody ever threw a party for a checklist. But I think in a factory model they become more important.

• Capacity planning used to mean "how many developer days do we have this sprint". With AI coding agents doing a chunk of the typing, the scarce resource is reviewer attention and tester time. You should plan that capacity, the same way we used to plan developers on a Monday spreadsheet.
• Production checklists exist because humans forget things under pressure. An agent that ships ten times more changes needs the same checklist applied ten times more often, ideally encoded in the harness itself.
• UAT is where you find out the thing you built is correct but wrong. Faster code just means you get to that moment faster, and more often.

Larson makes a point I fully agree with: the pieces only compound when you have the other pieces. Linear as single source of truth, Datadog and Snowflake for metrics, a harness that runs off your laptop. I would add a few non-technical pieces to that list: clear ownership of review, a release process people trust, and a manager whose job includes saying no to work that is technically free.

Where I actually am

To be honest, my own AI adoption is small scale and still in progress. I use AI-assisted workflows, I taught a class on AI and chatbots back in 2021, and that is about it. Nothing close to a fleet. So take my view as the view of someone who has spent years watching where work gets stuck, not of someone running agents in production.

Reading the Imprint timeline, what struck me is that Claude Code adoption was step one, in January, and everything after was about fixing what that exposed: workspaces, task management, orchestration. Every step solved a bottleneck and revealed the next one. My bet is that the next one is not technical. It is review, testing and product judgment, and I'm curious to see how the post about that month looks.

The detail I liked most is the post-release mode, where the factory checks in on a shipped feature like passkeys and notices if adoption or error rates change. That is literally what a good operations person does, and almost nobody has time for it. If agents take over that part, I'll happily let them.