GitHub Turns the Cost of Code Review Into a Pricing Problem

Engineering teams have a long-standing instinct: interrogate a “small” change before anyone writes code, because a two-hour fix can turn into a two-week distraction if it touches the wrong system. In a July 17 post on the GitHub Blog, GitHub’s Dalia Abuadas argues that instinct is now aimed at the wrong cost. AI coding agents have made a first draft of a change nearly free to produce. They have done nothing to make that change cheaper to own, and treating the two as the same thing is starting to waste real engineering time.

The Debate Now Costs More Than the Patch

Abuadas opens with a scenario many engineering teams will recognize: someone asks for a small change, such as surfacing a last_active_at timestamp that already exists in the backend on a settings page. The team spends forty minutes debating it in a thread. One person calls it risky. Someone remembers a related migration from two years earlier. Someone else brings up the deadline. The group eventually settles on “probably a day or two, could be more,” with low confidence, mostly because nobody has actually tried it.

That process made sense as long as writing the first version of the code was the expensive step. Under that assumption, relitigating scope before implementation was the cheapest way to avoid wasted engineering time. Abuadas’s argument is that the assumption is quietly breaking for a specific class of change: an AI coding agent can now produce a first patch in roughly the time the debate thread takes to warm up.

A Generated Patch Is a Price Check, Not a Deliverable

The mistake, in the post’s framing, is treating that AI-generated patch as the finished product. It is not free, and it is not automatically correct. It is a probe: a way to turn an abstract scope argument into a concrete artifact a reviewer can interrogate directly. Abuadas lists the questions that matter once a real diff exists:

• Does the patch touch the files you expected, or does it sprawl across five packages?
• Are the tests obvious, or does the change resist being tested?
• Does it preserve the existing abstractions?
• Does it quietly require a new product decision?
• Would you be comfortable owning this behavior six months from now?

Those questions are more productive than the pre-implementation guessing game most teams default to, because they are grounded in a real diff instead of a hypothetical one.

Cheap to Write Is Not Cheap to Own

The post draws a firm line between the cost of producing a candidate change and the cost of owning it afterward.

“AI lowers the cost of producing a candidate. It does nothing to lower the cost of owning one.”

Abuadas is explicit that plenty of changes still deserve a hard no even when the code itself is trivial to generate: anything that moves the product contract, creates a support burden, or touches privacy, billing, or compliance. Some kinds of changes stay cheap no matter who, or what, writes them. Changing data-retention semantics is not one of those, no matter how quickly an agent can draft the diff.

Moving Scope Discipline Closer to the Evidence

Scope discipline has traditionally happened before implementation, because implementation was the expensive thing worth protecting. Abuadas argues that some of that discipline can now move later, into review, without skipping planning altogether; the shift is about being precise on which planning actually pays off.

Her proposed pattern: before relitigating a small change in a meeting, ask for a constrained attempt instead. Keep the patch as small as possible. Keep it behind the existing feature flag. Do not change the public contract. Flag anything that looks risky. If the agent cannot produce a clean patch inside those constraints, the request was bigger than it looked, and the team now knows that before anyone commits to it. If it can, the open-ended “is this in scope” debate becomes a concrete question instead: here is what this costs, do we want to pay it.

The New Skill Is Pricing Uncertainty, Not Gatekeeping

Abuadas’s closing argument reframes what makes a strong engineer in an AI-assisted codebase. It will not be the person who says yes to every request, and it will not be the person who reflexively says no; it will be whoever can price uncertainty quickly, recognizing when a request is really a product decision wearing an implementation costume, when review will take longer than writing the patch, and when a change is small enough that the fastest responsible answer is simply to try it.

Abuadas calls that last option the genuinely new part: “try it and see” used to mean pulling a developer off other work entirely. AI coding agents change that calculus for a specific class of low-risk, well-bounded changes, where attempting the change directly, inside the constraints described above, is now faster and more informative than debating it first.

Why This Matters Beyond One Engineering Blog

The framework Abuadas describes is not really about any specific AI tool. It reads as a response to a structural shift that every engineering organization adopting AI coding agents will eventually run into: once drafting a patch stops being the bottleneck, the bottleneck moves to whoever has to decide whether that patch is safe to own. Teams that keep applying pre-AI scope discipline, debating hypothetical changes in meetings before anyone writes code, keep paying meeting costs that AI coding agents have already made unnecessary for a real subset of requests.

The harder discipline is the one the post is actually asking for: knowing which changes are safe to hand to a constrained, flagged, small-blast-radius attempt, and which ones, anything touching compliance, billing, or a public contract, still belong in the meeting first. Getting that triage wrong in either direction has a cost. Too cautious, and a team gives up the speed AI agents actually offer. Too loose, and a patch that looks like a five-minute fix quietly ships a product decision nobody signed off on.