On a Wednesday afternoon, a product manager asks for something small: one more column in an exported report. An engineer hands it to a coding agent, an AI tool that can read and change code on its own, and ten minutes later gets back a change touching five files with every test passing. The work looks finished.
But at this point the team still doesn’t know a few things. Why did all five files need to change? If tomorrow’s export breaks, where do they start looking? Six months from now, when this code needs updating, who will remember how it works?
In a July 2026 engineering post, GitHub described the first version of an AI-generated change as a “price check.” It’s cheap, and it lets a team see a possible solution and its scope at very little cost. But only the writing got cheap. Reviewing and maintaining the change didn’t get cheaper because of AI. So the first version shouldn’t be treated as done. Its purpose is to show the team what accepting this change will actually cost.
Writing got cheaper; the other two bills didn’t
The total cost of a code change roughly splits into three bills.
The cost of producing it: how much time and background explanation it took to get this version. AI really has cut this one sharply.
The cost of reviewing it: how much effort it takes a person to be sure the change is right. GitHub’s post is direct: a change is only cheap if a person can confidently validate it; a change that can’t be reviewed is just a deferred cost.
The cost of maintaining it: whether anyone will be responsible for this code’s behavior six months later. The author’s test question is whether you’d be comfortable owning this behavior six months from now.
Who pays the last two bills? A study posted in May 2026 and accepted at the software engineering conference EASE 2026 analyzed over a thousand AI-generated files and about 3,200 later changes across 100 popular open-source repositories. It found that human developers did the large majority of the later maintenance on this AI-written code. The AI hands over the code and leaves; the team stays.
Use the first version to find out three things
If the first version is a price check, what you do after receiving it is use it to find out three things.
Did the change go beyond its scope? Five files changed for a “one more column” request. Is that reasonable, or did the AI do other things along the way? The signals GitHub’s post suggests watching include whether the change spreads across several modules, whether it’s hard to test, and whether it requires a new product decision. All of these mean the change is more expensive than it looks.
Can the reviewer explain it on their own? Ask the reviewer to set the AI chat log aside and explain directly what problem the change solves, how data flows through it, and how to roll back to the previous version if it fails. If they can, the review cost has genuinely been paid. If they can’t, the key knowledge exists only in a chat log.
Has someone agreed to take it on? Name the person responsible for this code and ask them plainly: if this breaks six months from now, will you handle it? That question is harder to answer than whether the tests passed, and more important.
If all three have answers, the change can be merged. If the direction is right but the scope is too large or the tests too thin, ask the AI to redo it at a smaller scope. If the price check shows that the requirement itself is still unclear, or that nobody is willing to own it, stop. Stopping doesn’t mean the attempt was wasted: the value of a first version is exactly that it lets the team see the cost isn’t worth it before investing in full development.
Small changes don’t need all of this
These checks slow down small changes. For a one-line text fix or a version bump, asking who will maintain it is obviously overkill. The changes worth checking this way are ones that alter how data flows, add dependencies, or touch billing, privacy, or permissions. GitHub’s post also notes that changes involving support burden, privacy, billing, or compliance stay expensive no matter how little code they require.
The team’s own foundations also determine whether these checks help. DORA, a long-running research program on software delivery performance, says in its 2025 report that AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses. Teams with clear testing, delivery processes, and division of responsibility find it easier to turn AI’s speed into results. Where those foundations are weak, extra output only spreads the mess faster.
The next time AI hands over a first version, ask two questions before merging. Can the reviewer explain it without the chat log? Has someone agreed to own it six months from now? Merge when both answers are yes. If you haven’t yet decided where AI should stop while writing code, see Can a Coding Agent Take This Issue? Only If You Can Describe the First Diff. If review happens on a phone or another interface with incomplete information, see Before Merging AI-Written Code From Your Phone, Let Repository Rules Guard the Gate.
AI handoff card
AI has just handed over a set of code changes, and I want to judge whether it's worth accepting before merging.
The method comes from this article: https://boosterminiclass.com/en/posts/ai-code-change-ownership-price-check/
Its view: AI made writing a first version cheap, but the cost of review and maintenance didn't fall. The first version is a price check. Before merging, find out three things: whether the change went beyond its scope, whether the reviewer can explain it without the AI chat log, and whether someone has agreed to maintain it six months from now.
Ask me 3 questions first:
1. What was the original requirement, which files did the AI change, and which dependencies did it add?
2. Can the reviewer explain what the change solves, how data flows, and how to roll back if it fails?
3. Is there a named maintainer for this code, and have they agreed to take it on?
Based on my answers, give me:
- Whether the change goes beyond the requirement, and which parts the AI may have done along the way;
- The state of each of the three costs, producing, reviewing, and maintaining, and the evidence still missing;
- A single recommendation: merge / redo at a smaller scope / stop, with reasons;
- One smallest next step that can be done now.
Don't modify any files. Mark anything without evidence as "to confirm" rather than filling it in. Whether to merge is up to the person responsible for the project.
References
- GitHub Blog: The cost of saying yes has changed — https://github.blog/engineering/the-cost-of-saying-yes-has-changed/ (2026-07-17)
- arXiv (EASE 2026): To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — https://arxiv.org/abs/2605.06464 (2026-05-07)
- DORA: State of AI-assisted Software Development 2025 — https://dora.dev/research/2025/dora-report/ [accessed: 2026-10-11]
