Grilling
Have the agent interview you before it writes anything. Most bad features are underspecified, not badly built.
Grilling is inverting the conversation: instead of you instructing the agent, the agent interrogates you until the requirements are actually pinned down. It is the highest-leverage technique in this module, and it works because your requirements are less complete than they feel.
The prompt
I want to add [feature] to this project. Do not propose a design or write any code yet. Instead, interview me. Ask one question at a time, starting with whatever is most likely to change the design. Focus on: edge cases, failure behaviour, who the users are, what happens to existing data, and what is explicitly out of scope. Keep going until you can restate the requirement in a way I would sign off on. Then show me that restatement and stop.
One question at a time matters. A list of twelve questions gets a list of twelve shallow answers. A single question gets a considered one, and the agent's next question is informed by it.
What it actually surfaces
In practice, grilling a feature you thought was clear will surface:
- The unstated default. "What should happen if the user has no existing subscription?" — a case you had not considered, which changes the data model.
- The scope you assumed was obvious. "Does this apply to the admin API as well?" — no, and it would have been built there too.
- The migration question. "What happens to the 40,000 rows already in that table?" — the real work, hiding behind the feature.
- The disagreement with yourself. Two things you want that cannot both be true. Better found now.
Steer the grilling
You can redirect it. Useful mid-interview instructions:
"That is an implementation question, not a requirements question. Move on." "Ask me about failure modes now." "Assume the answer is the simplest thing and ask what that breaks." "I do not know. Ask me a question that would help me decide."
That last one is the reason to use an agent rather than a checklist. It can follow your uncertainty rather than march through a fixed list.
End with a restatement you keep
The output of grilling is a written restatement of the requirement, in the agent's words, that you have corrected until it is right. Save it. It is the first half of the spec you will write in Module 06, and it is a much better opening message for the implementation session than anything you would have typed cold.
Watch out
Grill in its own session, then clear. The interview transcript is long and mostly redundant once the restatement exists — carrying it into implementation spends your smart zone on questions that are already answered. Carry the restatement, not the conversation.
Try it
Grill the medium feature from your task list. Count how many questions in it you could not answer immediately. Those were going to be discovered during implementation, at ten times the cost.
Takeaways
- Have the agent interview you, one question at a time, before any design.
- Redirect the interview when it drifts into implementation.
- Keep the corrected restatement; discard the transcript.
Why one question at a time instead of a batch?
Because each answer should change the next question. A batch is a fixed checklist that cannot follow the specific ambiguity in your project, and it invites shallow answers to all twelve rather than a considered answer to the one that matters.
A course by Pieter Zandbergen