In diesem Beitrag
Bringt KI das Wasserfallmodell zurück? Wie viel Vorabplanung ist sinnvoll?
Du gibst einen detaillierten Plan frei. Erst Monate später kann jemand das Ergebnis nutzen. Inzwischen haben sich Prioritäten verschoben. Verkürzt KI diese Spanne, lohnt sich ein neuer Blick auf die Einwände gegen Vorabplanung.
Schnellere Implementierung kann gründliche Vorabplanung wirtschaftlich attraktiver machen. Ein guter Plan hat weniger Zeit zu veralten, und geklärte Entscheidungen werden früher nutzbar. Wir würden vor jeder folgenreichen Umsetzung das gewünschte Ergebnis, die Randbedingungen und die Abnahmekriterien festlegen. Annahmen müssen sich weiter an der Realität prüfen lassen.
Vorabplanung heißt, Entscheidungen vor der Implementierung zu klären. Das Wasserfallmodell ordnet die Umsetzung in aufeinanderfolgende Phasen. Du kannst vorab planen, ohne jede Anforderung bis zum letzten Release einzufrieren.
Stand der Recherche: 10. November 2026. Die Argumentation stützt sich auf Primärquellen und ein durchgerechnetes hypothetisches Beispiel. Wavect hat dafür kein Experiment zum Vergleich von Wasserfall und Agile durchgeführt. Das Szenario mit 100-fach schnellerer Codeerstellung ist eine Annahme, kein gemessenes Branchenergebnis.
Warum lohnt sich mit KI ein neuer Blick auf Vorabplanung?
Vorabplanung gewinnt an Wert, wenn die Implementierung so schnell wird, dass offene Entscheidungen die Auslieferung bestimmen. Ein Agent kann eine abgestimmte Anforderung sofort umsetzen. Hat niemand festgelegt, was als korrekt gilt, entsteht in kurzer Zeit Arbeit, die jemand verwerfen oder überarbeiten muss.
Beim Export von Kundendaten könnten zwei Agenten parallel die Oberfläche und die API bauen. Eine vereinbarte Mandantengrenze, ein gemeinsames Schema und festgelegtes Fehlerverhalten richten beide auf dasselbe Ergebnis aus. „Bau den Export“ überlässt diese Entscheidungen zwei voneinander unabhängigen Vermutungen.
Eine Änderung, die Nutzer noch diese Woche ausprobieren können, ist veränderten Umständen kürzer ausgesetzt als eine Umsetzung, die ein Jahr dauert. Das gilt bei gleicher anfänglicher Unsicherheit. Eine kürzere Implementierung kann Planung rentabler machen, ohne Vorhersagen unfehlbar zu machen.
Unser Essay über KI, Spezifikationen und die Rückkehr der Softwarefabrik behandelt die grundlegende Verschiebung der Engineering-Arbeit. Hier geht es darum, wie viel du vor der nächsten Umsetzung klären solltest.
War langsames Programmieren das einzige Problem des Wasserfallmodells?
Eine lange Implementierung konnte Wasserfallpläne veralten lassen. Späte Erkenntnisse waren ein weiteres Problem. Selbst eine sofortige Umsetzung kann die falsche Anforderung erfüllen. Planung muss deshalb falsche Annahmen sichtbar machen, bevor sich das Team zu weit festlegt. Neue Erkenntnisse müssen zu geänderten Entscheidungen führen können.
Royces Aufsatz von 1970 warnte bereits davor, Systemgrenzen erst bei späten Tests zu erkennen, und beschrieb Rückkopplungen zwischen Entwicklungsphasen. Als Begründung für einen starren Prozess mit nur einem Durchlauf taugt er wenig. Das zeigt der Originalaufsatz zur Entwicklung großer Softwaresysteme.
Auch das Agile Manifesto erkennt den Wert von Plänen an, gewichtet die Reaktion auf Veränderungen aber höher. Wer trotz gegenteiliger Erkenntnisse am Plan festhält, kann auch eine schnelle Implementierung verschwenden.
Ist die Implementierung mit KI schon 100-mal schneller?
Die hier ausgewerteten Studien belegen nicht, dass Software mit KI generell 100-mal schneller implementiert wird. Das Ergebnis hängt von Aufgabe, Entwickler, Werkzeug und Messgröße ab. Bearbeitungszeit einer Programmieraufgabe, Codeaktivität, Releases und Kundennutzen beantworten unterschiedliche Fragen.
| Evidenz | Berichtetes Ergebnis | Aussagegrenze |
|---|---|---|
| Kontrolliertes Copilot-Experiment, durchgeführt 2022 | 95 Entwickler rekrutiert; bei abgeschlossenen Aufgaben war die Bearbeitungszeit mit Copilot 55,8 % kürzer. | Eine HTTP-Server-Aufgabe in JavaScript, keine vollständige Produktauslieferung. |
| METR-Experiment von Anfang 2025 | 16 erfahrene Maintainer, 246 Issues; mit KI-Zugang dauerte die Bearbeitung 19 % länger. | Ein bestimmtes Repository-Umfeld und eine bestimmte Werkzeuggeneration, keine allgemeine Aussage über heutige Werkzeuge. |
| Writing Code vs. Shipping Code, Fassung vom September 2026 | Die Beobachtungsstudie mit mehr als 500.000 GitHub-Entwicklern schätzte einen deutlich stärkeren Zuwachs bei der Codeaktivität als bei Releases. | Code- und Release-Zahlen messen weder die verstrichene Zeit noch den Kundennutzen. |
Im Update vom Februar 2026 erklärt METR, dass Auswahleffekte und die Zeitmessung bei parallelen Agenten die neuere Produktivitätsschätzung unzuverlässig machen. Die frühere Verlangsamung ist kein Urteil über heutige Werkzeuge.
Als Gedankenexperiment lässt sich der Faktor 100 trotzdem ernst nehmen: Wenn eine konkrete Implementierung so viel schneller wird, wie stark verbessert das das gesamte Projekt?
Was würde 100-mal schnelleres Programmieren am Projekt ändern?
In einem hypothetischen Projekt mit aufeinanderfolgenden Phasen kann 100-fach schnelleres Programmieren den Planungsanteil deutlich erhöhen. Das gesamte Projekt wird dabei wesentlich weniger als 100-mal schneller. Entscheidend sind der ursprüngliche Anteil der Implementierung und die Frage, ob auch andere Arbeiten schneller werden. Die Rechnung bestimmt kein ideales Planungsbudget.
Nehmen wir bei gleichem Umfang und gleichen Abnahmekriterien 10 Tage für die Planung, 80 für die Implementierung und 10 für Prüfung und Release an. Gemessen wird die verstrichene Zeit. Nur die Implementierung beschleunigt sich. Die Phasen überlappen sich nicht; Nacharbeit und Wartezeiten bleiben unverändert. Das sind illustrative Eingaben, keine Wavect-Messwerte oder Branchendurchschnitte.
Gesamtdauer in Tagen = 10 + 80 / Beschleunigungsfaktor der Implementierung + 10
| Beschleunigungsfaktor | Tage für Implementierung | Gesamtdauer in Tagen | Beschleunigung des Gesamtprojekts | Planungsanteil |
|---|---|---|---|---|
| 1× | 80 | 100 | 1× | 10 % |
| 10× | 8 | 28 | 3,57× | 35,7 % |
| 100× | 0,8 | 20,8 | 4,81× | 48,1 % |
| Sofortige Implementierung als Grenzfall | 0 | 20 | 5× | 50 % |
Im 100×-Szenario beansprucht Planung fast die Hälfte der Zeit, obwohl kein zusätzlicher Planungstag hinzukommt. Ihr Anteil steigt, weil die Implementierung schrumpft. Daraus folgt nicht, dass eine doppelt so lange Planungsphase helfen würde.
Miss in deinem eigenen Prozess den kritischen Pfad. Addiere keine Zeiten, die sich überlappen. Verändert KI auch Tests, Reviews oder Nacharbeit, schätze diese Effekte getrennt. Die relevante Größe ist die verstrichene Zeit bis zu einer abgenommenen, nutzbaren Änderung.
Was solltest du klären, bevor ein Agent mit der Umsetzung beginnt?
Plane die Entscheidungen, deren Korrektur auch nach einer schnellen Implementierung teuer wäre: Nutzerergebnis, Zuständigkeit, Datengrenzen, Schnittstellen, Fehlerverhalten und Abnahmekriterien. Kläre jede so weit, dass sie die nächste Umsetzung sinnvoll begrenzt. Unkritische Implementierungsdetails brauchen keine Vorgabe, nur weil ein Agent ein langes Dokument darüber schreiben kann.
Bei folgenreichen Änderungen sollte die verantwortliche Person diese Fragen beantworten:
- Ergebnis und Umfang: Wessen Problem soll sich ändern, woran erkennst du Erfolg und welche angrenzenden Wünsche gehören nicht dazu?
- Randbedingungen: Auf welche Daten und Aktionen darf das System zugreifen, was muss es erhalten und welche Kompatibilitätszusagen gelten bereits?
- Schnittstellen: Was empfängt, liefert und protokolliert jede Komponente, wenn etwas fehlschlägt?
- Abnahme und Wiederherstellung: Welche Nachweise erlauben das Release, wer bewertet sie und wie stoppst oder korrigierst du einen fehlgeschlagenen Rollout?
Die MirrorCode-Ergebnisse von Epoch AI und METR vom April 2026 zeigen umfangreiche autonome Neuimplementierung mit ausführbarem Referenzverhalten und detaillierten Tests. Dieser eng umrissene Benchmark stützt den Nutzen prüfbarer Spezifikationen. Er belegt weder eine Überlegenheit des Wasserfallmodells noch einen gemessenen Geschwindigkeitsfaktor gegenüber Menschen.
„Fehler angemessen behandeln“ gibt einem Reviewer wenig zu prüfen. „Nach einer unklaren Antwort des Zahlungsanbieters die Vorgangskennung beibehalten und den Status vor einem weiteren Versuch abgleichen“ beschreibt dagegen testbares Verhalten.
Wie viel Vorabplanung braucht die jeweilige Änderung?
Wähle die Planungstiefe danach, wie unsicher die Anforderungen sind und wie viel es kosten würde, eine Entscheidung rückgängig zu machen. Geklärte Anforderungen mit teuren Folgen verdienen genaue Vorbereitung. Ungeklärte Anforderungen, deren Umsetzung sich günstig ändern lässt, sprechen für ein frühes Experiment. Sind Unsicherheit und Korrekturkosten hoch, plane zuerst einen sicheren Versuch, ohne dich bereits auf das vollständige System festzulegen.
| Unsicherheit der Anforderungen | Kosten einer späteren Korrektur | Sinnvoller nächster Schritt | Beispiel |
|---|---|---|---|
| Niedrig | Niedrig | Kurze, verbindliche Abnahmekriterien festhalten und umsetzen. | Eine Darstellungsänderung mit abgestimmtem Beispiel, die keine gespeicherten Daten verändert. |
| Niedrig | Hoch | Abhängigkeiten, Fehlerfälle und Wiederherstellung vor der Ausführung klären. | Eine Migration, die bestehende Datensätze und Integrationen erhalten muss. |
| Hoch | Niedrig | Eine Lernfrage formulieren und eine Wegwerfversion testen. | Zwei Onboarding-Abläufe im Test mit repräsentativen Nutzern. |
| Hoch | Hoch | Unsicherheit durch Simulation oder einen isolierten Versuch verringern, bevor die Entscheidung bindend wird. | Eine neue Zuteilungsregel wird mit synthetischen Daten geprüft, bevor sie reale Konten beeinflussen kann. |
Kann ein Agent schnell einen sicheren Prototyp bauen, lohnt sich eine weitere Woche Diskussion über eine spekulative Oberfläche womöglich kaum. Schnellere Umsetzung kann den Wert der Planung bekannter Randbedingungen erhöhen. Gleichzeitig kann sie den Wert von Vorhersagen über Nutzerpräferenzen senken, die du direkt beobachten könntest.
Berücksichtige bei den Kosten einer späteren Korrektur die Folgen für Menschen, verlorene Daten, gemachte Zusagen, Betriebsunterbrechungen und Engineering-Aufwand. Günstige Codeerstellung macht nicht jede Folge günstig. Verbindliche Sicherheitsanforderungen gelten auch dann, wenn die Kostenrechnung ein riskantes Experiment attraktiv erscheinen lässt.
Wann ist der Plan gut genug, um mit der Umsetzung zu beginnen?
Beende die Planung, sobald der nächste Umsetzungsabschnitt ein abgestimmtes Ziel, klare Randbedingungen, eine verantwortliche Person, beobachtbare Abnahmekriterien und einen Wiederherstellungsweg hat. Halte verbleibende Unsicherheiten fest und entscheide, wie du sie prüfst. Plane weiter, wenn die erwartete Vermeidung teurer Fehler den zusätzlichen Zeitaufwand rechtfertigt.
Ein fiktives Beispiel: Ein Support-Agent soll über einen Zahlungsanbieter eine vollständige Erstattung anfordern. Wir nehmen an, dass Erstattungsfähigkeit und Freigaberegeln bereits abgestimmt sind. Widersprechen sich diese Regeln, hilft zuerst der separate Leitfaden, widersprüchliche Geschäftsregeln vor der Spezifikation zu klären.
| Entscheidung vor der Implementierung | Prüfbare Anforderung |
|---|---|
| Berechtigung | Nur eine berechtigte Support-Rolle darf die freigegebene Erstattung für den eigenen Mandanten anfordern. |
| Identität des Vorgangs | Einen stabilen Idempotenzschlüssel für die autorisierte Erstattung dauerhaft speichern und einen Anbieter verwenden, der diesen Schlüssel über mehrere Versuche hinweg unterstützt. |
| Nebenläufigkeit | Gleichzeitige Klicks und doppelte Zustellungen dürfen keine getrennten Erstattungsvorgänge für denselben freigegebenen Antrag erzeugen. |
| Unklare Antwort des Anbieters | Bei einem Timeout bleibt der Vorgang bis zum Statusabgleich offen. Eine verlorene Antwort allein darf keinen neuen Vorgang auslösen. |
| Abnahme und Wiederherstellung | In einer Testumgebung nachweisen, dass unberechtigte Anfragen abgewiesen und doppelte Anfragen sowie verlorene Antworten korrekt behandelt werden; dokumentieren, wie der Betrieb einen ungeklärten Ausgang abgleicht. |
Diese Vereinbarung reicht, um das Verhalten des Anbieters zu untersuchen und eine begrenzte Testintegration zu bauen. Sie ist kein implementiertes oder verifiziertes Erstattungssystem. Der Agent darf Namen für Hilfsfunktionen wählen. Er darf keine Geschäftsregeln stillschweigend festlegen oder annehmen, dass bei einem Timeout kein Geld geflossen ist.
Was würde eine weitere Planungssitzung entscheiden, das uns diese sichere Umsetzung nicht günstiger zeigen könnte? Geht es nur noch um sprachlichen Feinschliff am Dokument, beginne mit der begrenzten Umsetzung.
Wie funktioniert ein KI-Entwicklungszyklus mit bewusster Vorabplanung?
Halte die Umsetzung klein genug für ein gründliches Review und die Spezifikation leicht änderbar. Vereinbare eine begrenzte Änderung, implementiere sie und prüfe sie gegen unabhängig überprüfte Abnahmekriterien. Sieh dir das Ergebnis mit Nutzern oder der verantwortlichen Person an, bevor der nächste Umsetzungsabschnitt beginnt.
- Ein Ergebnis auswählen. Benenne den Nutzer, die beobachtbare Änderung und die Person, die sie abnehmen kann.
- Teure Unklarheiten auflösen. Prüfe die Randbedingungen und Fehlerfälle, die sich aus der Planungsmatrix ergeben.
- Eine prüfbare Implementierung erzeugen. Teile die Arbeit dort auf, wo du Verhalten verifizieren kannst. Halte jede Abweichung von der freigegebenen Vereinbarung fest.
- Umsetzung und Annahmen prüfen. Teste die Korrektheit, prüfe den Diff und beschaffe Nachweise dafür, dass das Verhalten dem vorgesehenen Nutzer hilft.
- Die Spezifikation aktualisieren. Halte akzeptiertes Verhalten, verworfene Annahmen und die nächste offene Frage sichtbar, bevor erneut gebaut wird.
GitHubs Einführung in Spec Kit beschreibt fortgeschriebene Spezifikationen und kleine, prüfbare Aufgaben. Die Werkzeuge behandelt unser Spec-Kit-Leitfaden für Produktionsteams. Eine strukturierte Spezifikation braucht weiterhin ein unabhängiges Urteil darüber, ob ihre Annahmen stimmen.
Auch DORAs Leitfaden zu kleinen Arbeitspaketen betont schnelles Feedback bei KI-gestützter Entwicklung. Begrenze das Arbeitspaket auf das, was du prüfen kannst, auch wenn der Agent mehr erzeugen könnte.
Woran erkennst du, ob sich zusätzliche Planung lohnt?
Bewerte zusätzliche Planung anhand abgenommener Änderungen, Nacharbeit und nach dem Release entdeckter Fehler. Miss vom Beginn der Klärung bis zum abgenommenen Release, einschließlich Spezifikationsreview und Wartezeit. Eine kürzere Programmierphase hilft nur, wenn die übrige Arbeit den Gewinn nicht aufzehrt und die Abnahmekriterien erhalten bleiben.
Für einen vorgeschlagenen Pilotversuch könntest du vergleichbare Änderungen einmal mit einer kurzen Aufgabenbeschreibung und einmal mit einer ausführlicheren Vereinbarung vorab umsetzen. Erfasse Größe, Unsicherheit, Kosten einer späteren Korrektur, Vertrautheit des Teams mit der Aufgabe und Werkzeugversionen. Ordne vergleichbare Aufgaben möglichst zufällig zu. Ist das nicht praktikabel, behandle den Vergleich als beschreibend und mache die Unterschiede zwischen den Aufgaben sichtbar.
Erfasse neben der verstrichenen Durchlaufzeit den menschlichen Aufwand für Planung, Implementierung und Review. Notiere wiederaufgenommene Arbeit, nach dem Release entdeckte Fehler und ob die Änderung den vorgesehenen Nutzen erzielt hat. Das sind vorgeschlagene Messungen, keine Ergebnisse eines von uns durchgeführten Piloten.
Halte Umfang und Qualitätskriterien konstant. Mehr generierte Zeilen belohnen Menge; mehr Releases können lediglich kleinere Pakete bedeuten. Unser Leitfaden zu den Kosten eines KI-MVP behandelt die Projektbudgetierung. Hier lautet die Frage, ob zusätzliche Klärung ihren Aufwand im Entwicklungszyklus rechtfertigt.
Solltest du das Wasserfallmodell zurückholen?
Nimm Vorabplanung ernst, wenn sich Anforderungen klären lassen und Fehler teuer rückgängig zu machen sind. Mit KI lohnt sich ein Versuch: Eine gut beschriebene Implementierung könnte fertig sein, solange ihre Annahmen noch tragen. Halte den Umfang begrenzt und passe den Plan an neue Erkenntnisse an. Investiere nur mehr in Planung, wenn sich die Umsetzung bis zur Abnahme dadurch verbessert.
Für einen bekannten Ablauf würden wir eine präzise Spezifikation vorbereiten, bevor Agenten ihn umsetzen. Sind Nutzer oder Nutzenversprechen eines Produkts noch unklar, würden wir das Experiment planen und früh Evidenz sammeln.
Kann sich dein Team noch nicht auf Ergebnis, Randbedingungen oder Abnahmeverantwortung einigen, setzt Wavects Software Discovery und Anforderungsklärung bei diesen Entscheidungen an. Der Leitfaden zur Discovery-Phase erklärt den Umfang. Unsere Quivr-Fallstudie zu Protokollentwicklung und Migration liefert angrenzenden Engineering-Kontext. Sie belegt weder einen KI-Geschwindigkeitsfaktor noch einen Vergleich mit dem Wasserfallmodell.
Besprich eine konkrete geplante Änderung in einem Discovery-Gespräch. Kläre, was vor der Implementierung feststehen muss und welche Nachweise du vor dem Release brauchst.