Vom KI-Prototyp zum Produktivsystem: Was zwischen Demo und Livebetrieb wirklich passiert

Ein Unternehmen kam mit einem Prototyp zu uns. Gebaut hatte ihn jemand aus dem eigenen Haus — ohne Entwicklungshintergrund, vollständig mit KI. Der Prototyp lief, sah aus wie ein Produkt und hatte im Vertrieb bereits Türen geöffnet. Er hielt nur keiner Produktionslast stand.

Sechs Monate später war dasselbe System live und stabil. Daran gearbeitet hat ein Zweierteam. Wir beschreiben diesen Fall hier anonymisiert und in Teilen abgewandelt, weil wir ihn in Varianten inzwischen mehrmals im Jahr sehen — und weil die naheliegende Lehre daraus die falsche ist.

Die falsche Lehre lautet: „Nutzt einfach KI.“ Genau das hatten sie getan. So sind sie überhaupt erst zu einem Prototyp gekommen, der nicht in Betrieb gehen konnte. Interessant ist der Teil danach.

Der Ausgangspunkt

Das Produkt ist die Betriebssoftware, auf der eine Filiale läuft: Bedarfsprognose aus Verkaufshistorie, daraus abgeleitete Vorbereitungspläne, Bestands- und Ablaufverfolgung, Timer und Aufgaben — alles auf den Tablets, mit denen die Schicht tatsächlich arbeitet. Kein Dashboard für die Zentrale, sondern das Werkzeug, ohne das der Betrieb stehenbleibt.

Die Kundschaft des Unternehmens sind große Filialketten. Auf dem Tisch lag ein Vertrag mit einer Gruppe, deren Ausrollung mehrere hundert Standorte erreichen konnte. Zwischen dem Unternehmen und diesem Vertrag stand genau eine Sache: der Prototyp.

Zur Einordnung der Zahlen in diesem Artikel: Sie stammen aus diesem einen Projekt, sind gerundet und teilweise verfremdet. Sie sind ein Erfahrungswert, kein Benchmark. Wir zeigen sie trotzdem, weil die Verteilung — wohin der Aufwand geht — nach unserer Erfahrung erstaunlich stabil ist.

Was ein Prototyp beweist und was nicht

Der Prototyp war nicht schlecht. Er war das, was er sein sollte: ein Beweis, dass die Idee trägt. Die Bedarfsprognose lieferte plausible Zahlen, die Oberfläche war bedienbar, der Ablauf einer Schicht ließ sich vorführen. Für eine Vertriebsvorführung reicht das vollständig aus — und das ist ein echter Wert, kein Nebenprodukt.

Was er nicht war: ein System. Er war nicht erweiterbar, nicht nachvollziehbar und nicht ansatzweise in der Lage, mehrere hundert Standorte gleichzeitig zu tragen. Das ist keine Kritik an der Person, die ihn gebaut hat. Es ist der Unterschied zwischen zwei völlig verschiedenen Aufgaben, die zufällig beide „Software schreiben“ heißen.

Was die Vorführung verlangt	Was der Betrieb verlangt
Ein Ablauf funktioniert von Anfang bis Ende	Alle Abläufe funktionieren, auch in unerwarteter Reihenfolge
Ein Nutzer, ein Gerät, ein Standort	Dutzende Geräte, hunderte Standorte, gleichzeitig, mit widersprüchlichen Ständen
Verbindung ist vorhanden	Das Tablet in der Küche verliert die Verbindung — und muss weiterarbeiten
Daten sind sauber	Daten sind unvollständig, doppelt, verspätet oder aus einer anderen Zeitzone
Das Schema steht fest	Das Schema ändert sich, während echte Daten darin liegen
Fehler bricht die Vorführung ab	Fehler kostet Ware, Schichtzeit oder eine Auditverletzung

Diese Tabelle ist der ganze Artikel in Kurzform. Alles Weitere ist die Frage, was es kostet, von der linken in die rechte Spalte zu kommen. Wer noch vor dieser Entscheidung steht, findet die Abgrenzung ausführlicher in Was ist ein Minimum Viable Product?.

Die vier Bruchstellen, die wir fast immer finden

KI-generierter Code, den niemand prüft, bricht bemerkenswert reproduzierbar an denselben vier Stellen. Das liegt nicht an der Qualität der Modelle, sondern daran, dass diese vier Dinge in keinem Prompt vorkommen — man fragt nicht danach, wenn man nicht weiß, dass es sie gibt.

Dazu kommt eine fünfte Sache, die keine Bruchstelle ist, sondern deren Ursache: Es gab keinen einzigen Test und keine einzige geprüfte Änderung. Niemand konnte feststellen, ob eine Anpassung etwas kaputt gemacht hatte, außer indem er es später bemerkte.

Was der Lasttest ergab

Bevor wir irgendetwas umgebaut haben, haben wir gemessen. Der Lasttest simulierte die Vorbereitungsplanung zum Schichtwechsel — der Moment, in dem alle Standorte gleichzeitig rechnen lassen. Die Zahlen sind die p95-Antwortzeit, also der Wert, unter dem 95 Prozent der Anfragen bleiben.

Gleichzeitige Standorte	Prototyp	Nach dem Umbau
1	0,4 s	0,2 s
10	3,1 s	0,2 s
40	13,6 s, 4 % Fehler	0,3 s
120	Abbruch nach 60 s	0,4 s
250	nicht durchführbar	0,6 s

Die Ursache war nicht die Rechenlast der Prognose, sondern die Art, wie die Daten geholt wurden: eine Abfrage pro Zutat pro Standort, verschachtelt in einer Schleife. Ein Muster, das bei einem Standort unsichtbar bleibt und bei vierzig das System umlegt. Wir haben es an sechs Stellen im Code gefunden.

Der Prototyp war nicht langsam. Er war nur nie gefragt worden, ob er es ist. Messen ist billiger als vermuten — und die Messung entscheidet, was zuerst angefasst wird.

Nicht wegwerfen, nicht huldigen

Die zwei üblichen Reaktionen auf einen solchen Prototyp sind beide falsch. Die eine: alles wegwerfen und von vorn anfangen — teuer, langsam und ein Schlag ins Gesicht der Person, die das Ding gebaut und dem Unternehmen damit einen Vertrag herangeholt hat. Die andere: den Prototyp als Fundament behandeln und weiter darauf stapeln — schnell, bis es einstürzt.

Wir haben ihn behandelt wie ein Altsystem: bewerten, was trägt, und gezielt ersetzen, was nicht trägt. Dasselbe Vorgehen, das wir in Legacy-Software modernisieren statt ersetzen beschreiben — nur dass das „Altsystem“ hier vier Monate alt war.

42 Prozent des KI-Codes haben es also in irgendeiner Form in das Produktivsystem geschafft. Das ist deutlich mehr, als die übliche Erzählung nahelegt. Übernommen wurde vor allem, was nah an der Oberfläche liegt: Bildschirmaufbau, Formulare, Zustandsführung im Frontend, die Grundzüge der Prognoselogik. Neu geschrieben wurde alles, was mit Daten, Gleichzeitigkeit und Betrieb zu tun hat.

Bemerkenswert ist die Kategorie „ersatzlos gelöscht“. 17 Prozent des Codes taten schlicht nichts — halb fertige Funktionen, doppelte Implementierungen desselben Ablaufs, Konfigurationsschalter ohne Wirkung. Das ist der typische Rückstand aus einer Arbeitsweise, in der niemand aufräumt, weil niemand liest. Mehr dazu in 6 Wege, wie Du technischer Schuld begegnest.

Wohin die sechs Monate gegangen sind

Die Frage, die uns in Angeboten am häufigsten gestellt wird, lautet: Warum dauert das so lange, der Prototyp stand doch schon? Die Antwort ist diese Verteilung. Hinter „Datenmodell“ stecken auch die Migrationen, hinter „Tests“ das gesamte Sicherheitsnetz und hinter „Überwachung“ der Betriebsaufbau.

Zwölf Prozent der Arbeit waren neue Funktionen. Alles andere war die Umwandlung von etwas, das aussah wie ein Produkt, in etwas, das ein System ist. Wer Angebote vergleicht, sollte genau hier hinsehen: Ein Angebot, das im Wesentlichen aus Funktionslisten besteht, hat diese 88 Prozent entweder nicht gesehen oder nicht eingepreist. Woran man das in der Anforderungsphase erkennt, steht in Lastenheft für Softwareprojekte.

Der Ablauf

Auffällig daran: Erst in Monat 4 sieht jemand von außen einen Unterschied. Die ersten drei Monate produzieren keinen sichtbaren Fortschritt, sondern die Voraussetzung dafür, dass Fortschritt später nicht mehr zurückgenommen werden muss. Das ist die Phase, in der Projekte abgebrochen werden — und der Grund, warum wir sie in kurzen Abständen gemeinsam durchgehen statt monatlich zu berichten.

Ein Zweierteam statt einer Mannschaft

Auf dem Projekt saß ein Pod: eine entwickelnde Person und eine Person für Steuerung und Abstimmung. Nicht zehn. Das ist keine Sparmaßnahme, sondern eine Architekturentscheidung über die Kommunikation im Projekt.

Ein System dieser Art hätte klassisch vier Personen über etwa zwei Jahre beschäftigt — mit offenem Ausgang, weil ein Großteil dieser Zeit in Abstimmung zwischen den vier Personen geflossen wäre statt in das System. Die folgende Gegenüberstellung ist deshalb bewusst schief: Der obere Wert ist eine Schätzung, der untere ist gemessen.

Der Faktor entsteht nicht dadurch, dass eine Person achtmal so schnell tippt. Er entsteht aus drei Dingen: Es gibt keine Abstimmungsverluste zwischen Teilteams, es gibt genau einen Kopf, in dem das gesamte Systemverständnis liegt, und KI übernimmt genau die Arbeit, die vorher Personal gebunden hat — Umschreiben, Testschreiben, Nachziehen von Änderungen an vielen Stellen. Wir haben das Muster in Warum wir keine 5-Köpfe-Teams mehr finanzieren ausführlicher aufgeschrieben.

Die Grenze dieser Aufstellung ist ebenso klar: Sie funktioniert bei einem zusammenhängenden System mit einer verantwortlichen Person auf Kundenseite. Sie funktioniert nicht bei Vorhaben, die echte Parallelisierung über mehrere Produkte hinweg brauchen. Solche Projekte nehmen wir nicht an.

Der Teil, der uns am meisten bedeutet

Die Person, die den Prototyp gebaut hatte, blieb im Projekt. Das war keine Höflichkeitsgeste. Sie kannte die Fachlichkeit besser als jeder von uns — welche Zutat wie lange hält, wie eine Schicht wirklich abläuft, warum die Prognose montags danebenliegt. Dieses Wissen war das Wertvollste im ganzen Vorhaben.

Statt sie aufs Abstellgleis zu setzen, hat unsere entwickelnde Person ihr beigebracht, innerhalb des Systems zu arbeiten: Versionsverwaltung, Änderungen in nachvollziehbaren Schritten, Reviews, Datenbankmigrationen. Nicht Programmieren — das kann sie mit KI ohnehin. Sondern die Regeln, die dafür sorgen, dass ihre Änderungen unsere nicht mehr kaputt machen.

Fast jede zweite Änderung in der Prototypphase musste wieder zurück. Das ist kein Versagen einer Person, sondern die zwangsläufige Folge davon, dass niemand liest, was ausgerollt wird. Der Rückgang auf vier Prozent kommt nicht von besserer KI, sondern von zwei Regeln: Jede Änderung wird von einem Menschen gelesen, der dafür geradesteht, wenn sie im Schichtbetrieb läuft. Und jede Änderung muss durch die Tests, die es vorher nicht gab.

KI schreibt inzwischen sehr guten Code. Was sie nicht übernimmt, ist die Verantwortung dafür, was passiert, wenn dieser Code um 6:30 Uhr in einer echten Küche läuft. Diese Verantwortung ist kein Prozessschritt, sondern eine Person.

Diese Einarbeitung war die günstigste Investition im ganzen Projekt — geschätzt drei Wochen verteilte Zeit unserer entwickelnden Person. Sie hat dafür gesorgt, dass das Unternehmen nach unserem Ausstieg selbst weiterarbeiten kann, statt dauerhaft an uns zu hängen. Wie wir das absichern, steht in Warum KI-Projekte ohne Dokumentation scheitern.

Woran ihr erkennt, ob euer Prototyp tragfähig ist

Zwölf Fragen, die wir in der Bewertung stellen. Sie brauchen keinen Entwicklungshintergrund, um sie zu beantworten — nur die Bereitschaft, die Antwort „nein“ gelten zu lassen. Sechs oder mehr Neins bedeuten: Der Prototyp ist ein Prototyp, und das ist in Ordnung, solange niemand ihn verkauft.

• Lässt sich das System auf einem frischen Rechner in unter einer Stunde aufsetzen, ohne dass eine bestimmte Person hilft?
• Gibt es automatische Tests, und läuft irgendwo etwas, das sie bei jeder Änderung ausführt?
• Kann jemand das Datenbankschema ändern, ohne dass die vorhandenen Daten verloren gehen?
• Wurde in den letzten dreißig Änderungen auch nur eine von einer zweiten Person gelesen?
• Wisst ihr, was passiert, wenn zwei Nutzer gleichzeitig denselben Datensatz ändern?
• Gibt es eine Stelle, an der man sieht, dass gerade etwas nicht funktioniert — ohne dass ein Kunde anruft?
• Ist einmal gemessen worden, wie sich das System unter der zehnfachen Zielmenge verhält?
• Gibt es eine Sicherung, und wurde eine Wiederherstellung schon einmal geprobt?
• Ist klar, welche Daten personenbezogen sind und wie lange sie aufbewahrt werden?
• Kann eine zweite Person erklären, warum die Kernlogik so funktioniert, wie sie funktioniert?
• Gibt es Zugangsverwaltung und Rollen — oder haben alle alles?
• Existiert irgendwo aufgeschrieben, welche Entscheidungen bewusst so getroffen wurden?

Was das kostet und wann es sich nicht lohnt

Ein Prototyp in dieser Größenordnung produktionsreif zu machen, liegt bei einem Zweierteam über sechs Monate im niedrigen sechsstelligen Bereich. Das ist eine ernsthafte Summe, und sie ist nicht in jedem Fall gerechtfertigt. Drei Fälle, in denen wir davon abraten:

Situation	Unsere Empfehlung
Der Markt ist noch nicht bestätigt — es gibt Interesse, aber keinen zahlenden Kunden und keinen Vertrag in Aussicht	Beim Prototyp bleiben und weiter validieren. Produktionsreife kauft man, wenn es etwas zu verlieren gibt.
Es gibt ein Standardprodukt, das 80 Prozent abdeckt	Kaufen und die fehlenden 20 Prozent anbinden. Eigenentwicklung ist die teuerste Antwort auf ein gelöstes Problem.
Der Prototyp bedient dauerhaft eine Handvoll interner Nutzer	Nur das Nötigste absichern: Sicherung, Zugriffsschutz, ein Weg zur Schemaänderung. Der Rest ist Aufwand ohne Gegenwert.

In diesem Fall war die Rechnung eindeutig: Auf der anderen Seite lag ein Vertrag, dessen Wert die Investition um ein Vielfaches überstieg — und der ohne belastbares System nicht zustande gekommen wäre. Diese Klarheit ist selten. Wenn sie fehlt, ist das die wichtigere Erkenntnis.

Häufige Fragen

Hätte man den Prototyp nicht gleich richtig bauen lassen können?

Nur um den Preis, den Prototyp gar nicht zu bekommen. Er ist entstanden, weil jemand mit Fachwissen und ohne Entwicklungshintergrund in wenigen Wochen etwas Vorzeigbares bauen konnte. Ein Angebot für ein „richtiges“ System zu diesem Zeitpunkt hätte niemand freigegeben, weil noch nichts bewiesen war. Die Reihenfolge war richtig. Falsch wäre nur gewesen, den Prototyp für das Ziel zu halten.

Warum sechs Monate — KI schreibt Code doch in Sekunden?

Schreiben ist nicht der Engpass, und war es auch vorher nie. Der Engpass ist Verstehen, Entscheiden und Verantworten. Die Aufwandsverteilung oben zeigt es: 26 Prozent gingen in das Datenmodell, also in Entscheidungen darüber, was in diesem Geschäft eigentlich wahr ist. Diese Entscheidungen kann eine KI vorschlagen, aber nicht treffen — weil sie nicht weiß, welche davon in zwei Jahren teuer wird.

Kann man das interne Team nicht einfach mit KI weiterarbeiten lassen?

Nach der Einarbeitung ja, und genau das ist passiert. Vorher nein — nicht wegen fehlender Werkzeuge, sondern wegen fehlender Sicherungsmechanismen. Die 46 Prozent zurückgenommener Änderungen in der Prototypphase sind der Beleg. Was ein Terminal-Agent im Alltag übernehmen kann und wo die Grenze verläuft, beschreiben wir in Claude Code in der Praxis.

Was ist mit dem Vertrag geworden?

Das System ist produktiv und wird der Gruppe vorgeführt, während sie über die Ausrollung entscheidet. Wie das ausgeht, wissen wir nicht. Was wir wissen: Diese Vorführung findet auf einem laufenden System statt und nicht mehr auf einem Prototyp — und die Fragen, die dabei gestellt werden, lassen sich jetzt beantworten.

Fazit

Wir sehen diese Ausgangslage inzwischen regelmäßig, und sie wird häufiger: Jemand mit Fachwissen und ohne Entwicklungshintergrund baut mit KI in Wochen etwas, wofür früher ein Team und ein Budget nötig gewesen wären. Das ist eine gute Entwicklung. Sie verschiebt nur nicht den schwierigen Teil, sondern macht ihn sichtbarer.

Der schwierige Teil ist alles, was nicht in der Vorführung vorkommt: das Datenmodell, die Gleichzeitigkeit, der Weg von einer Schemaversion zur nächsten, das Verhalten bei Verbindungsverlust, die Frage, wer geradesteht. In diesem Projekt waren das 88 Prozent des Aufwands. Zwölf Prozent waren neue Funktionen.

Der Kunde, um den es hier geht, hatte vor Jahren schon einmal mit uns gearbeitet, war zwischenzeitlich weg und kam für diesen Teil zurück. Das ist die Zusammenfassung, die uns am meisten sagt: Ein Prototyp beweist die Idee. Ein System übersteht den Betrieb. Das Zweite ist die Arbeit, die wir machen.