For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/de/articles/bun-s-ai-powered-rust-rewrite.md.
Ein von Buns KI-gestütztem Wechsel von Zig zu Rust inspiriertes Validierungshandbuch, das Verhaltensverträge, isolierte Codierungs-Agenten, ...
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.
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:
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:
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.
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.
Ein Verhaltensvertrag ist eine explizite Liste von Eigenschaften, die die neue Implementierung erhalten muss.
Er kann Folgendes umfassen:
Vorhandener Code enthält Verhalten, aber nicht jedes vorhandene Verhalten ist beabsichtigt. Der Vertrag trennt Anforderungen von historischen Zufälligkeiten.
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 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 prüft Beziehungen zwischen mehreren Ausführungen, wenn exakte erwartete Ausgaben schwer zu schreiben sind.
Beispiele hierfür sind:
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.
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.
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.
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.
Bun dokumentierte Fehler, bei denen Code sprachübergreifend fast identisch aussah, sich aber anders verhielt.
Beispiele umfassten:
debug_assert! platziert wurden und in Release-Builds verschwanden, während eine vergleichbare Zig-Assertion ihre Argumente noch auswertete.unwrap_or-Ausdruck, der Verhalten auslöste, das träge hätte bleiben sollen.Dies sind genau die Fehler, die oberflächliche Überprüfungen übersehen, weil der übersetzte Code plausibel aussieht.
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.
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.
Die Architektur hat vier Ebenen.
Die Vertragsebene speichert:
Menschen pflegen diese Ebene, und das Repository versioniert sie.
Die Ausführungsebene enthält isolierte Implementierungsagenten.
Jeder Agent erhält:
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.
Die Verifikationsebene ist unabhängig von der Implementierung.
Sie kann:
Verifikationsagenten können Tests vorschlagen, aber die deterministische CI entscheidet, ob ein Tor passiert wird.
Die Freigabeebene kontrolliert Integration und Produktionsexposition.
Sie:
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.
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.
Für jeden Endpunkt erfasst das Team:
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.
Das Team wählt aus:
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.
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:
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:
Das Team sendet dann 1 % Canary-Verkehr von einer Händlergruppe mit geringem Risiko.
Die Erweiterung erfordert:
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.
Bevor ein Agent Code bearbeitet, entscheiden Sie, was als dasselbe Produkt gilt.
Bestandsaufnahme:
Markieren Sie jede Eigenschaft als eine der folgenden:
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:
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.
Erstellen Sie explizite Zuordnungen für gängige, subtile oder gefährliche Quell-Ziel-Muster.
Decken Sie Bereiche ab wie:
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:
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.
Wählen Sie nicht nur die einfachsten Dateien.
Ein nützlicher Pilot umfasst drei Formen:
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:
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.
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
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:
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.
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:
allow-AttributeFühre Tests in sich erweiternden Kreisen durch:
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.
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:
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:
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.
Behandeln Sie jedes der folgenden Elemente als separate Überprüfungsklasse:
unsafe-BlöckeZum 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:
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:
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.
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:
Definieren Sie automatische Rollback-Schwellenwerte für:
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:
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.
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:
Ausnahmen sind möglich, aber sie müssen dokumentiert und genehmigt werden, anstatt in einem Prompt versteckt zu sein.
Codezeilen, Agentenanzahl und vergangene Tage sind interessante Kapazitätsmetriken. Sie messen keinen Produkterfolg.
Verwenden Sie eine ausgewogene Migrationsbewertungstafel.
Verfolgen Sie Migrationseinheiten, die:
Messen Sie akzeptierte Einheiten pro Zeiteinheit.
Verfolgen Sie entdeckte Unterschiede und ob jeder einzelne:
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.
Messen Sie die Zeit, die Menschen aufwenden für:
KI kann die Implementierungszeit reduzieren und gleichzeitig die Spezifikationsqualität erhöhen. Das ist ein guter Austausch, kein Automatisierungsfehler.
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.
Verfolgen Sie:
Eine Portierung, die schnell ausgeliefert wird, aber für das Team intransparent bleibt, hat Schulden verschoben, nicht beseitigt.
Wählen Sie eine abgegrenzte Migration mit einer live existierenden Referenzimplementierung, wie zum Beispiel:
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:
Führen Sie ein vollständiges Ausführungsprotokoll:
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.
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.
unsafe, FFI, Authentifizierung, Parser und Persistenz.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.
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.
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.
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.
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.
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.
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.
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.
unsafe-Grenzen.com/blog/introducing-dynamic-workflows-in-claude-code: Anthropics Beschreibung des Multi-Agenten-Workflows, der während der Bun-Migration verwendet wurde.
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.
Starte mit einem Satz und erhalte in wenigen Minuten eine vollständige Website.
