Softwarequalität sichern, wenn KI den Code schreibt:Welcher Nachweis schützt welche Regel?

Ein Fall, der in der Softwareentwicklung regelmäßig vorkommt: Hunderte Testdateien, und nur eine Handvoll Prüfungen, die das Produkt so benutzen, wie ein Mensch es benutzt. Ein Teil der Tests prüft, ob ein Schildchen die richtige Farbe hat. Auffällig wird das bei einem Umbau, bei dem sich für niemanden etwas ändert und trotzdem Dutzende Tests rot werden. Umgekehrt gibt es Dinge, die wirklich kaputt sind, und alles bleibt grün.

Was sagt so ein grüner Haken also aus? Drei Begriffe helfen beim Einordnen.

Ein Unit-Test prüft ein einzelnes kleines Bauteil für sich. Wie die Prüfung, ob ein Ziegel den Druck aushält.

Die Testabdeckung, englisch Code Coverage, sagt, wie viel vom Code beim Testen durchlaufen wurde. Ob jemand hingeschaut hat, was dabei herauskam, sagt sie nicht. 87 Prozent heißt: 87 Prozent der Zeilen wurden einmal angefasst.

Und dann gibt es die Attrappe, Fachwort Mock. Damit ein Test schnell läuft, ersetzt man die Datenbank, den Bezahldienst oder das Mailprogramm durch eine Attrappe, die immer brav antwortet.

Stell dir vor, du probst dein Kreditgespräch mit deinem Schwager, der die Bank spielt. Er sagt ja, und du gehst beruhigt nach Hause. Die echte Bank hat andere Formulare. Genau so arbeitet ein Test gegen eine Attrappe. Er beweist, dass dein Code mit deiner Vorstellung von der Datenbank klarkommt. Ob die Vorstellung stimmt, zeigt erst die echte Datenbank. Ich nenne das Mock-Theater: Test und Code teilen dieselbe falsche Annahme. Und beide spielen ihre Rolle perfekt. Deshalb muss zuerst abgesichert sein, dass die Attrappe dieselbe Schnittstelle hat wie das echte System: dieselben Fragen versteht und in derselben Form antwortet. Das ist die Aufgabe deines Dienstleisters, nicht deine. Es hilft aber zu verstehen, was Qualität hier überhaupt bedeutet.

Jeder Ziegel geprüft. Das Haus nie betreten.

Ein Forschungsteam um Asma Hamidi hat diesen Ablauf nachgestellt. Fünf Sprachmodelle schrieben Code und die Tests dazu, über 6.000 fehlerhafte Programme kamen zusammen. Das Ergebnis in ihren Worten: Die tatsächliche Fehlererkennung bleibt extrem niedrig, oft nahe null (Quelle: Hamidi et al., 2026). Die Tests laufen durch die kaputte Stelle, aber sie fragen dort nicht das Richtige ab. Fairerweise: Es ist eine Vorabveröffentlichung, und einfache Fehler werden laut derselben Arbeit gut gefunden. Das Problem sind die schwierigen.

Eine zweite Arbeit von der Universität Toronto hat über 100.000 KI-geschriebene Testfälle von elf Modellen ausgewertet. Sobald man nicht sicher weiß, ob der getestete Code selbst stimmt, ist die Testabdeckung kein verlässliches Zeichen mehr dafür, ob Fehler gefunden werden (Quelle: Zhao, Zhou und Cohen, 2026). Auch das gehört dazu: Gilt der Code als korrekt und sollen die Tests nur künftige Änderungen absichern, taugt die Abdeckung durchaus als Signal. Coverage ist ein Diagnosewert. Ein Qualitätsurteil ist sie nicht.

Marens Bericht war wahr. Er hat nur eine Frage beantwortet, die sie nie gestellt hatte.

Der andere Maßstab ist erstaunlich unspektakulär. Er passt auf ein Blatt.

Du kennst dein Geschäft. Du weißt, was nie passieren darf. Das reicht als Anfang.

Deine Regeln findest du mit drei Fragen. Was wäre dir vor einer Kundin peinlich? Was kostet sofort Geld, wenn es schiefgeht? Was darf nie bei der falschen Person landen?

Bei Maren sind es diese fünf Sätze:

1. Eine Abrechnung geht nie an den falschen Haushalt.
2. Eine Rechnung geht nie doppelt raus.
3. Was gespeichert ist, ist nach einem Neustart noch da.
4. Gesperrt schlägt freigegeben. Ist ein Konto gesperrt, geht nichts raus, egal welche anderen Rechte gesetzt sind.
5. Ohne zweite Freigabe keine Auszahlung über 500 Euro.

Kein Fachwort drin. Jede Person im Büro kann sagen, ob der Satz stimmt.

Aus jedem Satz wird eine Kette: Regel, Nachweis, die Ebene, auf der er sitzt, und der Ablauf, in dem die Regel im Alltag vorkommt. Die alte Frage lautete: Wie viele Tests gibt es, und wie hoch ist die Abdeckung? Die neue ist die Nachweisfrage: Welcher Nachweis schützt diese Regel? Auf die erste Frage gibt es immer eine beeindruckende Zahl. Auf die zweite gibt es entweder eine Antwort oder ein ehrliches Schweigen.

Fachleute kennen die Idee als risikobasiertes Testen. Neu ist, wer sie stellen kann: Solange Tests teuer waren, war ihre Zahl ein brauchbares Zeichen für Sorgfalt, und die Frage blieb in der Entwicklung. Seit Tests fast nichts kosten, gehört sie zu der Person, die die Regeln kennt. Zu dir.

Warum der Regel-Teil beim Menschen bleibt, hat Martin Kleppmann von der Universität Cambridge auf den Punkt gebracht. Wenn das Prüfen selbst automatisch wird, wandert die Schwierigkeit dahin, die Anforderung richtig aufzuschreiben: Woher weißt du, dass das, was bewiesen wurde, auch das ist, was dir wichtig war (Quelle: Kleppmann, 2025)? Das nimmt dir keine Maschine ab. Und das ist eine gute Nachricht, denn dein Wissen über dein Geschäft wird wertvoller, wenn Code billiger wird.

Meiner Meinung nach sind die Regeln wichtiger als die Funktion, in der sie gerade programmiert sind. Code wird umgebaut. Die Regel bleibt.

Ein Test ist eine Stichprobe. Du probierst zehn Fälle und hoffst, dass der elfte auch passt. Ein Beweis ist eine Rechnung, die für alle Fälle auf einmal gilt. So wie du nicht jede Zahl ausprobieren musst, um zu wissen, dass gerade plus gerade wieder gerade ergibt. Das Fachwort dafür heißt formale Verifikation.

Warum war das bisher nichts für den Mittelstand? Das berühmteste Beispiel, ein bewiesener Betriebssystem-Kern, hatte 8.700 Zeilen Code. Der Beweis brauchte 20 Personenjahre (Quelle: Kleppmann, 2025). Das war 2009.

Jetzt ändert sich etwas. Martin Kleppmann hat im Dezember 2025 vorhergesagt, dass KI dieses Verfahren aus der Nische in den Alltag der Softwareentwicklung holt (Quelle: Kleppmann, 2025). Nun sind Vorhersagen schwierig, besonders wenn sie die Zukunft betreffen (frei nach einem dänischen Sprichwort, das oft Niels Bohr zugeschrieben wird; Quelle: Quote Investigator, 2013). Amazon setzt solche Beweise nach eigener Aussage schon in mehreren Produkten ein und schreibt: Wenn KI-Agenten Geld bewegen und Anträge freigeben, reicht der übliche Ansatz des Testens nicht mehr aus (Quelle: Amazon Science, 2026). Das sagt ein Unternehmen, das selbst in diese Technik investiert.

Der Dämpfer kommt aus einem Vergleichstest von der Konferenz ICML 2026. Lässt man aktuelle Modelle bewiesenen Code für klassische Rechenverfahren schreiben, gelingt das je nach Beweissprache in 40,3, in 24,7 oder in nur 7,8 Prozent der Fälle (Quelle: Zhao et al., ICML 2026). Ein älterer Vergleich vom September 2025 kam mit anderen Aufgaben auf 82, 44 und 27 Prozent (Quelle: Beneficial AI Foundation und MIT, 2025). Ich lese das so: Es geht, die Quote hängt stark an Aufgabe und Beweissprache, und es ist weit weg von „auf Knopfdruck für das ganze Produkt“.

Wo die Grenze liegt, zeigt ein Fall vom April 2026. Kiran Gopinathan hat ein Programm zum Packen von Dateien genommen, das als korrekt bewiesen war, und es mit rund 105 Millionen zufälligen Eingaben beschossen. Im bewiesenen Teil: null Speicherfehler (Quelle: Gopinathan, 2026). Trotzdem fand er zwei Fehler, und beide lagen außerhalb dessen, was der Beweis abdeckt (Quelle: Gopinathan, 2026). Einer saß in einem Teil, für den niemand eine Regel aufgeschrieben hatte. Der andere im Unterbau, dem der Beweis blind vertraut. Sein Fazit, sinngemäß: Ein Beweis ist nur so stark wie die Fragen, die du zu stellen gedacht hast, und das Fundament, dem du vertraust.

Daraus folgt ein Muster, das Fachleute wiedererkennen werden. Die Regel einmal klein und exakt aufschreiben und beweisen. Dann den echten Code mit sehr vielen Zufalls-Eingaben gegen diese kleine Fassung laufen lassen und schauen, ob beide immer dasselbe sagen. Bei einem Projekt von Amazon ist das bewiesene Modell etwa zehnmal kleiner als der Produktionscode (Quelle: Lean FRO, ohne Datum). In einer älteren Auswertung von 2024 fanden die Beweise dort 4 Fehler, der Abgleich zwischen Modell und Code 21 weitere (Quelle: Disselkoen et al., 2024).

Donald Knuth hat diese Grenze schon 1977 in einen Satz gepackt, am Ende einer Notiz zu einem Algorithmus: „Beware of bugs in the above code; I have only proved it correct, not tried it.“ Also: Vorsicht vor Fehlern im Code oben, ich habe ihn nur als korrekt bewiesen, nicht ausprobiert (Quelle: Knuth, 1977). Bewiesen ist die Regel. Ob der Code ihr folgt, prüfst du zusätzlich.

Welche Regel taugt dafür? Sie ist eindeutig, gleiche Eingabe, gleiches Ergebnis. Sie ändert sich selten. Ein Fehler wäre teuer. Sie passt auf eine Seite und kommt ohne Oberfläche und ohne Netzwerk aus. Bei Maren sind das „Gesperrt schlägt freigegeben“ und „Ohne zweite Freigabe keine Auszahlung über 500 Euro“. Der Rest bleibt bei Journey und Grenztest.

Aufräumen fängt man an einer Ecke an. Hier ist deine: 60 Minuten, ein Blatt, fünf Sätze. Damit gehst du zu dem Menschen oder dem Agenten, der deine Software baut, und stellst zu jedem Satz die Nachweisfrage. Und gleich eine zweite hinterher: Zeig mir, dass er rot wird, wenn die Regel bricht.

Vier Antworten kannst du hören.

• „Dafür gibt es einen Ablauf-Test gegen das echte System.“ Gut.
• „Das ist in den Unit-Tests.“ Nachfragen: gegen die echte Datenbank oder gegen eine Attrappe?
• „Das testen wir manuell vor dem Release.“ Ehrlich, aber kein Nachweis, der von allein rot wird.
• Schweigen. Auch eine Antwort. Jetzt weißt du, wo du anfängst.

Ein Blick nach vorn, ohne Rechtsrat. Für Produkte mit digitalen Elementen gelten seit dem 11. September 2026 Meldepflichten aus dem europäischen Cyber Resilience Act, die Hauptpflichten ab dem 11. Dezember 2027. Die Verordnung verlangt eine technische Dokumentation der Mittel, mit denen der Hersteller die Anforderungen sicherstellt (Quelle: Verordnung (EU) 2024/2847). Und die neue EU-Produkthaftungsrichtlinie zählt Software ausdrücklich als Produkt, für Produkte, die ab Dezember 2026 auf den Markt kommen (Quelle: Richtlinie (EU) 2024/2853). Ob dein Projekt darunter fällt, klärt eine rechtliche Beratung, nicht ich. Die Richtung ist aber klar: Die Frage, womit du nachweist, dass deine Software tut, was sie soll, wird öfter gestellt werden. Wer sie mit fünf Sätzen und fünf Nachweisen beantworten kann, hat einen soliden Anfang.

Die Regeln aufschreiben ist Menschenarbeit. Das Nachweisen ist Maschinenarbeit. Wenn das sauber getrennt ist, musst du nicht mehr jeden Abend selbst durch das Programm klicken, um ruhig zu schlafen. Dein Kopf wird frei für das, was nur du kannst: das Gespräch mit der Kundin, die Entscheidung, was als Nächstes gebaut wird.

Jede wichtige Regel verdient einen Nachweis, genau dort, wo ein Fehler wehtun würde. Mit kleinen Teams baue ich diese Brücke: von fünf Sätzen im Büro zu Nachweisen im Produkt, die rot werden, sobald eine Regel bricht. Kam auf deine Nachweisfrage Schweigen, fängt dort meine Arbeit an.

Nimm dir heute ein Blatt und schreib den ersten Satz auf. Den, bei dem dir gerade etwas mulmig geworden ist.

Alle in diesem Artikel verwendeten Namen von Personen und Unternehmen sind frei erfunden. Ähnlichkeiten mit real existierenden Personen oder Unternehmen sind rein zufällig und nicht beabsichtigt. Die Beispiele dienen ausschließlich der Veranschaulichung.