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/fr/articles/bun-s-ai-powered-rust-rewrite.md.
Un manuel de validation inspiré par la pratique assistée par IA de Bun lors de sa migration de Zig vers Rust, couvrant les contrats comporte...
Le titre est difficile à ignorer : Bun aurait migré en 11 jours une implémentation majeure de Zig vers Rust en utilisant un workflow dynamique Claude Code. Les récits publiés décrivent des milliers de commits, jusqu'à 64 agents Claude, environ 780 000 lignes de Rust, deux relecteurs adversaires pour chaque unité d'implémentation, et une progression allant d'un code qui ne compilait pas à un port capable de passer la suite de tests et d'être livré.
La mauvaise leçon est que les réécritures de langage sont devenues des tâches en un clic. La leçon utile est que le débit d'implémentation et le débit de vérification sont désormais des problèmes d'ingénierie distincts.
Les agents IA peuvent générer du code plus rapidement qu'une équipe humaine ne peut le lire. Une fois cela arrivé, la revue de pull request conventionnelle ne peut plus servir de mécanisme de sécurité principal. Les équipes ont besoin d'un système qui convertit un changement probabiliste massif en petites affirmations étayées par des preuves vérifiables par machine.
Le rapport de production ultérieur de Bun a rendu cela exceptionnellement concret. L'équipe a signalé 19 régressions connues, toutes corrigées par la suite ; 11 cycles de révision de sécurité ; du fuzzing continu guidé par couverture sur les parseurs ; et environ 27 000 lignes de Rust dans des blocs unsafe sur un total d'environ 780 000 lignes. Ces faits n'affaiblissent pas l'histoire de la migration. Ils montrent à quoi ressemble un travail de migration sérieux une fois la démo impressionnante terminée.
Ce guide transforme cette expérience en un manuel de vérification réutilisable. L'objectif n'est pas de copier l'échelle de Bun. Il s'agit de fournir une méthode pour toute migration — ports de langage, remplacements de framework, modernisation d'API, conversions de bases de données, ou refontes à l'échelle du dépôt — où les agents de codage IA peuvent écrire plus de code que l'équipe ne peut en inspecter de manière responsable ligne par ligne.
Le récit d'ingénierie a commencé avant la génération de code à grande échelle.
Jarred Sumner aurait passé environ trois heures à créer PORTING.md, qui cartographiait les motifs Zig récurrents vers Rust. Un workflow séparé a analysé les champs de structure, proposé des durées de vie Rust, envoyé ces choix à deux relecteurs adversaires, et sérialisé les résultats dans LIFETIMES.tsv. Ces artefacts ont également été examinés manuellement.
La première
L'essai pilote a porté sur trois fichiers, et non sur l'ensemble du dépôt. Pour chaque fichier :
Ce n'est qu'après ce pilote que le travail s'est étendu à 1 448 fichiers Zig.
Le premier déploiement à grande échelle a échoué. Les agents partageaient un espace de travail et utilisaient des commandes telles que git stash, git stash pop et git reset --hard. Leurs modifications interféraient les unes avec les autres. Le flux de travail a ensuite été modifié pour interdire les commandes de coordination risquées et utiliser quatre répertoires de travail, chacun contenant 16 agents.
Ce détail importe plus que le taux de génération de lignes maximal. La programmation parallèle est un problème de systèmes distribués. L'état partagé, les conflits d'écriture, les opérations globales coûteuses, la propriété et la récupération nécessitent tous des règles explicites.
Le code généré n'a pas fonctionné immédiatement. Bun a utilisé les erreurs du compilateur comme file d'attente et a progressé d'une crate à la fois. À un moment donné, environ 16 000 erreurs du compilateur ont été attribuées aux agents. La boucle utilisait un correcteur, deux réviseurs et un agent d'application, tout en limitant la fréquence des commandes coûteuses telles que cargo check et les opérations Git.
Il ne s'agissait pas d'une traduction magique. C'était une convergence par étapes, pilotée par un retour d'information déterministe.
L'annonce du flux de travail dynamique d'Anthropic indiquait que 99,8 % de la suite existante réussissait au moment de la rédaction initiale, tout en précisant explicitement que le port n'était pas encore en production. L'article ultérieur de Bun couvrait le travail qui a suivi : audits de sécurité, fuzzing, régressions en production, corrections sémantiques et réduction du code non sécurisé.
Lus ensemble, les sources décrivent deux jalons différents :
Ces définitions sont importantes car une équipe ne peut pas vérifier une migration tant qu'elle ne s'est pas mise d'accord sur ce que les preuves doivent démontrer. Elles séparent également la déclaration de confiance d'un agent d'un résultat vérifiable de manière externe.
Un port réimplémente un logiciel dans un nouveau langage, environnement d'exécution, plateforme ou cadre, tout en préservant un ensemble défini de comportements.
« Préserver le comportement » nécessite une limite. Un port peut préserver les API publiques et les sorties tout en modifiant intentionnellement l'architecture interne, les caractéristiques de performance, les messages d'erreur ou les cas limites non pris en charge.
Un contrat de comportement est une liste explicite de propriétés que la nouvelle implémentation doit préserver.
Il peut inclure :
Le code existant contient un comportement, mais tous les comportements existants ne sont pas intentionnels. Le contrat sépare les exigences des accidents historiques.
Un oracle de test détermine si une sortie est correcte.
Une assertion de test unitaire est un oracle. Une implémentation de référence, une spécification de protocole, un fichier de référence, un invariant de base de données ou une règle rédigée par un humain peuvent également servir d'oracle.
Les conseils d'Anthropic sur les
Le codage scientifique souligne que le travail autonome nécessite des références, des objectifs mesurables ou des suites de tests afin que les agents puissent déterminer s'ils progressent.
Les tests différentiels envoient les mêmes entrées aux implémentations ancienne et nouvelle, puis comparent les résultats observables.
Cette méthode est particulièrement utile lorsque l'implémentation ancienne est fiable mais qu'aucune spécification formelle complète n'existe. Un accord ne prouve pas que les deux implémentations sont correctes, mais un désaccord crée une file d'attente d'investigation précise.
Les tests métamorphiques vérifient les relations entre plusieurs exécutions lorsqu'il est difficile d'écrire des résultats attendus exacts.
Les exemples incluent :
La surface non sécurisée est le code où les garanties normales du langage cible sont affaiblies ou contournées.
En Rust, unsafe peut être nécessaire aux interfaces FFI avec C ou C++, à l'intérieur d'allocateurs personnalisés, ou pour l'intégration d'exécution de bas niveau. Le nombre brut n'est pas un verdict. L'équipe a besoin de propriété, d'invariants, de tests et d'un plan explicite pour chaque frontière non sécurisée.
Un défaut échappé est un bogue induit par la migration découvert après le point de contrôle qui aurait dû le détecter — après la fusion, le déploiement progressif, les tests de version candidate ou le déploiement en production.
Les défauts échappés sont un retour d'information sur le système de vérification, pas seulement sur l'implémentation.
Le parallélisme des agents change l'économie de l'implémentation. Si 64 travailleurs traduisent des fichiers en même temps, le temps de génération de code peut diminuer considérablement. Le graphe de dépendances, la sémantique du langage cible et l'environnement de test partagé ne disparaissent pas. Le débit déplace simplement le goulot d'étranglement en aval.
Des fichiers individuellement raisonnables peuvent échouer lorsqu'ils sont compilés ensemble.
Les quelque 16 000 erreurs de compilation et les dépendances cycliques de crates de Bun illustrent l'écart entre la traduction locale et la cohérence globale. Le compilateur est un excellent oracle déterministe pour les types, la propriété, les durées de vie, les noms et certaines propriétés de flux de contrôle. Il n'est pas un oracle pour le comportement du produit.
Bun a documenté des bogues où le code semblait presque identique entre les langages mais se comportait différemment.
Les exemples incluaient :
debug_assert! de Rust disparaissant dans les builds de release, tandis qu'une assertion Zig comparable évaluait toujours ses arguments.unwrap_or trop impatiente déclenchant un comportement qui aurait dû rester paresseux.Ce sont exactement les échecs qu'une revue superficielle manque parce que le code traduit semble plausible.
Si le même modèle écrit et révise un changement en utilisant le même contexte et les mêmes hypothèses, il peut reproduire les
Erreur originale.
La documentation des meilleures pratiques de Claude Code d'Anthropic recommande d'utiliser un contexte d'évaluation frais. L'évaluateur voit la différence et la norme sans hériter du raisonnement de l'auteur. L'indépendance ne garantit pas l'exactitude, mais elle réduit le biais de contexte partagé.
Les tests peuvent réussir alors que la latence double, l'utilisation de la mémoire augmente, une cible de système d'exploitation se brise ou l'observabilité disparaît.
Plus le changement est important, plus il est probable que l'équipe découvre une exigence violée seulement après le déploiement. C'est pourquoi un plan de migration doit inclure des canaris, un rollback, une comparaison de télémétrie et un processus qui convertit chaque défaut échappé en une nouvelle règle contractuelle ou un nouveau test.
La conclusion causale est simple :
L'IA n'élimine pas le coût de la migration. Elle déplace le coût de la frappe vers la spécification, la conception du harnais, l'examen des preuves et le contrôle du déploiement.
Une équipe qui ignore ce changement peut finir de générer du code rapidement, puis passer des mois à déterminer si la réécriture fonctionne réellement.
L'architecture comporte quatre plans.
Le plan contractuel stocke :
Les humains maintiennent ce plan, et le référentiel en versionne les modifications.
Le plan d'exécution contient des agents d'implémentation isolés.
Chaque agent reçoit :
L'agent ne peut pas modifier le contrat ni les tests globaux. Il modifie uniquement son périmètre assigné et retourne à la fois un commit et une preuve.
Le plan de vérification est indépendant de l'implémentation.
Il peut :
Les agents de vérification peuvent proposer des tests, mais l'IC déterministe décide si une passerelle est franchie.
Le plan de publication contrôle l'intégration et l'exposition en production.
Il :
We0 AI peut se situer entre ces plans en tant que couche d'orchestration et de preuve. Les équipes peuvent utiliser des tâches pour attribuer des tranches de migration, isoler les arbres de travail, attacher des contrats, collecter les résultats des tests et exiger une révision avant que le travail n'avance.
La frontière importante est que l'orchestration coordonne les preuves. Elle ne transforme pas la déclaration de succès d'un agent en autorisation de publication.
Considérez un service de paiement Python de 120 000 lignes en cours de migration vers Go. L'objectif commercial est de réduire
latence de queue et simplifier le déploiement.
Une invite dangereuse serait :
Réécrivez ce service en Go et faites passer tous les tests.
Cette invite laisse indéfinies la sémantique de transaction, le comportement des erreurs, la précision monétaire, l'idempotence et le déploiement.
Pour chaque point de terminaison, l'équipe enregistre :
Elle marque également les changements intentionnels, comme la suppression d'un en-tête de débogage spécifique à Python. L'équipe définit la plateforme prise en charge et la matrice de dépendances, puis fixe des budgets de latence p95 et p99 ainsi qu'un plafond de mémoire maximale.
L'équipe sélectionne :
Le premier teste la traduction mécanique. Le second teste les transactions et la concurrence. Le troisième teste la compatibilité HTTP.
Un agent d'implémentation gère chaque tranche. Les nouveaux réviseurs ne reçoivent que le contrat, l'ancienne source, le diff proposé et les commandes de validation.
Un corpus nettoyé de requêtes historiques est rejoué sur les deux versions.
Les réponses sont normalisées uniquement là où le contrat autorise des différences, puis comparées. Pour les chemins d'écriture, les deux implémentations s'exécutent sur des instantanés de base de données jetables. Les lignes résultantes et les événements émis sont comparés.
Des tests métamorphiques effectuent ensuite :
Avant d'activer les écritures en production, le service Go reçoit un trafic ombre avec les écritures désactivées ou redirigées vers un récepteur isolé.
L'équipe compare :
L'équipe envoie ensuite un trafic canari à 1 % provenant d'une cohorte de commerçants à faible risque.
L'expansion nécessite :
L'implémentation peut toujours avancer rapidement. La sécurité vient de la transformation de « réécrire le service » en affirmations observables.
Cet exemple montre également pourquoi l'expertise du domaine reste essentielle. Les agents peuvent traduire du code, mais les experts en paiement savent que les événements en double, les différences d'arrondi et le comportement de relance sont des exigences commerciales.
Avant qu'un agent ne modifie du code, décidez ce qui compte comme étant le même produit.
Inventaire :
Marquez chaque propriété comme l'une des suivantes :
Les inconnus ne sont pas une permission de deviner. Ils deviennent des tâches de découverte.
Exécutez l'ancien système, recherchez dans les problèmes et les journaux de modifications, inspectez les traces de production, ou demandez aux mainteneurs. L'arbre source pré-migration de Bun
reorganisation a préservé l'historique Git grâce à des commits de déplacement uniquement, faisant de la traçabilité une exigence intentionnelle plutôt qu'un dommage collatéral.
Définissez des conditions d'arrêt strictes. Arrêtez le déploiement en éventail lorsque :
L'arrêt protège le projet de l'escalade des coûts irrécupérables.
Le contrat doit être contrôlé séparément de l'exécution. Un agent ne doit pas « corriger » un test défaillant en affaiblissant l'exigence. Les modifications du contrat nécessitent un amendement examiné par un humain expliquant pourquoi l'ancien comportement est obsolète ou incorrect.
Créez des correspondances explicites pour les modèles source-cible courants, subtils ou dangereux.
Couvrez des domaines tels que :
Le PORTING.md et le LIFETIMES.tsv de Bun ont servi à cet effet.
Leur valeur ne se limitait pas à de meilleures invites. Ils ont donné à des centaines de travailleurs une stratégie sémantique commune. Sans une telle carte, chaque agent invente sa propre approche de traduction, et l'incohérence devient un problème d'intégration.
Demandez à des agents indépendants d'attaquer la carte :
Les humains doivent inspecter les règles les plus risquées, en particulier celles impliquant la possession de mémoire, la concurrence, les limites de sécurité, la persistance et le comportement uniquement en version.
Versionnez la carte. Chaque nouveau désalignement découvert doit mettre à jour les règles, identifier les unités de migration affectées et déclencher une revalidation ciblée.
La carte sémantique est une spécification vivante, pas une invite collée une fois au début.
Ne choisissez pas uniquement les fichiers les plus faciles.
Un pilote utile comprend trois formes :
Bun a utilisé trois fichiers pour valider la boucle implémenter-examiner-corriger avant de traduire 1 448 fichiers. Le nombre exact importe moins que l'éventail des modes de défaillance couverts.
Mesurez le processus du pilote, pas seulement son résultat :
Introduisez délibérément des défauts. Ajoutez une différence subtile de mode version, un montage de cas limite ou un seuil de performance et confirmez que le système de vérification le détecte.
Un harnais qui n'a passé que des exemples propres n'a pas encore été testé.
Le déploiement en éventail ne devrait commencer que lorsque le pilote produit des preuves stables et reproductibles. Si les invites, les modèles ou les politiques d'outils changent ensuite substantiellement, relancez le petit pilote. Workflow
la configuration est du code de production et mérite des tests de régression.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
Créez des unités de migration alignées sur le graphe de dépendances.
Le partitionnement au niveau des fichiers est pratique, mais peut constituer une mauvaise frontière lorsque le comportement traverse les modules. Attribuez un rédacteur à chaque unité et rendez la propriété lisible par machine. Les travailleurs peuvent lire les dépendances mais ne peuvent modifier que leur périmètre, sauf s'ils demandent une modification coordonnée.
Utilisez des arbres de travail séparés, des conteneurs ou des machines virtuelles éphémères lorsque c'est possible.
L'échec de l'espace de travail partagé de Bun montre pourquoi. Restreignez les commandes Git destructrices et les commandes de construction globales coûteuses pour les travailleurs feuilles. Laissez un coordinateur effectuer l'intégration ordonnée.
Des identifiants à courte durée de vie et des listes d'autorisation réseau réduisent l'impact de l'injection de prompt ou de l'exfiltration de dépendances. Les recommandations d'isolement d'Anthropic décrivent les limites du système de fichiers et du réseau comme des fondations pour une autonomie plus sûre.
Chaque unité acceptée doit produire un commit atomique contenant :
Git devient à la fois un mécanisme de coordination et de récupération.
Les recommandations d'Anthropic pour les workflows de longue durée préconisent des commits significatifs et des tests avant chaque commit, car un historique récupérable empêche une longue exécution d'agent de devenir un artefact opaque.
N'optimisez pas pour les lignes par minute. Optimisez pour les unités vérifiées par heure.
Un débit de génération élevé combiné à une file d'intégration croissante est un progrès négatif.
La sortie du compilateur crée un travail structuré.
Regroupez les erreurs par unité de propriété ou couche de dépendance, supprimez les cascades de doublons et corrigez les causes profondes avant les symptômes superficiels.
Interdisez les raccourcis, sauf si le contrat les autorise explicitement, y compris :
allow largesExécutez les tests en cercles élargis :
Conservez la sortie des échecs comme artefact. Une exécution finale verte sans historique peut cacher si les travailleurs ont affaibli à plusieurs reprises les vérifications en cours de route.
Lorsque c'est possible, séparez la rédaction des tests de l'implémentation.
Un agent peut dériver des cas limites du contrat et de l'ancienne implémentation, tandis qu'un autre écrit le port. Verrouillez les tests de compatibilité approuvés afin que les travailleurs d'implémentation ne puissent pas les modifier. Les nouveaux relecteurs doivent se demander si le code réussit pour la raison prévue.
Les régressions de production de Bun démontrent l'écart entre une suite verte et l'exhaustivité sémantique.
Une défaillance HMR uniquement en release provenait d'un effet secondaire dans debug_assert!. Un crash UTF-16 de longueur impaire reflétait un comportement de découpage différent. Chaque défaut échappé doit devenir à la fois un test de régression permanent et une nouvelle règle de carte sémantique.
Exécutez les anciennes et nouvelles implémentations contre le même corpus.
Comparez :
Codes de sortie
Sorties normalisées
Catégories d’erreurs
Effets secondaires
État de la base de données
Événements émis
Traces
Construire des générateurs de valeurs limites pour :
Fuzzer en continu les parseurs et les frontières des protocoles.
Bun a rapporté que ses fuzzers guidés par couverture ont exécuté le code des parseurs environ 100 milliards de fois et généré environ 15 demandes de correctifs. Le nombre absolu dépend de la charge de travail. Le schéma transférable consiste à relier la découverte de plantages à des tests reproductibles, des correctifs proposés par des agents et des demandes de tirage examinées par des humains.
Lorsque les utilisateurs dépendent de la performance, la performance fait partie du comportement.
Benchmark :
Comparer les distributions plutôt que les moyennes. Fixer des budgets avant la migration afin que l’équipe ne puisse pas justifier des régressions après avoir fortement investi dans la réécriture.
Effectuer également des tests de longue durée. Les fuites mémoire, les fuites de descripteurs, la croissance des files d’attente, la fragmentation de l’allocateur et les compétitions rares peuvent nécessiter des heures ou des jours pour apparaître.
Un langage offrant des garanties plus solides en matière de sécurité mémoire peut éliminer des classes entières de bogues tout en introduisant des comportements différents en matière d’allocation, d’ordonnancement ou de performance.
Traiter chacun des éléments suivants comme une classe d’examen distincte :
unsafeAu moment du rapport source, Bun a décrit environ 27 000 lignes dans des blocs unsafe sur environ 780 000 lignes de Rust, dont une grande partie liée à l’intégration avec le C et le C++.
Cette surface nécessite plus qu’une simple revue de code ordinaire.
Exiger un commentaire d’invariant près de chaque frontière non sécurisée :
Regrouper les motifs unsafe répétés derrière des wrappers révisés. Suivre les lignes et blocs unsafe par propriétaire plutôt que de considérer le total comme une métrique de vanité.
Utiliser :
Les 11 cycles de revue de sécurité de Bun sont la preuve d’un durcissement continu, et non l’absence de défauts.
La revue automatisée de sécurité doit compléter la revue de domaine, en particulier autour de l’authentification, de l’évasion de bac à sable, des secrets et des changements dans la chaîne d’approvisionnement.
Examiner le mécanisme de migration lui-même. Les agents exécutent le contenu du dépôt, les scripts de construction et les sorties d’outils. Une dépendance compromise ou une instruction cachée dans le code source peut influencer l’exécution.
L’isolation du système de fichiers, les restrictions réseau, les jetons limités et les vérifications CI immuables réduisent ce risque.
La fusion n’est pas la publication.
Construire des artefacts versionnés à partir de commits connus, d’ensembles d’outils, de verrous de dépendances et de manifestes de preuves. Garder l’ancienne implémentation constructible.
Si les anciens et nouveaux binaires peuvent coexister, ajouter un commutateur d’exécution ou une couche de routage.
plutôt que de remplacer définitivement le chemin.
Commencez par une exécution en mode shadow lorsque les effets de bord peuvent être isolés.
Procédez ensuite par canari en utilisant :
Définissez des seuils de rollback automatique pour :
Les humains doivent conserver la capacité d’interrompre l’expansion même lorsque les seuils automatisés ne sont pas atteints.
Pratiquez le rollback.
Confirmez que :
Une documentation de rollback qui n’a jamais été exécutée n’est qu’une hypothèse.
Après chaque défaut échappé, mettez à jour le contrat, le plan sémantique, le corpus de tests et le modèle de risques.
Les 19 régressions connues de Bun sont utiles car elles exposent des risques de traduction récurrents. Une migration est achevée lorsque la nouvelle implémentation est opérationnelle et que l’équipe en a tiré des enseignements — pas lorsque le diff généré est fusionné.
Le YAML suivant est conçu comme un artefact d’équipe réutilisable. Adaptez les commandes, les seuils et les responsables au dépôt.
We0 AI ou un autre système d’orchestration peut attacher cette politique aux tâches de migration et exiger le manifeste de preuve avant la revue.
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
Cette politique empêche délibérément les travailleurs d’implémentation de modifier le contrat ou les tests de contrat approuvés.
Elle exige :
limites de performance
Des exceptions sont possibles, mais elles doivent être documentées et approuvées, non cachées dans une invite.
Les lignes de code, le nombre d'agents et les jours écoulés sont des métriques de capacité intéressantes. Elles ne mesurent pas le succès du produit.
Utilisez un tableau de bord de migration équilibré.
Suivez les unités de migration qui :
Mesurez les unités acceptées par unité de temps.
Suivez les différences découvertes et déterminez si chacune est :
Suivez les défauts qui passent une barrière qui aurait dû les attraper.
Chaque défaut échappé doit identifier une règle contractuelle, un test, un oracle, une étape de révision ou un seuil de déploiement manquant.
Mesurez le temps que les humains consacrent à :
L'IA peut réduire le temps de mise en œuvre tout en améliorant la qualité des spécifications. C'est un bon compromis, pas un échec d'automatisation.
Mesurez le coût total du modèle, du calcul et de l'outillage par unité acceptée.
Les workflows dynamiques peuvent consommer plus de jetons que les sessions ordinaires. Le parallélisme est justifié lorsqu'il réduit le temps d'attente pour un travail à haute valeur sans créer un arriéré de vérification plus important.
Suivez :
Un portage qui est livré rapidement mais reste opaque pour l'équipe a déplacé la dette plutôt que de l'éliminer.
Choisissez une migration délimitée avec une implémentation de référence fonctionnelle, telle que :
Rédigez un contrat de comportement d'une page et trois cas pilotes axés sur les risques.
Utilisez des tâches d'agent distinctes pour l'implémentation et la révision afin que leurs contextes restent indépendants.
Avant l'implémentation :
Conservez un enregistrement complet :
Cet enregistrement permet à l'équipe de comparer les versions de l'outillage et d'enquêter sur les défauts sans deviner ce que l'agent a vu.
Utilisez une règle d'adoption simple :
L'autonomie doit être gagnée.
Un workflow qui produit de manière répétée des unités vérifiées peut recevoir une portée de fichier plus large ou un temps d'exécution non supervisé plus long. Il ne reçoit pas automatiquement la permission de déploiement.
La capacité, la preuve et l'autorité restent séparées.
Bun est un projet inhabituel.
Son créateur a dirigé le
migration, had deep knowledge of the codebase, and held direct architectural authority. The old implementation had a large test suite, Rust provided strong compiler feedback, and the project could use substantial parallel compute.
Most teams will not share all of those advantages.
The case was also presented through Anthropic, and the source article says the work used a prerelease Claude Fable 5 model. It is valuable primary evidence, but it is not an independent vendor comparison.
Claims about how long a human team would have needed are counterfactual estimates. Teams should not make procurement decisions from one successful migration.
The 19 reported regressions are known regressions, not a guarantee of the complete count. Fuzzing executions and security-review rounds measure effort, not the absence of defects.
The strongest defensible conclusion is modest:
Large AI-driven migrations are feasible when paired with strong deterministic feedback and expert orchestration, but their risk remains an engineering problem after code generation is complete.
That conclusion is still meaningful. Teams can attempt modernization projects that were previously delayed by cost, provided they budget for specification, verification, and controlled rollout at the same scale as implementation.
unsafe, FFI, authentication, parser, and persistence boundaries.Bun migrated a major implementation that had previously been written in Zig into Rust. The published account describes roughly 780,000 lines of Rust and a highly parallel AI-assisted workflow, followed by extensive testing, security review, fuzzing, and production hardening.
No. Human-authored migration rules, manual artifact review, isolated workflows, compiler feedback, independent agent reviewers, security review, fuzzing, and production rollout controls all played important roles. The case is better understood as AI-accelerated engineering than unattended code conversion.
migration de langage ?
Les tests existants ne couvrent généralement qu'une partie du comportement observé. Ils peuvent omettre des sémantiques propres à la version finale, des différences de plateforme, des régressions de performance, des limites liées à la sécurité, des changements de télémétrie ou des cas limites qui n'ont jamais été encodés dans la suite de tests.
Le test différentiel exécute les implémentations ancienne et nouvelle avec les mêmes entrées et compare leurs sorties observables ainsi que leurs effets secondaires. Il est particulièrement utile lorsque l'ancien système est fiable mais qu'aucune spécification formelle complète n'existe.
Un relecteur novice est moins susceptible d'hériter des hypothèses et des erreurs de raisonnement de l'agent auteur. Le relecteur peut se concentrer sur le contrat, le diff, les preuves et les contre-exemples, plutôt que de défendre le chemin d'implémentation qui a produit le changement.
unsafe lors d'une migration ?Chaque bloc unsafe ou interface FFI doit avoir un propriétaire désigné, des invariants documentés, des tests ciblés, et une explication claire de la validité des pointeurs, de leur durée de vie et de la propriété des threads. L'analyse statique, les sanitizers, le fuzzing, la revue des dépendances et la revue manuelle de sécurité doivent être appliqués séparément de la relecture de code ordinaire.
Suivez le débit unitaire vérifié, le rapprochement des divergences, les défauts échappés, l'attention humaine, le coût de calcul, la santé du déploiement et la maintenabilité après migration. Les lignes générées et le nombre d'agents sont des indicateurs de capacité, non une preuve de correction.
Oui. Commencez par un composant délimité, un contrat de comportement écrit, trois projets pilotes axés sur les risques, des contextes d'implémentation et de relecture distincts, des barrières CI déterministes et un chemin de retour arrière testé. Ne passez à l'échelle du flux de travail qu'après avoir produit des résultats vérifiables de manière répétée.
unsafe explicites.com/blog/introducing-dynamic-workflows-in-claude-code) : Description par Anthropic du flux de travail multi-agent utilisé lors de la migration de Bun.
La réécriture de Bun en Rust démontre que les agents de codage IA peuvent considérablement compresser le temps d'implémentation, mais elle montre aussi pourquoi la vérification doit devenir un système d'ingénierie de premier ordre. Les contrats, les cartes sémantiques, les workers isolés, l'examen indépendant, les tests différentiels, le fuzzing, les budgets de performance et le déploiement progressif sont ce qui transforme le code généré en preuve de migration crédible.
La leçon pratique ne consiste pas à copier le nombre d'agents ou de lignes de code. Il s'agit de décomposer une migration en assertions bornées, d'exiger une preuve déterministe pour chaque assertion, et d'étendre l'autonomie uniquement après que le workflow a produit des résultats fiables de manière répétée.
Une réécriture assistée par IA de grande envergure n'est complète que lorsque le nouveau système est vérifié, opérable, récupérable et compris—et non lorsque le code généré a été fusionné.
Partez d’une phrase et obtenez un site complet en quelques minutes.
