The expensive part of a request has moved
Engineering instincts were formed in an era when writing code was the biggest cost in delivering a change. A two-hour modification could become a two-week distraction, so we learned to challenge requests before committing. That instinct isn't wrong—tests, rollout plans, edge-case thinking, and long-term ownership all still carry real weight.
But the balance has shifted. For a certain class of work, generating a first version of a change is no longer the expensive step. The bottleneck has moved to the process around it: the deliberation about whether something is worth doing, how risky it might be, and where it fits in the roadmap. When a request can be turned into a concrete candidate quickly, the cost of a debate can easily exceed the cost of simply trying.
Asking for a diff instead of an opinion
A common pattern: someone requests a small addition—say, surfacing a last_active_at timestamp that already exists in the backend on a settings page. The natural reaction is a defensive discussion. Someone questions the risk. Someone recalls an old migration. Someone cites a deadline. After forty minutes, the consensus is usually “a day or two, possibly more,” based on nothing concrete.
This made sense when trying was the costly step. You’d need to context-switch, load the relevant system into your head, hand-write the change, build tests, and then discover indirect consequences. But when an agent can produce the first patch quickly in the time the thread takes to warm up, the smart move is often to stop guessing.
That said, the generated patch is not the final deliverable. It is a probe—an artifact for interrogation:
- Does it touch only the expected files, or does it sprawl across packages?
- Are tests straightforward, or does the change resist them?
- Does it preserve existing abstractions?
- Does it surface an unplanned product decision?
- Would you comfortably own the behavior it introduces six months from now?
These are more effective filters than “is this scope creep?” because they force the argument to be grounded in evidence. If the last_active_at addition comes back as a four-line diff with passing tests, the debate was the most expensive part and should simply end. If the same request returns touching the auth middleware, you’ve learned the request wasn't small at all—and with far less time spent.
Production cost and ownership cost are different metrics
The central trap: code being cheap to generate does not make the change itself cheap. A change is only cheap if a human can confidently review and own the result.
A thousand-line diff that meets technical requirements but no one wants to maintain is not a cheap change—it’s a deferred liability. For that reason, the dividing question changes. You are not asking “can an agent write it?” but rather “can a person validate it?”
- Adding a display field backed by existing data is typically cheap.
- Altering authorization behavior is never cheap, regardless of diff cleanliness.
- Refactoring a well-tested utility is usually cheap.
- Adjusting data-retention semantics is inherently costly.
Many changes will still warrant a hard no even when the underlying code is trivial to produce—anything that becomes support burden or touches privacy, billing, compliance, or product contracts. AI reduces the expense of producing a candidate. It does not reduce the expense of owning one.
Move scope discipline toward review
Traditionally, scope control happened before implementation because coding was the valuable resource to protect. When a generation attempt is fairly cheap, that discipline can be moved later in the process. Planning is not obsolete; only the kind of planning that occurs without evidence adds little. Real planning now means asking upfront for a constrained attempt:
- Produce the smallest possible patch, behind an existing feature flag if needed.
- Keep the public contract unchanged.
- Add or update relevant tests.
- List every touched file and flag any uncertainty.
If the agent fails to produce a clean, scoped patch under those constraints, that is concrete proof the request carried more weight than assumed. If it delivers, the team now has a basis for an informed decision. Either way, the question transforms from “is this in scope?” to “here is what it actually costs—can we live with it?”
Pricing uncertainty is the new core skill
Strong engineers in an AI-supported workflow will not be those who grant every request, nor those who automatically decline them. They will be the ones who can rapidly evaluate what kind of risk a request embodies—knowing when it hides a product decision, when review will outpace writing, and when the fastest responsible answer is a quick experimental attempt backed by focused constraints.
That last scenario is what is genuinely new. Historically, “try it and see” meant taking a developer away from other work for a day or more. Now inputs, in the right situations, it may only warrant a purposeful assignment to an agent against explicit limitations, yielding a concrete result used to reach a better position.
Scope creep concerns remain valid. But saying “no, because any new code is already too costly” is substantially weaker reasoning than it was two years ago—just as producing code is now cheaper, while reviewing and owning that code is not. Attention should therefore shift from “is this work?” toward “where is the real cost?” For a small, bounded request, that assessment itself is often the deciding step. So the cost of saying yes has changed. The cost of an automatic no should catch up as well.
