Forschungsbericht · überarbeitet am 09. November 2026
Reparaturfähigkeit und Feedbackwirkung sind zwei Fragen
Im Entwurfsprozess kann KI auf zwei Arten nützlich sein. Sie kann eine passende Änderung im Quelltext vorschlagen und sie kann aus Rückmeldungen der Werkzeuge zusätzliche Informationen gewinnen. Ein erfolgreicher Vorschlag mit beigefügter Fehlermeldung beweist zunächst nur die Reparaturfähigkeit. Um den Beitrag der Fehlermeldung zu bestimmen, braucht es denselben Versuch ohne diese zusätzliche Information.
Unser Vergleich verwendet vier eingefrorene synthetische RTL-Fehler. Die Module und Aufgabenfamilien sind im Projekt bereits bekannt. Es handelt sich um einen kontrollierten Reparaturschritt, nicht um eine autonome vollständige Chipentwicklung. Die zu prüfende Hypothese lautet, dass zusätzliche Icarus-Diagnosen bei gleichem Vorschlagsbudget häufiger zu korrekt abgenommenen Änderungen führen.
Ein Vorschlag unter einem festen Änderungsvertrag
Beide Bedingungen enthalten denselben fehlerhaften Quelltext und denselben Port- und Verhaltensvertrag. Die Feedback-Bedingung erhält zusätzlich den ersten Icarus-Fehler und höchstens sieben zusammenhängende Zeilen der Entwicklungssequenz. Pro Fall ist eine Textänderung erlaubt. Die zu ersetzende und die neue Zeichenfolge dürfen jeweils höchstens 256 UTF-8-Bytes umfassen. Der übrige Quelltext bleibt unverändert.
Vor der Modellanfrage wird geprüft, dass die unbeschädigte Referenz alle drei Testsequenzen besteht und der neue Fehler die Entwicklungssequenz verletzt. Eine vorgeschlagene Änderung wird nur angenommen, wenn sie korrekt angewendet werden kann und anschließend sämtliche Tests besteht. Die zwei reservierten Testsequenzen werden nicht als Vorschlagskontext bereitgestellt. Sie teilen allerdings Teile gerichteter Präfixe mit der Entwicklungssequenz.
Modelle und Bedingungen getrennt ausführen
Codex bearbeitete die beiden Bedingungen in getrennten Agentenkontexten. Zusätzlich wurden zwei Gemini-Varianten über Vertex ausgeführt. Innerhalb einer Modellversion bleiben Decoding-Einstellungen und Ausgabelimits gleich. Die Antworten einer Bedingung werden der anderen nicht gezeigt. Diese prozedurale Trennung vermeidet eine direkte Weitergabe der Lösung zwischen den Armen, ist aber keine unabhängige Zugriffskontrolle aller Modellwerkzeuge.
Der Vergleich zwischen Modellanbietern kann durch Unterschiede der Modelle und Aufrufsysteme beeinflusst sein. Die kausale Frage zum Feedback wird deshalb vor allem innerhalb derselben Modellversion betrachtet. Eine feste Reparaturregel läuft als zusätzliche Kontrolle mit. Die Bewertung erfasst Quellhashes, Antwortformat und funktionale Tests, statt einen plausibel aussehenden Änderungsvorschlag bereits als Erfolg zu verbuchen.
Die vollständigen Paare erreichen schon ohne Diagnose das Maximum
Im ersten vollständigen Durchlauf reparieren Codex, Gemini 4 Argon und Gemini 3.8 Flash jeweils alle vier Fälle mit und ohne Diagnose. Die feste Regel löst in diesem Vier-Fall-Versuch keinen Fall. Für die vollständigen Modellpaare ist damit kein Zusatznutzen des Feedbacks sichtbar. Die Aufgaben lassen sich bereits aus Quelltext und Vertrag vollständig lösen. Das Ergebnis belegt erfolgreiche Reparaturen, liefert aber keine Rangfolge zwischen diesen drei Modellen.
Die Wiederholungen zeigen zusätzlich Unterschiede im Ablauf. Ein Argon-Aufruf ohne Diagnose überschreitet das Zeitlimit und liefert keine Vorschläge. Zwei Flash-Antworten enthalten gültiges JSON, jedoch eine Liste statt der vorgeschriebenen Zuordnung. Nach der vorab festgelegten Hauptwertung werden diese Antworten nicht angenommen. Die getrennte nachträgliche Zuordnung über unveränderte Quellhashes ergibt zwar korrekte Reparaturen, ändert aber die Hauptwertung nicht.
Was der frühere Pilot ergänzt
Ein separater Pilot mit drei anderen Fehlern untersuchte Belegungsgrenzen, die Übernahme akzeptierter Nutzdaten und die Priorität gleichzeitiger Speicheranforderungen. Codex reparierte drei von drei Fällen, die feste Regel einen. Codex-Vorschläge benötigten zwölf Werkzeugaufrufe, die Regel acht. Fehlgeschlagene Änderungen wurden früh abgebrochen, weshalb weniger Aufrufe dort keinen höheren Wirkungsgrad bedeuten.
Die Werkzeugunterprozesse dauerten im Pilot 2,26 Sekunden für Codex-Vorschläge und 1,74 Sekunden für die Regel. Modellrechenzeit und Tokenzahl standen nicht vollständig zur Verfügung. Dieser Pilot hatte keinen Codex-Arm ohne Feedback. Er zeigt deshalb eine praktisch nutzbare Reparaturfähigkeit auf den drei Fällen, isoliert aber weder die Wirkung des Feedbacks noch eine Einsparung der gesamten Entwicklungszeit.
Ein anspruchsvollerer Abnahmetest muss anders aussehen
Vier ausgewählte kleine Fehler erzeugen schnell einen Deckeneffekt. Für einen aussagekräftigeren Feedbacktest werden zurückgehaltene Aufgaben benötigt, deren Ursache sich aus dem Quelltext allein schwer erkennen lässt. Dazu gehören zeitliche Wechselwirkungen, längere Transaktionsfolgen und Fälle, bei denen mehrere zunächst plausible Änderungen an einer unabhängigen Prüfung scheitern. Diese Erweiterungen sind Anforderungen an einen nächsten Versuch und keine bereits erreichten Ergebnisse.
Für eine Produktivitätsaussage müssten korrekt abgenommene Entwürfe, Modellzeit, Werkzeugzeit, Fehlversuche und menschliche Eingriffe gemeinsam erfasst werden. Funktionale Simulation ersetzt außerdem keine Synthese- oder Layoutqualifikation. Der vorliegende Nachweis rechtfertigt, LLM-Vorschläge als überprüfbare Reparaturschritte in die Software einzubinden. Einen nachgewiesenen Vorteil durch zusätzliche Diagnosen liefert diese konkrete Fehlermenge noch nicht.
Konsequenz für den nächsten Entwurf
Schwierigere zurückgehaltene Aufgaben und vollständige Modell-, Werkzeug- und Eingriffskosten wären der nächste KI-Nachweis.