Picture Monday's planning session. Your team estimates a story at five days. By Tuesday, the agent has already written the code and the tests. On Friday the story is still open: nobody had decided what happens when a customer has no billing address, and the answer took three days to arrive.
When coding stops being the expensive part, the software lifecycle does not disappear: its bottleneck moves. The time the agent saves writing code is lost on the assumptions nobody said out loud before starting.
What happens when AI plans alone
Adriana Caraeni, Alexander Shick and Andrew Lan compared three ways of planning a sprint on a real client deliverable at a mid-sized digital agency: AI only, people only, and both together. Planning with AI alone was the fastest and the cheapest, but it «significantly degrades risk capture rates»: it captured fewer risks and left more rework from assumptions nobody had stated.
Their conclusion questions something many teams take for granted: «that efficiency equates to effectiveness». They suggest leaving estimation and backlog formatting to tools, and keeping the conversation about risks and ambiguity for people.
Limit It is a seven-page preprint, under review, run at a single agency, and its abstract does not give the sample size. It works as a signal of where to look in your team.
Where the time goes now
If the code comes out in hours, the pace of the cycle is set by how long your team takes to answer a question. What happens with this edge case? Who decides whether the API contract changes? Those questions used to come up halfway through implementation and got solved along the way, because coding left time to think. With an agent they come up in minutes. Then they sit waiting for someone, as in meta-work with agents, or the agent answers them itself with whatever seems reasonable to it.
Something similar happened at a public-sector client. External suppliers were coding with AI without being integrated into the team's workflow or context. The pull requests, the proposed changes that get reviewed before they go into the code, kept getting more complex to make.
The phase that grows most is the one before the code: writing down what the team takes for granted. A two-line issue is not enough, for the reasons in why an issue is not a spec. One line per assumption, with the way to check it holds, already changes the week.
One question for your next planning session
Look at the last story that got delayed in your team. Was it delayed writing code or waiting for an answer? If it was the second, the shortcut is in planning: bring in whoever can answer and leave with the assumptions written down.
If you want to look at it with someone from outside, the diagnostic is free. Before that, you can see how we work with development teams in AI-Accelerated Development.
Frequently asked questions
How does the software development lifecycle change with AI?
The phases stay the same: understanding the problem, specifying, building, testing, deploying and operating. What changes is where the time goes. Writing the code can come down to hours, and the pace is set by how long the team takes to decide what the agent cannot work out on its own.
Do we need to switch methodology, for example to AIDLC?
Not necessarily. AIDLC (AI-Driven Development Life Cycle) is the methodology AWS introduced in July 2025 for an AI-driven development cycle, and there are other proposals. Before renaming your process, look at where your team's work waits today: if it waits for answers, the change lies in when and with whom the team decides.
Can AI plan the sprint on its own?
It can help with estimating and ordering the backlog. In an experiment published in April 2026 on a real client deliverable at a digital agency, planning with AI alone was faster and cheaper, but it captured fewer risks and left more rework from assumptions nobody had stated. The authors suggest leaving the conversation about risks and ambiguity to people.
Does that experiment apply to my company?
It works as a signal of where to look. It is a seven-page preprint under review, run at a single agency, and its abstract does not give the sample size. What is useful is to look at where stories get delayed in your team: writing code or waiting for an answer.
What is an unwritten assumption?
Any decision the team takes for granted that nobody has written down before starting: what happens if a customer has no billing address, who can change an API contract, what response time is acceptable. If nobody writes it down, the agent fills it in with whatever seems reasonable to it.
Does writing assumptions down mean long documents?
It does not have to. One line per assumption is enough, with the way to check it holds. That is the basis of Spec-Driven Development (SDD): writing down what the change has to do and the criteria for accepting it before anyone, person or agent, writes the code.
Sources
- Adriana Caraeni, Alexander Shick and Andrew Lan, «Cognitive Offloading in Agile Teams: How Artificial Intelligence Reshapes Risk Assessment and Planning Quality», arXiv:2604.13814, 15 April 2026 (under review).
- Raja SP, «AI-Driven Development Life Cycle: Reimagining Software Engineering», AWS DevOps & Developer Productivity Blog, 31 July 2025.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →