From Coding Agents to Software Factories: Rethinking How Teams Work

We are starting to build software faster than our teams are learning to work at that speed. Coding agents have already changed how a lot of us approach implementation. Work that used to take a focused afternoon can be delegated, reviewed and iterated on before lunch, and nobody finds that remarkable any more.

Most of what surrounds that work has barely moved. You probably still plan, coordinate, review and measure delivery the way you did two years ago, with rituals designed around a constraint that is quietly disappearing: the time it took an engineer to write the code.

That gap is why the idea of a software factory has caught on so quickly this year, and also why it is so easy to misunderstand. Using agents to write code does not turn a team into a factory. The factory is what grows around the agents once the way of working stops belonging to individual engineers and starts belonging to the team, checks and lessons included. Getting there has less to do with finding more things for agents to do than with deciding which parts of your process can become part of the system, and which ones need to stay with people.

A factory is more than a collection of agents

Depending on who says it, a software factory is anything from a team with good agent habits to a building with the lights off. In January, Dan Shapiro described five levels of AI-assisted programming, ending in a "dark factory" that turns specifications into software with no human in the loop. He also observed that almost everyone tops out two levels earlier, at the point where a person still reviews what the agents write.

A few weeks later StrongDM described its own factory with two rules, quoted on Simon Willison's blog: code must not be written by humans, and code must not be reviewed by humans.

That is one end of the range, and it is an experiment rather than a destination anyone is obliged to reach. Most teams using the word sit somewhere far more ordinary. PostHog's newsletter places itself on a spectrum where agents write around 70% of its pull requests and people still skim at least 80% of them.

What I find more interesting than the level of autonomy is the shift from individual engineers running their own agents, with their own prompts and habits, to a delivery system the whole team can share, inspect and improve. Warp put it plainly in its guide to making that move: teams that treat it as a tool rollout rather than an infrastructure project tend to see nothing compound. If every engineer on your team has an excellent personal agent workflow, what you have is a row of separate workshops. They do not add up to a factory on their own.

The bottleneck moves, even when the process does not

When writing code stops being the slow part, the pressure goes somewhere else. Gergely Orosz's look inside OpenAI's agentic workflow describes pull requests per engineer rising like a hockey stick, and CI and version control straining under the load. Venkat Venkataramani, who leads Applied Infra engineering there, put it bluntly: "every month, we wake up to a new set of infrastructure scaling challenges to solve."

I would expect a smaller version of the same pattern in teams that speed up implementation without touching anything else: planning, integration, review and operations each absorbing a little more than they were built for.

A ticket could be two lines long because whoever picked it up would wander over and ask what you meant, and the question doubled as a design conversation. An agent does not wander over. It fills the gap with something plausible and keeps going. At the other end, review was a person reading a diff they could hold in their head, written by a colleague who would be around to explain it during the next incident. Now the diffs are larger and more frequent, and the author will never be paged.

So the middle gets fast, the ends get buried, and a team can reasonably conclude that this way of working does not suit it. Often the agents were fine. Nobody had redesigned the two places where people decide — what is worth building, and what is safe to trust.

Redesigning the workflow before automating it

Building an AI harness around my team's workflow made some of this much more concrete for me. What the agents could automate turned out to be the less interesting part. The more interesting one was how much of our existing process had to be made explicit first.

Decisions that had always happened through a quick conversation, a shared assumption or one person's experience suddenly needed to be visible enough for an agent to act on them — and a surprising number had never been written down anywhere. Looking back, it was a small factory, or at least the beginning of one.

It also made me wonder how much of the difficulty in moving towards software factories is about the agents at all, and how much is about processes we built around human execution without ever describing them.

The teams writing openly about this keep running into the same discovery: automation only starts to pay off once the things we used to leave implicit have somewhere to live.

Intent is the first of them, and it is the one that used to live in that conversation by the desk: the problem, the expected behaviour and what done means, agreed while disagreement is still cheap. Dex Horthy, who tried running HumanLayer with nobody reading the code, came back from it arguing for exactly this: settle product behaviour, architecture contracts and the shape of the program before a patch exists, so that review afterwards is short.

It is close to what approach review tries to do for human pull requests, with the difference that, once agents are doing the implementation, it becomes the main place where the team's judgment enters the work.

The two-line ticket was missing more than intent, too. PostHog's argument is that agents need the same inputs a good engineer uses to make design decisions, such as how the product is actually used, who the customers are and what users are complaining about, rather than a ticket with nothing behind it. A factory that only sees the repository makes repository-shaped decisions.

At the other end, the check cannot come from the same place as the code. Tests written by the same agent that implemented a change can be useful, and they do catch real problems, but they are built on the same assumptions as the code. Independent checks, browser walkthroughs and environments that look like production matter more as more of the implementation moves away from human hands.

Not every change needs the same scrutiny, either. In the OpenAI workflow Orosz describes, changes are classified by risk, low-risk areas can opt in to automatic approval, and high-risk ones may still require a human. Deciding where those lines sit is a decision about people as much as about code.

And then there is what happens after the merge. What happened in production, what had to be reverted, which instructions keep producing rework: if none of that reaches the next iteration, the factory repeats its mistakes at speed.

None of this is new, and good teams have always cared about it. What the agents take away is the slack that let the rest of us get by without it.

The transition happens through people

Even with the workflow redesigned, a team does not move at the speed of its tooling. Resistance to software factories tends to take a few shapes, and only one of them is loud. You have probably worked next to all three. There is the engineer who argues in planning. There is the one who agrees and then keeps doing the work by hand, because they do not trust what comes out the other end. And there is the one who goes along completely, approving whatever is green, which looks like adoption from the outside and is probably the riskiest of the three.

The easy move is to treat all of them as a mindset problem. That misreads what most of them are reacting to. For many engineers, writing code is not only the job. It is how they come to understand a system well enough to be responsible for it.

Being told that the new role is to write specifications and supervise agents can sound like being asked to manage the thing you used to make, and to call it a promotion. Some people want exactly that. And for engineers who find meaning in understanding and building systems directly, that can feel like losing an important part of the work.

And some of the scepticism is correct: the person asking who will understand this code when it breaks at three in the morning is asking the question Horthy's team had to answer the hard way.

Two quieter things shift at the same time. Junior engineers may lose some of the small, safe tasks that used to teach them a codebase, the loop I wrote about in growing engineering judgment without the grunt work, so the team has to decide deliberately where that learning now happens. And authorship spreads across agents while responsibility does not. If nobody has agreed whose name sits on work that nobody typed, the weight tends to land on whoever cares most, and stays there.

I have to count myself in this picture rather than above it. I am one of the people who built the harness, wrote the instructions and found the whole thing exciting. From the other side of the table, that enthusiasm can look like a decision already taken. Some of the doubt in a team will be about agents. Some of it may be about not having been asked, and that part, at least, a team can do something about.

One workflow before a transformation programme

The transitions that seem to hold up start small and stay reversible for a while. Warp's guidance is to run one bounded workflow on one repository, with a human approving every output, and to move on only once that output is usually accepted without rework. Only then does it get wired into wherever work already arrives, with review and triage around it and someone watching what it costs and how often people have to step in.

It helps to picture something deliberately unglamorous, such as keeping dependencies up to date. Often one engineer handles it when they find the time: reads the changelog, makes the change, runs the tests, opens a pull request and hopes someone reviews it before it goes stale.

A first factory version does not have to change who is accountable for the decisions. An agent picks up the upgrade when it is released, makes the change, runs the checks the team has agreed matter for that area, and writes down what it changed, why, and what it could not verify. Then it leaves a proposal for a person to approve. Someone still says yes. What moves is that person's attention, from doing the upgrade to judging whether the evidence in front of them is enough.

A few weeks later the team knows which upgrades come back clean and which need rework, and that record is what justifies the next step. Perhaps automatic approval for patch releases in low-risk areas. Perhaps nothing at all.

The sequence lets a team form an opinion from evidence instead of an announcement, and the habits around it matter as much as the steps. The decisions that stay human are worth writing down before anything is automated — somewhere the agents can read them too. The verification gates are worth handing to the people who worry most about unreadable code; a sceptic who designs the check has far less reason to block it. Acceptance and rework say more than adoption does, a point Warp makes too, since a count of agent pull requests only tells you the factory is running.

A plan does not make a team ready. What seems to move people, if anything does, is watching one workflow succeed, fail and get fixed in front of them, with the doubters holding some of the controls.

What we still do not know

Most of what has been written about software factories this year comes from companies selling them, or from teams describing systems of their own that are still young. Warp's figure of 20–30% of pull requests going through factories describes Warp, not the industry.

Very little independent work measures what happens to a codebase that few people read closely after a year or two. Horthy's own guess is that agents start to struggle in fast-moving repositories after three to six months, and he is open that there are no good benchmarks yet for whether models keep a codebase healthy over time. Cost is still unsettled as well. StrongDM's suggested benchmark of at least $1,000 in tokens per engineer per day reads as seriousness to some people and as a bill most teams will never justify to others.

I do not know where most teams will settle. My guess, and it is only a guess, is closer to the light end than the keynotes suggest, mainly because the parts of the process that matter most are made of people, and people change how they work at a different pace from their tools.

Final thoughts

What the transition to a software factory tends to expose is how much of a team's engineering process still runs on assumptions, on one person's judgment, and on conversations nobody wrote down because, until the agents arrived, nobody needed to.

Some of those decisions can become part of the system: written down, checked automatically, repeated without anyone having to remember them. Others belong with people, because they depend on context no instruction captures, or because someone has to stand behind them when things go wrong. Telling the two apart is harder than it sounds, and the line is not fixed. It moves as models improve and as the team learns what it can trust. It also moves, more slowly and less predictably, as the people in it change what they want their work to be.

That is probably the real work of the transition — building a way of working that can keep redrawing that line without losing the understanding, ownership and learning that made the team good in the first place.