We stopped writing requirements, and let the agent interview us instead

the tax nobody put on the invoice

Every product person has lived this cycle. A client sends over a call recording, a half-finished brief, or a thread of emails, and somehow that has to become a spec an engineering team can build against without guessing.

For years the honest cost of turning that raw material into something buildable was measured in weeks. You'd run a brainstorming session, draft a document, circulate it, wait for comments, fold them in, circulate again, book a workshop to resolve the disagreements the comments exposed, and finally chase the sign-offs. Somewhere in that relay, the work aged. And no matter how careful the process, there was always the one requirement nobody thought to ask about: the mid-month special case, the currency that behaves differently, the state the system can enter that no one designed for. You didn't find it in the review. You found it six months later, mid-build, at the single most expensive moment it could possibly surface.

We wrote about our agentic SDLC a little while ago: six phases, six gates, AI agents doing the volume work while our team makes every call that matters. This article is a close look at the first phase, Discover, from the seat of the person who actually runs it. Not the diagram, the chair.

I'll be specific about what changed, because the short version sounds like marketing and the long version is the point: the requirements work that used to take days-to-weeks now closes in a single sitting, and the specs that come out are not in the same league as what we produced before. I mean that literally. There isn't a fair way to compare them.

what actually changed: from authoring to being interviewed

The old workflow put the entire burden of imagination on us. It was our job to think of everything up front, structure it, write it down, and defend it in review. The document was the deliverable, and the document was only ever as complete as the most tired person in the room at the time it was written.

The new workflow inverts that. I don't arrive to write the spec. I arrive to be interviewed for it.

You run a single command, and Claude conducts a structured, depth-first interview, one requirement area at a time, one question at a time, in plain language. My job in the room stops being "have I remembered to document everything?" and becomes "do I recognise a good answer when I hear it, and can I tell when something needs a follow-up with the client?" That is a fundamentally easier job to do well, and a fundamentally harder job to do badly. The completeness is no longer bottlenecked on my stamina.

The interview doesn't ask me to be thorough. It is thorough, and asks me to be knowledgeable. Those are very different demands on a person.

you don't need to arrive with a polished brief

This is the part that caught me off guard the first time, so I'll flag it early: you do not need a clean, structured brief to begin. A rough call transcript is enough. So is a messy email thread, or a page of notes from a client conversation. The interview is designed to start from raw material, because raw material is what actually exists at the start of a project. Requiring a tidy brief before you can begin is just relocating the hard part, not removing it.

There's a quiet step that makes this work. Before it asks a single question, the agent scans our existing codebase silently, so every question it asks is grounded in what's actually there, not in an assumption about what might be there. You never see this happen. You just notice, a few questions in, that the questions are oddly well informed: it already knows the system has a concept of allocations, so it doesn't ask whether we track them. It asks how mid-month changes should behave. That grounding is the difference between an interview and a survey.

inside the interview: one area, one question at a time

Here is what the session actually feels like, because "AI-assisted requirements gathering" is a phrase that could mean almost anything.

It works through one requirement area at a time and refuses to move on until that area is genuinely resolved. Within an area, it asks a single question, waits, and uses your answer to decide the next one. There are no field names, no API routes, nothing that assumes you can read a schema. It's a business conversation that happens to produce an engineering artefact.

A real exchange from our own session looked roughly like this. It asked how an engineer's cost should be handled when they're split across two projects. Fine, we prorate by allocation percentage. Then: what happens when that split changes on the 15th of the month? That's the follow-up I wouldn't have written down unprompted, because in my head "we prorate allocations" already felt like a closed answer. It isn't. Mid-month reallocation is its own case, and it has a right answer and several plausible wrong ones. The interview doesn't let a comfortable generalisation stand in for the specific behaviour the build will actually need.

Two practical things matter here. If a session gets interrupted, and stakeholder sessions always get interrupted, it saves state and picks up exactly where it left off, so a dropped call doesn't cost you the thread. And when you want pressure rather than coverage, you can explicitly ask it to stress-test what you've built so far: throw adversarial cases, hostile inputs, and "what if two of these happen at once" scenarios at the emerging spec. Coverage by default, stress on demand.

One more discipline worth naming, because it's the one most teams get wrong. When a question genuinely can't be answered in the room: the stakeholder isn't there, the client hasn't decided, the interview does not invent an answer to keep things tidy. It records an open question, assigns it an owner, and moves on. Silence is never quietly logged as consent. An unresolved question you can see is worth ten confident assumptions you can't.

the moment it earns its keep

We ran this on our own P&L engine, the internal forecasting tool we wrote about a few weeks ago. One session. Roughly two hours. Six requirement areas covered end to end: allocations, FX exposure, bench cost, overallocation, scenario modelling, and monthly closing. In the old process, that was several meetings and a document that would have spent a fortnight in review.

Two cases got escalated in that first session that we had not thought to write down ourselves. The first was the mid-month engineer reallocation I described above. The second was a currency-exposure edge case, a specific way RON/USD movement interacts with a partially-closed month, that we would only have noticed when the numbers looked subtly wrong in production.

Here's why that's the whole game. A missed requirement isn't equally expensive whenever you find it. Found on day one, it costs a follow-up question. Found in design, it costs a diagram. Found mid-build, it costs a rebuild, and often a quiet erosion of trust in the numbers the system produces. Both of those cases would ordinarily have surfaced deep in development. Catching them in hour one of hour two isn't a nice-to-have; it's the difference between a cheap edit and an expensive one, made at the only point where it's still cheap.

The way I'd put it to a colleague who hasn't tried it:

"It grills you, use cases, edge cases, the things you'd never think to ask. You don't have to be technical. You just answer."

what you walk away with: artefacts that don't rot

The output is not a Word document that gets forgotten in a shared drive three sprints later. Two things are produced, and from that point on both are treated as living contracts, not paperwork.

A validated spec. Problem statement, current behaviour versus new behaviour, the impact on the existing system, and, crucially, a list of the open questions that genuinely couldn't be resolved in the room, each with an owner. The unresolved parts are surfaced, not buried. That list is a feature, not an embarrassment.

Acceptance tests written in plain business language. One file per requirement area, phrased so that anyone who was on the call can read them, not just engineers. "Given an engineer is reallocated on the 15th, when the month closes, then their cost is split proportionally across both projects." These become the definition of done for everything that follows. Design, build, and review all answer to them.

And before either artefact is allowed to be called final, every claim the spec makes about our existing system is checked against the real code. If the spec says "the system already handles X," that sentence is verified, not trusted. Where the spec and the codebase disagree, the discrepancy is caught and corrected on the spot, before a single hour of design or engineering is spent building on top of a wrong assumption. The validation runs as a loop with a built-in failsafe: it will attempt to reconcile discrepancies a bounded number of times, and if it still can't, it stops and asks a human rather than papering over the gap. A spec that has been reconciled against reality is a different object from a spec that has merely been signed.

the gate didn't move, the thinking did

The question I get most often is some version of "so the AI decides the requirements now?" No. Nothing about who owns the decision changed.

Discover ends at a gate, and that gate is owned by a person, a PM or BA, who confirms the spec before anything moves forward. The bar to pass it is concrete: zero unresolved discrepancies between the spec and the codebase, and every open question explicitly acknowledged rather than ignored. A human still signs. What changed is not who decides; it's how much has already been thought through by the time that person has to decide.

That's the honest framing of the whole thing. It doesn't remove judgement from the process. It moves judgement earlier, to the point where being wrong costs a follow-up question instead of a rebuild. Front-loading the thinking is not a trick to go faster; going faster is a side effect of thinking more clearly, sooner.

doing this as a PM

I have a technical background, I came up as a developer before moving into product, and I want to be clear that it was never what this required. The interview doesn't lean on it, and my honest instinct is that the session wouldn't have gone differently without it. Nothing in the flow assumes you can read a schema, and nothing rewards you for being able to.

What the session actually asks of you is the thing the job was always supposed to be about: know the business, recognise a good answer when you hear one, and flag when something needs to go back to the client. The skill that used to be quietly load-bearing, the stamina to write and rewrite and shepherd a document through committee, turns out to have been a tax, not a talent. Remove it, and what's left is judgement. That's a better job.

The first time I ran it, I tested it alone, on a small feature, to see whether the questions were any good. They were. But the real unlock came the second time, when I ran it live with the people who actually own the feature in the room. The agent asks; the stakeholders discuss and answer; I steer. By the end of the session the whole feature is documented, requirements and edge cases both, and the odds of something important having slipped through are low in a way the old process never managed. If you have the right people in the room, one sitting genuinely does it.

why this matters beyond one phase

Discover is the first of six phases, but it sets the terms for all of them. A validated spec and a set of business-readable acceptance tests aren't just the output of this phase, they're the input to design, plan, build, and review. Every later gate answers to artefacts that were reconciled against reality at the start. Get Discover right and the whole pipeline inherits that rigour; get it wrong and every downstream phase is quietly building on sand, faster than ever.

Which is really the same lesson our forecasting build taught us, seen from the front of the process rather than the middle:

The bottleneck is no longer producing the work. It's thinking clearly about what the work actually needs to be.

The agentic approach doesn't lower that bar. It raises it, and then does everything downstream of it at pace. The reward for articulating your domain precisely used to be a document. Now it's a working system that already knows about the cases you'd otherwise have discovered the hard way.

what's next

This is the first in a series looking at each phase of our agentic SDLC in turn, each written from the seat of the person who owns that gate. Five more to go: Design, Plan, Build, Review, and Ship.

If you're a product manager or business analyst tired of watching requirements rot in a shared doc while everyone waits for the next review cycle, or a leader wondering what "human in the loop" actually means in practice rather than on a slide, we'd be glad to talk.