A coding agent returns a clean-looking patch in minutes. The requested behavior appears to work, the test suite is green, and the diff is short enough to review before lunch. It is tempting to treat the ticket as nearly done.
What the agent has actually delivered is a candidate. Your team still has to understand the change, decide whether releasing it is safe, and accept responsibility for whatever happens after it enters the codebase.
GitHub recently suggested a useful way to think about that first result: it is a price check. A quick patch can reveal a plausible implementation and show where the work may spread. That information is valuable, but it does not tell you the full cost of accepting the change.
The important question is not whether the agent produced code quickly. It is whether the team now has enough evidence to own that code.
A fast patch buys information, not approval
Working software can still be an expensive commitment. Passing tests may show that one path behaves as expected, but they do not prove that the agent understood the requirement, stayed within the intended boundary, covered meaningful failures, or preserved a practical route back to the previous working state.
Those questions must be answered by a person. If the answers exist only inside the agent conversation, the work has not been eliminated. It has been deferred until a reviewer—or an incident responder—has to reconstruct the missing context.
Ownership extends well beyond today’s review. Six months from now, someone may need to explain the design, diagnose an outage, update a dependency, remove part of the implementation, or hand the component to a new teammate. An EASE 2026 / arXiv empirical study found that humans still performed most subsequent maintenance of agent-generated code.
DORA describes why the surrounding system matters so much: AI amplifies the delivery environment in which it operates. Clear responsibility, dependable tests, and disciplined release practices can turn faster generation into useful output. When those foundations are weak, the same speed creates more uncertainty and more cleanup.
That makes a narrow, reversible trial the right starting point. Its purpose is not to demonstrate that the patch deserves to ship. Its purpose is to expose the obligations that arrived with an inexpensive first draft.
Price the change in three parts
Generation time is only one part of the bill. Review and long-term maintenance need their own estimates because each can make an apparently cheap patch unaffordable.
| Cost | Evidence to examine | Decision signal |
|---|---|---|
| Generation | How much context did the agent need, and how many correction rounds were required? | The estimate is credible when the task boundary is explicit and another run produces a broadly similar approach. If repeated runs invent different designs or rely on undocumented chat context, the apparent speed is unstable. |
| Review | Can a person explain the purpose, data flow, realistic failure paths, and safe rollback route? | Review may be affordable when the diff is focused, tests correspond to the requirement, and the reviewer can identify the main risks. Revise when the change is entangled, tests cover only the happy path, or nobody can explain what is safe to remove. |
| Ownership | Who will maintain the code in six months, and can that person diagnose, recover, and hand it over? | Ownership is plausible when a named maintainer understands the design, dependencies, monitoring, and recovery method. Do not ship when the patch introduces unfamiliar dependencies, hidden state, or knowledge found only in the AI conversation. |
Use ship only when all three judgments have concrete support. A successful test run alone is not enough.
Choose revise when the approach appears useful but the patch is too broad, the tests leave important behavior unexamined, or nobody has formally accepted ownership. Reduce the scope or gather the missing evidence, then evaluate the candidate again.
Choose stop when the requirement remains unclear, the architectural burden is larger than the likely value, or there is no credible maintainer. Stopping does not make the trial a failure. It means the price check uncovered a responsibility worth declining before the team paid the full development and maintenance cost.
Test ownership with one reversible change
Start with a task that does not touch production data and can be rolled back completely. The coding agent may prepare a candidate patch, but it must not merge or deploy the result automatically.
Before the run, define the files the agent may change, the tests it must execute, the evidence a reviewer must inspect, and the person responsible for the final decision and cleanup. These boundaries keep three different roles from collapsing into one: the agent explores an implementation, a reviewer evaluates the evidence, and the team decides whether to accept the maintenance burden.
If your workflow does not yet specify where the agent must pause, read Before Letting an AI Agent Write Code, Put Checkpoints into the Task. When an approval request might arrive on a phone or another context-limited interface, Coding agents now start from a phone: what can you watch, delegate, or approve? can help separate remote observation from decisions that require a fuller review environment.
Once the candidate is ready, close the agent conversation. The patch should be able to stand on the evidence that accompanies it. Ask the reviewer to explain what changed, how data moves through the implementation, where it can fail, and how the previous working state would be restored. Then ask the proposed maintainer to accept responsibility explicitly.
If the explanation is supported by the diff, tests, and recovery procedure—and the maintainer accepts the burden—the team may consider ship. If either checkpoint fails, the result is revise or stop.
The agent’s speed can open the investigation, but it cannot close the decision. Merging and deployment still require explicit human approval.
AI handoff card
Work from the project context you can access right now. Begin with read-only inspection of the repository, workspace, issues, tests, and relevant Git history; do not ask me to assemble requirements, a diff, test evidence, or an ownership packet. If there is no accessible project at all, ask no more than one focused question that names the repository or project access you need.
Produce a decision brief about one—and only one—small, reversible improvement opportunity. Ground it in direct evidence such as file paths, issue wording, test output, or commits. Keep observations distinct from interpretations, and mark unsupported points as “To confirm” rather than filling gaps.
Evaluate the opportunity through three costs: the effort or compute needed to generate the change, the human attention required to review it, and the six-month cost of owning and maintaining it. Choose exactly one recommendation: ship, revise, or stop. “ship” means the change is suitable to prepare as a candidate; it is not permission to edit, merge, deploy, or release anything.
End with one smallest next action. Do not modify files while discovering or assessing the opportunity, and wait for explicit human approval before any edit, merge, deployment, or release.
Everyday four-panel comic
When a small patch opens up the whole coat
- A customer brings in a coat with a small tear on the outside. The tailor chooses a patch, expecting a quick repair.
- Opening the same coat reveals a much larger problem: the coral lining is badly torn, and several seams have come loose.
- Instead of quietly expanding the job, the tailor pauses. Today’s work will cover only the outer tear, while the attached lining is secured out of the way.
- The outer patch is finished. The damaged lining remains visible and clearly set aside for a future visit, keeping completed work separate from deferred work.
References
- GitHub Blog：The cost of saying yes has changed — https://github.blog/engineering/the-cost-of-saying-yes-has-changed/（2026-07-17）
- DORA：State of AI-assisted Software Development 2025 — https://dora.dev/research/2025/dora-report/（2026-07-19）
- EASE 2026 / arXiv：To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — https://arxiv.org/html/2605.06464v1（2026-05-07）
