A Closed Pull Request Is Not Finished Work

Counting lines of code has always confused activity with value. Agents make that mistake impossible to ignore because they can produce code faster than a person can understand it. The number rises dramatically while the product may not move at all. Generated files, duplicated abstractions, speculative helpers, and repair work all count the same as a small change that solves the actual problem.

A closed pull request is a better measure because it records movement across a real boundary. Somebody or something accepted the change. The branch stopped being private output and became part of the shared system. Releases move the checkpoint farther still: the work reached the environment where it is supposed to matter.

Better does not mean sufficient. A factory can merge weak work quickly. It can release a regression cleanly. If you stop measuring at closure or deployment, you reward the machine for crossing a line without asking what happened on the other side.

The useful unit is a change tied to a promised outcome. Track it from the requirement through implementation, independent proof, release, and production behavior. Did it do what was requested? Did it stay fixed? Did it create support work, rollback work, or another pull request that quietly repaired the first one? That full route tells you whether the factory delivered or merely transferred the cost downstream.

This does not require pretending every product decision can be reduced to one score. It requires preserving the evidence around the decision. A defect can carry its reproduction and the production signal that stopped firing. A feature can carry the executable behavior that earned acceptance. A maintenance change can carry the operational condition it was meant to improve.

Now the count has a denominator worth caring about: work that survived. You can compare attempts with accepted outcomes, releases with reversals, and autonomous runs with the human interventions they consumed. The point is not a prettier dashboard. The point is knowing which routes can safely take more authority.

Cheap implementation creates a new failure mode. Every plausible idea becomes easy to add, so the product collects local decisions that make sense alone and fight each other together. The code can be tested, reviewed, and released while the system grows harder to explain. That is not a model failure. It is a selection failure.

A software factory needs a budget for complexity, not just tokens. New concepts should pay for themselves against the product's existing language and structure. If a request introduces another path, state, permission, or abstraction, the plan should name why the existing mechanism cannot carry it. Proof should include what was removed, reused, or deliberately left unchanged.

This is where human judgment belongs. People decide whether the new room belongs in the building at all. Agents should do the repeatable work of tracing the impact, testing the boundaries, and enforcing the chosen architecture. Keeping people busy typing the room does not preserve coherence. Giving their decision mechanical authority does.

A metric that never changes the route is decoration. When a class of change repeatedly survives, the factory should expand autonomy there. When merged work repeatedly returns as repair, the route should tighten its specification or proof. When one kind of release creates disproportionate intervention, it should receive a different model, a different budget, or an explicit human gate before implementation begins.

The same evidence should expose fake speed. An agent that closes ten pull requests and triggers eight rounds of cleanup is not outperforming one that closes four and leaves the system stable. A team that releases constantly but cannot connect releases to durable outcomes has accelerated its ceremony, not its delivery.

This is also why the model is rarely the durable advantage. Models will keep getting faster at producing code. Every buyer gets that curve. The advantage belongs to the factory that remembers which work survived, turns failures into controls, and routes the next change with more discipline than the last.

Our position is that agent-run factories will remove jobs built around writing, moving, reviewing, and releasing routine changes by hand. Measuring pull requests instead of lines of code does not prevent that displacement. It only moves the scoreboard closer to completed work. The remaining human value is judgment about what should exist and which consequences the factory may accept.

So count pull requests if the alternative is counting code. Count releases if the alternative is counting pull requests. But do not confuse either event with the outcome. Follow the work until reality has had a chance to disagree, then feed that disagreement back into the machinery.

The best factory metric answers one operational question: after what we just learned, can this route take more authority next time? If the number cannot help you answer that, it is reporting motion. The agents already know how to make plenty of that.