The biggest change AI brings to agile is not speed, it is audience.
For years, most delivery artefacts were written for humans who don't read large corpuses happy or reliably, but can ask clarifying questions and carry a lot of context in conversation. User stories, lightweight acceptance criteria, planning meetings, and Slack threads all made sense in that world.
AI coding agents change the economics of that arrangement. They can consume far more written context than a human teammate would tolerate in one sitting, but they are much less reliable at understanding and resolving certain types of ambiguity through conversation. They quickly execute, inconsistently fill gaps, and happily act on a partial understanding if you let them.
That creates a new problem for product and engineering teams. Much of our delivery process is still optimised for the wrong reader.
Anyone who has spent real time working with AI coding agents has felt this. A thin prompt can become a large diff before anyone has had much time to think. I have felt it in my own work too. The more easily agents turn intent into output, the more pressure moves onto the quality of the intent going in.
Anthropic's 2026 Agentic Coding Trends Report describes a shift in the human role. Engineers spend less time being only implementers and more time orchestrating agents, evaluating output, setting direction, and checking whether the system solves the right problem.
The shift raises a practical question for agile teams. What happens to the stories, tickets, review notes, acceptance criteria etc. They are no longer just prompts for human conversation. They are becoming inputs to a delivery system.
One thing is already clear though.
Specs are back.
This creates an understandable discomfort. Software teams used to write big specs before Agile told us, for good reasons, they were often part of the problem. So what is the right model?
The conversation crutch
Historically, big upfront requirements documents failed because they were too detached from delivery. The theory was that if you defined enough before building, delivery would become predictable. In practice, the documents went stale, change stayed expensive, and teams often shipped the wrong thing slowly.
Agile was a rational reaction to that failure. Extreme Programming shifted the emphasis from speculative documentation to engineering discipline. The Agile Manifesto reinforced the broader principle that working software matters more than comprehensive documentation. Ron Jeffries, one of the Manifesto's authors, described user stories as "conversation starters," not complete specifications. The point was not to eliminate thinking. It was to move detail into collaborative discussion at the moment of execution.
That model shaped a lot of my own career. I learned to compress my thinking into a few sentences and let close communication fill in the rest. If you wrote too much, people would not read it. That was not cynicism. It was usually true.
There was also a deeper reason it worked. A lightweight story was not supposed to transfer all knowledge by itself. It created a reason for the right people to talk. The handoff was not just a document; it was a conversation where the builder could ask questions, test edges, challenge assumptions, and notice when something did not quite fit.
The old agile bargain depended on a human reader who could generate and participate in the missing conversation. That assumption is no longer clearly safe.
So the question is not whether we should bring big specifications back. It is what replaces the old conversations when the reader is no longer only human.
Talking to the AI does not make the problem disappear. A back-and-forth with an agent can help you think through an idea, but a one-off chat is still a private conversation unless the useful parts become structured material the rest of the delivery loop can read.
The alignment gap gets harder to see
The Three Gaps model from Stephen Bungay's The Art of Action: How Leaders Close the Gaps Between Plans, Actions and Results is useful here. Bungay describes a gap between what we know and what we would like to know, a gap between the plan and what people actually do, and a gap between action and the effect it produces. He calls those the knowledge gap, the alignment gap, and the effects gap.
AI does not remove those gaps. It changes how visible they are. The alignment gap, in particular, can become insidiously harder to see. Closing it relies on two different questions that used to get mixed together in the normal friction of delivery.
The first is whether the team is aligned on the right intent. Are we actually planning to do the right thing, given the user need, strategy, trade-offs, constraints, and what we have recently learned?
The second is whether the plan contains enough practical information for someone else to execute it. Are the missing details implementation details, acceptance examples, edge cases, dependencies, or constraints that a builder needs before they can do the work?
AI is generally strong on the second question and can often infer missing implementation detail. It is much weaker at noticing missing thinking. The problem is this is not an easy gap to fill. Product intent still rests on human-owned judgment calls, made from layers of context that agents are nowhere near having yet. That makes weak product thinking easier to miss, because a plan can become working-looking output before anyone has had to test the edges or notice that the team is not actually aligned. If that happens repeatedly, the team does not just build the wrong thing faster. It builds new work on top of previous misunderstandings.
An agent can ask clarifying questions if you set the workflow up that way. It can point out missing decisions if you explicitly ask it to. But the default failure mode is different from a human team. A human builder often exposes misunderstanding while trying to make sense of the work. An agent is more likely to produce a plausible completion of the written instruction.
However, we also need to recognise that even explicit instructions are not guarantees. Birgitta Böckeler at Thoughtworks tested three spec-writing tools, Kiro, Spec Kit, and Tessl and found agents still skipped important instructions, while the generated artefacts became repetitive and heavy. Addy Osmani has described the same tension: vague prompts produce vague code, but overlong context is not a substitute for context quality. Anthropic's engineering team makes a similar point when they talk about context engineering and the limits of an LLM's attention budget.
That is why the new alignment problem is dangerous. The gap has not disappeared. It has moved into the spec, the agent's interpretation of the spec, and the review loop that decides whether the result is actually right.
Requirements are becoming the bottleneck
A Kaggle-hosted paper by Google employees, The New SDLC With Vibe Coding, observes that while AI makes coding faster, it compresses the software delivery lifecycle unevenly. Implementation that once took weeks can happen in hours, and teams are already experimenting with workflows where agents handle implementation, testing, and deployment in the background. However, parts of the process remain stubbornly human-paced. The bottleneck moves toward specification, evaluation, architectural judgment, and product judgment.
Andrew Ng makes the product version of that point in his piece on the Product Management Bottleneck. Agentic coding accelerates building software to a specification. Deciding what is worth building becomes the new constraint.
When delivery was slower, a vague story could survive for a while. There was time for discovery during delivery. Engineers would pull at the edges, product people would clarify, designers would adjust, testers would find gaps, and the story would accrete meaning as it moved across the board. The elapsed time of delivery created room for the missing conversation.
When the build-test-deploy part of the loop gets faster, ambiguity becomes more dangerous. An agent can turn a thin story into a large diff before the team has noticed the story was thin. Automated tests may tell you whether the code matches the tests. They do not tell you whether the tests represent the right product intent.
That is why "AI makes developers faster" is only the shallow version of the story. AI changes where the constraint sits. The scarce work is increasingly upstream of the agent and around the agent. What is the strategy and priority? Has it been written down well enough? Are we getting the right results from what we did?
Organisations that can do that work at the new pace of delivery will gain the real advantage.
Fortunately, writing is much cheaper now. You can now talk through an idea with an AI and turn it into structured material quickly. That does not make documentation good by default, but it removes one of the historical reasons teams avoided writing more of their thinking down.
Cheap writing does not mean every ambiguity should become another meeting. If alignment still depends on more human back-and-forth each time the work changes, the process slows around people just as delivery speeds up around agents. The useful move is to let conversation do what it is good at, then turn the useful parts into something the loop can carry forward.
Spec-writing tools are everywhere
A lot of people are arriving at the "write more structured input" approach at the same time. GitHub's Spec Kit, Amazon's Kiro, grassroots methods like BMAD, and a broader spec-driven development conversation are all responses to the same pressure: if agents do more of the downstream delivery work, the intent they receive has to get better.
The one-shot version of this is impressive. A large, carefully researched spec can get you from nothing to a surprisingly complete first build. You can see this pattern in demo videos, and I have used it myself to research an idea, write the spec, hand it to an agent, and let it build.
To be fair, the current generation of tools is not just one-shot spec capable. Spec Kit has evolving specs, Kiro supports refining requirements and syncing tasks, and BMAD includes correct-course and planning workflows. However, these tools are strongest once the work has already been chosen. It is easy to turn a Product Requirements Document (PRD) into requirements, turn requirements into design, turn design into tasks, then ask an agent to implement. Iteration inside a spec is not the same as product backlog management.
The most interesting questions, though, start the moment the first build exists, and in the messy upstream product space before work is ready for engineering. That is where I have spent most of my career. Does a problem matter? Is intent clear? What is now the next spec, and how is it connected to the backlog and overall strategy? Does work need splitting, reshaping or reordering? Is this item clear enough to hand off?
I feel the gap in currently available AI-suitable tooling, and the failure in ones I have seen and tested is treating the document, spec, or issue as if it solves the backlog problem by itself. A well-written spec can still be stale, too broad for the task, interpreted too locally by the agent, not the right thing to do next, or detached from the decisions and evidence that made it matter.
Agile discipline doesn't need to be replaced with a larger prompt. The backlog needs to be AI-enabled while preserving the habits that still matter: iterative work, clear ownership, sensible decomposition, explicit assumptions, scoped work, testable acceptance, review, evidence, and feedback.
That is the real shift.
Tooling for the backlog loop
Put these threads together and several linked problems emerge:
- The team still has to decide whether it is pursuing the right intent, not just whether a task contains enough implementation detail.
- Agents can make thin plans look executable by filling practical gaps, which can hide missing product thinking until review or production.
- Written instructions are not guarantees. Even a good spec can be skipped, over-weighted, or interpreted too locally unless the work is bounded and checked.
- Iteration has to be built into the process. The backlog needs to absorb new learning without losing the shape of the work: what matters, what is ready, what depends on what, and what should be handed to an agent next.
That points to a different kind of specification and operating model. Not one big document upfront, and not a loose story that relies on human conversation to fill the gaps, but many smaller specifications created and revised inside the delivery loop, each close to the work it governs.
Much of today's tooling starts after the first backlog decision has already been made. It can help shape and execute the selected item, but it is less clearly responsible for the product-management loop that decides what should be in the backlog, whether it is ready, how it should be split, what context belongs with it, and what should happen after the first implementation changes what you know.
The backlog loop is the layer I have been building Haven for. Haven is not magic for making models obey instructions, and it is not another place to track tickets after the work is already understood. It is a local-first, AI-native backlog manager.
You can read more about what Haven is and how it works in Introducing Haven.
The primary goal for Haven is to make good backlog practice fast and easy to maintain. You can capture the idea, clarify the assumption, split the work, attach relevant specs or research, mark what is blocked, decide whether it is ready, choose the next item, and update the backlog when implementation teaches you something. It also comes bundled with skills that help an AI be an effective expert partner in that process.
The point of giving the backlog structure is that AI can work across the backlog, not just inside one ticket. It can spot that one item is really three, ask what decision is missing, summarise research into a spec, explain why nothing is ready, or turn review feedback into the next backlog item.
AI can also do the backlog maintenance humans tend to avoid. Keeping every ticket, spreadsheet row, assumption, and follow-up item current is tedious, so backlog drift is normal. When a new metric changes your view of impact or cost of delay, AI can update the linked assumptions, affected items, priority order, and follow-up specs together.
Haven also keeps provenance for those changes. When work is split, merged, parked, reprioritised, or deprioritised, the backlog can retain the reason. That turns routine backlog maintenance into a decision log, which is valuable in organisations trying to understand and improve how product decisions are made.
Talk is no longer cheap
Agile was reacting to a real problem. Documents that were too large, too early, too detached from delivery, and too expensive to maintain. AI changes the cost model. A spoken conversation, a Slack thread, or a one-off AI chat can all clarify intent in the moment, but you suffer compounding costs when that clarity never becomes durable context.
So the principle, and Agile practices, need updating.
Do not write giant documents for their own sake. Do not bring back the PRD as a sacred object. Do not confuse ceremony with clarity.
Do make intent durable where execution depends on it. Put assumptions, examples, constraints, acceptance checks, and review evidence somewhere the delivery system can route, query, update, and use when deciding what happens next.
The next discipline is not bigger documents. It is better backlog management. Clear intent, close to the work, kept current as the loop runs.
Haven is built to support that discipline. If this is a problem you are running into, you can download Haven from GitHub, point it at a real project, and try using it as the backlog layer between your product thinking and your AI-assisted delivery loop.