200 PR a Day: One-Person Software Factories That Work

The work changed shape, not just speed

Everyone has now watched an agent write a feature. Far fewer have built the system around it that makes that repeatable, safe and affordable when a hundred sessions are running at once. That system is the actual product of an AI-native agency, and it is where our time goes.

Here is how we work: the framework, the automations, the parts we refuse to automate, and what the resulting throughput does to a development budget.

We do not stick to work locally

Local development is the constraint now. To run five tasks at once on a laptop you are juggling git worktrees or duplicated checkouts, and your attention goes to coordination instead of decisions. Cloud sessions each get a disposable VM, so parallelism costs nothing mentally and nothing collides.

The exception we grant is heavy new UI work, where local iteration still wins, before the work moves back into a cloud session.

The framework: change management, not prompt management

Running one agent is a prompting problem. Running a hundred is a change management problem, and that is what our delivery framework exists to solve. It sits between the work and the models, and it owns four things:

• Work decomposition. Client intent becomes scoped, independently mergeable units of work, sized so that a session can finish one and a human can review it in a sitting. Most agent failure at scale is really scoping failure.

• Model routing. We harness third-party models rather than betting on one. Frontier models handle architecture, planning and review. Cheaper fine-tuned coding models handle the high-volume unattended loops. The framework decides which, per task, and the choice is portable when pricing or capability shifts.

• Change control. Every change is traceable back to the decision that authorised it, through review, to the merge and the person accountable for it. Volume without an audit trail is not delivery, it is churn.

• Isolation and secrets. Least-privilege sandboxes per session, and credentials that never enter an agent's environment.

We are also training our own models on the narrow, repetitive parts of this pipeline: the classification, triage and review passes that run thousands of times a week and do not need a frontier model to do well. That work is in progress rather than finished, and we will publish results when we have them rather than before.

The automations that earn their keep

Most of our leverage is not in interactive sessions at all. It is in scheduled runs:

• End-to-end browser tests. An agent walks the full user path in a real browser, records what it did, reviews its own recording and opens fixes for what broke.

• A production watchdog. Every morning an agent summarises what real users did the previous day, with links back into the live UI. Reading a summary tells you what happened. The link tells you whether it was any good.

• Graded improvement loops. Transcripts and flows graded daily against a rubric, with anything below threshold spawning a session that opens a fix. The value is in the paper cuts nobody would otherwise prioritise.

The pattern underneath all three is the same. The agent finds the problem and opens the PR. A person decides whether it ships.

What 200 pull requests a day does to the cost model

This is the part clients care about, so here is the arithmetic rather than the adjectives.

A strong senior engineer merges somewhere between one and three substantive pull requests on a good day, once you account for review, meetings and context switching. Call it two. Two hundred merged PRs a day is therefore the change throughput of roughly a hundred engineers.

A hundred engineers, fully loaded, is not a number most companies can write down without flinching. Even at a conservative blended cost, you are looking at millions per year before a line of code is reviewed. The agent-run equivalent is a small supervision team plus compute, and compute is the smaller half of that bill. The gap is not a percentage. It is an order of magnitude.

The expensive resource stopped being the person who writes the change. It is now the person who decides whether the change should exist.

Three honest caveats, because the comparison is easy to abuse:

1. PRs are not fungible. Agent-authored changes skew smaller and more numerous. Two hundred small ones are not a hundred engineers' worth of judgement, they are a hundred engineers' worth of typing.

2. Review is the real ceiling. Merge volume is limited by how fast humans can responsibly approve, which is why our framework spends more effort on decomposition and automated review passes than on generation.

3. Token spend is real money. Unmanaged, it goes somewhere no client should be asked to fund. Routing is what keeps the arithmetic working, not restraint.

Taken together, the honest claim is not "software is now free". It is that the cost of producing a change collapsed, the cost of deciding on a change did not, and any pricing model that has not adjusted for that is charging for the wrong thing.

Two things we refuse to automate

First, production credentials. Write access to prod lives in a password manager and never in an agent's environment. Run enough sessions and one eventually does something destructive, so the blast radius has to be bounded in advance rather than apologised for afterwards.

Second, using the thing we built. We click through the whole product ourselves on a schedule. The strongest models still miss what any user would flag in a second, and there is no substitute yet for a person going "that is weird".

What this adds up to

• Isolation is the enabler. An agent that cannot reach prod cannot break it, which is what makes parallelism safe rather than merely fast.

• Loops need an adversary. A system that grades its own work and merges its own fixes is marking its own homework. We keep generation and review in separate hands, with a person accountable for the merge.

• Throughput is not the goal. Volume only counts if somebody still owns whether the product is coherent. That judgement has not been automated, and it is what clients are actually paying for.

The conclusion most people find uncomfortable is the one we are most confident about: running agents well makes you more technical, not less. You cannot supervise work you do not understand.