The most expensive part of a small feature request used to be writing the code. According to GitHub engineer Dalia Abuadas, it is now usually the meeting about whether to write the code at all. That single sentence reframes a quiet but real shift in how software teams should make scope decisions in the age of AI-generated patches GitHub Engineering: The cost of saying yes has changed.
It is not a call to abandon engineering judgment. It is a recognition that one of the oldest instincts in the trade — push back hard on every “small ask” — now rests on an assumption that is quietly breaking: that writing the first version of the code is the expensive step. For a specific class of change, it no longer is.
The meeting became the bottleneck
Abuadas frames the problem with a familiar pattern. Someone asks for a trivial-sounding change: surface a last_active_at timestamp that already exists in the backend on a settings page. The team spends forty minutes in a thread. One person says it sounds risky. Someone remembers a related migration from two years ago. Someone mentions the deadline. The group eventually lands on “probably a day or two, could be more” — with low confidence, primarily because nobody has actually tried it GitHub Engineering.
That process made sense when trying was the expensive part. You had to stop what you were doing, load the context into your head, make the change by hand, write the tests, and only then discover the second- and third-order consequences. When the first attempt is cheap, defending the boundary can cost more than crossing it. An agent can produce that first patch in roughly the time the thread takes to warm up. The patch is not free and is definitely not automatically correct — but it is cheap enough that the smart move is often to stop guessing and look at a real diff.
This is the core behavioral change: the debate about scope is now frequently more expensive than the patch it is debating.
The first patch is a price check, not the product
The mistake teams make, Abuadas argues, is treating the generated patch as the deliverable. It is not. It is a probe — a way to turn an abstract scope argument into a concrete artifact you can interrogate:
- Does it 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 are better questions than “does this feel like scope creep?” because now you are arguing from evidence instead of from vibes. If the last_active_at field comes back as a four-line diff with a passing test, ship it — the debate was the expensive part. If the same request comes back touching the auth middleware, you have learned the request was never small, and you learned it in thirty minutes instead of two days.
Crucially, this is not letting the AI decide. It is using the AI to make human judgment cheaper and better-informed. The human still owns the call; the model just removed the blank-page tax that used to precede it.
Cheap to write is not the same as cheap to own
Here is the trap, and Abuadas calls it the most important distinction of the AI era: a change is not cheap simply because the code was cheap to generate. It is cheap only if a human can confidently review and own the result. A thousand-line diff that technically passes but nobody wants to own is not a cheap change — it is a deferred cost.
So the dividing line is not “can an agent write this?” It is “can a person validate it?” Adding a display field that already exists in the backend is usually cheap. Changing authorization behavior is not cheap, no matter how clean the diff. Refactoring a well-tested helper is usually cheap. Changing data-retention semantics is not cheap. Plenty of changes still deserve a hard no even when the code is trivial — anything that moves the product contract, creates a support burden, or touches privacy, billing, or compliance. AI lowers the cost of producing a candidate; it does nothing to lower the cost of owning one.
That framing aligns with how GitHub itself describes its engineering culture, where principles like “optimize for the person after you” and tight ownership of behavior are treated as non-negotiable GitHub engineering principles. The tooling changed; the ownership bargain did not.
Where scope discipline moves now
Traditionally, scope discipline happened before implementation, because implementation was the expensive thing to protect. Abuadas’s recommendation is to move some of that discipline to review. That does not mean skipping planning — it means being precise about which planning actually pays off.
Before relitigating a small change, ask for a constrained attempt. The constraints are the whole point:
- Produce the smallest possible patch.
- Keep it behind the existing feature flag.
- Do not change a contract, a privacy boundary, or a billing path.
- Attach the diff to the scope conversation instead of a paragraph of speculation.
When the candidate is cheap and well-bounded, the review becomes the moment of truth — and the human reviewer is answering a sharper question than “should we?” They are answering “is this safe to own?” That is a question engineers are genuinely good at, and it is far cheaper to answer against a real artifact than against a thread of maybes.
The takeaway for teams
The lesson is not “say yes to everything” — that is the caricature, and Abuadas explicitly preserves the instinct to push back on contract-changing, privacy-, billing-, or compliance-touching work. The lesson is that the cost curve moved. Writing got cheap; owning did not. So the leverage is in spending your expensive human attention on ownership and review, and spending a near-free probe to collapse the ambiguity that used to eat the meeting.
Teams that internalize this replace two-day scope debates with thirty-minute evidence checks, ship the genuinely small things faster, and still slam the door on the changes that actually carry risk. The cost of saying yes did change — but only because the cost of finding out what “yes” really means finally dropped.
