Writing code used to be the expensive part of a small feature request. Now, according to Dalia, a software engineer on GitHub's Copilot Agent Control Plane team, the bigger drain is often the meeting to decide whether the code should be written at all.
This shift is forcing engineering teams to rethink a reflex that has shaped software development for decades: the instinct to push back on every "small ask" because implementation carries hidden costs. Tests, rollout plans, edge cases, and long-term ownership can turn a two-hour coding job into a two-week distraction. But when an AI agent can produce a first draft in minutes, the cost of trying has collapsed. The real cost now sits elsewhere.
The Problem with Scope Debates in the AI Era
The pattern Dalia describes is familiar to most engineering teams. A stakeholder asks for something minor, like surfacing an existing backend timestamp on a settings page. The team burns forty minutes in a Slack thread. Someone flags risk. Someone dredges up a migration from two years ago. Someone mentions the deadline. The estimate lands at "probably a day or two, could be more," with low confidence, because nobody has actually attempted the change.
This process made sense when trying was the expensive part. A developer had to drop their current task, load context, write the code manually, add tests, and then discover second-order consequences. When that cycle took days, defending scope boundaries was rational. But when an agent can generate a patch in the time it takes the thread to heat up, the defense itself becomes the waste.
Using AI as a Probe, Not a Deliverable
The critical mistake, Dalia argues, is treating the AI-generated patch as the final product. It isn't. It is a probe, a concrete artifact that replaces abstract scope arguments with inspectable evidence. Instead of asking "does this feel like scope creep?", the team can now ask harder, better questions: How many files does this actually touch? Does it pass existing tests? Does it change any public contracts? Does it stay behind a feature flag?
If the probe comes back as a four-line diff with passing tests, the debate was the expensive part. Ship it. If it touches auth middleware, the request was never small, and the team learned that in thirty minutes instead of two days. The AI did not make the decision. It made human judgment faster and better informed.
The Real Cost Hasn't Disappeared, It Moved
Here is the trap that Dalia flags as the most important distinction of the AI era. A change is not cheap just 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 maintain is not a cheap change. It is a deferred cost.
The dividing line, then, is not "can an agent write this?" It is "can a person validate it?" Plenty of changes still deserve a hard no even when the code is trivial: anything that shifts 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.
A New Discipline: Constrained Probes Before Debates
Traditionally, scope discipline happened before implementation because implementation was the expensive thing to protect. Now some of that discipline can move to review, but that does not mean skipping planning. It means being precise about which planning actually pays off.
Dalia proposes a specific constraint set for these probes: produce the smallest possible patch, keep it behind an existing feature flag, do not change the public contract, add or update tests, and list every file touched with explicit risk callouts. If the agent cannot produce a clean patch under those constraints, the request carries real ownership cost before anyone commits. If it can, the team has a concrete price tag. Either way, "is this in scope?" becomes "here's what it costs. Do we want to pay it?"
This reframing has broader implications for how engineering teams structure their workflows. It suggests a future where the bottleneck shifts from writing code to reviewing and validating it, a trend already visible in teams that have adopted AI-assisted development at scale. The engineers who thrive will be those who can price uncertainty fast, who know when a request is a product decision disguised as an implementation question, and when review will be harder than writing.
What Comes Next
The cost of producing code has dropped. The cost of understanding, reviewing, and owning it has not. 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 simply finding out. Watch for engineering teams to rewrite their intake playbooks around probes rather than estimates, and for the best teams to treat review bandwidth, not coding time, as their scarcest resource.