Buns KI-gestützte Rust-Neuschreibung: Ein Validierungshandbuch zur Migration von einer Million Zeilen Code

Ein von Buns KI-gestütztem Wechsel von Zig zu Rust inspiriertes Validierungshandbuch, das Verhaltensverträge, isolierte Codierungs-Agenten, Differenztests, Fuzzing, Unsafe-Code-Reviews, Fortschrittsmetriken und sichere Veröffentlichungen abdeckt.

发布于 2026年7月12日•general•GEO 评分: 0•3 次阅读

选择语言

العربية Deutsch English Español Français Italiano 日本語 한국어 Português Русский 中文

Buns KI-gestützte Rust-Neufassung: Ein Verifikationshandbuch für Migrationen mit Millionen Zeilen

Einleitung

Die Schlagzeile ist kaum zu übersehen: Bun soll eine große Implementierung in nur 11 Tagen von Zig nach Rust migriert haben, und zwar mithilfe eines dynamischen Claude-Code-Workflows. Die veröffentlichten Berichte beschreiben Tausende von Commits, bis zu 64 Claude-Agenten, rund 780.000 Zeilen Rust, zwei gegnerische Prüfer für jede Implementierungseinheit und eine Entwicklung von Code, der nicht kompilierte, bis hin zu einem Port, der die Testsuite bestehen und ausgeliefert werden konnte.

Die falsche Lehre daraus ist, dass Sprachneufassungen zu Ein-Klick-Aufgaben geworden sind. Die nützliche Lehre ist, dass Implementierungsdurchsatz und Verifikationsdurchsatz nun getrennte ingenieurtechnische Probleme darstellen.

KI-Agenten können Code schneller generieren, als ein menschliches Team ihn lesen kann. Sobald dies geschieht, kann die konventionelle Pull-Request-Überprüfung nicht mehr als primäre Sicherheitsmaßnahme dienen. Teams benötigen ein System, das eine massive probabilistische Änderung in kleine Behauptungen umwandelt, die durch maschinell überprüfbare Belege gestützt werden.

Buns späterer Produktionsbericht machte dies ungewöhnlich konkret. Das Team berichtete von 19 bekannten Regressionen, die alle anschließend behoben wurden; 11 Runden Sicherheitsüberprüfung; kontinuierliches coveragegesteuertes Fuzzing über Parser hinweg; und etwa 27.000 Rust-Zeilen innerhalb von unsafe-Blöcken von insgesamt rund 780.000 Zeilen. Diese Fakten schmälern die Migrationsgeschichte nicht. Sie zeigen, wie ernsthafte Migrationsarbeit aussieht, nachdem die beeindruckende Demo vorbei ist.

Dieser Leitfaden verwandelt diese Erfahrung in ein wiederverwendbares Verifikationshandbuch. Das Ziel ist nicht, Buns Größenordnung zu kopieren. Es geht darum, eine Methode für jede Migration bereitzustellen – Sprachports, Framework-Ablösungen, API-Modernisierung, Datenbankkonvertierungen oder repositorienweite Refactorings – bei der KI-Codierungsagenten mehr Code schreiben können, als das Team verantwortungsbewusst Zeile für Zeile prüfen kann.

Wichtige Erkenntnisse

Buns Neufassung zeigt, dass KI-Agenten die Implementierungszeit komprimieren können. Sie zeigt nicht, dass die Verifikationszeit entfallen kann.
Der übertragbare Wert liegt im Migrationssystem: schriftliche Verhaltensverträge, Risikokarten, kleine Pilotprojekte, isolierte Arbeitskräfte, unabhängige Prüfer, deterministische Tore und wiederherstellbare Commits.
Compiler und alte Testsuites fangen unterschiedliche Fehlerklassen ab. Keine fängt jede sprachübergreifende semantische Diskrepanz, jede Release-Modus-Abweichung, jede Leistungsregression oder jede unsichere Grenze ab.
Große Diffs erfordern evidenzorientierte Überprüfung. Menschen sollten Verträge, Risikohotspots, Gegenbeispiele, Testlücken und Einführungsentscheidungen prüfen, anstatt so zu tun, als würde jede generierte Zeile gleichermaßen untersucht.
Teams können dasselbe Muster übernehmen, ohne eine Millionen-Zeilen-Neufassung zu versuchen: Verlangen Sie von den Agenten, dass sie das Verhalten jeweils häppchenweise nachweisen, und gewähren Sie dann erst nach gemessenen Ergebnissen breitere Autonomie.

Was Bun tatsächlich tat – und was die Schlagzeile auslässt

Der ingenieurtechnische Bericht begann vor der großangelegten Codegenerierung.

Jarred Sumner soll etwa drei Stunden damit verbracht haben, PORTING.md zu erstellen, das wiederkehrende Zig-Muster auf Rust abbildete. Ein separater Workflow analysierte Strukturfelder, schlug Rust-Lebensdauern vor, sandte diese Entscheidungen an zwei gegnerische Prüfer und serialisierte die Ergebnisse in LIFETIMES.tsv. Diese Artefakte wurden ebenfalls manuell überprüft.

Die Implementierungserprobung umfasste drei Dateien, nicht das gesamte Repository. Für jede Datei:

Ein Agent implementierte die Rust-Version.
Zwei neue Agenten überprüften die Verhaltensgleichheit und die Einhaltung der Migrationsdokumentation.
Ein weiterer Agent wandte die genehmigten Korrekturen an.

Erst nach diesem Pilotversuch wurde die Arbeit auf 1.448 Zig-Dateien ausgeweitet.

Der erste groß angelegte Durchlauf schlug fehl. Agents teilten sich einen Arbeitsbereich und verwendeten Befehle wie git stash, git stash pop und git reset --hard. Ihre Änderungen störten sich gegenseitig. Daraufhin wurde der Workflow geändert, um unsichere Koordinationsbefehle zu verbieten und vier Arbeitsbäume zu verwenden, jeder mit 16 Agents.

Dieses Detail ist wichtiger als die Spitzenzeilen-Erzeugungsrate. Paralleles Programmieren ist ein Problem von verteilten Systemen. Gemeinsamer Zustand, konkurrierende Schreiber, teure globale Operationen, Eigentümerschaft und Wiederherstellung benötigen alle explizite Regeln.

Der generierte Code funktionierte nicht sofort. Bun verwendete Compiler-Fehler als Warteschlange und rückte jeweils eine Crate vor. Irgendwann wurden etwa 16.000 Compiler-Fehler an Agents zugewiesen. Die Schleife verwendete einen Korrekturleser, zwei Prüfer und einen Anwendungs-Agenten, während gleichzeitig begrenzt wurde, wie oft teure Befehle wie cargo check und Git-Operationen ausgeführt werden konnten.

Dies war keine magische Übersetzung. Es war eine stufenweise Konvergenz, angetrieben von deterministischem Feedback.

Die Ankündigung von Anthropic zum dynamischen Workflow berichtete, dass zum Zeitpunkt des ersten Artikels 99,8 % der bestehenden Suite bestanden wurden, wobei ausdrücklich darauf hingewiesen wurde, dass der Port noch nicht in der Produktion war. Buns späterer Artikel behandelte die darauffolgenden Arbeiten: Sicherheitsüberprüfungen, Fuzzing, Produktionsregressionen, semantische Korrekturen und Reduzierung von unsicherem Code.

Zusammen beschreiben die Quellen zwei verschiedene Meilensteine:

Implementierung ausreichend für einen Merge
Nachweise ausreichend für einen sicheren Betrieb

Begriffe, die Sie kennen müssen: Port, Orakel, Differential Testing und Unsafe Surface

Diese Definitionen sind wichtig, da ein Team eine Migration erst überprüfen kann, wenn es sich einig ist, was die Nachweise beweisen müssen. Sie trennen außerdem die Vertrauensaussage eines Agenten von einem extern überprüfbaren Ergebnis.

Port

Ein Port implementiert Software in einer neuen Sprache, Laufzeitumgebung, Plattform oder einem neuen Framework neu, während eine definierte Menge von Verhalten erhalten bleibt.

"Verhalten erhalten" benötigt eine Abgrenzung. Ein Port kann öffentliche APIs und Ausgaben erhalten, während er absichtlich interne Architektur, Leistungsmerkmale, Fehlermeldungen oder nicht unterstützte Randfälle ändert.

Verhaltensvertrag

Ein Verhaltensvertrag ist eine explizite Liste von Eigenschaften, die die neue Implementierung erhalten muss.

Er kann Folgendes umfassen:

Ein- und Ausgaben
Fehlerverhalten
Reihenfolge
Seiteneffekte
Nebenläufigkeitssemantik
Ressourcengrenzen
Unterstützte Plattformen
Leistungsbudgets
Beobachtbarkeitsanforderungen

Vorhandener Code enthält Verhalten, aber nicht jedes vorhandene Verhalten ist beabsichtigt. Der Vertrag trennt Anforderungen von historischen Zufälligkeiten.

Test-Orakel

Ein Test-Orakel bestimmt, ob eine Ausgabe korrekt ist.

Eine Unit-Test-Assertion ist ein Orakel. Eine Referenzimplementierung, eine Protokollspezifikation, eine Goldene Datei, eine Datenbankinvariante oder eine von Menschen erstellte Regel kann ebenfalls als Orakel dienen.

Anthropics Leitlinien für langlebige

wissenschaftliches Programmieren betont, dass autonome Arbeit Referenzen, messbare Ziele oder Testsuiten benötigt, damit Agenten feststellen können, ob sie Fortschritte machen.

Differentielles Testen

Differentielles Testen sendet dieselben Eingaben an alte und neue Implementierungen und vergleicht dann die beobachtbaren Ergebnisse.

Es ist besonders nützlich, wenn die alte Implementierung vertrauenswürdig ist, aber keine vollständige formale Spezifikation existiert. Übereinstimmung beweist nicht, dass beide Implementierungen korrekt sind, aber Abweichungen erzeugen eine präzise Untersuchungswarteschlange.

Metamorphes Testen

Metamorphes Testen prüft Beziehungen zwischen mehreren Ausführungen, wenn exakte erwartete Ausgaben schwer zu schreiben sind.

Beispiele hierfür sind:

Das Serialisieren und Parsen eines Wertes sollte ihn erhalten.
Das Umordnen unabhängiger Eingaben sollte ein mengenwertiges Ergebnis nicht ändern.
Das zweimalige Ausführen einer idempotenten Migration sollte den Zustand beim zweiten Durchlauf nicht ändern.
Das erneute Senden desselben Idempotenzschlüssels sollte keinen doppelten Nebeneffekt erzeugen.

Unsichere Oberfläche

Die unsichere Oberfläche ist Code, bei dem die normalen Garantien der Zielsprache abgeschwächt oder umgangen werden.

In Rust kann unsafe an C- oder C++-FFI-Grenzen, innerhalb benutzerdefinierter Allokatoren oder für Low-Level-Laufzeitintegration erforderlich sein. Die reine Anzahl ist kein Urteil. Das Team benötigt Eigentümerschaft, Invarianten, Tests und einen expliziten Plan für jede unsichere Grenzfläche.

Entwichener Fehler

Ein entwichener Fehler ist ein migrationsbedingter Fehler, der nach dem Gate entdeckt wurde, das ihn hätte erkennen sollen – nach dem Merge, im Canary-Deployment, beim Release-Candidate-Test oder in der Produktion.

Entwichene Fehler sind Feedback an das Verifikationssystem, nicht nur an die Implementierung.

Die Kausalkette: Warum schnellere Generierung stärkere Verifikation erfordert

Agentenparallelität verändert die Ökonomie der Implementierung. Wenn 64 Arbeiter gleichzeitig Dateien übersetzen, kann die Code-Generierungszeit drastisch sinken. Der Abhängigkeitsgraph, die Zielsprachensemantik und die gemeinsame Testumgebung verschwinden nicht. Der Durchsatz verlagert den Engpass einfach nachgelagert.

Engpass 1: Integration

Einzeln betrachtet vernünftige Dateien können scheitern, wenn sie zusammen kompiliert werden.

Buns rund 16.000 Compilerfehler und zyklische Crate-Abhängigkeiten veranschaulichen die Lücke zwischen lokaler Übersetzung und globaler Konsistenz. Der Compiler ist ein ausgezeichneter deterministischer Orakel für Typen, Eigentümerschaft, Lebensdauern, Namen und einige Kontrollflusseigenschaften. Er ist kein Orakel für das Produktverhalten.

Engpass 2: Semantische Äquivalenz

Bun dokumentierte Fehler, bei denen Code sprachübergreifend fast identisch aussah, sich aber anders verhielt.

Beispiele umfassten:

Seiteneffekte, die in Rust debug_assert! platziert wurden und in Release-Builds verschwanden, während eine vergleichbare Zig-Assertion ihre Argumente noch auswertete.
Ein eifriger unwrap_or-Ausdruck, der Verhalten auslöste, das träge hätte bleiben sollen.
Byte-Slice- und Grenzsemantiken, die zwischen Implementierungen unterschiedlich waren.
UTF-16-Eingaben mit ungerader Länge, die einen Absturz auslösten.

Dies sind genau die Fehler, die oberflächliche Überprüfungen übersehen, weil der übersetzte Code plausibel aussieht.

Engpass 3: Korrelation von Überprüfungen

Wenn dasselbe Modell einen Wechsel mit demselben Kontext und denselben Annahmen schreibt und überprüft, kann es denselben

Originalfout.

Anthropics Claude-Code-Dokumentation zu Best Practices empfiehlt einen frischen Prüfungskontext. Der Prüfer sieht den Diff und die Vorgabe, ohne die Argumentation des Autors zu übernehmen. Unabhängigkeit garantiert nicht Korrektheit, reduziert aber die gemeinsame Kontextverzerrung.

Engpass 4: Betriebliche Nachweise

Tests können bestehen, während die Latenz steigt, die Speichernutzung wächst, ein Betriebssystemziel bricht oder die Beobachtbarkeit verschwindet.

Je umfangreicher die Änderung, desto wahrscheinlicher entdeckt das Team eine verletzte Anforderung erst nach der Bereitstellung. Deshalb muss ein Migrationsplan Canary-Releases, Rollback, Telemetrievergleiche und einen Prozess umfassen, der jeden entkommenen Fehler in eine neue Vertragsregel oder einen Test umwandelt.

Die kausale Schlussfolgerung ist einfach:

KI beseitigt nicht die Migrationskosten. Sie verlagert die Kosten vom Tippen hin zur Spezifikation, Prüfstandsgestaltung, Nachweiseprüfung und Bereitstellungskontrolle.

Ein Team, das diese Verschiebung ignoriert, mag Code schnell generieren, aber dann Monate damit verbringen, festzustellen, ob die Umschreibung tatsächlich funktioniert.

Eine Verifikationsarchitektur für KI-gesteuerte Migrationen

Die Architektur hat vier Ebenen.

1. Vertragsebene

Die Vertragsebene speichert:

Öffentliches Verhalten
Kompatibilitätszusagen
Geplante Änderungen
Unterstützte Plattformmatrix
Leistungsbudgets
Sicherheitsbeschränkungen
Beobachtbarkeitsanforderungen

Menschen pflegen diese Ebene, und das Repository versioniert sie.

2. Ausführungsebene

Die Ausführungsebene enthält isolierte Implementierungsagenten.

Jeder Agent erhält:

Eine Migrationseinheit
Relevante Quelldateien
Den genehmigten Vertrag
Die semantische Karte
Eng abgegrenzte Werkzeuge
Zielgerichtete Prüfungen

Der Agent kann weder den Vertrag noch globale Tests ändern. Er bearbeitet nur seinen zugewiesenen Bereich und gibt sowohl einen Commit als auch Nachweise zurück.

3. Verifikationsebene

Die Verifikationsebene ist unabhängig von der Implementierung.

Sie kann:

Den Kandidaten kompilieren
Zielgerichtete und globale Tests ausführen
Alt-gegen-Neu-Differenzprüfungen durchführen
Parser und Protokollgrenzen fuzz-testen
Sicherheitskritischen Code scannen
Repräsentative Arbeitslasten benchmarken
Frische Prüfer bitten, nach Gegenbeispielen zu suchen

Verifikationsagenten können Tests vorschlagen, aber die deterministische CI entscheidet, ob ein Tor passiert wird.

4. Freigabeebene

Die Freigabeebene kontrolliert Integration und Produktionsexposition.

Sie:

Fügt in Abhängigkeitsreihenfolge zusammen
Erzeugt reproduzierbare Artefakte
Identifiziert Builds mit unveränderlichen Versionen oder Hashes
Führt, wo möglich, Schattenverkehr aus
Weitet Canary-Releases allmählich aus
Überwacht Service-Level-Indikatoren
Bewahrt einen getesteten Rollback-Pfad

We0 AI kann zwischen diesen Ebenen als Orchestrierungs- und Nachweisschicht sitzen. Teams können Aufgaben verwenden, um Migrationsabschnitte zuzuweisen, Arbeitsbäume zu isolieren, Verträge anzuhängen, Testausgaben zu sammeln und eine Überprüfung vor Fortschritt zu verlangen.

Die wichtige Grenze ist, dass Orchestrierung Nachweise koordiniert. Sie verwandelt nicht die Erfolgsbehauptung eines Agenten in eine Freigabeberechtigung.

Beispielszenario: Migration eines Zahlungsdienstes von Python zu Go

Stellen Sie sich einen 120.000-zeiligen Python-Zahlungsdienst vor, der zu Go migriert wird. Das Geschäftsziel ist es,

Zeitverzögerung am Ende (Tail Latency) und vereinfachte Bereitstellung.

Ein gefährlicher Prompt wäre:

Schreibe diesen Dienst in Go um und lasse alle Tests bestehen.

Dieser Prompt lässt Transaktionssemantik, Fehlerverhalten, monetäre Genauigkeit, Idempotenz und Rollout undefiniert.

Schritt 1: Den Vertrag schreiben

Für jeden Endpunkt erfasst das Team:

Anfrage- und Antwortschemata
Autorisierungsregeln
Idempotenzschlüssel-Verhalten
Währungsrundung
Wiederholungssemantik
Datenbanktransaktionen
Ereignisreihenfolge
Fehlercodes
Telemetrieanforderungen

Es markiert auch beabsichtigte Änderungen, wie das Entfernen eines Python-spezifischen Debugging-Headers. Das Team definiert die unterstützte Plattform und die Abhängigkeitsmatrix, legt dann p95- und p99-Latenzbudgets sowie eine Spitzenarbeitsspeicherobergrenze fest.

Schritt 2: Drei Pilotabschnitte auswählen

Das Team wählt aus:

Ein reines Währungsformatierungsmodul
Ein Idempotenz-Repository mit Datenbank-Seiteneffekten
Einen schreibgeschützten HTTP-Endpunkt

Der erste testet die mechanische Übersetzung. Der zweite testet Transaktionen und Nebenläufigkeit. Der dritte testet die HTTP-Kompatibilität.

Ein Implementierungsagent bearbeitet jeden Abschnitt. Neue Prüfer erhalten nur den Vertrag, den alten Quellcode, den vorgeschlagenen Diff und die Validierungsbefehle.

Schritt 3: Den alten Dienst als differentielles Orakel nutzen

Ein bereinigtes Korpus historischer Anfragen wird gegen beide Versionen abgespielt.

Antworten werden nur dort normalisiert, wo der Vertrag Unterschiede zulässt, und dann verglichen. Für Schreibpfade laufen beide Implementierungen gegen Einweg-Datenbanksnapshots. Die resultierenden Zeilen und ausgegebenen Ereignisse werden verglichen.

Metamorphe Tests führen dann durch:

Wiederholen desselben Idempotenzschlüssels
Ändern der harmlosen JSON-Schlüsselreihenfolge
Einführen von Variationen im Wiederholungszeitpunkt
Ausreizen von grenzwertigen Geldbeträgen

Schritt 4: Den neuen Dienst im Schattenbetrieb und als Canary testen

Bevor Produktionsschreibvorgänge aktiviert werden, erhält der Go-Dienst Schattenverkehr, wobei Schreibvorgänge deaktiviert oder an einen isolierten Senker umgeleitet werden.

Das Team vergleicht:

Latenzverteilungen
Fehlerklassifikationen
Abhängigkeitsaufrufe
Ablaufverfolgungsformen
Speichernutzung
Ereignisverhalten

Das Team sendet dann 1 % Canary-Verkehr von einer Händlergruppe mit geringem Risiko.

Die Erweiterung erfordert:

Keine ungeklärten finanziellen Abweichungen
Fehlerratenparität
Latenz innerhalb des vereinbarten Budgets
Eine erfolgreiche Rollback-Übung

Die Implementierung kann sich dennoch schnell bewegen. Sicherheit entsteht dadurch, dass "den Dienst umschreiben" in überprüfbare Behauptungen umgewandelt wird.

Dieses Beispiel zeigt auch, warum Fachwissen unerlässlich bleibt. Agenten können Code übersetzen, aber Zahlungsexperten wissen, dass doppelte Ereignisse, Rundungsunterschiede und Wiederholungsverhalten Geschäftsanforderungen sind.

Phase 0: Den Migrationsvertrag und die Stoppbedingungen definieren

Bevor ein Agent Code bearbeitet, entscheiden Sie, was als dasselbe Produkt gilt.

Bestandsaufnahme:

Öffentliche APIs
CLI-Verhalten
Dateiformate
Datenbankeffekte
Umgebungsvariablen
Telemetrie
Für Benutzer sichtbare Fehlermeldungen
Unterstützte Plattformen
Leistungsmerkmale

Markieren Sie jede Eigenschaft als eine der folgenden:

Beibehalten
Absichtlich ändern
Einstellen
Unbekannt

Unbekanntes ist keine Erlaubnis zum Raten. Sie werden zu Erkundungsaufgaben.

Führen Sie das alte System aus, durchsuchen Sie Issues und Änderungsprotokolle, inspizieren Sie Produktionsablaufverfolgungen oder fragen Sie Betreuer. Der Quellbaum von Bun vor der Migration.

Die Reorganisation bewahrte die Git-Historie durch reine Verschiebe-Commits und machte die Herkunft zu einer bewussten Anforderung anstatt zu Kollateralschaden.

Definieren Sie harte Abbruchbedingungen. Beenden Sie die Aufweitung, wenn:

Die Fehlerrate bei Piloten den Schwellenwert überschreitet.
Arbeiter wiederholt geschützte globale Tests modifizieren.
Die Warteschlange für Compiler-Fehler schneller wächst als sie abgebaut wird.
Die Zielperformance das Budget verfehlt.
Ein Rollback-Artefakt nicht erstellt werden kann.
Die Nachweise unvollständig oder unlesbar sind.

Das Stoppen schützt das Projekt vor der Eskalation versunkener Kosten.

Der Vertrag muss getrennt von der Ausführung kontrolliert werden. Ein Agent darf einen fehlschlagenden Test nicht "reparieren", indem er die Anforderung abschwächt. Vertragsänderungen erfordern eine von Menschen geprüfte Änderungsbegründung, die erklärt, warum das alte Verhalten veraltet oder falsch ist.

Phase 1: Erstellen einer semantischen Karte vor der großflächigen Generierung

Erstellen Sie explizite Zuordnungen für gängige, subtile oder gefährliche Quell-Ziel-Muster.

Decken Sie Bereiche ab wie:

Besitz- und Lebensdauerregeln
Nullfähigkeit (Nullable)
Ausnahmen und Fehlerbehandlung
Ganzzahlüberlauf
Zeitberechnungen
Zeichenkodierung
Nebenläufigkeitsprimitive
Allokator-Besitz
FFI (Fremdfunktionsschnittstelle)
Debug- versus Release-Verhalten
Plattformspezifischer Code

Buns PORTING.md und LIFETIMES.tsv dienten diesem Zweck.

Ihr Wert beschränkte sich nicht auf bessere Prompts. Sie gaben Hunderten von Arbeitern eine gemeinsame semantische Strategie. Ohne eine solche Karte erfindet jeder Agent seinen eigenen Übersetzungsansatz, und Inkonsistenz wird zu einem Integrationsproblem.

Beauftragen Sie unabhängige Agenten mit der Überprüfung der Karte:

Geben Sie einem Prüfer die Semantik der Quellsprache.
Geben Sie einem anderen die Risiken der Zielsprache.
Geben Sie einem dritten repräsentative Codebeispiele.
Fordern Sie konkrete Gegenbeispiele.

Menschen sollten die risikoreichsten Regeln überprüfen, insbesondere solche, die Speicherbesitz, Nebenläufigkeit, Sicherheitsgrenzen, Persistenz und reines Release-Verhalten betreffen.

Versionieren Sie die Karte. Jede neu entdeckte Abweichung sollte die Regeln aktualisieren, betroffene Migrationsmodule identifizieren und eine gezielte erneute Validierung auslösen.

Die semantische Karte ist eine lebendige Spezifikation, kein Prompt, der einmal zu Beginn eingefügt wird.

Phase 2: Bewusst schwierige Piloten entwerfen

Wählen Sie nicht nur die einfachsten Dateien.

Ein nützlicher Pilot umfasst drei Formen:

Eine einfache, repräsentative Einheit
Eine abhängigkeitsreiche Einheit
Ein semantischer Hotspot

Bun verwendete drei Dateien, um den Implementierungs-Prüfungs-Korrektur-Zyklus zu validieren, bevor 1.448 Dateien übersetzt wurden. Die genaue Zahl ist weniger wichtig als die Bandbreite der abgedeckten Fehlermodi.

Messen Sie den Pilotprozess, nicht nur sein Ergebnis:

Haben Arbeiter die Dateibesitzverhältnisse respektiert?
Waren Commits atomar?
Haben Prüfer echte Fehler gefunden oder hauptsächlich Rauschen produziert?
Konnte der Korrektor Vorschläge anwenden, ohne den Vertrag zu verletzen?
War der Nachweis noch lesbar?
Wie viel Kontext und Rechenleistung verbrauchte jede akzeptierte Einheit?

Säen Sie Fehler bewusst ein. Fügen Sie einen subtilen Unterschied im Release-Modus, einen Edge-Case-Fixture oder einen Leistungsschwellenwert hinzu und bestätigen Sie, dass das Verifikationssystem ihn erkennt.

Ein Testrahmen, der nur saubere Beispiele bestanden hat, wurde noch nicht getestet.

Die Aufweitung sollte erst beginnen, wenn der Pilot stabile, wiederholbare Nachweise liefert. Wenn sich später die Prompts, Modelle oder Toolrichtlinien wesentlich ändern, führen Sie den kleinen Piloten erneut durch. Der Arbeitsablauf

Konfigurationscode ist Produktionscode und verdient Regressionstests.

Phase 3: Ausweitung mit Isolation, Zuständigkeit und atomaren Commits

Erstelle Migrationseinheiten, die auf den Abhängigkeitsgraphen abgestimmt sind.

Eine Partitionierung auf Dateiebene ist praktisch, aber möglicherweise die falsche Grenze, wenn sich Verhalten über Module erstreckt. Weise jeder Einheit einen Autor zu und mache die Zuständigkeit maschinenlesbar. Mitarbeiter können Abhängigkeiten lesen, aber nur ihren eigenen Bereich bearbeiten, es sei denn, sie beantragen eine koordinierte Änderung.

Verwende wo praktikabel separate Arbeitsbäume, Container oder flüchtige virtuelle Maschinen.

Das Scheitern des gemeinsamen Arbeitsbereichs von Bun zeigt, warum. Beschränke destruktive Git-Befehle und teure globale Build-Befehle für Blatt-Mitarbeiter. Lasse einen Koordinator eine geordnete Integration durchführen.

Kurzlebige Anmeldeinformationen und Netzwerk-Whitelists reduzieren die Auswirkungen von Prompt-Injection oder Abhängigkeitsexfiltration. Die Sandboxing-Richtlinien von Anthropic beschreiben Dateisystem- und Netzwerkgrenzen als Grundlage für sicherere Autonomie.

Jede akzeptierte Einheit sollte einen atomaren Commit erzeugen, der Folgendes enthält:

Quellkennung
Anwendbare Vertragsregeln
Ausgeführte Befehle
Test- und Prüfausgaben
Prüfergebnisse
Genehmigte Ausnahmen

Git wird sowohl zu einem Koordinations- als auch zu einem Wiederherstellungsmechanismus.

Die Richtlinien von Anthropic für langlaufende Arbeitsabläufe empfehlen sinnvolle Commits und Tests vor jedem Commit, da eine wiederherstellbare Historie verhindert, dass eine lange Agentenausführung zu einem undurchsichtigen Artefakt wird.

Optimiere nicht für Zeilen pro Minute. Optimiere für geprüfte Einheiten pro Stunde.

Ein hoher Generierungsdurchsatz in Kombination mit einer wachsenden Integrationswarteschlange ist negativer Fortschritt.

Phase 4: Behandle Compiler-Fehler und Tests als Warteschlangen, nicht als Beweise

Die Compiler-Ausgabe erzeugt strukturierte Arbeit.

Gruppiere Fehler nach Zuständigkeitseinheit oder Abhängigkeitsebene, entferne doppelte Kaskaden und behebe Grundursachen, bevor du Blattsymptome behandelst.

Verbiere Abkürzungen, es sei denn, der Vertrag erlaubt sie ausdrücklich, einschließlich:

Leere Stubs
Ignorierte Ergebnisse
Großzügige allow-Attribute
Deaktivierte Assertions
Platzhalter-Implementierungen
Tests, die nur geändert wurden, um den Kandidaten bestehen zu lassen

Führe Tests in sich erweiternden Kreisen durch:

Unit-Tests für das geänderte Modul
Vertragstests an öffentlichen Grenzen
Integrationstests über Abhängigkeiten hinweg
Plattformübergreifende Testsuiten
Vollständige Regressionstests

Behalte fehlgeschlagene Ausgaben als Artefakt. Ein endgültig grüner Durchlauf ohne Historie kann verbergen, ob Mitarbeiter unterwegs wiederholt Prüfungen abgeschwächt haben.

Trenne nach Möglichkeit die Testautorenschaft von der Implementierung.

Ein Agent kann Randfälle aus dem Vertrag und der alten Implementierung ableiten, während ein anderer die Portierung schreibt. Sperre genehmigte Kompatibilitätstests, damit Implementierungsmitarbeiter sie nicht ändern können. Neue Prüfer sollten fragen, ob der Code aus dem beabsichtigten Grund besteht.

Die Produktionsregressionen von Bun zeigen die Lücke zwischen einer grünen Testsuite und semantischer Vollständigkeit.

Ein nur in der Release-Version auftretender HMR-Fehler stammte von einem Nebeneffekt in debug_assert!. Ein Absturz mit ungerader UTF-16-Länge spiegelte unterschiedliches Slice-Verhalten wider. Jeder übersehene Fehler sollte sowohl zu einem permanenten Regressionstest als auch zu einer neuen semantischen Kartenregel werden.

Phase 5: Füge differentielle Tests, Fuzzing und Leistungsbudgets hinzu

Führe die alten und neuen Implementierungen gegen dasselbe Korpus aus.

Vergleiche:

Exit-Codes
Normalisierte Ausgabe
Fehlerkategorien
Nebenwirkungen
Datenbankzustand
Ausgelöste Ereignisse
Ablaufverfolgungen

Erstellen Sie Grenzwertgeneratoren für:

Leere Eingaben
Maximale Größen
Fehlerhafte Kodierungen
Zeitpunkte um die Unix-Epoche
Nebenläufige Wettlaufsituationen
Plattformspezifische Pfade
Ressourcenerschöpfung

Testen Sie Parser und Protokollgrenzen kontinuierlich mit Fuzzing.

Bun berichtete, dass seine abdeckungsgesteuerten Fuzzer den Parser-Code etwa 100 Milliarden Mal ausführten und etwa 15 Pull Requests für Fehlerbehebungen generierten. Die absolute Anzahl hängt vom Arbeitsaufwand ab. Das übertragbare Muster besteht darin, die Erkennung von Abstürzen mit reproduzierbaren Tests, von Agenten vorgeschlagenen Korrekturen und von Menschen geprüften Pull Requests zu verbinden.

Wenn Benutzer von der Leistung abhängen, ist die Leistung ein Teil des Verhaltens.

Benchmark:

Kaltstart
Durchsatz
p50-Latenz
p95-Latenz
p99-Latenz
Spitzenarbeitsspeicher
Binärgröße
Build-Zeit
CPU-Auslastung unter repräsentativen Arbeitslasten

Vergleichen Sie Verteilungen anstelle von Durchschnittswerten. Legen Sie Budgets vor der Migration fest, damit das Team Regressionen nicht rationalisieren kann, nachdem es stark in die Neufassung investiert hat.

Führen Sie auch Dauertests durch. Speicherlecks, Deskriptorlecks, Warteschlangenwachstum, Allokator-Fragmentierung und seltene Wettlaufsituationen können Stunden oder Tage benötigen, um aufzutauchen.

Eine Sprache mit stärkeren Speichersicherheitsgarantien kann ganze Fehlerklassen beseitigen, während sie dennoch unterschiedliches Allokations-, Planungs- oder Leistungsverhalten einführt.

Überprüfen Sie unsicheren Code, FFI und Sicherheitsgrenzen separat

Behandeln Sie jedes der folgenden Elemente als separate Überprüfungsklasse:

unsafe-Blöcke
FFI-Aufrufe
Rohzeiger
Benutzerdefinierte Allokatoren
Kryptografische Grenzen
Parser
Deserialisierer
Berechtigungsprüfungen
Authentifizierungslogik
Persistenzgrenzen

Zum Zeitpunkt des Quellberichts beschrieb Bun etwa 27.000 Zeilen in unsafe-Blöcken von etwa 780.000 Rust-Zeilen, ein Großteil davon im Zusammenhang mit der Integration von C und C++.

Diese Oberfläche erfordert mehr als eine gewöhnliche Code-Überprüfung.

Fordern Sie einen Invariantenkommentar in der Nähe jeder unsicheren Grenze:

Was muss wahr sein?
Wer stellt die Invariante auf?
Wie lange bleibt der Zeiger gültig?
Welchem Thread gehört der Wert?
Welcher Test testet die Bedingung?

Gruppieren Sie wiederholte unsichere Muster hinter überprüften Wrappern. Verfolgen Sie unsichere Zeilen und Blöcke nach Eigentümer, anstatt die Gesamtzahl als Eitelkeitsmetrik zu behandeln.

Verwenden Sie:

Statische Analyse
Sanitizer
Abhängigkeitsaudits
Fuzzing
Manuelle Sicherheitsüberprüfung

Die 11 Sicherheitsüberprüfungsrunden von Bun sind ein Beweis für kontinuierliche Härtung, nicht dafür, dass keine Mängel vorhanden waren.

Automatisierte Sicherheitsüberprüfungen sollten die Domänenüberprüfung ergänzen, insbesondere bei Authentifizierung, Sandbox-Escape, Geheimnissen und Lieferkettenänderungen.

Überprüfen Sie den Migrationsmechanismus selbst. Agenten führen Repository-Inhalte, Build-Skripte und Tool-Ausgaben aus. Eine kompromittierte Abhängigkeit oder eine versteckte Anweisung im Quellcode kann die Ausführung beeinflussen.

Dateisystemisolierung, Netzwerkbeschränkungen, bereichsbegrenzte Token und unveränderliche CI-Prüfungen verringern dieses Risiko.

In Stufen veröffentlichen und Rollback üben, bevor Sie es brauchen

Merge ist nicht Release.

Erstellen Sie versionierte Artefakte aus bekannten Commits, Toolchains, Abhängigkeitssperren und Beweismanifesten. Halten Sie die alte Implementierung baubar.

Wenn alte und neue Binärdateien koexistieren können, fügen Sie einen Laufzeitschalter oder eine Routing-Ebene hinzu.

anstatt den Pfad unwiderruflich zu ersetzen.

Beginnen Sie mit Schattenausführung, wenn Seiteneffekte isoliert werden können.

Führen Sie dann Canary-Tests mit folgenden Gruppen durch:

Interne Benutzer
Risikoarme Mieter
Plattform
Region
Datenverkehrsanteil

Definieren Sie automatische Rollback-Schwellenwerte für:

Korrektheitsabweichungen
Absturzrate
Latenz
Speicher
Fehlerkategorien
Supportsignale

Menschen müssen in der Lage sein, die Ausweitung zu stoppen, auch wenn die automatischen Schwellenwerte nicht ausgelöst wurden.

Üben Sie das Rollback.

Stellen Sie sicher, dass:

Das alte Artefakt erfolgreich startet.
Schemata kompatibel bleiben.
In der Warteschlange befindliche Arbeiten abfließen können.
Die Beobachtbarkeit identifiziert, welche Implementierung jede Anfrage bedient hat.
Die gemessene Rollback-Zeit dem operativen Ziel entspricht.

Eine Rollback-Dokumentation, die noch nie ausgeführt wurde, ist nur eine Hypothese.

Aktualisieren Sie nach jedem entgangenen Defekt den Vertrag, die semantische Karte, das Testkorpus und das Risikomodell.

Die 19 bekannten Regressionen von Bun sind nützlich, weil sie wiederkehrende Übersetzungsrisiken aufdecken. Eine Migration ist abgeschlossen, wenn die neue Implementierung betriebsfähig ist und das Team daraus gelernt hat – nicht wenn der generierte Diff gemerged wurde.

Wiederverwendbare KI-Migrationsrichtlinie und Nachweis-Manifest

Das folgende YAML ist als wiederverwendbares Team-Artefakt konzipiert. Passen Sie Befehle, Schwellenwerte und Verantwortliche an das Repository an.

We0 KI oder ein anderes Orchestrierungssystem kann diese Richtlinie Migrationsaufgaben zuweisen und das Nachweis-Manifest vor der Überprüfung anfordern.

ai_migration:
  name: payments-python-to-go
  contract: docs/MIGRATION_CONTRACT.md
  semantic_map: docs/PORTING_RULES.md
  old_reference: artifacts/payments-python@sha256:OLD
  new_candidate: artifacts/payments-go@sha256:NEW

  worker_policy:
    isolation: ephemeral_worktree
    one_writer_per_unit: true
    forbidden_commands:
      - "git reset --hard"
      - "git stash"
      - "git push --force"
    editable_paths: ["cmd/", "internal/", "tests/migration/"]
    protected_paths: ["tests/contracts/", "docs/MIGRATION_CONTRACT.md"]

  required_gates:
    compile: "go build ./..."
    unit: "go test ./..."
    contracts: "./scripts/run-contract-tests.sh"
    differential: "./scripts/compare-old-new.sh --corpus fixtures/replay"
    fuzz: "./scripts/fuzz.sh --hours 24 --unique-crashes 0"
    security: "./scripts/security-scan.sh --severity high"
    performance:
      p99_latency_regression_pct: 5
      peak_memory_regression_pct: 10
    platforms: [linux-amd64, linux-arm64]

  independent_review:
    fresh_context: true
    reviewers_per_unit: 2
    require_counterexample_search: true

  rollout:
    shadow_hours: 48
    canary_percentages: [1, 5, 20, 50, 100]
    rollback_artifact_required: true
    rollback_drill_required: true

  evidence_manifest:
    include:
      - contract_version
      - source_and_target_commits
      - changed_units
      - commands_and_exit_codes
      - differential_mismatches
      - fuzzing_summary
      - benchmark_distributions
      - unsafe_or_ffi_inventory
      - reviewer_findings
      - approved_exceptions
      - rollback_drill_result

Diese Richtlinie verhindert bewusst, dass Implementierungsmitarbeiter den Vertrag oder die genehmigten Vertragstests bearbeiten.

Sie erfordert:

Referenzartefakte
Unabhängige Überprüfung
Quantitative Validierung

Leistungsgrenzen

Nachweise für die Einführung
Ein getesteter Rollback-Pfad

Ausnahmen sind möglich, aber sie müssen dokumentiert und genehmigt werden, anstatt in einem Prompt versteckt zu sein.

Messen Sie nachgewiesenen Fortschritt, nicht erzeugte Menge

Codezeilen, Agentenanzahl und vergangene Tage sind interessante Kapazitätsmetriken. Sie messen keinen Produkterfolg.

Verwenden Sie eine ausgewogene Migrationsbewertungstafel.

Nachgewiesener Einheitsdurchsatz

Verfolgen Sie Migrationseinheiten, die:

Kompilieren
Gezielte Vertragsprüfungen bestehen
Eine unabhängige Überprüfung erhalten
Ohne Regression integrieren

Messen Sie akzeptierte Einheiten pro Zeiteinheit.

Abweichungsschließung

Verfolgen Sie entdeckte Unterschiede und ob jeder einzelne:

Erklärt
Behoben
Als beabsichtigt genehmigt
Noch ungelöst ist

Entkommene Fehler

Verfolgen Sie Fehler, die eine Kontrollinstanz passieren, die sie hätte abfangen sollen.

Jeder entkommene Fehler sollte eine fehlende Vertragsregel, einen fehlenden Test, ein fehlendes Orakel, einen fehlenden Überprüfungsschritt oder eine fehlende Einführungsschwelle identifizieren.

Menschliche Aufmerksamkeit

Messen Sie die Zeit, die Menschen aufwenden für:

Definieren von Verträgen
Auflösen von Mehrdeutigkeiten
Überprüfen von risikoreichem Code
Untersuchen von Abweichungen
Betreiben von Bereitstellungen

KI kann die Implementierungszeit reduzieren und gleichzeitig die Spezifikationsqualität erhöhen. Das ist ein guter Austausch, kein Automatisierungsfehler.

Rechen- und Werkzeugkosten

Messen Sie die gesamten Modell-, Rechen- und Werkzeugkosten pro akzeptierter Einheit.

Dynamische Workflows können mehr Tokens verbrauchen als gewöhnliche Sitzungen. Parallelisierung ist gerechtfertigt, wenn sie Wartezeiten für hochwertige Arbeit reduziert, ohne einen größeren Überprüfungsrückstand zu erzeugen.

Wartbarkeit nach der Migration

Verfolgen Sie:

Startzeit
Build-Geschwindigkeit
Änderungsfehlerrate
Überprüfungslatenz
Fehlerdichte
Eigentümerschaft unsicherer Module
Einfachheit des Debuggings
Qualität der Betriebsdokumentation

Eine Portierung, die schnell ausgeliefert wird, aber für das Team intransparent bleibt, hat Schulden verschoben, nicht beseitigt.

Wie ein Team ohne eine Millionen-Zeilen-Neuschreibung beginnen kann

Wählen Sie eine abgegrenzte Migration mit einer live existierenden Referenzimplementierung, wie zum Beispiel:

Eine SDK-Versionsänderung
Ein Framework-Subsystem
Ein CLI-Befehl
Ein Service-Endpunkt

Schreiben Sie einen einseitigen Verhaltensvertrag und drei risikoorientierte Pilotfälle.

Verwenden Sie separate Agentenaufgaben für Implementierung und Überprüfung, damit ihre Kontexte unabhängig bleiben.

Vor der Implementierung:

Schließen Sie die Abnahmeprüfungen fest.
Verlangen Sie vom Implementierer die Rückgabe eines Commits und von Nachweisen, nicht einer Fließtextbehauptung.
Bitten Sie den Prüfer, Gegenbeispiele zu finden und fehlende Tests zu identifizieren.
Führen Sie die Prüfungen in der CI außerhalb des Modells durch.
Erweitern Sie den Umfang erst auf die nächste Abhängigkeitsebene, nachdem der Pilot erfolgreich war.

Führen Sie ein vollständiges Ausführungsprotokoll:

Prompt
Modell
Werkzeugumfang
Quell-Commit
Ziel-Commit
Geänderte Pfade
Prüfungen
Fehlschläge
Prüferbefunde
Ausnahmen
Kosten
Endgültige Entscheidung

Dieses Protokoll ermöglicht es dem Team, Versionen des Testrahmens zu vergleichen und Fehler zu untersuchen, ohne raten zu müssen, was der Agent gesehen hat.

Verwenden Sie eine einfache Einführungsregel:

Autonomie muss verdient werden.

Ein Workflow, der wiederholt verifizierte Einheiten produziert, kann einen breiteren Dateiumfang oder eine längere unbeaufsichtigte Laufzeit erhalten. Er erhält nicht automatisch eine Bereitstellungserlaubnis.

Fähigkeit, Nachweise und Befugnis bleiben getrennt.

Grenzen: Was der Bun-Fall nicht beweist

Bun ist ein ungewöhnliches Projekt.

Sein Schöpfer leitete die

Migration, hatte tiefgehende Kenntnisse der Codebasis und trug direkte architektonische Verantwortung. Die alte Implementierung verfügte über eine große Testsuite, Rust bot starkes Compiler-Feedback, und das Projekt konnte erhebliche parallele Rechenleistung nutzen.

Die meisten Teams werden nicht alle diese Vorteile teilen.

Der Fall wurde auch über Anthropic vorgestellt, und der Quellartikel gibt an, dass die Arbeit ein Vorab-Modell von Claude Fable 5 verwendete. Es ist ein wertvoller primärer Beleg, aber kein unabhängiger Anbietervergleich.

Behauptungen darüber, wie lange ein menschliches Team gebraucht hätte, sind kontrafaktische Schätzungen. Teams sollten keine Beschaffungsentscheidungen auf der Grundlage einer einzigen erfolgreichen Migration treffen.

Die 19 gemeldeten Regressionen sind bekannte Regressionen, keine Garantie für die vollständige Anzahl. Fuzzing-Ausführungen und Sicherheitsüberprüfungsrunden messen den Aufwand, nicht die Abwesenheit von Fehlern.

Die stärkste vertretbare Schlussfolgerung ist bescheiden:

Große KI-gesteuerte Migrationen sind machbar, wenn sie mit starkem deterministischem Feedback und fachkundiger Orchestrierung kombiniert werden, aber ihr Risiko bleibt nach Abschluss der Codegenerierung ein technisches Problem.

Diese Schlussfolgerung ist dennoch bedeutsam. Teams können Modernisierungsprojekte in Angriff nehmen, die zuvor aufgrund von Kosten verschoben wurden, vorausgesetzt, sie budgetieren für Spezifikation, Verifikation und kontrollierte Ausbringung im gleichen Umfang wie die Implementierung.

Praktische Migrations-Checkliste

Definieren Sie erhaltene, geänderte, veraltete und unbekannte Verhaltensweisen.
Erfassen Sie Plattform-, Leistungs-, Telemetrie-, Fehler- und Nebenwirkungsverträge.
Erstellen Sie eine semantische Karte für riskante Quell-Ziel-Muster.
Schützen Sie Verträge und genehmigte Tests vor Implementierungsarbeitern.
Führen Sie schwierige Pilot-Einheiten durch, bevor Sie das gesamte Repository ausrollen.
Isolieren Sie Autoren und schränken Sie destruktive Git- und Netzwerkoperationen ein.
Verlangen Sie atomare Commits mit Befehlen, Ausgaben und Vertragsreferenzen.
Nutzen Sie gegnerische Prüfer mit frischem Kontext für risikoreiche Einheiten.
Führen Sie Compiler-, Unit-, Vertrags-, Integrations- und plattformübergreifende Kontrollen durch.
Vergleichen Sie alte und neue Implementierungen anhand repräsentativer Korpora.
Fügen Sie metamorphe, Fuzz-, Sanitizer- und Leistungsprüfungen hinzu.
Erfassen Sie Grenzen von unsafe, FFI, Authentifizierung, Parser und Persistenz.
Bewahren Sie ein reproduzierbares Rollback-Artefakt auf und führen Sie eine Rollback-Übung durch.
Rollen Sie durch Schatten- und Canary-Phasen mit automatischen Stoppschwellen aus.
Wandeln Sie jeden entkommenen Fehler in eine Vertrags- oder Verifikationsverbesserung um.
Messen Sie verifizierte Einheiten, Abweichungen, menschliche Aufmerksamkeit, Kosten und Wartbarkeit.

FAQ

Was hat Bun in Rust neu geschrieben?

Bun hat eine große Implementierung, die zuvor in Zig geschrieben war, nach Rust migriert. Der veröffentlichte Bericht beschreibt etwa 780.000 Zeilen Rust und einen stark parallelen, KI-gestützten Arbeitsablauf, gefolgt von umfangreichen Tests, Sicherheitsüberprüfungen, Fuzzing und Produktionshärtung.

Hat die KI Buns Rust-Neuschreibung ohne menschliche Überprüfung abgeschlossen?

Nein. Von Menschen erstellte Migrationsregeln, manuelle Artefaktprüfung, isolierte Arbeitsabläufe, Compiler-Feedback, unabhängige Agentenprüfer, Sicherheitsüberprüfung, Fuzzing und Produktions-Rollout-Kontrollen spielten alle wichtige Rollen. Der Fall ist besser als KI-beschleunigtes Engineering zu verstehen denn als unbeaufsichtigte Code-Konvertierung.

Warum sind vorhandene Tests für eine

Sprachmigration?

Bestehende Tests decken in der Regel nur einen Teil des beobachteten Verhaltens ab. Sie können release-spezifische Semantiken, Plattformunterschiede, Performance-Einbrüche, unsichere Grenzen, Telemetrieänderungen oder Randfälle übersehen, die nie in der Testsuite kodiert wurden.

Was ist differentielles Testen bei einer Codemigration?

Differentielles Testen führt die alte und neue Implementierung mit denselben Eingaben aus und vergleicht ihre beobachtbaren Ausgaben und Seiteneffekte. Es ist besonders nützlich, wenn das alte System als vertrauenswürdig gilt, aber keine vollständige formale Spezifikation existiert.

Warum sollten Implementierungs- und Überprüfungsagenten separate Kontexte verwenden?

Ein frischer Prüfer übernimmt seltener die Annahmen und Denkfehler des Autoren-Agenten. Der Prüfer kann sich auf den Vertrag, den Diff, die Beweise und Gegenbeispiele konzentrieren, anstatt den Implementierungsweg zu verteidigen, der die Änderung hervorgebracht hat.

Wie sollten Teams unsicheren (`unsafe`) Rust-Code während der Migration überprüfen?

Jeder unsafe-Block oder jede FFI-Grenze sollte einen benannten Eigentümer, dokumentierte Invarianten, gezielte Tests und eine klare Erklärung der Zeigergültigkeit, Lebensdauer und Thread-Eigentümerschaft haben. Statische Analyse, Sanitizer, Fuzzing, Abhängigkeitsüberprüfung und manuelle Sicherheitsüberprüfung sollten getrennt von der gewöhnlichen Code-Überprüfung durchgeführt werden.

Welche Metriken sollte eine KI-gestützte Migration verfolgen?

Verfolgen Sie verifizierten Unit-Durchsatz, Abweichungsabschluss, entkommene Fehler, menschliche Aufmerksamkeit, Rechenkosten, Einführungszustand und Wartbarkeit nach der Migration. Generierte Zeilen und die Anzahl der Agenten sind Kapazitätsmetriken, kein Nachweis für Korrektheit.

Kann ein kleines Team dieses Handbuch nutzen, ohne Dutzende von Agenten auszuführen?

Ja. Beginnen Sie mit einer begrenzten Komponente, einem schriftlichen Verhaltensvertrag, drei risikoorientierten Pilotprojekten, separaten Implementierungs- und Überprüfungskontexten, deterministischen CI-Gates und einem getesteten Rollback-Pfad. Skalieren Sie den Workflow erst, nachdem er wiederholt überprüfbare Ergebnisse liefert.

Zusammenfassung

Die Rust-Neufassung von Bun zeigt, dass KI-Codierungsagenten die Implementierungszeit drastisch verkürzen können, aber sie zeigt auch, warum die Verifikation zu einem erstklassigen Engineeringsystem werden muss. Verträge, semantische Karten, isolierte Arbeiter, unabhängige Reviews, differentielle Tests, Fuzzing, Leistungsbudgets und gestaffelte Einführungen sind das, was generierten Code in glaubwürdige Migrationsnachweise verwandelt.

Die praktische Lehre ist nicht, die Anzahl der Agenten oder Codezeilen zu kopieren. Es geht darum, eine Migration in begrenzte Behauptungen zu unterteilen, für jede Behauptung einen deterministischen Nachweis zu verlangen und die Autonomie erst dann zu erweitern, wenn der Workflow wiederholt zuverlässige Ergebnisse liefert.

Eine große KI-gestützte Neufassung ist erst dann abgeschlossen, wenn das neue System verifiziert, betriebsfähig, wiederherstellbar und verstanden ist – nicht, wenn der generierte Code zusammengeführt wurde.