Das Grilling-Pattern: Anforderungen schärfen, bevor sie Code werden

Eine Anforderung wie „die Freigabeübersicht verbessern“ kann auf den ersten Blick eindeutig wirken. Für die Umsetzung bleiben jedoch entscheidende Fragen offen: Wer soll welche Einträge sehen? Welche Zustände sind relevant? Wird ein vorhandener Bereich ergänzt oder entsteht ein neuer Ablauf? Werden diese Fragen erst beim Implementieren beantwortet, kann aus einem kleinen Wunsch ein längerer Zyklus aus Annahmen, Rückfragen und Nacharbeit werden.

Im Folgenden bezeichnet das Grilling-Pattern einen begrenzten Klärungsschritt vor der verbindlichen Umsetzungsplanung. Mit „Pattern“ ist hier kein Software-Entwurfsmuster gemeint, sondern ein wiederkehrendes Vorgehensmuster. Es soll nicht jede Anforderung in ein Interview verwandeln. Stattdessen macht es nur die offenen Fragen sichtbar, deren unterschiedliche Beantwortung Umfang, Architektur, Verifikation – also die geplante Prüfung durch Tests, Reviews oder andere Nachweise – oder sichtbares Verhalten wesentlich verändern würde. Der Beitrag untersucht die Arbeitshypothese, dass diese gezielte Klärung in agentischen Entwicklungsprozessen mehr Orientierung bieten kann als ein zusätzlicher allgemeiner Prozessschritt, weil sie Annahmen dort sichtbar macht, wo sie noch einfach zu korrigieren sind.

Als Fallkontext dient Lutions, eine Webanwendung für strukturierte Projekt- und Ticketarbeit. Ihre Weiterentwicklung folgt einem dokumentierten, teilweise KI-agentengestützten Ablauf: Menschen treffen fachliche Entscheidungen, während spezialisierte Agenten Kontext analysieren, Änderungen vorbereiten und umsetzen sowie Ergebnisse verifizieren können. Den Aufbau der Entwicklungsumgebung rund um Lutions beschreibt der Beitrag „Agentic AI: Wie ich zu meiner idealen Entwicklungsumgebung kam“ (Hermanns, 2026d).

Dieser Beitrag ordnet zunächst das Grilling-Pattern im Kontext der Anforderungsklärung in agentischen Entwicklungsprozessen und vorhandener Ansätze ein. Darauf aufbauend leitet er dessen Lutions-spezifische Arbeitsstruktur her, erläutert sie anhand eines dokumentierten Praxisfalls und beschreibt anschließend ihre Verankerung im Entwicklungsablauf (Lutions, 2026a; Lutions, 2026b).

1. Wenn Agenten aus offenen Anforderungen Lösungen ableiten

Auch ohne Agenten führen unklare oder unterschiedlich interpretierte Anforderungen häufig erst später zu Fehlern und Nacharbeit. Das Erheben, Präzisieren, Dokumentieren und Validieren solcher Anforderungen ist deshalb eine zentrale Aufgabe des Requirements Engineering. Der Standard ISO/IEC/IEEE 29148 beschreibt diesen Gegenstand über den System- und Softwarelebenszyklus; der BABOK Guide führt dazu unter anderem Elicitation, Requirements Life Cycle Management und Requirements Analysis als eigene Bereiche (IEEE, 2018; IIBA, 2025).

In agentischen Entwicklungsprozessen kann sich diese Unklarheit schneller auswirken, weil ein umsetzender Agent aus einer knappen Anforderung in kurzer Zeit konkrete Planung, Änderungen und Verifikation ableiten kann. Fehlt dabei eine fachliche Entscheidung, wird eine Annahme nicht nur formuliert, sondern unmittelbar in eine technisch plausible, fachlich aber möglicherweise falsche Lösung übersetzt. Diese Geschwindigkeit ist nützlich, wenn das Zielbild stimmt. Sie ersetzt jedoch keine Entscheidung darüber, was gebaut werden soll und für wen.

Das Grilling-Pattern setzt genau hier an. Es ist kein vollständiges Requirements Engineering und kein beliebiger Fragenkatalog. Es ist ein Risiko-Filter für die kurze Phase vor der Umsetzung: Welche Unsicherheiten müssen geklärt werden, damit eine fachlich verantwortbare Planung möglich ist – und welche können ohne relevantes Risiko offen bleiben?

2. Was das Grilling-Pattern ist – und was nicht

Der Name ist bewusst alltagsnah. Bevor die Umsetzung verbindlich geplant wird, werden die entscheidungsrelevanten Unklarheiten gezielt geprüft.

Die herangezogenen Quellen beschreiben keinen einheitlichen operativen Ablauf für die Klärung einzelner Softwareanforderungen. ISO/IEC/IEEE 29148 ordnet das Requirements Engineering als über den Lebenszyklus verteilte Prozesse und Arbeitsergebnisse ein; der BABOK Guide beschreibt dafür unter anderem das Erheben, Analysieren und Verwalten von Anforderungen. Pococks Grilling-Ansätze beschreiben dagegen die dialogische Klärung einer noch vagen Idee; grill-with-docs bezieht zusätzlich einen Codebestand ein und hält ihren Kontext fest (IEEE, 2018; IIBA, 2025; Pocock, 2026).

Für den hier betrachteten Anwendungskontext lassen sich daraus als fachliche Einordnung gemeinsame Grundprinzipien verdichten: vorhandene Informationen zuerst nutzen, Verständnis absichern, Annahmen sichtbar machen, Entscheidungen nachvollziehbar festhalten und nur die Unsicherheit klären, die für die nächste Entscheidung relevant ist. Diese Verdichtung ist eine Interpretation der Quellen, kein direktes Zitat und kein Standardmodell.

Die bisherige Einordnung beschreibt das Pattern auf allgemeiner Ebene. Für den Lutions-Entwicklungsprozess wurden diese Prinzipien in eine kompakte Arbeitsstruktur überführt. Die folgenden fünf Bausteine sind diese projektspezifische Operationalisierung. Die Struktur verbindet die dialogische Klärung aus Pococks Ansätzen mit dem Entwicklungsprozess von Lutions. Die Bausteine wurden weder unverändert aus Pococks Arbeiten übernommen noch unmittelbar aus Requirements-Engineering-Standards abgeleitet und sind kein allgemein anerkannter Standard (Lutions, 2026c; Lutions, 2026d). Eine Grilling-Runde im Lutions-Kontext besteht aus folgenden fünf Bausteinen:

1. Das Problem wird in eigenen Worten zurückgespiegelt. So wird sichtbar, ob Ausgangslage und Ziel richtig verstanden wurden.
2. Vor einer Rückfrage prüft der Agent zunächst vorhandene Projektquellen: Ticket, Dokumentation, frühere Entscheidungen sowie erkennbare Code- und UI-Muster.
3. Beantwortete Entscheidungen und verbleibende Annahmen werden getrennt dokumentiert; zugleich wird festgehalten, ob eine Rückfrage nötig war.
4. Lässt sich eine entscheidende Frage nicht sicher aus den Quellen beantworten, stellt der Agent höchstens eine solche Frage zugleich und bietet eine begründete Standardannahme an.
5. Das Grilling endet, sobald keine offene Frage mehr besteht, deren unterschiedliche Beantwortung Umfang, Architektur, Verifikation oder sichtbares Verhalten wesentlich verändern würde.

Das Grilling ist von Akzeptanzkriterien abzugrenzen. Akzeptanzkriterien beschreiben die überprüfbaren Bedingungen, unter denen ein Arbeitsergebnis als erfüllt gilt. Das Grilling liegt davor: Es prüft, ob Problem, Rollen, Zielbild, Nicht-Ziele und Prüfweg klar genug sind, damit solche Kriterien sinnvoll formuliert werden können.

3. Ein dokumentierter Praxisfall: Einfache Tabellen im Rich-Text-Editor

Eine Anforderung lautete, dass Anwender im in Lutions eingesetzten Rich-Text-Editor Tabellen anlegen können sollen. Das klingt zunächst einfach. Für die Umsetzung war aber offen, was mit „Tabellen“ konkret gemeint ist: eine einfache Darstellung strukturierter Inhalte oder ein umfangreicher Tabelleneditor mit Funktionen wie in einer Office-Anwendung.

Das folgende Beispiel stammt aus einem internen Lutions-Ticket mit zugehöriger Umsetzungsdokumentation. Die Darstellung ist für diesen Beitrag sprachlich verdichtet. Sie fasst dokumentierte Ausgangslage, Entscheidungen und Verifikation zusammen und ist keine wortgetreue Abschrift eines Gesprächs (Lutions, 2026h).

Die entscheidende Klärung lässt sich vereinfacht so beschreiben:

Sollen Anwender einfache Tabellen mit Zeilen und Spalten erstellen können – oder soll der Editor auch komplexe Tabellenfunktionen wie verbundene Zellen, frei anpassbare Breiten, besondere Zellformatierungen oder Berechnungen anbieten?

Die dokumentierte Entscheidung begrenzte den ersten Umfang auf einfache, lesbare Tabellen. Anwender sollen eine Tabelle einfügen sowie Zeilen und Spalten ergänzen oder entfernen können. Nicht zum Ziel gehören verbundene Zellen, frei veränderbare Spaltenbreiten, Tabellenkalkulationsfunktionen oder weitergehende Zellformatierungen.

Das daraus abgeleitete Grilling-Ergebnis lässt sich verkürzt so darstellen:

## Grilling-Ergebnis

- Problem: Strukturierte Informationen lassen sich im Rich-Text-Editor bislang nur umständlich darstellen.
- Zielbild: Anwender können einfache Tabellen anlegen und deren Zeilen und Spalten bearbeiten.
- Wichtige Entscheidung: Unterstützt werden bewusst einfache Tabellen, nicht die Funktionsbreite einer Tabellenkalkulation.
- Rückfrageentscheidung: Die Funktionsgrenze lässt sich aus der Anforderung allein nicht ableiten und wird für den ersten Umfang auf einfache Tabellen begrenzt.
- Nicht-Ziele: Keine verbundenen Zellen, frei einstellbaren Breiten, Berechnungen oder erweiterten Zellformatierungen.
- Verifikation: Tabelle anlegen, bearbeiten, speichern und erneut öffnen; prüfen, ob Inhalt und Struktur erhalten bleiben.

Die Verifikation machte eine weitere Unterscheidung sichtbar. In einem ersten manuellen Test ließ sich die Tabelle im Editor zwar anlegen, nach dem Speichern war sie jedoch nicht mehr vorhanden. Die Ursache lag nicht in einer fachlichen Erweiterung der Anforderung, sondern in einer technischen Lücke zwischen Editor und serverseitiger Verarbeitung des Rich-Text-Inhalts. Erst nachdem die Tabellenstruktur auch dort akzeptiert und erhalten wurde, war das vereinbarte Zielbild überprüfbar.

Während dieser Prüfung entstand zudem eine weitere fachliche Folgefrage: Sollen Tabellen innerhalb von Tabellen möglich sein? Diese Frage gehörte nicht zur ursprünglichen Klärung, beeinflusst aber Bedienbarkeit, Komplexität und die zulässige Inhaltsstruktur. Die Entscheidung lautete, verschachtelte Tabellen zunächst nicht zuzulassen. Diese Begrenzung wurde sowohl in der Bedienoberfläche als auch bei der Verarbeitung gespeicherter Inhalte berücksichtigt.

Der Fall zeigt zwei Aspekte des Patterns. Erstens wird eine vage Anforderung in nachvollziehbare Entscheidungen, Nicht-Ziele und einen Prüfweg überführt. Zweitens ersetzt diese Klärung keine Verifikation: Tests können weitere technische oder fachliche Fragen sichtbar machen, die anschließend bewusst entschieden und dokumentiert werden müssen (Lutions, 2026h).

4. Umsetzung in Lutions

Das vorangehende Beispiel zeigt, wie ein Grilling-Ergebnis aussieht. In der Entwicklungsumgebung rund um Lutions ist ein Skill eine versionierte Arbeitsanweisung für einen KI-Agenten. Sie beschreibt für eine bestimmte Aufgabe Regeln, Schritte und ein erwartetes Ergebnisformat. Der requirements-griller ist ein solcher Skill. Er gehört zur Phase, in der ein Developer-Agent eine Anforderung für die Umsetzung vorbereitet; er ist keine eigene Agentenrolle (Lutions, 2026c; Lutions, 2026d).

Die folgende gekürzte Passage aus diesem intern versionierten Skill dokumentiert die operative Umsetzung des Patterns. Sie ist kein allgemeiner Standard; ihre Einordnung, Begründung und Grenzen erläutert dieser Beitrag (Lutions, 2026d):

1. Restate the user problem in one or two sentences.
2. Inspect available local context first.
3. Identify which decisions are already answered by sources and which are still assumptions.
4. Ask at most one decisive user question at a time when the answer cannot be inferred safely.
5. Include a recommended answer or default assumption with every question.
6. Stop grilling when the remaining uncertainty no longer changes scope, architecture, verification, or user-facing behavior.
7. Record a compact `Grilling-Ergebnis` in the ticket contract, planning note, or milestone comment.

Der im Beispiel erwähnte Contract ist ein Umsetzungscontract. Er ist kein juristisches Dokument und kein bloßer Prompt, sondern ein kompakter, versionierter Umsetzungsplan mit Umfang, Nicht-Zielen, betroffenen Bereichen, Akzeptanzkriterien und Verifikation. Er entsteht erst, wenn die entscheidungsrelevanten Fragen ausreichend geklärt sind.

Das folgende Beispiel zeigt, wie das Grilling-Ergebnis des Tabellenfalls in einen Umsetzungscontract überführt wird. Es fasst die dokumentierten Entscheidungen zusammen (Lutions, 2026h):

## Umsetzungscontract

- Zielbild: Anwender können im Rich-Text-Editor einfache Tabellen anlegen sowie Zeilen und Spalten bearbeiten.
- Umfang: Tabelle einfügen sowie Zeilen und Spalten ergänzen oder entfernen.
- Nicht-Ziele: Keine verbundenen Zellen, frei einstellbaren Breiten, Berechnungen oder erweiterten Zellformatierungen.
- Betroffene Bereiche: Rich-Text-Editor und serverseitige Verarbeitung gespeicherter Rich-Text-Inhalte.
- Akzeptanzkriterien: Angelegte Tabellen bleiben nach dem Speichern erhalten und können erneut geöffnet sowie bearbeitet werden.
- Verifikation: Tabelle anlegen, bearbeiten, speichern und erneut öffnen; Inhalt und Struktur bleiben erhalten.

Wann wird gegrillt?

Lutions ordnet Änderungen nach Umfang und Risiko in Risikostufen, sogenannte Tiers, ein: Tier 0 umfasst rein redaktionelle Kleinständerungen, Tier 1 kleine Korrekturen, Tier 2 fachlich breitere Änderungen und Tier 3 Arbeiten mit erhöhtem Risiko. Eine Textkorrektur oder ein klar begrenzter UI-Fehler ist daher typischerweise Tier 0 oder Tier 1 und braucht kein Grilling. Eine Änderung eines fachlichen Ablaufs mit mehreren Rollen ist typischerweise Tier 2. Änderungen mit Sicherheits-, Datenschutz-, Berechtigungs- oder Betriebsrisiken gehören in Tier 3. Das Pattern wird vor allem bei Tier 2 und Tier 3 eingesetzt: etwa bei unklaren Rollen, Benutzerabläufen, API- oder Datenmodellgrenzen, sichtbarem Verhalten oder noch nicht prüfbaren Zielbildern (Lutions, 2026c; Lutions, 2026e).

Wie läuft es praktisch ab?

1. Eine neue Anforderung wird aufgenommen und grob nach Umfang und Risiko eingeordnet.
2. Bei relevanter Mehrdeutigkeit prüft der Developer-Agent zunächst Ticket, Dokumentation, frühere Entscheidungen und gegebenenfalls bestehende Code- oder UI-Muster.
3. Nicht auflösbare, entscheidungsrelevante Fragen werden einzeln mit einer begründeten Standardannahme an den Auftraggeber gestellt.
4. Antworten, Annahmen, Nicht-Ziele und der Prüfweg werden als Grilling-Ergebnis festgehalten.
5. Erst danach entsteht der Umsetzungscontract; anschließend folgen Implementierung und Verifikation.
6. Bei Sicherheits-, Datenschutz-, Berechtigungs- oder Betriebsrisiken bleibt zusätzlich ein unabhängiger Review erforderlich.

Die Regeln und Ergebnisformate sind im Repository versioniert: in Agentenregeln, dem Skill sowie Prozess- und Ticket-Workflows. Dadurch bleibt der Ablauf nachvollziehbar, wiederholbar und gemeinsam mit dem Entwicklungsprozess weiterentwickelbar (Lutions, 2026c; Lutions, 2026d; Lutions, 2026e; Lutions, 2026f).

5. Grenzen und Risiken

Das Grilling-Pattern kann fehlende fachliche Entscheidungen nicht ersetzen. Bleibt nach wenigen entscheidenden Fragen offen, was gebaut werden soll, ist eine Pause mit dokumentierter Klärung ehrlicher als eine spekulative Implementierung. Ebenso hängt das Pattern von der Qualität der vorhandenen Quellen ab: Wer ohne Ticket-, Dokumentations- oder Systemkontext fragt, verlagert Recherche lediglich zum Auftraggeber.

Ein weiterer Risikopunkt ist die Ausweitung des Umfangs. Die möglichen Fragebereiche sind breit, dürfen aber nur dort genutzt werden, wo sie eine Umsetzung wirklich verändern. Nicht-Ziele gehören deshalb zum Ergebnis. Umgekehrt erzeugt ein dokumentiertes Ergebnis keine automatische Sicherheit: Es kann falsch oder unvollständig sein und muss durch Tests, fachliche Verantwortung und – wo das Risiko es verlangt – einen getrennten Review ergänzt werden.

6. Wie sich die Wirkung überprüfen lässt

Das Pattern sollte nicht schon deshalb als erfolgreich gelten, weil ein Skill existiert oder Fragen dokumentiert wurden. Seine Wirkung ist eine prüfbare Hypothese. Sinnvolle Fragen sind: Werden entscheidungsrelevante Annahmen vor der Implementierung sichtbarer? Lassen sich Akzeptanzkriterien und Testfälle klarer ableiten? Treten nach Beginn der Umsetzung weniger fachliche Nachfragen oder Korrekturen des Umfangs auf? Bleiben Dokumentations- und Prüfauswirkungen nachvollziehbar?

Für einen ersten Vergleich reichen ähnlich gelagerte Anforderungen mit und ohne dokumentiertes Grilling-Ergebnis. Entscheidend ist nicht die Zahl der Rückfragen, sondern ihre Qualität: War die Frage entscheidend, war die Antwort bereits in Projektquellen vorhanden, und hat die Klärung Umsetzung oder Verifikation konkret verändert? Die Aussagekraft bleibt kontextabhängig. Teams mit klaren Produktverantwortlichen und gut gepflegter Dokumentation brauchen möglicherweise weniger Grilling als neue, verteilte oder stark agentisch arbeitende Teams. Das Pattern ist deshalb kein Reifegradmodell, sondern ein gezielter Risiko-Filter.

Fazit

Das Grilling-Pattern verlagert keine vollständige Requirements-Engineering-Disziplin in einen Agentenprompt. Es bringt eine begrenzte, aber wichtige Klärung an die Stelle, an der eine Umsetzungsplanung noch formbar ist. Der Agent fragt nicht alles, sondern nur das, was die Umsetzung erkennbar verändern würde. Er prüft zunächst vorhandene Quellen und hält Entscheidungen sowie Annahmen in einem kleinen Artefakt fest.

Lutions verbindet diese Dialogidee mit einem versionierten Entwicklungsablauf. Der konkrete Nutzen muss sich an realen Arbeitsfällen bewähren. Das Pattern kann dazu beitragen, entscheidungsrelevante Unsicherheiten früh zu klären oder sichtbar zu machen, welche fachliche Entscheidung vor der Umsetzung noch fehlt – ohne aus jeder Anforderung einen schweren Vorprozess zu machen.

Quellenverzeichnis

Öffentliche Einführung

• Hermanns, Christoph (2026d). Agentic AI: Wie ich zu meiner idealen Entwicklungsumgebung kam. cherware.de. https://www.cherware.de/lutions-project-einstieg/

Externe Primärquellen

• IEEE (2018). ISO/IEC/IEEE 29148-2018: Systems and software engineering — Life cycle processes — Requirements engineering. https://standards.ieee.org/standard/29148-2018.html
• IIBA (2025). The Business Analysis Standard. https://www.iiba.org/globalassets/business-analysis-resources/the-business-analysis-standard/files/the-business-analysis-standard.pdf
• Pocock, Matt (2026). The /grill-me Skill. AI Hero. https://www.aihero.dev/skills-grill-me

Interne Lutions-Primärquellen

Die folgenden internen Projektquellen dokumentieren die beschriebene Umsetzung, sind aufgrund des privaten Repositories jedoch nicht öffentlich zugänglich.

• Lutions (2026a). Product Overview. wiki/product/overview.md
• Lutions (2026b). Development Process End to End. docs/aidev/development_process_end_to_end.md
• Lutions (2026c). AGENTS Working Agreement. AGENTS.md
• Lutions (2026d). Requirements Griller. .codex/skills/requirements-griller/SKILL.md
• Lutions (2026e). Agent Roles: Current State. docs/aidev/agent_roles_current.md
• Lutions (2026f). Ticket and Release Workflow. docs/process/ticket_release_workflow.md
• Lutions (2026g). Agentic-AI Decision Log und Repo-Verankerung. docs/process/contracts/2026-07-01-agentic-ai-decision-log.md
• Lutions (2026h). Tabellen im Rich-Text-Editor anlegen. LUMVP-1201, internes Ticket mit Umsetzungs- und Verifikationsdokumentation.