The Pull Request Is the Product: A Delivery System for Coding Agents
Within a month there are several teams, several tools, several permission models, and several definitions of done. Management asks how much faster engineering has become. Nobody can say, but the token dashboard is exceptionally detailed.
🗓️ Last updated: September 2026
The pilot begins with one developer and one coding agent. Within a month, several teams have different tools, different repository instructions, different permission models, and different definitions of completion. Management asks how much faster engineering has become. Nobody can say, but the token dashboard is exceptionally detailed.
The unit an engineering organization should optimize is not generated code. It is an accepted, verified, reviewable change. The pull request is the product of the coding agent workflow.
Assemble the delivery loop
A production workflow has seven explicit stages.
Intake turns an issue into a task contract.
Risk classification chooses permissions, environment, and review route.
Provisioning creates an isolated branch, worktree, and disposable runtime.
Execution lets the agent inspect, modify, and run scoped checks.
Verification runs authoritative repository checks.
Review evaluates intent, architecture, evidence, and risk.
Integration merges through current target branch checks and records the outcome.
Each stage has an owner and a failure state. The agent may participate in several stages, but it should not silently redefine them. A workflow in which the same process writes the task, implements the change, invents the acceptance test, approves the result, and merges it is efficient in the way an unsigned blank cheque is efficient.
Classify before execution
Use a small risk model based on affected components and action types. Documentation, local tests, and mechanical refactors may run with minimal privileges. Dependency changes, workflows, secrets handling, authentication, authorization, infrastructure, migrations, and public contracts require tighter controls and designated reviewers.
Risk classification controls network access, available credentials, writable paths, runtime limits, and approval requirements. It also decides whether the agent may open a pull request automatically or must return a proposal.
Keep agent environments disposable. Start from a known image and commit. Supply only task specific credentials. Capture commands and artifacts. Destroy the environment after the handoff according to retention policy. A developer laptop with years of ambient credentials is not an execution platform. It is a museum of implicit trust.
Standardize the repository interface
The platform should not hardcode every project's build system. Define a small repository contract: setup, fast verification, full verification, formatting, generated file policy, and instruction discovery. Let each repository implement the contract through checked in scripts or task definitions.
This keeps the platform generic while preserving local truth. It also makes onboarding measurable. A repository that cannot satisfy the contract is not ready for unattended agent work. That finding may be more valuable than the first generated patch.
Keep the model replaceable
Model capability changes rapidly. The durable assets are the task format, repository interface, isolation boundary, verification evidence, review policy, and outcome data. Avoid coupling the delivery workflow to one provider's conversation format or tool names.
Store model and harness versions with each run so results can be compared. Route tasks by capability and risk where useful, but do not treat model selection as the architecture. The model is an important dependency. It is not the entire software delivery system, despite marketing's best efforts.
Measure accepted outcomes
Useful measures follow work from intake to production:
Time from ready task to merged change
First pass verification rate
Human review time and queue delay
Rework requested after review
Revert and escaped defect rate
Percentage of runs that escalate correctly
Cost per accepted change
Segment results by task class and risk. Documentation changes and schema migrations should not share one productivity average. Avoid lines of code, prompts sent, and raw pull request count as success measures. A system can maximize all three while making the product worse with remarkable consistency.
Compare against an appropriate baseline and include human time. An agent that saves twenty minutes of implementation and consumes an hour of review has not created forty minutes of innovation. It has moved work to a more senior salary band.
Roll out by repository and task class
Begin with repositories that have reliable setup and verification. Choose bounded task classes. Establish baseline measures. Expand permissions and autonomy only when evidence supports it. Keep a disable path at the organization, repository, and task level.
Use failed runs as repository feedback. Repeated setup failures indicate environment debt. Repeated scope violations indicate weak task contracts or boundaries. Repeated review surprises indicate missing architecture documentation or tests. The agent workflow becomes a diagnostic instrument for the engineering system around it.
Failure modes
The first failure is tool first adoption. The organization buys seats before defining the work and evidence flow. Usage grows; accountable outcomes remain elusive.
The second is universal autonomy. Every repository and task receives the same permissions because policy design would delay the launch announcement.
The third is local optimization. Agent execution becomes faster while verification, review, and integration queues grow.
The fourth is vendor shaped architecture. Repository and process design become dependent on one product's current interface, making future capability improvements oddly expensive to adopt.
The architect's checklist
Optimize for accepted changes, not generated code.
Make intake, risk, isolation, verification, review, and integration explicit stages.
Define a portable repository contract for setup and checks.
Provision disposable environments with task specific authority.
Record model, harness, task, evidence, review, and outcome data.
Expand autonomy only by task class and measured results.
Coding agents do not create a software factory by themselves. They create a very fast workstation. The factory is the delivery system that decides what work enters, what evidence leaves, and what is allowed to reach production.
