← Neueste Arbeiten
💻 computer science

Specification-first convergence with an AI coding agent: a case study of dismantling a core architectural invariant across 189 files in a 717k-line codebase with no test oracle and no human code review

Diese Arbeit präsentiert eine Fallstudie, die zeigt, dass ein KI-Coding-Agent, der unter einem Specification-First-Protokoll ohne menschliche Code-Review oder eine vorbestehende Test-Oracle operierte, erfolgreich eine zentrale architektonische Invariante über 189 Dateien in einer 717.000 Zeilen umfassenden TypeScript-Codebasis durch die iterative Verfeinerung einer formalen Spezifikation und die Korrektur von 201 Defekten über drei Tage für 2.430 $ demontierte.

Ursprüngliche Autoren: Joël Abenhaïm

Veröffentlicht 2026-08-25
📖 8 Min. Lesezeit🧠 Tiefgang

Ursprüngliche Autoren: Joël Abenhaïm

Originalarbeit lizenziert unter CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

In der Welt der Software sind Programme wie riesige, komplexe Städte aufgebaut. Sie bestehen aus Millionen von Zeilen von Anweisungen, die einem Computer sagen, wie er sich verhalten, wie er sich Dinge merken und wie er reagieren soll, wenn ein Benutzer auf eine Schaltfläche klickt. Jahrzehntelang war der Standardweg, diese Städte zu verändern, darin bestand, einen menschlichen Architekten zu entsenden, um jeden neue Stein zu inspizieren, den eine künstliche Intelligenz legen könnte. Diese menschliche Überprüfung gilt als essenziell, da die Verbindungen zwischen den verschiedenen Teilen eines Programms so tief und verschlungen sind, dass ein kleiner Fehler in einer Ecke einen Zusammenbruch in einer anderen verursachen kann. Wenn eine Änderung groß genug ist, um hunderte von Dateien gleichzeitig zu berühren, wird die Aufgabe, die Arbeit zu prüfen, zu einem Flaschenhals; kein einzelner Mensch kann die gesamte Karte der Änderungen gleichzeitig im Kopf behalten. Diese Einschränkung hat viele zu der Annahme geführt, dass für die komplexesten architektonischen Verschiebungen der einzige sichere Weg darin besteht, die alte Struktur abzureißen und eine neue von Grund auf neu aufzubauen – ein Prozess, der langsam, teuer und riskant ist.

Eine aktuelle Fallstudie stellt die Vorstellung infrage, dass die menschliche Überprüfung der einzige Weg ist, um Sicherheit bei solch massiven Änderungen zu gewährleisten. Sie untersucht eine Methode, bei der sich der Fokus von der Überprüfung des fertigen Produkts hin zur Perfektionierung des Bauplans verschiebt, noch bevor ein einzener Stein gelegt wird. Anstatt die künstliche Intelligenz zu bitten, Code zu schreiben und dann zu hoffen, dass ein Mensch die Fehler findet, bittet dieser Ansatz die Maschine, zuerst eine detaillierte, formale Beschreibung dessen zu verfassen, was sie genau beabsichtigt zu tun. Diese Beschreibung wird dann rigoros gegen den bestehenden Code geprüft – nicht um zu sehen, ob der Code funktioniert, sondern um zu prüfen, ob der Plan selbst Sinn ergibt. Der Plan wird verfeinert, korrigiert und eingefroren, bis er keine Befunde mehr liefert. Erst dann beginnt die Maschine zu bauen, und selbst dann wird sie ständig gegen diesen eingefrorenen Plan auditiert. Das Ergebnis ist ein Nachweis dafür, dass eine massive, komplexe architektonische Änderung abgeschlossen werden kann, ohne dass jemals ein Mensch den generierten Code gelesen hat, vorausgesetzt, der Prozess der Definition und Verifizierung der Absicht ist robust genug.

Das Experiment fand innerhalb einer großen, proprietären Softwareanwendung statt, die für die Unterstützung beim Programmieren durch künstliche Intelligenz verwendet wird. Das System, geschrieben in einer Sprache namens TypeScript, enthielt über 717.000 Zeilen Code, verteilt auf fast 3.650 Dateien. Es war eine lebendige, atmende Software, die täglich genutzt wurde, kein theoretisches Modell. Die dem KI-Agenten zugewiesene Aufgabe war es, eine Kernregel zu demanteln, die das System seit seiner Entstehung regiert hatte. Diese Regel, bekannt als Invariante, garantierte, dass das Fenster, das eine Konversation anzeigt, für die gesamte Dauer der Anfrage offen bleibt, wann immer ein Benutzer ein Gespräch beginnt. Wenn der Benutzer das Fenster schließt, stirbt die Konversation. Das Ziel war es, diese Regel zu brechen: Der Benutzer sollte das Fenster schließen können, und die Konversation sollte im Hintergrund weiterlaufen, bereit, genau dort wiederaufgenommen und fortgesetzt zu werden, wo sie aufgehört hat, ohne Daten zu verlieren oder Wörter zu wiederholen.

Diese spezifische Änderung galt als nahezu unmöglich durch Standard-Refactoring zu erreichen. Nach Einschätzung des Autors war die Interdependenz des Codes so eng, dass die Modifizierung der Lebensdauer einer Konversation, ohne das gesamte System zu beschädigen, normalerweise eine komplette Neuschreibung der betroffenen Komponenten erfordert hätte. Die Aufgabe beinhaltete das Management komplexer Timing-Probleme, wie etwa was passiert, wenn ein Fenster geschlossen wird, während noch Daten gestreamt werden, und wie man einen Benutzer wieder an einen Live-Stream anbindet, der ohne ihn gelaufen ist. Um dies zu lösen, wandte der Autor ein fünfphasiges Protokoll an, das die künstliche Intelligenz auf einem strengen Pfad hielt. Der Prozess begann damit, dass der Agent die Anfrage analysierte und eine formale Spezifikation erstellte – ein detailliertes Dokument, das genau beschreibt, wie die Änderung funktionieren soll.

Der kritischste Teil des Prozesses war die Verfeinerungsphase. Der Agent wurde angewiesen, seine eigene Spezifikation zu nehmen und sie gegen den echten Quellcode zu prüfen, um nach Widersprüchen oder fehlenden Details zu suchen. Dies war keine einmalige Prüfung. Der Agent durchlief vierzehn Zyklen dieses Audits. In jedem Zyklus fand er Fehler in seinem eigenen Plan – vielleicht eine Datei, die er vergessen hatte zu aktualisieren, oder eine Abhängigkeit, die er missverstanden hatte – und schrieb die Spezifikation um, um den Fehler zu beheben. Über diese vierzehn Runden hinweg wurde der Plan etwa fünfundachtzig Mal korrigiert, wobei sich der Umfang der Änderung von 110 Dateien auf 160 Dateien erweiterte, als verborgene Verbindungen entdeckt wurden. Am Ende des vierzehnten Zyklus wurde die Spezifikation eingefroren. Es war ein fester Bauplan, der gegen die Realität der Codebasis auditiert worden war, bis der letzte Zyklus keine Befunde mehr lieferte, woraufhin er als Referenz für alle nachfolgenden Phasen festgeschrieben wurde.

Mit dem festgeschriebenen Plan ging der Agent zur Implementierungsphase über. Er wurde angewiesen, die Code-Änderungen zu generieren, die der eingefrorenen Spezifikation entsprechen. Der Agent weigerte sich, Teiländerungen vorzunehmen, da er korrekt identifizierte, dass eine halbfertige Migration das System unterbrechen würde. Stattdessen führte er die Arbeit in drei distinkten, bestätigten Schritten aus. Nachdem der Code geschrieben worden war, begann die Verifizierungsphase. Genau wie der Plan gegen den Code geprüft worden war, wurde nun der neue Code gegen den eingefrorenen Plan geprüft. Der Agent durchlief siebzehn Ziele dieses Audits, indem er den tatsächlichen Code auf dem Bildschirm mit den schriftlichen Regeln in der Spezifikation verglich. In jedem Zyklus fand und korrigierte er Abweichungen und behob subtile architektonische Fehler, die ein Mensch vielleicht übersehen hätte. Über diese siebzehn Runden hinweg korrigierte der Agent 116 Defekte im Code selbst. Der Prozess stoppte erst, als zwei aufeinanderfolgende Audits null Fehler zurückgaben, was bestätigte, dass der Code innerhalb des definierten Konvergenzkriteriums mit dem Plan übereinstimmte.

Die gesamte Operation berührte 189 Dateien, wobei insgesamt 288 Dateien geändert wurden, wenn man die Extraktion des alten Codes mit einrechnet. Die Änderungen umfassten über 34.000 neue Zeilen Code und die Löschung von mehr als 16.000 Zeilen. Bemerkenswerterweise wurde diese massive Umstrukturierung in drei Tagen abgeschlossen. Die Kosten für die KI-Verarbeitung, die für diese Aufgabe erforderlich waren, beliefen sich auf 2.430 US-Dollar. Während des gesamten Dreitageszeitraums wurde das Programm kein einziges Mal von einem Menschen ausgeführt. Die erste Ausführung der Software erfolgte erst nach dem siebzehnten Verifizierungszyklus, als der Autor schließlich das neue Verhalten testete.

Das Ergebnis war ein Erfolg. Als das Programm gestartet wurde, funktionierte das neue Verhalten exakt so, wie es die Spezifikation beschrieben hatte. Ein Benutzer konnte eine Konversation starten, das Fenster schließen und die Konversation lief im Hintergrund weiter. Wenn der Benutzer das Fenster wieder öffnete, setzte sich die Konversation sofort fort, ohne Datenverlust und ohne Duplikation von Text. Ein neuer Stopp-Button erschien in der Seitenleiste, der es ermöglichte, den Hintergrundprozess bei Bedarf zu beenden. Die bestehenden automatisierten Tests, die seit Jahren auf der Software liefen, zeigten keine Fehler an, was darauf hindeutete, dass das neue System keine der alten Funktionalitäten brach. Die Software wurde als Version 2.3.0 veröffentlicht, und in den etwa dreißig Sitzungen, die auf die Veröffentlichung folgten, wurden keine Bugs beobachtet.

Diese Fallstudie behauptet nicht, dass künstliche Intelligenz nun in der Lage ist, menschliche Ingenieure in allen Szenarien zu ersetzen, noch legt sie nahe, dass diese Methode für jede Art von Problem funktioniert. Der Autor weist vorsichtig darauf hin, dass dies ein einzelner, spezifischer Fall in einer einzigen Codebasis war und die Ergebnisse nicht automatisch auf andere Systeme oder Aufgaben übertragen werden können. Die Studie schließt explizit die Idee aus, dass ein bereits existierender Satz von Tests dieses Problem hätte lösen können, da das gewünschte Verhalten vor der Änderung noch nicht existierte. Es gab keine „korrekte“ Antwort, gegen die man im alten Code hätte prüfen können; die Korrektheit musste von Grund auf neu definiert werden. Die Studie räumt zudem ein, dass der Prozess auf einem spezifischen, leistungsstarken KI-Modell basierte und die Ergebnisse sich bei schwächeren Modellen unterscheiden könnten.

Die Bedeutung der Arbeit liegt in der Demonstration eines neuen Weges zum Management von Komplexität. Indem die Forscher die Last der Qualitätskontrolle von der Inspektion des Endprodukts hin zur rigorosen Definition und Verifizierung des Plans verlagerten, zeigten sie, dass eine Maschine durch ein Minenfeld aus interdependentem Code navigieren kann, ohne menschliche Intervention. Der Schlüssel war nicht, dass die Maschine unfehlbar war, sondern dass der Prozess es ihr ermöglichte, ihre eigenen Fehler wiederholt abzufangen, bevor sie permanent wurden. Die Spezifikation wurde vierzehn Mal herausgefordert, und der Code wurde siebzehn Mal geprüft, was eine Schleife der Selbstkorrektur erzeugte, die das System basierend auf einer empirischen Stoppregel in Richtung einer Übereinstimmung zwischen Absicht und Realität trieb. Die Protokolle dieses gesamten Prozesses, die über 1.500 Seiten umfassen, wurden zur Einsicht veröffentlicht und bieten einen transparenten Blick darauf, wie eine Maschine eine zentrale architektonische Regel demanteln und neu aufbauen kann, Stein für Stein, ohne jemals einen Menschen benötigen zu müssen, der über ihre Schulter blickt.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →