Produktionsreife Software: die neun Fragen, die deinen Prototyp durch die zweite Woche tragen

Der Dienstag nach dem Start ist der ehrlichste Tag. Am Start selbst haben alle geguckt, das war laut und aufregend. Am Dienstag guckt keiner mehr. Es läuft, niemand hat sich beschwert, und trotzdem machst du morgens als Erstes die Seite auf und schaust, ob sie noch da ist.

Hör auf das Nachschauen. Es weiß etwas. Ein Teil von dir hat verstanden, dass „es läuft“ und „es trägt“ zwei verschiedene Dinge sind, und dass du bisher nur eines davon geprüft hast.

Das Ding ist schnell entstanden, ein großer Teil des Codes kam aus einem KI-Werkzeug. Genau daher kommt der Abstand zwischen „es läuft“ und „es trägt“, und der heißt produktionsreife Software. Er ist kleiner, als er aussieht. Die Liste, die dieses morgendliche Nachschauen überflüssig macht, ist neun Fragen lang. Nicht neunzig. Du kannst sie an einem Nachmittag durchgehen.

Was ist produktionsreife Software?

Produktionsreif ist Software, die auch dann noch funktioniert, wenn niemand danebensteht. Das ist der ganze Unterschied. Ein Prototyp braucht dich, damit er läuft. Ein produktionsreifes System läuft, während du schläfst.

Im Fachjargon heißt das Production Readiness, und der Begriff hat ein Imageproblem: Er klingt nach Rechenzentrum, nach Bereitschaftsdienst, nach einer Abteilung, die du nicht hast. Genau dieses Missverständnis kostet kleine Teams am meisten.

Ob sich dein Produkt richtig anfühlt und ob es nach dir klingt, ist eine eigene Frage, und die habe ich in „Vibe Coding testen“ beantwortet. Hier geht es um die andere Hälfte: ob das Ding auch dann noch steht, wenn du gerade nicht hinschaust.

Warum wird der Code immer besser und die Sicherheit nicht?

Die Modelle sind viel besser darin geworden, Code zu schreiben, der funktioniert. Kein Stück besser darin, Code zu schreiben, der hält. Das erledigt sich auch nicht mit dem nächsten Release. Es ist eingebaut.

Veracode misst das seit zwei Jahren: über 150 KI-Modelle, 80 Programmieraufgaben, immer derselbe Test. Das Ergebnis vom März 2026 sind zwei Zahlen, die du nebeneinanderlegen musst, damit sie wehtun. Die Syntax-Korrektheit liegt inzwischen bei über 95 Prozent. Der Code läuft also, fast immer. Die Sicherheits-Quote liegt bei ungefähr 55 Prozent. Und die ist seit zwei Jahren praktisch unverändert. Quelle: Veracode, 2026

Veracodes eigene Zusammenfassung ist der beste Satz zum Thema: Zwei Jahre revolutionäre Modell-Releases haben die Sicherheits-Nadel von ungefähr 55 Prozent auf ungefähr 55 Prozent bewegt.

Eine Einordnung gehört dazu: Veracode verkauft Security-Testing. Das Geschäftsmodell lebt davon, dass Code Lücken hat. Das musst du mitdenken. Aber 150 Modelle, standardisierte Aufgaben, eine Messreihe über zwei Jahre: an der Methodik kommst du nicht so leicht vorbei. Zwei Kurven laufen auseinander, und das siehst du nur, wenn du lange genug misst.

Konkret heißt das: 45 Prozent der KI-generierten Code-Samples bauen eine bekannte OWASP-Top-10-Lücke ein. Bei Java sind es mehr als sieben von zehn. Quelle: Veracode, 2025 Und jetzt kommt der Halbsatz, den fast alle weglassen, wenn sie diese Zahl zitieren: Das gilt, wenn keine Sicherheits-Vorgaben mitgegeben werden. Da fehlt eine Anweisung, mehr steckt nicht dahinter. Merk dir den Halbsatz.

Die zweite Zahl kommt von Faros: zwei Jahre Telemetrie, 22.000 Entwickler:innen, über 4.000 Teams. Faros hat dabei nicht früher gegen heute verglichen, sondern innerhalb derselben Organisation die Phasen mit wenig KI-Nutzung gegen die Phasen mit viel. Bei hoher Nutzung liegt das Verhältnis von Zwischenfällen zu Pull-Requests um 242,7 Prozent höher. Quelle: Faros AI, 2026 Pro Pull-Request, das ist der Punkt: Die Menge ist da schon rausgerechnet. Faros hat dafür einen Begriff, den ich ziemlich gut finde: Acceleration Whiplash. Es geht mehr raus, und was rausgeht, ist öfter kaputt.

Auch hier gehört die Einordnung dazu, und Faros liefert sie selbst mit: Das ist ein Verhältnis, keine Wahrscheinlichkeit. Ein einzelner Pull-Request kann mit mehreren Zwischenfällen zusammenhängen, und nicht jeder Zwischenfall geht auf die letzte Änderung zurück. Ein Zusammenhang, kein Beweis. Und Faros verkauft Engineering-Analytics, da gilt dieselbe Vorsicht wie bei Veracode.

Ist Production Readiness nicht etwas für große Firmen?

Nein, genau andersherum. Es ist der einzige Teil dieser Arbeit, der klein bleibt, wenn du klein bist.

Der DORA-Report 2025 hat eine Erkenntnis, die alles ordnet: KI ist ein Verstärker. Sie vergrößert die Stärken funktionierender Organisationen und die Dysfunktionen der strauchelnden. Quelle: DORA / Google Cloud, 2025 Ein Verstärker dreht auf, was schon da ist. Wer die neun Fragen beantwortet hat, wird durch KI-Lösungen schneller. Wer sie offen lässt, wird schneller kaputt. Dieselbe Technologie, entgegengesetzte Richtung.

Production Readiness galt jahrelang als Luxus für Große. Eigene Abteilung, Runbooks, dreihundert Punkte auf einer Liste. Kleine Teams haben daraus geschlossen, dass das Thema nicht zu ihnen gehört.

Das war ein Missverständnis. Die Liste ist bei den Großen lang, weil deren System groß ist. Zweihundert Services, vierzig Teams, niemand kennt mehr das Ganze. Die Liste ersetzt dort das Wissen, das keine einzelne Person mehr haben kann.

Du kennst dein ganzes System. Wenn eine Rechnung falsch rauskommt, weißt du, welche Datei du aufmachen musst, und du musst nicht suchen. Das ist die Ausgangslage, für die eine kurze Liste reicht. Neun Fragen, weil dein System neun Fragen groß ist.

Was gehört auf die Liste?

Drei Blöcke: Was passiert, wenn es kaputtgeht. Was passiert, wenn jemand es angreift. Was passiert, wenn du weg bist. Drei Fragen pro Block. Daher die neun.

Die beiden Zahlen von vorhin meinen dabei verschiedene Blöcke, das ist wichtig. Veracodes 45 Prozent meinen Block zwei, die Sicherheit. Faros meint Block eins und drei: Wenn öfter etwas kaputtgeht, brauchst du einen Weg, es zu merken und zurückzukommen. Die zweite Hälfte der Liste war schon immer richtig. Die KI-Werkzeuge haben nur dafür gesorgt, dass viel mehr Software existiert, die sie nie durchlaufen hat.

Eine Regel vorweg, sonst funktioniert die Liste nicht. Jede dieser Fragen wird mit Ja oder Nein beantwortet. Wenn du „eigentlich schon“ antwortest, ist die Antwort Nein.

Block 1: Was passiert, wenn es kaputtgeht?

1. Merkst du es, bevor deine Kundschaft es merkt? Der Normalzustand bei frisch gebauten Systemen: Du erfährst von Ausfällen durch eine Mail von jemandem, der sich ärgert. Ein Uptime-Check, der alle fünf Minuten anklopft und dir sonst schreibt, kostet nichts. Zehn Minuten Arbeit, und du bist nie wieder der Letzte, der es erfährt.

2. Kannst du zurück? Gibt es einen letzten Stand, von dem du sicher weißt, dass er lief, und kommst du in unter fünf Minuten dahin? Schon mal gemacht?

3. Sind die Daten von gestern noch da, und hast du sie schon mal zurückgespielt? Der zweite Halbsatz ist die eigentliche Frage.

Ein Backup, das du nie zurückgespielt hast, ist kein Backup. Das ist eine Hoffnung mit Dateiendung.

Das ist die Stelle, an der es unangenehm wird. Ein Backup einzurichten fühlt sich an wie Fertigsein. Das Zurückspielen ist die Arbeit, die danach niemand mehr macht.

Block 2: Was passiert, wenn jemand es angreift?

Hier kommt der Halbsatz von vorhin zurück: wenn keine Sicherheits-Vorgaben mitgegeben werden. Die 45 Prozent sind das Ergebnis davon, dass niemand danach gefragt hat.

4. Liegen Zugangsdaten im Code? API-Schlüssel, Passwörter, Tokens. Einmal aus Versehen öffentlich gepusht, und der Schlüssel ist draußen. Zurückholen geht nicht, nur austauschen. KI-Assistenten schreiben Zugangsdaten gerne direkt rein, weil es in den Beispielen, aus denen sie gelernt haben, auch so stand.

5. Wer darf was, und wird das auf dem Server geprüft? Der Klassiker: Der Button ist im Frontend versteckt, aber der Server fragt nicht nach. Wer die Adresse kennt, kommt rein. Ein Türschild abschrauben verriegelt die Tür nicht.

6. Was passiert bei Müll-Eingaben? Negative Zahlen, leere Felder, ein Roman im Namensfeld, ein Emoji in der Postleitzahl. Serverseitig geprüft, nicht nur im Browser.

Block zwei ist der, bei dem du am ehesten denkst, du kannst ihn nicht selbst beantworten. Kannst du doch. Du lässt dasselbe KI-System, das den Code geschrieben hat, gegen ihn antreten. Frag es nicht „ist das sicher?“, da bekommst du ein Ja. Sag:

Hier ist der Code. Finde die drei Wege, wie ich an Daten komme, die mir nicht gehören.

Die Rolle ändert alles. Angreifen kann es besser als verteidigen.

Block 3: Was passiert, wenn du weg bist?

7. Kann jemand anderes es starten? Wenn du zwei Wochen weg bist und es fällt aus: Kommt jemand rein? Gibt es eine Seite, auf der steht, wo es liegt und wie du es hochfährst?

8. Weißt du, was es kostet, wenn hundert Leute gleichzeitig kommen? Nicht ob es das aushält. Was es kostet. Der teure Moment ist selten der Ausfall. Der teure Moment ist die Rechnung.

9. Wo liegen die Daten, und wer ist Auftragsverarbeiter? DSGVO. Unangenehm, aber es ist die einzige Frage auf der Liste, bei der dir jemand Post schicken kann.

Ein paar Punkte auf dieser Liste lassen sich später in einer Stunde ändern, andere nie wieder ohne Neubau. Frage neun gehört zur zweiten Sorte. Warum genau diese Grenze verläuft, wo sie verläuft, habe ich in „Software-Design vs. Softwarearchitektur“ auseinandergenommen.

Was ist der teuerste Fehler, den dein System machen kann?

Diese Frage hat keine Nummer, weil sie allen neun ihr Gewicht gibt.

Eine kaputte Terminbuchung ist ärgerlich. Eine Rechnung mit der falschen Summe ist teuer. Kundendaten in der falschen Mail sind existenziell. Dieselben neun Fragen bekommen je nach Antwort eine völlig andere Dringlichkeit.

Die Zahlen, die du zu Ausfallkosten findest, stammen übrigens meistens aus Rechenzentren mit eigener Abteilung. Für dich sieht der Schaden anders aus. Er sieht aus wie ein Kunde, der nicht wiederkommt und dir auch nicht sagt, warum.

Wo du anfängst

Fang mit Frage drei an. Spiel dein Backup einmal zurück. Einmal.

Wenn es klappt, weißt du etwas über dein System, was du vorher nicht wusstest. Wenn es nicht klappt, hast du gerade den teuersten Fehler deines Jahres gefunden, während er noch nichts gekostet hat. Eine Frage, ein Nachmittag.

Die Liste durchgehen kannst du allein. Bei ein paar der Antworten wird das Reparieren dann eine eigene Aufgabe, vor allem bei Frage fünf und Frage neun. Da geht es um Dinge, die du nicht siehst, weil du nicht weißt, dass es sie gibt. Das soll dich nicht davon abhalten, die Liste durchzugehen. Es ändert nur, was du danach mit ihr machst.

Die zwei Kurven werden nicht wieder zusammenlaufen. Nach zwei Jahren Messung spricht wenig dafür, dass das nächste Modell die Sicherheitslücke schließt. Frage vier hat schon hingezeigt, woher das kommt: aus den Beispielen, aus denen die Modelle gelernt haben. Die werden durch ein größeres Modell nicht besser. Alles andere wird also schneller. Der Teil, der dir gehört, bleibt gleich groß.

Neun Fragen. Die werden nicht mehr, egal wie schnell der Rest wird.

Und irgendwann kommt ein Dienstag, an dem du nicht mehr nachschaust.