GitHub Engineer Argues the Cost of Saying 'Yes' Has Changed in the AI Era

Mon, 20 Jul 2026 00:00:00 +0000

The Great Recalculation of Engineering Scope

“The most expensive part of a small feature request used to be writing the code. Now it’s usually the meeting about whether or not to write the code.”

That opening line from GitHub software engineer Dalia Abuadas captures the central argument of her widely-discussed GitHub Blog post — a thoughtful framework for how AI is quietly rewriting the economics of engineering decision-making.

Published July 17 on the GitHub Blog, the post addresses a tension many engineering teams are feeling: when AI agents can produce a working patch in minutes, does the instinct to reflexively push back on “small asks” still hold?

The Debate Often Costs More Than the Patch

Abuadas describes a pattern familiar to any senior engineer — a request for a seemingly minor change, say surfacing a last_active_at timestamp that already exists in the backend. The team spends forty minutes debating risk, recalling a migration from two years ago, citing deadlines, eventually estimating “maybe a day or two.” All without anyone having tried to implement it.

That process made sense when writing code was the bottleneck. Now, as she notes, an AI agent “can produce that first patch in the time the thread takes to warm up.” Not automatically correct, but cheap enough that the smart move is often to stop guessing and look at a real diff.

The First Patch Is a Price Check, Not the Product

The article’s key insight is that AI-generated code should be treated as a probe, not a deliverable. The generated patch turns abstract scope arguments into concrete evidence teams can interrogate: Does it touch the expected files or sprawl across five packages? Are the tests obvious? Does it preserve existing abstractions? Would you be comfortable owning this six months from now?

If a request returns as a four-line diff with passing tests, ship it. If it touches the auth middleware, you learned the request was never small — in thirty minutes instead of two days.

Cheap to Write Is Not Cheap to Own

Abuadas’s most critical warning: “A change is not cheap just because the code was cheap to generate. It’s cheap only if a human can confidently review and own the result.”

A thousand-line diff that nobody wants to own is a deferred cost. Adding a display field? Usually cheap. Changing authorization behavior? Not cheap. Refactoring a tested helper? Cheap. Changing data-retention semantics? Not cheap. Anything touching privacy, billing, or compliance still deserves a hard no — AI lowers the cost of producing a candidate, but does nothing to lower the cost of owning one.

The New Skill Is Pricing Uncertainty

The best engineers in an AI-assisted world, Abuadas argues, won’t be those who say yes to everything or no to everything. They’ll be the ones who can price uncertainty fast — knowing when a request is a product decision in disguise, and when a change is small enough that the fastest answer is to just try it.

“That last one is genuinely new,” she writes. “‘Try it and see’ used to mean pulling a developer off other work. Now it means handing an agent a bounded assignment and using the result to make a better call.”