Bevor du Code schreibst: Warum ich Greenfield-Projekte mit einem Requirements Analyst starte

Ich starte kein neues Projekt mehr ohne ein Gespräch mit einem Requirements Analyst.

Nicht mit einem Menschen; mit einem KI-Agenten, der als einzige Aufgabe hat, mir die Fragen zu stellen, die ich sonst überspringe, und die Antworten zu hinterfragen:

• Wer nutzt das eigentlich?
• Was genau erwarten die?
• Was passiert im Fehlerfall?
• Welche Annahmen mache ich gerade, die ich nicht ausgesprochen habe?

Klingt so lange banal, bis man merkt, dass man auf die Hälfte davon in der Praxis gar keine klare Antwort hat.

Das Problem: Direkt in den Code, direkt in die Sackgasse

Die meisten Projekte starten so: Feature-Idee, technische Architektur im Kopf, Plan klingt plausibel, und los. Mit einem Frontier-Modell geht das sogar erschreckend schnell und in einer Stunde steht ein funktionierender Prototyp.

Aber dann fängt die eigentliche Arbeit an. Jede Anforderung, die vorher nur implizit im eigenen Kopf existiert hat, kommt als Mikro-Entscheidung zurück. Der Agent fragt nach, oder schlimmer: er entscheidet still und du merkst es erst beim Review. Dann steckst du im Human-in-the-Loop-Modus fest, steuerst jeden Schritt manuell, und die anfänglichen Produktivitätsgewinne gehen in den Aufräumarbeiten wieder verloren.

Auch in Zeiten von Agentic Engineering gilt die Maxime: Zwei Wochen programmieren ersparen einem fünf Minuten Nachdenken.

Der Kern des Problems ist nicht technisch. Es ist, dass wir als Entwickler gewohnt sind, direkt in Lösungen zu denken.

Als Handwerker denken wir mit den Händen. Unser Handwerk besteht darin, mit Sorgfalt in kleinen Inkrementen eine Annäherung an die Lösung durchs Programmieren zu finden. Es ist verführerisch, das mit einem langen Hebel durchzubeschleunigen. Aber dann fehlt die persönliche Verarbeitungstiefe, die Pausen und die kleinen Fragen im Prozess, wenn wir als Hebel KI benutzen und alle kleinen Feedbackschleifen des Handwerks abgeben. Wir lernen dabei nicht und kriegen erst das Zwischenergebnis präsentiert.

Technische Architektur, Datenmodelle, API-Design — das ist unsere Komfortzone. Die Frage „Was will der Nutzer eigentlich, und woran messen wir Erfolg?“ fühlt sich dagegen nach Projektmanagement an. Also überspringen wir sie.

Die Lösung: Ein Agent, der die Nutzerperspektive vertritt

Mein Workflow hat jetzt einen Schritt davor. Bevor eine Zeile Code entsteht, führe ich ein Gespräch mit einem KI-Agenten, der als Requirements Analyst auftritt. Der Agent stellt strukturierte Fragen, arbeitet sich durch neun Phasen — von der Projektvision über Stakeholder und funktionale Anforderungen bis zu Priorisierung und Akzeptanzkriterien — und produziert am Ende ein REQUIREMENTS.md-Dokument.

Das Dokument geht dann an den nächsten Agenten: einen Solution Architect, der daraus eine technische Spezifikation baut. Erst danach wird implementiert.

Der entscheidende Punkt: Der Requirements Analyst darf keine Lösungen vorschlagen. Er definiert das Was und das Warum, nicht das Wie. Das zwingt mich, die Anforderungen sauber durchzudenken, bevor die technische Architektur sie einengt.

Wie der Agent entstanden ist

Die Idee, Agenten in Rollen aufzuteilen — Analyst, Architect, Developer, Reviewer — stammt aus Emmz Rendles Talk „How I Tamed Claude“ auf der NDC London. Ich habe den Ansatz aufgegriffen und für meinen Workflow angepasst. Das klang alles so seltsam einfach, das musste ich einmal ausprobieren. Für mich hat dieser Fund ganz andere Workflows erst freigeschaltet.

Das Überraschende dabei: Der System Prompt für den Requirements Analyst entstand aus einem einzigen Satz. Ich habe Claude folgendes geschrieben:

Create a system prompt document for a Requirements Analyst that gathers information and asks questions to produce a REQUIREMENTS.md document that a Solution Architect can use to design the solution and plan the implementation.

Daraus hat Claude einen vollständigen Agenten generiert — mit neun Discovery-Phasen, Gesprächsrichtlinien, Scope-Management und einem strukturierten Output-Template. Den Prompt habe ich danach iteriert und angepasst, aber die Grundstruktur kam aus dieser einzigen Anweisung.

Vorher hatte ich keine klare Vorstellung davon, was ich bekommen würde. Erst nach den ersten Durchläufen konnte ich gezielt Anpassungen vornehmen. Gerade diese erste Version, fast nur aus dem im Modell vorhandenen Wissen erzeugt, war schon überraschend brauchbar.

Das Muster, das sich wiederholt: Du beschreibst die Rolle und die erwartete Ausgabe, und das Modell füllt die Struktur. Du musst nicht jede Phase selbst entwerfen — du musst wissen, was du brauchst. Und dann lernst du daraus und machst es beim nächsten Mal vielleicht noch genauer.

Was der Agent konkret tut

Der von Claude (Opus 4.5) generierte System Prompt und damit der Agent arbeitet sich durch neun Phasen, von breit nach tief. Ein paar Highlights, damit du ein Gefühl bekommst:

Phase 1 — Projektkontext & Vision. Bevor es um Features geht: Was bauen wir, warum, und woran messen wir Erfolg? Der Agent fragt nach Business-Motivation, bestehendem System, und Zieltermin. Das sind die Fragen, die ein erfahrener Berater in den ersten 10 Minuten stellt, und die wir als Entwickler gerne überspringen, weil wir die Antwort zu kennen glauben.

Phase 3 — Funktionale Anforderungen. Für jede Capability fragt der Agent nach Trigger, Inputs, erwarteten Outputs, Geschäftsregeln und Edge Cases. Das zwingt dich, Workflows durchzudenken, statt nur Features aufzulisten. (Beim Schreiben fällt mir auf, wie unangenehm der Mix aus deutscher Prosa mit englischen Bruchstücken wird, weil ich aus meinen englischen Artefakten zitiere — wenn du auf Deutsch denkst und arbeitest, schreib deinen System Prompt vielleicht auch direkt auf Deutsch!)

Phase 7 — Constraints & Annahmen. Der für mich wertvollste Teil: „Welche Annahmen machen wir gerade, die, wenn sie falsch sind, die Anforderungen signifikant ändern würden?“ Diese Frage allein hat mir bei meinem letzten Projekt zwei Wochen Korrekturen erspart.

Pro Phase stellt der Agent 2–4 fokussierte Fragen, paraphrasiert die Antworten zur Bestätigung, und eskaliert Widersprüche oder Lücken. Wenn ich auf eine Frage keine Antwort habe, schlägt er sinnvolle Defaults vor oder markiert den Punkt als offen.

Das klingt nach viel Aufwand. Ist es nicht. Ein typisches Gespräch dauert 15–30 Minuten. In einzelnen Fällen kann es länger dauern, wenn sehr viel Kontext zusammenkommt oder die Antworten besonders ausführlich ausfallen. Plane also lieber 30 Minuten plus etwas Puffer ein.

Danach habe ich ein Dokument, das die meisten Fragen beantwortet, die sonst während der Implementierung aufgetaucht wären — nur ohne den Kontext, sie dann noch sauber zu beantworten.

Was sich verändert hat

Seit ich diesen Schritt eingebaut habe, hat sich vor allem eins geändert: Die Arbeit lässt sich besser abgeben. Wenn die Anforderungen klar dokumentiert sind, kann der Solution Architect (auch ein Agent) eine technische Spec bauen, die ein Entwicklungs-Agent direkt umsetzen kann. Die Kette wird länger, aber jeder Schritt wird kürzer und vorhersagbarer.

Vorher war ich bei jeder Entscheidung der ad-hoc-Flaschenhals. Zum limitierenden Faktor wurde ich vor allem deshalb, weil mein Gedächtnis nicht perfekt ist und ich über Tage hinweg kein konsistentes Nudging leisten kann. Das klappt besser in klaren Intervallen: Denken — Planen — Implementieren.

Jetzt bin ich der Flaschenhals nur noch bei den Fragen, die wirklich mein Urteil brauchen — und die beantworte ich, bevor der erste Agent mit dem Code anfängt.

Den Prompt ausprobieren

Den vollständigen System Prompt als Markdown kannst du hier herunterladen: ANALYST.md

Speicher die Datei und starte den Agenten mit Claude, Codex, oder pi bspw. so:

$ claude --system-prompt-file ANALYST.md
$ codex --config developer_instructions="$(cat ANALYST.md)"
$ pi --system-prompt "$(cat ANALYST.md)"

Der Prompt enthält neben den neun Discovery-Phasen auch Gesprächsrichtlinien (wie der Agent mit Unklarheiten umgeht, wie er Scope Creep einfängt), ein Output-Template für das REQUIREMENTS.md-Dokument, und eine klare Grenzziehung: Der Agent darf keine Lösungen vorschlagen — er definiert das Problem, nicht die Architektur.

Der größere Workflow

Der Requirements Analyst ist der erste Schritt in einer längeren Kette. Der vollständige Workflow, den ich aktuell nutze:

1. Requirements Analyst — klärt Anforderungen, produziert REQUIREMENTS.md
2. Solution Architect — liest REQUIREMENTS.md, entwirft technische Spezifikation, produziert SPEC.md
3. Developer — implementiert nach SPEC.md, test-driven, in kleinen atomaren Commits
4. Reviewer — prüft Änderungen gegen SPEC.md, produziert COMMENTS.md, Loop zurück zum Developer

Jede Rolle hat einen eigenen (System) Prompt und läuft in einem eigenen Kontext. Über die einzelnen Rollen und wie sie zusammenspielen schreibe ich in den nächsten Wochen mehr. Der Requirements Analyst ist der Einstieg, weil er den größten Hebel hat: Einmal vorher konkret werden spart Tage an Korrekturen danach.