„Mach mir eine App."
Das ist der häufigste Prompt, mit dem Entwickler ein neues Projekt starten, und der schlechteste. Nicht weil das Modell nichts produziert, im Gegenteil. Es produziert sofort. Ordnerstruktur, Konfiguration, Routing, Datenbankschema, UI-Komponenten. In Minuten entsteht etwas, das aussieht wie eine Anwendung.
Aber es ist keine Architektur. Es ist eine Halluzination von Architektur.
Das Architekturproblem
Wenn ich einem KI-Agenten sage „Baue mir eine Projektverwaltung mit Benutzerrollen und Zeiterfassung", trifft er in den ersten Sekunden Dutzende von Architekturentscheidungen: Welches Framework? Welches ORM? Wie werden Rollen modelliert (RBAC, ACL, oder einfache Flags)? Wie wird Zeiterfassung abgebildet (pro Aufgabe, pro Projekt, pro Tag)? Monolith oder Services?
Das Modell entscheidet nicht. Es rät. Es wählt das statistisch wahrscheinlichste Setup, also das, was in den meisten Tutorials und GitHub-Repos vorkommt. Für einen Prototypen mag das reichen. Für eine Anwendung, die gewartet, erweitert und betrieben werden muss, ist es ein Fundament aus Zufällen.
LLMs haben keinen Architekturüberblick. Sie können sich keinen erarbeiten, weil Architektur kein Textproblem ist. Sie ist ein Entscheidungsproblem, und Entscheidungen brauchen Kontext, den kein Prompt vollständig liefern kann.
Was das Werkzeug selbst verrät
Ein Blick auf die Werkzeuge selbst ist aufschlussreich, und ein wenig meta.
Ich nutze Claude Code als meinen Hauptagenten. Dieses Werkzeug hat einen eingebauten Plan Mode: Bevor Code geschrieben wird, erstellt der Agent einen Plan, den der Mensch absegnen muss. Das Tool ist buchstäblich so gebaut, dass es zuerst denkt und dann implementiert.
Im Projekt-Root liegt eine Datei namens CLAUDE.md. Sie enthält Architekturregeln, Konventionen, Patterns, alles, was der Agent wissen muss, um konsistenten Code zu schreiben. Ohne diese Datei passiert etwas Vorhersagbares: Der Agent liest den bestehenden Code, leitet daraus ab, was „normal" ist, und reproduziert es. Wenn der Code inkonsistent ist, wird der neue Code es auch sein.
„Claude does not invent architecture. It copies what it sees." (aus der Claude Code Dokumentation)
Die Ironie ist kaum zu übersehen: Das Werkzeug selbst ist für Wasserfall gebaut. Spezifiziere, plane, dann implementiere. In genau dieser Reihenfolge. Die Entwickler bei Anthropic haben das nicht aus Nostalgie so gebaut. Es ist die einzige Reihenfolge, die zuverlässig funktioniert.
Wasserfall in 15 Minuten
Ich bin nicht der Einzige, der das beobachtet hat.
Harper Reed hat einen Workflow beschrieben, der mit einer Konversation beginnt: Er lässt sich vom Modell Frage für Frage durch seine Idee führen, bis eine vollständige Spezifikation steht, eine spec.md. Dann generiert ein Reasoning-Modell daraus einen Projektplan mit kleinteiligen, aufeinander aufbauenden Aufgaben. Erst danach wird Code geschrieben.
Addy Osmani, der im Chrome-Team bei Google arbeitet, beschreibt denselben Ansatz und nennt ihn beim Namen: „Waterfall in 15 minutes." Eine komprimierte, aber vollständige Planungsphase (Anforderungen, Architekturentscheidungen, Datenmodell, Teststrategie), bevor die erste Zeile Code entsteht.
Das Muster ist eindeutig: Die Leute, die erfolgreich mit KI-Agenten arbeiten, planen mehr als vorher.
Warum Agile hier nicht greift
Das widerspricht einem Grundsatz, der unsere Branche seit 20 Jahren prägt: Lass die Architektur emergent entstehen. Schreib Code, lerne dabei, refaktoriere. „Working software over comprehensive documentation."
Dieses Prinzip setzt voraus, dass der Mensch beim Codieren lernt. Dass das Schreiben von Code nicht nur ein Produktionsprozess ist, sondern auch ein Denkprozess. Dass die Architektur im Kopf des Entwicklers reift, während er implementiert.
Wenn ein KI-Agent den Code schreibt, bleibt dieses Lernen aus. Die Implementierung ist in Minuten fertig, aber das Verständnis für die Entscheidungen, die darin stecken, ist es nicht. Die Architektur emergiert nicht, sie driftet: Jeder Prompt fügt eine Schicht hinzu, die auf der vorherigen aufbaut, ohne dass jemand das Gesamtbild im Kopf hat.
Die Agile-Bewegung hat Planung durch Lernen beim Tun ersetzt. KI-Agenten haben das Tun automatisiert. Was bleibt, wenn weder geplant noch gelernt wird?
Mein Workflow für Greenfield-Projekte
In den letzten Monaten habe ich einen Workflow entwickelt, der diese Probleme angeht. Er ist nicht elegant, aber er funktioniert.
Phase 1: Architektur ohne Agent
Bevor ein Agent eine Zeile Code sieht, schreibe ich ein Architekturdokument, ein einfaches Markdown-Dokument (kein Foliensatz) mit:
- Ziel: Was soll die Software tun? Was explizit nicht?
- Datenmodell: Welche Entitäten gibt es? Wie hängen sie zusammen?
- Technische Entscheidungen: Welches Framework, warum? Welche Patterns?
- Schnittstellen: Welche APIs, welche Formate?
Das dauert eine Stunde. Manchmal zwei. Aber diese Zeit spare ich mehrfach wieder ein, weil der Agent danach nicht raten muss.
Phase 2: Aufgaben definieren, klein und sequenziell
Ich zerlege die Architektur in Aufgaben, die einzeln abarbeitbar und einzeln testbar sind. Nicht „Implementiere die Benutzerverwaltung", sondern „Erstelle das User-Model mit diesen Feldern" → „Schreibe die Registrierung mit diesen Validierungsregeln" → „Implementiere die Login-Route mit diesen Akzeptanzkriterien."
Jede Aufgabe hat ein klares Ergebnis und klare Grenzen. Innerhalb dieser Grenzen bekommt der Agent Kontext.
Phase 3: Implementierung mit Pipeline
Jede Aufgabe durchläuft eine automatisierte Pipeline: Compile, Lint, Test. Der Agent iteriert gegen diese Pipeline, bis alles grün ist. Dazu laufen eigene Quality-Gate-Skripte: Prüfungen auf offene TODOs, verschluckte Fehler, fehlende Tests.
Phase 4: Review-Zyklus
Nach jeder abgeschlossenen Aufgabe lasse ich den Code reviewen, teilweise von einem zweiten Agenten, immer von mir. Nicht nur auf Korrektheit, sondern auch auf Architekturkonformität: Hält sich der Code an die Entscheidungen aus Phase 1? Oder hat der Agent stillschweigend ein anderes Pattern eingeführt?
Letzteres passiert häufiger, als man denkt.
Was alt aussieht, ist neu gedacht
Ja, das sieht aus wie Wasserfall. Spezifikation → Design → Implementierung → Test → Review. In genau dieser Reihenfolge.
Aber es gibt wesentliche Unterschiede zum Wasserfall der 90er:
- Geschwindigkeit: Der gesamte Zyklus dauert Stunden, die Planung eine Stunde. Früher waren es Monate, für die Planung allein drei.
- Iteration: Nach jedem Durchlauf kann ich das Architekturdokument anpassen. Es ist ein lebendiges Dokument und kein Vertrag.
- Granularität: Die Aufgaben sind so klein, dass Fehler lokal bleiben. Ein falscher Prompt betrifft nur eine einzelne Funktion.
Was gleich geblieben ist, ist das Prinzip: Denken vor Tippen. Der alte Wasserfall scheiterte daran, dass zwischen dem Denken und dem Ergebnis Monate lagen und sich die Anforderungen änderten. Der neue Wasserfall hat dieses Problem nicht, weil die Implementierung nur Minuten dauert. Was früher zu langsam war, ist jetzt genau richtig.
Die Implementierung ist so schnell geworden, dass die Denkzeit, die früher im Codieren steckte, jetzt davor liegen muss. Das ist die logische Konsequenz daraus und kein Rückschritt.
Handwerk heißt planen können
In 35 Jahren Softwareentwicklung habe ich beide Extreme erlebt: den starren Wasserfall der 90er mit seinen tonnenschweren Pflichtenheften und die agile Gegenbewegung, die Planung fast zur Sünde erklärte. Beides in Reinform hat nicht funktioniert.
Was jetzt entsteht, ist etwas Drittes, ein Workflow, den das Werkzeug erzwingt: Der Mensch denkt, entscheidet die Architektur und prüft das Ergebnis. Die Maschine tippt, implementiert die Architektur und iteriert.
Das erfordert Fähigkeiten, die in der agilen Welt manchmal vernachlässigt wurden: ein System zu entwerfen, bevor es existiert, und Entscheidungen zu treffen und zu begründen, bevor der erste Test grün ist. Mit einem Wort: planen.
90% fertig in Minuten, aber nur, wenn die Architektur stimmt. Die schreibt kein Agent.