The Cost of Saying Yes Has Changed: AI and the New Era of Engineering Decisions
Engineering is a discipline of trade-offs. For decades, the most expensive part of a small feature request was writing the code. But as AI tools like GitHub Copilot become more integrated into our workflows, that assumption is crumbling. Now, the most expensive part is often the meeting about whether or not to write the code. This shift is subtle but profound, and it’s quietly breaking some of our long-held engineering instincts.
The Old Instinct: Push Back on Small Requests
As engineers, we’ve been trained to push back on what appear to be small requests. Why? Because they’re rarely as small as they seem. Even a seemingly innocuous change—like surfacing a last_active_at timestamp on a settings page—can spiral into a two-week distraction if it touches the wrong part of the system. We instinctively ask questions like:
- Is this really needed?
- Does it belong in this release?
- Does it change a contract we already agreed to?
These questions are valid, but they rest on an outdated assumption: that writing the first version of the code is the most expensive step. For certain types of changes, that’s no longer true. If you can tell the difference between these changes and the rest, you can replace “is this in scope?” with a question you can answer in 30 minutes instead of debating for two days.
The Debate Often Costs More Than the Patch
Here’s a pattern you might recognize: someone asks for a small change. The team spends 40 minutes in a thread debating it. One person thinks it sounds risky. Someone else remembers a related migration from two years ago. Another person mentions the upcoming deadline. Eventually, the group settles on “probably a day or two, could be more,” with low confidence, because no one has actually tried it.
This 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 tests, and discover the second- and third-order consequences. But when the first attempt is cheap, defending the boundary can cost more than crossing it.
Enter AI-generated code. An agent can produce a first patch in the time it takes for the debate to warm up. It’s not perfect, and it’s definitely not automatically correct, but it’s 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 mistake is to treat the AI-generated patch as the final deliverable. It isn’t. It’s a probe—a way to turn an abstract scope argument into a concrete artifact you can interrogate. With a real diff in hand, you can ask better questions:
- 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 existing abstractions?
- Does it quietly require a new product decision?
- Would you be comfortable owning this behavior six months from now?
These are far more useful questions than “does this feel like scope creep?” because now you’re arguing from evidence instead of 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. But if the same request touches the auth middleware, you’ve learned that the request was never small—and you learned it in 30 minutes instead of two days.
This isn’t about letting the AI decide. It’s about using AI to make human judgment cheaper and better-informed.
Cheap to Write ≠ Cheap to Own
Here’s the trap, and it’s the most important distinction of the AI era: a change is not cheap just because the code was cheap to generate. It’s only cheap 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’s a deferred cost. So the dividing line isn’t “can an agent write this?” It’s “can a person validate it?” For example:
- 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. This includes anything that moves the product contract, creates a support burden, or touches privacy, billing, or compliance. AI lowers the cost of producing a candidate, but it does nothing to lower the cost of owning one.
Move Scope Discipline Closer to the Evidence
Traditionally, scope discipline happened before implementation because implementation was the expensive thing to protect. Now, some of that discipline can move to review. That doesn’t 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 an existing feature flag.
- Don’t change the public contract.
- Add or update tests.
- List every file you touched and call out anything risky.
If the agent can’t produce a clean patch under these constraints, the request was bigger than you thought, and you know it carries a real ownership cost before anyone commits to it. If it can, that tells you something too. Either way, you’ve replaced “is this in scope?” with “here’s what it costs. Do we want to pay it?”
The New Skill: Pricing Uncertainty
The best engineers in an AI-assisted world won’t be the ones who say yes to everything, and they won’t be the ones who reflexively say no. They’ll be the ones who can price uncertainty fast. They’ll know when a request is a product decision wearing an implementation costume, when review will be harder than writing, and when a change is small enough that the fastest responsible answer is to just try it.
That last one is genuinely new. “Try it and see” used to mean pulling a developer off other work. 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, more time evaluating concrete artifacts.
Scope creep is still real. But “no, because any new code is too expensive” is a much weaker argument than it was two years ago. The cost of producing code has dropped. The cost of understanding, reviewing, and owning it didn’t. So the question worth asking has shifted from “is this more work?” to “where’s the real cost?” And 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.