The problem with writing the document yourself
Before you can ask AI to build something with any confidence, someone has to write down what it should do, what already exists around it, and what must not change. On this site that's the Behaviour and Context & Constraints work of PDAID. It's also the part people put off, because turning what's in your head into a complete, well-organised document is genuinely hard - and reviewing someone else's attempt at that document is often just as hard.
Martin Fowler, writing on his bliki, describes a technique that attacks both problems from a different angle: instead of writing the context yourself, have the LLM interview you for it. Instead of asking a busy expert to read and critique a specification, have the LLM interview the expert and check the document against their answers. He calls this an "interrogatory LLM."
Using the LLM to build the document
The idea, as Fowler describes it: instead of writing several pages of context yourself - how a feature should appear to the user, implementation guidelines, which external systems matter - you prompt the LLM to interrogate you. You tell it to ask you everything it needs to produce that context document, feed it what you know, and point it at other sources to consult for the rest. When it's done, the output is a context report that a separate session (possibly with a different model) can build from.
Fowler reports that he first saw a clear description of this approach on Harper Reed's blog, and that a notable detail there was insisting the LLM ask only one question at a time. Fowler says he found the model needed frequent reminding to actually stick to that rule.
That one detail matters more than it looks. A document produced by a model asking five questions at once, or by dumping a checklist for you to fill in, is not that different from writing the document yourself: you're still holding the whole shape of it in your head and deciding what matters. Asked one question at a time, you only have to answer what's in front of you, and the model is doing the work of noticing what to ask next, in what order, and when something you said contradicts something you said earlier. If you try this, treat "one question at a time" as an instruction you'll need to repeat, not one you can set and forget.
This fits directly into the Clarifications and Context & Constraints phases of PDAID: the interview is a way of surfacing the ambiguities, assumptions and boundaries those phases ask for, rather than trying to anticipate all of them yourself before you start writing. It's a complement to working from the behaviour template, not a replacement for it - the interview can be the process that fills the template in, with you supplying answers and the model supplying the questions and the structure.
It's worth being clear about what doesn't change. The model is doing the asking and the drafting; you're still the one deciding what's true, what's required, and what's out of scope. Accepting an answer the model proposes back to you is still a decision you make, in the same way accepting any AI output is - see what you still need to understand when AI writes the code. The interview changes how the document gets produced. It doesn't change who is responsible for what's in it.
Using the LLM to check a document against an expert
The second half of the technique runs the other way: instead of asking a human expert to read a specification and say whether it's accurate, you give the LLM the document and have it interview the expert to check it. Fowler notes that people often find reviewing hard, and that a conversation may surface problems a cold read of the document would not - particularly, he suggests, when the document itself isn't well written.
A companion note from Fowler records that this idea also came up independently at a gathering of software developers discussing agentic programming: one attendee described using an interrogatory LLM to have it ask a human expert questions that verify the correctness of a specification, as an alternative to asking the expert to review the document directly.
This is a different use of the same mechanism, and it maps onto a gap the site has already named elsewhere: getting useful review out of a document nobody has time to read closely. If a specification or behaviour document is going to govern what gets built, someone with domain knowledge needs to confirm it's actually correct before Build starts - not just plausible. Handing them a conversation instead of a document to mark up may get you an answer where asking for a review would have got you silence or a skim.
Fowler also points out the two halves combine: one interrogatory LLM builds the document with you, then a separate one reviews it with an expert who wasn't involved in writing it. That separation is useful in its own right - the person who wrote the spec is a poor judge of what's missing from it, and a second conversation with someone else is one way to get past that.
What this doesn't solve
Nothing here removes the judgement calls the site keeps coming back to. The interview produces a document; it doesn't decide whether the document is complete, whether the expert being interviewed actually knows the domain, or whether an answer the model records is what you meant. Fowler is candid that the writing this process produces "will have that tang of AI-writing" - his phrase - and treats that as an acceptable cost against the alternative of no document at all, not as something to ignore. Read the result before you build from it, the same way you'd read a document you wrote yourself before treating it as settled Context & Constraints for a build.
The technique is also aimed at people who find writing hard, or find it hard to get a busy expert to sit down and read something. If you're a fluent writer and your reviewer already reads documents carefully, plain writing and plain review may still be less friction than an interview. Fowler's own framing is that this helps "people who find writing hard" get the information out of their head at all - not that interviewing beats writing in every case.
A way to try it
If you want to test this on a real piece of work: pick a feature you're about to define, open a session, and prompt the LLM to interview you one question at a time until it has enough to write a Behaviour and Context & Constraints document, and to say when it thinks it has enough rather than stopping at a fixed number of questions. Watch for it batching questions or going quiet on the "one at a time" instruction, and remind it when it does. When the document comes out, don't hand it straight to Build - read it as you would any draft, then, if there's someone else whose knowledge the spec depends on, consider giving them the same document and having a second session interview them against it before you commit to it.