The Grilling Pattern: Clarify Requirements Before They Become Code

A requirement such as “improve the approval overview” may look clear at first glance. Yet important implementation questions remain: Who should see which entries? Which states matter? Is an existing area being extended, or is a new workflow being created? If these questions are answered only while implementing, a small request can turn into a longer cycle of assumptions, follow-up questions, and rework.

In this article, the Grilling Pattern means a bounded clarification step before an implementation plan becomes binding. “Pattern” does not mean a software design pattern here. It is a recurring way of working. It should not turn every request into an interview. Instead, it exposes only those unanswered questions whose different answers would materially change scope, architecture, verification—the planned evidence through tests, reviews, or other checks—or visible behaviour. The working hypothesis is that this targeted clarification can provide more orientation in agentic development than another generic process step, because it makes assumptions visible while they are still easy to correct.

The practical context is Lutions, a web application for structured project and ticket work. Its ongoing development follows a documented, partly AI-agent-assisted process: people make product decisions, while specialised agents can analyse context, prepare and implement changes, and verify results. I describe the surrounding development environment in How a Ticket System Became My Agentic AI Lab.

The article first places the Grilling Pattern in the context of requirements clarification and related approaches in agentic development. It then explains the project-specific working structure through a practical case and describes how it fits into a development workflow.

1. When agents derive solutions from open requirements

Even without agents, unclear or differently interpreted requirements often cause errors and rework only later. Eliciting, refining, documenting, and validating requirements is therefore a central concern of requirements engineering. ISO/IEC/IEEE 29148 addresses requirements processes and work products across the system and software life cycle. The IIBA standard includes Elicitation and Collaboration, Requirements Life Cycle Management, and Requirements Analysis and Design Definition as distinct knowledge areas (IEEE, 2018; IIBA, 2025).

In agentic development, that ambiguity can have an effect more quickly. An implementing agent can derive concrete plans, changes, and verification from a short request in a very short time. Where a product decision is missing, the agent does not merely state an assumption—it can immediately translate it into a technically plausible but productively wrong solution. That speed is useful when the target state is correct. It does not replace a decision about what should be built and for whom.

This is where the Grilling Pattern starts. It is neither complete requirements engineering nor an arbitrary questionnaire. It is a risk filter for the short phase before implementation: which uncertainties must be resolved for responsible planning to be possible, and which can remain open without material risk?

2. What the Grilling Pattern is—and is not

The name is deliberately informal. Before implementation is planned in a binding way, decision-relevant ambiguities are examined deliberately.

The sources used here do not define one uniform operational procedure for clarifying individual software requirements. ISO/IEC/IEEE 29148 frames requirements engineering as processes and work products distributed across the life cycle. The IIBA standard covers, among other things, eliciting and confirming information, the life cycle of requirements, and their analysis and design. Matt Pocock’s grilling approaches, by contrast, describe a conversational way to clarify an initially vague idea; grill-with-docs additionally brings an existing codebase into the conversation and records its context (IEEE, 2018; IIBA, 2025; Pocock, 2026).

For the application context considered here, these sources suggest a set of shared principles: use existing information first, confirm understanding, make assumptions explicit, record decisions in a traceable way, and clarify only the uncertainty relevant to the next decision. This is an interpretation of the sources, not a quotation or a standard model.

In my work on Lutions, I turn those principles into a compact working structure. The following five elements are a project-specific operationalisation. They combine the dialogic clarification in Pocock’s approaches with my development workflow. They were not adopted unchanged from Pocock’s work, nor derived directly from requirements-engineering standards; they are not a generally recognised standard.

1. Restate the problem in your own words, making misunderstandings about the starting point and goal visible.
2. Before asking a question, inspect available project sources: the ticket, documentation, earlier decisions, and recognisable code and UI patterns.
3. Record answered decisions separately from remaining assumptions, including whether a follow-up question was necessary.
4. If a decisive question cannot be answered safely from the sources, ask at most one such question at a time and offer a reasoned default assumption.
5. Stop grilling when no open question remains whose answer would materially change scope, architecture, verification, or visible behaviour.

Grilling must be distinguished from acceptance criteria. Acceptance criteria describe the verifiable conditions under which a work result is considered fulfilled. Grilling comes before them: it checks whether the problem, roles, target state, non-goals, and verification path are clear enough for meaningful acceptance criteria to be formulated.

3. A documented practical case: simple tables in a rich-text editor

One request was to let users create tables in the rich-text editor used in Lutions. That initially sounds simple. But “tables” could mean a basic presentation of structured content—or a broad table editor with office-style features.

This example comes from my work on Lutions and has been condensed for this article. It summarises the starting point, decisions, and verification; it is not a verbatim transcript, and the questions below are not historical quotations.

The decisive clarification can be simplified as follows:

Should users be able to create simple tables with rows and columns, or should the editor also support complex table capabilities such as merged cells, freely adjustable widths, specialised cell formatting, or calculations?

The documented decision limited the first scope to simple, readable tables. Users should be able to insert a table and add or remove rows and columns. Merged cells, freely adjustable column widths, spreadsheet functions, and advanced cell formatting are explicitly out of scope.

The resulting grilling record can be represented in condensed form:

## Grilling result

- Problem: Structured information is difficult to present in the rich-text editor.
- Target state: Users can create simple tables and edit their rows and columns.
- Important decision: Support intentionally remains limited to simple tables, not the feature breadth of a spreadsheet.
- Follow-up decision: The functional boundary cannot be inferred from the request alone, so the first scope is limited to simple tables.
- Non-goals: No merged cells, configurable widths, calculations, or advanced cell formatting.
- Verification: Create, edit, save, and reopen a table; verify that content and structure persist.

Verification revealed another distinction. In an initial manual test, a table could be created in the editor but was gone after saving. The cause was not a new product requirement. It was a technical gap between the editor and server-side handling of rich-text content. Only after the table structure was accepted and preserved there could the agreed target state be verified.

The check also raised a further product question: should tables within tables be possible? It was not part of the original clarification, but it affected usability, complexity, and the permitted content structure. The decision was to disallow nested tables for the time being. That boundary was applied both in the UI and when processing saved content.

The result of the implementation: creating and editing tables in the editor

The case demonstrates two aspects of the pattern. First, a vague request becomes traceable decisions, non-goals, and a verification path. Second, clarification does not replace verification: tests can reveal further technical or product questions that must then be decided and documented deliberately.

4. Putting it into practice in Lutions

The preceding example shows what a grilling result looks like. This section explains when and how Lutions uses that clarification in its development process.

In my Lutions workflow, a skill is a versioned work instruction for an AI agent. It defines rules, steps, and an expected result format for a specific task. The Grilling Pattern belongs to the phase in which a developer agent prepares a requirement for implementation; it is not an independent agent role.

Operationally, the sequence is simple: restate the problem, inspect available context, separate source-backed decisions from assumptions, decide whether one decisive follow-up is necessary, and record a compact grilling result. Do not finalise an implementation contract while a decision-relevant answer remains unsafe to infer. Stop when the uncertainty that remains can no longer change scope, architecture, verification, or user-facing behaviour.

The contract mentioned in the example is an implementation contract. It is neither a legal document nor simply a prompt. It is a compact, versioned implementation plan covering scope, non-goals, affected areas, acceptance criteria, and verification. It is created only after decision-relevant questions have been clarified sufficiently.

Here is how the grilling result from the table case translates into an implementation contract:

## Implementation contract

- Target state: Users can create simple tables in the rich-text editor and edit rows and columns.
- Scope: Insert a table and add or remove rows and columns.
- Non-goals: No merged cells, configurable widths, calculations, or advanced cell formatting.
- Affected areas: The rich-text editor and server-side processing of stored rich-text content.
- Acceptance criteria: Created tables persist after saving and can be reopened and edited.
- Verification: Create, edit, save, and reopen a table; content and structure persist.

When does grilling happen?

In my workflow, work is classified by scope and risk into tiers. Tier 0 covers purely editorial micro-changes, Tier 1 small corrections, Tier 2 broader product changes, and Tier 3 work with elevated risk. A text correction or clearly bounded UI defect is therefore typically Tier 0 or Tier 1 and needs no grilling. A change to a product workflow involving several roles is typically Tier 2. Work with security, privacy, permission, or operational risk belongs to Tier 3. The pattern is used principally for Tier 2 and Tier 3 work: for example, when roles, user workflows, API or data-model boundaries, visible behaviour, or the target state are still unclear.

What does it look like in practice?

1. A new requirement is recorded and classified roughly by scope and risk.
2. Where meaningful ambiguity exists, the developer agent first inspects the ticket, documentation, earlier decisions, and, where appropriate, existing code or UI patterns.
3. The agent records the follow-up decision: either a decision can be derived from reliable sources, or one unresolved, decision-relevant question is posed to the requester with a reasoned default assumption.
4. Answers or source evidence, assumptions, non-goals, and the verification path are recorded as the Grilling result. No final implementation contract is created while an answer cannot safely be derived.
5. Only then is the implementation contract written, followed by implementation and verification.
6. Security, privacy, permission, and operational risks additionally require an independent review. “Audit” here does not mean external certification; it means a product and technical check performed separately from the implementing agent.

The rules and result formats are versioned in the development workflow. That keeps the workflow traceable, repeatable, and capable of evolving with the project.

5. Limits and risks

The Grilling Pattern cannot replace missing product decisions. If a few decisive questions still leave unclear what should be built, pausing for documented clarification is more honest than speculative implementation. The pattern also depends on the quality of available sources. Asking without product documentation, prior decisions, or system context merely shifts research work to the requester.

Scope expansion is another risk. The possible question areas are broad, but they should be used only where they genuinely change implementation. That is why non-goals belong in the result. Conversely, a documented result does not create automatic certainty. It can be wrong or incomplete and must be supplemented by testing, product accountability, and—where risk requires it—independent review.

6. How to test whether it helps

The pattern should not be considered successful merely because a skill exists or questions were documented. Its effect is a testable hypothesis. Useful questions include: Do decision-relevant assumptions become visible before implementation? Can acceptance criteria and test cases be derived more clearly? Are there fewer product follow-ups or scope corrections after implementation starts? Do documentation and verification effects remain traceable?

For an initial comparison, similar requirements with and without a documented Grilling result are enough. The number of questions is not what matters; their quality is. Was the question decisive? Was its answer already available in project sources? Did clarification concretely change implementation or verification? The evidence remains context-dependent. Teams with clear product ownership and well-maintained documentation may need less grilling than new, distributed, or heavily agentic teams. The pattern is therefore not a maturity model. It is a focused risk filter.

Conclusion

The Grilling Pattern does not move an entire requirements-engineering discipline into an agent prompt. It brings a limited but important clarification to the point where an implementation plan is still malleable. The agent does not ask everything. It asks only what would recognisably change the implementation. It inspects existing sources first and records decisions and assumptions in a small artefact.

I use Lutions to combine that dialogic idea with a versioned development workflow. Its concrete value must prove itself in real cases. The pattern can help clarify decision-relevant uncertainty early—or make visible which product decision is still missing before implementation—without turning every requirement into a heavyweight preliminary process.

Sources and scope

This article is an English adaptation of the German original, Das Grilling Pattern, published on my blog. It describes a project-specific practice from my work on Lutions. It is neither official product documentation nor a claim that the Grilling Pattern is a general standard or proven best practice.

The external references provide context for requirements engineering and adjacent approaches. The Lutions-specific examples are personal practice reports, not independently reproducible evidence.

• IEEE (2018). ISO/IEC/IEEE 29148-2018: Systems and software engineering—Life cycle processes—Requirements engineering.
• IIBA (2025). The Business Analysis Standard.
• Pocock, Matt (2026). The /grill-me Skill.
• Hermanns, Christoph (2026). How a Ticket System Became My Agentic AI Lab.