The Rejected Pull Request Trains the Factory

The most convincing use of agents in software is not a dazzling feature built from a sentence. It is the work teams postpone because it is repetitive, bounded, and never quite urgent enough: finding crashes, removing dead code, simplifying tangled logic, cleaning up stale flags, and repairing flaky tests.

That work has a clear advantage. It can be described as a routine. The routine can run against the real system, produce a narrow change, and send that change through the same checks every other change faces. Nobody has to invent a fresh prompt each morning or remember which repository needs attention. The schedule carries the work to the worker.

This is what makes the example in the linked article matter. The headline is about an agent writing pull requests. The mechanism is a collection of specialized maintenance routes running every day. That is the beginning of a factory, not a clever chat session.

A pull request that does not merge is not automatically wasted output. It is a result from a production gate. The important question is whether the factory can explain the rejection and change the route that produced it.

Maybe the agent chose a cleanup that was technically valid but not worth the review cost. Maybe it removed code whose reachability was unclear. Maybe the test evidence was too weak, the change crossed an ownership boundary, or the routine bundled several ideas that should have been judged separately. Each reason points to a different repair. A raw acceptance rate cannot tell you which one you need.

Treat every rejection as labeled evidence. Record the failed gate, the reviewer decision, the affected routine, the authority it used, and the smallest change that would have made the proposal acceptable. Then update the instruction, scope, verifier, or escalation rule. If the same rejection keeps returning, the system is not learning. It is merely generating again.

The routines described in the article begin with ordinary instructions. That is good. A control surface should be understandable to the person who owns the outcome. But plain language does not remove the machinery beneath it.

A dependable routine still needs a bounded repository, permitted tools, a definition of the change it may make, a budget, a stopping condition, and proof produced somewhere the author cannot quietly redefine. It needs to know when to open a pull request, when to gather more evidence, and when to leave the code alone. The sentence starts the route. It does not supply those controls by itself.

This is why prompt collections do not compound. A saved prompt preserves wording. A factory preserves the entire route from request to evidence to decision, including every correction earned by earlier runs.

Human review is valuable while the routine is young because people still own the standards and the consequences. The trap is using reviewers as permanent cleanup crews. If they repeatedly explain the same boundary, split the same oversized change, or reject the same weak proof, their judgment is being consumed instead of installed.

Move recurring judgment into mechanical gates. Turn an architectural objection into a dependency rule. Turn uncertainty about unused code into an observation period. Turn a flaky-test repair into a reproduction requirement. Keep people on novel tradeoffs and consequential exceptions, then capture whatever can be stated and tested for the next run.

That shift will eliminate maintenance work that currently fills engineering calendars. It should. People should decide which risks are acceptable and which systems deserve attention. They should not be paid to rediscover the same review comment every morning because the routine has no memory.

Our position is that daily autonomous maintenance will become ordinary. The model will not be the durable advantage. The advantage will belong to the organization that can turn every run into a better operating policy without weakening the proof that protects production.

Start with one narrow routine whose result can be judged. Run it on a schedule. Require a small change and independent evidence. Classify every rejection instead of throwing it away. Update the route, then check whether that class of failure actually declines without a new one slipping through. That is a learning loop you can operate, not a demo you have to believe.

The pull request is only the visible artifact. The real product is the routine that selects the work, the gates that decide what survives, and the feedback path that makes tomorrow's attempt better than today's. When rejection improves that machinery, failure compounds into capability. When it does not, you are just making a larger review queue with an agent attached.