I wrote recently about how Agile is bending under the weight of AI-assisted development. The unit of work is getting larger, iterations are happening on complete features instead of thin slices, and the old assumptions about how to decompose work are shifting.
There’s a sneakier problem hiding inside that shift. When every next feature is just one more prompt away, the hardest part of the job isn’t building. It’s stopping.
The “one more prompt” trap#
Before AI, projects had a natural governor built in. The next task on the backlog would take a day, maybe two. That friction created a decision point. Is this feature worth the time? Does it need to ship now, or can it wait? The cost of implementation forced the conversation.
AI removed the friction, but the decision point still matters. In fact, it matters more.
When your AI agent can scaffold a new feature in fifteen minutes, “one more prompt” feels harmless. You already built the notification preferences system. Why not add granular per-channel controls? That’s just one more prompt. Why not add a digest mode? Another prompt. Why not add a scheduling UI so users can set delivery windows? The agent will have it done before your coffee gets cold.
Each addition is small and cheap in isolation. But you just turned an MVP notification system into a feature-rich beast that needs testing, documentation, edge case handling, and ongoing maintenance. None of that was in the original scope. You didn’t plan for it. You just kept prompting.
This is Parkinson’s Law applied to code. Work expands to fill the capacity available. Give a team more time and they’ll find ways to use it. Give a developer an AI agent that makes building nearly free, and they’ll keep building past the point where they should have shipped.
Estimation is uncharted territory#
This creates a genuine problem for scoping and estimation. The old heuristic of complexity equals time is breaking down. Tasks that used to take a week might take a day. Tasks that seemed trivial might take longer because the AI generates a plausible-looking solution that fails in subtle ways. Even experienced engineers struggle to predict timelines when the relationship between complexity and effort keeps shifting underneath them.
Does AI cut every project to half the time? A third? A fifth? The honest answer is: nobody knows yet. It depends on the task, the codebase, the model, and whether the problem is greenfield or tangled up in production constraints. New models keep pushing the boundary of what’s “just one prompt away,” which means any estimate you make today might be wildly wrong in six months.
What we do know is that the old safety valve is gone. When a hard task took a week, you had a week of natural friction preventing scope creep. When that same task takes an afternoon, you have the rest of the week to keep adding things nobody asked for.
Engineers as taste makers#
This is where the role of the engineer changes in a way that most teams haven’t caught up to yet.
When building is cheap, the valuable skill isn’t building. It’s taste. Knowing what belongs in the product and what doesn’t. Knowing when a feature is complete enough to ship and when you’re gold-plating. Knowing the difference between “this needs one more iteration” and “this is done, I just want to keep tinkering.”
That’s a product sense skill, not a technical skill. And it’s one that most engineering cultures don’t develop deliberately. We train engineers to solve problems, not to decide which problems are worth solving right now. We celebrate thoroughness and completeness, not the discipline to ship something 80% polished because the last 20% doesn’t matter yet.
The engineers who thrive in an AI-assisted world will be the ones who can look at a working feature and say “this is the MVP, ship it.” Not because they can’t make it better, but because they understand that shipping something good today beats shipping something perfect next week. That’s always been true in theory. AI makes it true in practice every single day, because “next week’s perfect version” is now “two hours from now” and the temptation to chase it is constant.
The real definition of done#
Every process framework has a “definition of done.” Most teams treat it as a checklist: tests pass, code reviewed, documentation updated. That checklist doesn’t protect you from scope creep driven by cheap implementation.
What teams need now is a “definition of enough.” Before you start building, answer: what does this feature need to do to be shippable? Not ideal. Not complete. Shippable. Write that down. When the AI agent hands you a working implementation that meets that bar, ship it. Resist the pull of one more prompt.
This is harder than it sounds. Every engineer has felt the gravitational pull of “while I’m in here, I might as well…” That instinct used to be moderated by the cost of implementation. Now the cost is near zero, so the only thing standing between a clean MVP and a bloated feature is the engineer’s judgment.
That judgment, the ability to decide when something is fully baked and to ship the thing, is becoming one of the most valuable skills on any engineering team. It’s not a skill you can automate. It’s not a skill the AI agent has. It’s a fundamentally human call about what’s good enough, and making it well requires understanding the user, the business context, and the maintenance cost of everything you add.
Build less, ship more#
The teams that will win in an AI-assisted world aren’t the ones that build the most. They’re the ones that ship the right amount. They’ll treat their AI agents like a kitchen with an unlimited pantry: just because you can make twelve courses doesn’t mean the dinner needs them.
The bottleneck was never the code. It still isn’t. Now the bottleneck is the discipline to stop writing code and start shipping it.