I write requirements in two roles. By day I'm a Product Owner at ING, and what I write down gets built by people. On the side I build iOS apps and this website, these days with coding agents, and what I write down there gets built by a model. Put the two side by side and you see how much a team fills in that never made it into the ticket.
My post on AI-assisted programming one year later came to this conclusion: the bottleneck is no longer writing code, it's judging it. That was the view from development, the review that comes after. This post goes one step back, to what's in the ticket before any code exists.
The tallest wall
The post on silos was about handovers: one team throws something over the wall, and on the other side the intent is gone. With a coding agent, that wall is as high as it gets. The agent wasn't in any refinement session. It doesn't know the stakeholders, didn't hear the conversation after the meeting, and has no idea which edge case caused trouble before. All it has is what's written down.
A human team fills gaps in a ticket. It asks, it knows the product's history, it remembers the decision from last quarter. An agent fills gaps too, but usually without asking: with the most plausible assumption. Faced with conflicting rules, it quietly picks one, which is what The agent won't object was about. Gaps work the same way. The result runs, looks finished, and solves a slightly different problem from the one you meant.
GitHub put it plainly when it introduced Spec Kit: language models are "exceptional at pattern completion, but not at mind reading." A vague prompt forces them "to guess at potentially thousands of unstated requirements."
When code gets cheap, requirements get expensive
As long as implementation takes weeks, a fuzzy requirement gets corrected along the way: in the daily, while pairing, in a quick question across the desk. When an agent does the same work in an hour, those loops disappear. The requirement isn't sharpened, it's executed. Whatever is in it gets built. Whatever is missing gets guessed.
That changes which document counts. The GitHub post describes a move from "code is the source of truth" to "intent is the source of truth". It sounds like a keynote slide, but the mechanism is plain: if code can be regenerated from a spec, the spec is the thing you have to maintain.
What an executable requirement contains
The Claude Code documentation is fairly precise about what a spec an agent can work through looks like. The most useful ones are self-contained: they name the files and interfaces involved, state what's out of scope, and end with an end-to-end verification step that proves the feature works. It adds a line that belongs in any product owner training: time spent making the spec precise pays off more than time spent watching the implementation. For larger features, the documentation also suggests letting the agent interview you first and having it write the spec from that. That's a refinement session, just with a different cast.
For product owners this is familiar ground, only stricter. In backlog terms:
- Acceptance criteria you can run. "Search should be fast" is a conversation starter for people and a blank check for an agent. A criterion you can derive a test from is neither. The documentation is blunt about why: the agent stops when the work looks done. Without a check it can run itself, "looks done" is the only signal it has.
- Scope boundaries. What's out of scope rarely made it into the ticket, because the team knew anyway. An agent doesn't, and will happily tidy up something else while it's there.
- Decisions with their reasons. A rule without a reason gets broken sooner or later, by people and models alike. In my side projects there's a file next to the code that records decisions and says why for each one. For this website, it explains why internal links never end in
.html: through such links, Google had found the duplicate addresses and left the real ones unindexed. That's product context, just in a form a machine reads at the start of every session. - Context that usually lives in someone's head. User groups, regulatory constraints, the history of a feature. What used to be passed on in conversation has to be written down somewhere, or it doesn't exist for the agent.
More text doesn't make it better. What holds for instruction files holds here too: a requirement that mentions everything buries what matters. Precise means short and testable.
What shifts in the role
The 2020 Scrum Guide lists, among the product owner's accountabilities, creating and clearly communicating Product Backlog items, ordering them, and ensuring that the Product Backlog is transparent, visible and understood. None of that goes away with agents. The weights shift.
Specification. "Clearly communicating" often meant: sort it out in conversation. An agent only knows what's clear on paper. Writing carries more weight than before.
Ordering. When implementation gets cheap, capacity no longer limits what gets built. What comes out without strict selection shows at market scale in the flood of generated apps, few of which find an audience. A backlog that gets worked through faster needs stricter ordering, not looser.
Acceptance. Review moves earlier and happens more often. Spec Kit builds a checkpoint into each phase where a person looks before anything moves on. The line that goes with it: "The AI generates the artifacts; you ensure they're right." For product owners that means looking at results sooner and more often, not just in the Sprint Review.
Marty Cagan went further in February 2025: product discovery is primarily about judgment, product delivery much more about process. He expects that within three to ten years, product teams will spend almost all their time on discovery. You don't have to buy the forecast to see the direction. What can be automated sits on the delivery side.
The limits
So much for the thesis. It has limits, some of them fundamental.
Accountability doesn't delegate. The Scrum Guide is unambiguous: the product owner is "one person, not a committee". The work can be delegated, but the product owner remains accountable. An agent can draft a spec, suggest acceptance criteria and summarize feedback. Deciding what ships stays with a person. In regulated industries like banking, that isn't a matter of taste.
Discovery happens with users. An agent can turn a ticket into code. Whether the ticket describes the right problem, it can't tell. You only find that out by talking to users, testing, watching. The 2025 DORA report calls user-centricity a prerequisite for AI success. According to its data, that focus amplifies AI's positive influence on team performance.
AI is an amplifier. According to the same report, 90 percent of respondents use AI at work. Its core message: AI doesn't fix a team, it amplifies what's already there. A team with poor requirements won't get better ones from agents. It gets poor software, faster.
The framework has no agents. AI and agents don't appear anywhere in the 2020 Scrum Guide. The Scrum Team is explicitly "a small team of people". Whether an agent belongs to it, is a tool, or something in between, the guide leaves open. That's no criticism of a document from 2020, but it means anyone using agents has to set those rules themselves. Who reviews the agents' code? Who gets to hand a ticket straight to an agent? What counts as done?
People read tickets too. If you only optimize requirements for machines, at some point you stop writing for the team. A ticket that consists only of file paths and test cases tells the team what to build, but no longer what for.
Conclusion
The requirement was always what product owners deliver. What's new is that it now gets taken literally. That puts the weight back on what always belonged to the role: write things down precisely, order them strictly, check early. So who writes the requirements now? The same role as before. Only now there's a reader who won't ask unless told to.
Sources
- Ken Schwaber and Jeff Sutherland: The 2020 Scrum Guide - product owner accountabilities, "one person, not a committee", delegation and accountability, "a small team of people"
- Anthropic: Best practices for Claude Code - structure of a spec, letting the agent interview you, "looks done" as the only signal
- GitHub Blog: Spec-driven development with AI: Get started with a new open source toolkit - pattern completion versus mind reading, intent as the source of truth, checkpoints in each phase (Den Delimarsky, September 2, 2025)
- Google Cloud: Announcing the 2025 DORA Report - AI adoption, AI as an amplifier, user-centricity (September 23, 2025)
- Silicon Valley Product Group: A Vision For Product Teams - Marty Cagan on discovery and delivery (February 25, 2025)