Engineers Are Still Saying No For A Reason That Stopped Being True
Saying no used to be free. GitHub is noticing that for one class of change, the debate now costs more than just building the thing.
TLDR
There is a shift happening across the industry, and GitHub’s engineering blog put a name on it last week: engineering’s oldest reflex is now misfiring on a specific class of work.
The argument goes like this. Scope discipline happens before implementation because implementation was the expensive thing to protect. That was correct for decades. It is no longer correct for small, bounded changes, because producing the first patch got cheap enough that debating whether to produce it can cost more than producing it.
The framing is the part worth stealing. The generated patch is not the deliverable. It is a price check. And the line that separates cheap changes from expensive ones is not “can an agent write this,” it is “can a person validate it.”
The Forty Minute Thread
Start with a pattern that shows up on nearly every team right now.
Someone asks for a small change. Surface a last_active_at timestamp that already exists in the backend on a settings page. That is the whole request.
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. They land on “probably a day or two, could be more,” with low confidence, and the reason confidence is low is that nobody has actually tried it.
Every instinct in that thread is defensible. Engineers learn early that most small asks are not small. They need tests. They need a rollout plan. They need someone to think through the edge cases and own the behavior after it ships. A two hour change becomes a two week distraction when it lands in the wrong part of the system.
Nobody is arguing you should give that instinct up. The thing worth examining is the assumption underneath it, which is that writing the first version of the code is the expensive step.
That process made sense when trying was expensive. You had to stop what you were doing, load the context into your head, make the change by hand, write the tests, then discover the second and third order consequences. Guessing was cheaper than trying, so the industry got very good at guessing.
An agent can produce that first patch in the time the thread takes to warm up. Not free. Not automatically correct. But cheap enough that defending the boundary now sometimes costs more than crossing it.
A few editions worth your time:
The CAP Theorem Lie Everyone Keeps Repeating
From Prompts to Partners: How LinkedIn Built Its Agentic Stack
How Pinterest Runs Spark at Scale with Moka
The Patch Is A Price Check
This is where most teams will get it wrong.
The mistake is treating the generated patch as the deliverable. It is a probe. You are not asking the agent to solve the problem, you are asking it to tell you what the problem costs.
The patch turns an abstract scope argument into an 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 product decision nobody has made? Would you be comfortable owning this behavior six months from now?
Those beat “does this feel like scope creep” because now you are arguing from evidence instead of vibes.
If last_active_at comes back as a four line diff with a passing test, ship it. The debate was the expensive part. If it comes back touching the auth middleware, the request was never small, and you learned that in thirty minutes rather than two days.
Both outcomes are useful. That is what makes it a price check and not a gamble.
One line from the GitHub piece deserves repeating: this is not letting the AI decide. It is using the AI to make human judgment cheaper and better informed.
Cheap To Write Is Not Cheap To Own
This is the strongest part of the argument and the one most likely to get skimmed past.
A change is not cheap 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 with good test coverage. You have not saved anything, you have moved the bill to whoever inherits the behavior.
So the dividing line is not “can an agent write this.” It is “can a person validate it.”
Four examples sort cleanly. Adding a display field that already exists in the backend is usually cheap. Changing authorization behavior is not, no matter how clean the diff. Refactoring a well tested helper is usually cheap. Changing data retention semantics is not, even if the diff is a config line, because the entire cost lives outside the code.
Plenty of changes still deserve a hard no when the implementation is trivial. Anything that moves the product contract. Anything that creates a support burden. Anything touching privacy, billing, or compliance.
AI lowered the cost of producing a candidate. It did nothing to the cost of owning one. Teams that do not separate those two numbers are going to accumulate a very specific kind of debt.
Move The Discipline Closer To The Evidence
Some scope discipline can move from planning to review. Not all of it. Some.
That does not mean skipping planning. It means being precise about which planning pays for itself. Debating the shape of a service boundary pays. Debating whether a display field takes a day or two, when finding out takes thirty minutes, does not.
The suggestion is to ask for a constrained attempt before relitigating a small change, and the constraints are the whole point:
Produce the smallest possible patch. Keep it behind the existing feature flag. Do not change the public contract. Add or update tests. List every file you touched and call out anything risky.
If the agent cannot produce something clean under those constraints, the request was bigger than anyone thought, and you know it carries real ownership cost before a single person commits to a date. If it can, that tells you something too.
Either way you have replaced “is this in scope” with “here is what it costs, do we want to pay it.” The second question is answerable. The first one never really was.
The New Skill Is Pricing Uncertainty
Here is the part that will matter for careers.
The engineers who do well in an AI assisted world will not be the ones who say yes to everything, and they will not be the reflexive no. They will be the ones who can price uncertainty fast.
They will know when a request is a product decision wearing an implementation costume. They will know when review will be harder than writing, which is now a common and badly underrated failure mode. And they will know when a change is bounded enough that the fastest responsible answer is to go find out.
That last one is what actually changed. “Try it and see” used to mean pulling a developer off other work for a day. Now, for the right kind of task, it means handing an agent a bounded assignment and using the result to make a better call. Less time guessing, more time supervising. Less time treating implementation as a black box you estimate blind.
What To Do With This
Pick the next small request in your team’s Slack.
Before anyone estimates it, before anyone argues about the sprint, write the constraints and ask for the patch. Then run the review questions against what comes back. Does it touch what you expected. Can it be tested. Would you own it.
Do this on small, bounded, low blast radius requests only. Display fields, config surfaces, well tested helpers. Nothing near auth, billing, retention, or the public API. Those still get the old process, and they should.
You will learn two things quickly. How often your team’s instincts were correct, which is more often than the AI optimists want to admit. And how often you spent a day of collective engineering attention avoiding thirty minutes of finding out.
The Pattern Worth Internalizing
Scope creep is real and it will still kill your quarter. None of this argues for saying yes to more things.
It argues that one particular reason for saying no got weaker. “No, because any new code is too expensive” carried real weight two years ago. It carries less now.
The cost of producing code dropped. The cost of understanding, reviewing, and owning it did not move at all. So the question shifted from “is this more work” to “where is the real cost.”
Sometimes, for a small bounded change, the real cost is just finding out.
The cost of saying yes has changed. The cost of saying no should change with it.
Source: The cost of saying yes has changed, The GitHub Blog, July 17, 2026.
P.S. What is the smallest request your team has ever spent the most time debating? Reply and tell me. I suspect the ratios are worse than any of us want to admit.