Software entsteht in Schleifen, nicht im Wasserfall: wie moderne KI-Entwicklung wirklich abläuft

Kurz gesagt. Klassische Softwareprojekte planen alles von vorne bis hinten durch und liefern am Ende. Moderne KI-Software entsteht anders: in kurzen Schleifen, bei denen nach jedem Durchlauf etwas Funktionierendes vorliegt, das man ansehen, testen und korrigieren kann. Der Unterschied ist nicht kosmetisch. Er entscheidet darüber, ob ein KI-Vorhaben in Produktion geht oder als teures Pilotprojekt endet. Und genau das ist die häufigste Art, wie KI-Projekte scheitern.

Warum der Wasserfall bei KI besonders schlecht funktioniert

Das klassische Vorgehen in der Softwareentwicklung heißt oft Wasserfall: erst der komplette Plan, dann die Umsetzung, am Ende die Lieferung. Bei gut verstandenen Problemen kann das funktionieren. Bei KI funktioniert es selten.

Der Grund ist einfach. Bei KI weißt du zu Beginn noch nicht, was tatsächlich gut genug funktioniert. Ob ein Modell deine Dokumente zuverlässig genug liest, ob ein Agent den Prozess wirklich end-to-end übernimmt, ob die Qualität in der Praxis reicht, das zeigt sich erst, wenn etwas läuft. Ein großer Plan, der zwölf Monate im Voraus festlegt, was gebaut wird, trifft auf eine Technologie, deren Ergebnis man vorher nicht kennt. Deshalb produzieren so viele KI-Vorhaben eine beeindruckende Demo und danach nichts, was in den Betrieb geht.

Wie verbreitet dieses Muster ist, zeigt eine Untersuchung des MIT (Projekt NANDA, "The GenAI Divide", 2025): rund 95 Prozent der untersuchten generativen KI-Pilotprojekte lieferten keinen messbaren Return und schafften es nicht in die Produktion. Wichtig zum Einordnen: das ist eine Aussage über generative KI-Pilotprojekte, nicht über KI insgesamt, und nicht über die Nutzung fertiger Werkzeuge. Aber genau um diese Pilotprojekte geht es, wenn ein Unternehmen etwas Eigenes bauen lässt. Der von MIT genannte Hauptgrund ist kein technischer, sondern ein struktureller: die Systeme lernen im Betrieb nicht dazu und werden nicht angepasst. Das ist ein Wasserfall-Problem.

Die Bauschleife

Der Gegenentwurf ist eine kurze, wiederholte Schleife. Ein Durchlauf sieht so aus:

1. Ein kleines Stück bauen. Nicht das ganze System, sondern der nächste sinnvolle Schritt.
2. Sofort prüfen. Läuft es? Löst es das Problem an echten Daten? Automatisierte Tests plus ein menschlicher Blick.
3. Aus dem Ergebnis lernen. Was funktioniert, was nicht, und was heißt das für den nächsten Schritt?
4. Wiederholen. Der nächste Durchlauf baut auf dem Gelernten auf.

Jeder Durchlauf endet mit etwas Funktionierendem, nicht mit einem Fortschrittsbericht. Das klingt nach einer Kleinigkeit, ändert aber alles: Risiko wird früh sichtbar statt am Ende, Kurskorrekturen kosten Tage statt Monate, und niemand baut zwölf Monate lang auf einer Annahme, die sich als falsch herausstellt.

Diese Arbeitsweise ist nicht neu, agile Softwareentwicklung folgt seit langem einem ähnlichen Prinzip. Neu ist, dass KI-Codieragenten die Schleife drastisch beschleunigen. Ein Durchlauf, der früher einen Sprint dauerte, kann heute in Stunden liegen. Damit wird das iterative Vorgehen bei KI nicht nur sinnvoll, sondern zur einzigen ehrlichen Option.

Wasserfall gegen Bauschleife

Was das in der Praxis heißt, mit echten Zahlen

Ein Vorbehalt vorweg, weil dieser Text sonst genau den Fehler machen würde, den er kritisiert: Die folgenden Zahlen stammen aus unserer eigenen Arbeit an unserer eigenen Plattform. Es sind keine Kundenzahlen und keine allgemeingültige Studie. Sie zeigen, wie eine kleine Mannschaft mit dieser Arbeitsweise liefert, nachprüfbar in unserer eigenen Git-Historie.

In einem Zeitraum von rund 36 Stunden gingen bei uns etwa 30 einzelne Features in Produktion, jedes als eigener geprüfter und zusammengeführter Schritt: zusammen 244 geänderte Dateien und gut 32.000 Zeilen Code. Das Testfundament dahinter umfasst 660 Testfälle über 76 Testdateien. Diese Geschwindigkeit kommt nicht daher, dass wir schneller tippen. Sie kommt daher, dass jeder Schritt klein, sofort geprüft und abgesichert ist, also aus der Schleife selbst.

Und zur Ehrlichkeit gehört die andere Seite. Schnelligkeit ohne Kontrolle ist gefährlich. Ein Beispiel aus unserem eigenen Betrieb: Zwei parallel arbeitende Agenten haben einmal dieselbe Datei angefasst, weil eine Zuständigkeitsliste eine Abhängigkeit nicht erfasst hatte, und sich gegenseitig ins Gehege kam. Solche Dinge passieren, wenn man Tempo macht. Der Punkt ist nicht, dass nichts schiefgeht. Der Punkt ist, dass die Schleife diese Fehler früh sichtbar macht, wo sie Minuten kosten, statt spät, wo sie ein Release kosten. Genau deshalb bauen wir die Prüfpunkte ein, bevor es losgeht, nicht nachdem etwas kaputtgegangen ist.

Woran du erkennst, mit wem du es zu tun hast

Wenn du KI-Software bauen lässt, ist die Arbeitsweise deines Partners eine der wenigen Fragen, die du vorab wirklich prüfen kannst. Ein paar Fragen, die schnell Klarheit schaffen:

• Wann sehe ich das erste lauffähige Stück? Wenn die Antwort "am Ende" lautet, ist es ein Wasserfall.
• Wie oft liefert ihr? Wochen sind gut, Quartale sind ein Warnsignal.
• Was passiert, wenn sich im Bauen herausstellt, dass eine Annahme falsch war? Wenn das ein Änderungsantrag mit Aufpreis ist statt der nächste Durchlauf, verrät das das Modell dahinter.
• Testet ihr an echten Daten oder nur in der Demo? Eine Demo beweist nichts über den Betrieb.

Wir bauen KI-Software in Produktion, jeden Tag, in genau diesen Schleifen. Wenn du wissen willst, wie sich das auf ein konkretes Vorhaben in deinem Unternehmen übertragen lässt, ist das der Stoff für ein erstes Gespräch.