„Mach mir eine App."
Das ist der häufigste Prompt, mit dem Entwickler ein neues Projekt starten. Und es ist 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.
Es gibt eine Datei namens CLAUDE.md, die im Projekt-Root liegt. 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. Nicht weil die Entwickler bei Anthropic nostalgisch sind, sondern weil es die einzige Reihenfolge ist, 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, nicht weniger.
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 ein Denkprozess ist, nicht nur ein Produktionsprozess. Dass die Architektur im Kopf des Entwicklers reift, während er implementiert.
Wenn ein KI-Agent den Code schreibt, findet dieses Lernen nicht statt. 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
Über die letzten Monate habe ich einen Workflow entwickelt, der diese Probleme adressiert. Er ist nicht elegant, aber er funktioniert.
Phase 1: Architektur — ohne Agent
Bevor ein Agent eine Zeile Code sieht, schreibe ich ein Architekturdokument. Kein Foliensatz, ein einfaches Markdown-Dokument mit:
- Zielsetzung: 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. Der Agent bekommt Kontext, nicht Freiheit.
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 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, nicht Monate. Die Planung dauert eine Stunde, nicht drei Monate.
- Iteration: Nach jedem Durchlauf kann das Architekturdokument angepasst werden. Es ist kein Vertrag, es ist ein lebendiges Dokument.
- Granularität: Die Aufgaben sind so klein, dass Fehler lokal bleiben. Ein falscher Prompt betrifft eine Funktion, nicht das ganze System.
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 in Minuten stattfindet. Was früher zu langsam war, ist jetzt genau richtig.
Die Implementierung ist so schnell geworden, dass die Denkzeit, die früher beim Codieren stattfand, jetzt davor stattfinden muss. Das ist kein Rückschritt. Das ist die logische Konsequenz.
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. Kein Wasserfall, kein Agile, sondern ein Workflow, der vom Werkzeug erzwungen wird: Der Mensch denkt, die Maschine tippt. Der Mensch entscheidet die Architektur, die Maschine implementiert sie. Der Mensch prüft das Ergebnis, die Maschine iteriert.
Das erfordert Fähigkeiten, die in der agilen Welt manchmal vernachlässigt wurden: die Fähigkeit, ein System zu entwerfen, bevor es existiert. Die Fähigkeit, Entscheidungen zu treffen und zu begründen, bevor der erste Test grün ist. Die Fähigkeit, zu planen.
90% fertig in Minuten. Aber nur wenn die Architektur stimmt. Und die schreibt kein Agent.