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/pt/articles/bun-s-ai-powered-rust-rewrite.md.
Um manual de verificação inspirado na prática assistida por IA do Bun ao migrar de Zig para Rust, abrangendo contratos comportamentais, agen...
A manchete é difícil de ignorar: a Bun supostamente migrou uma implementação importante de Zig para Rust em 11 dias usando um fluxo de trabalho dinâmico com Claude Code. Os relatos publicados descrevem milhares de commits, até 64 agentes Claude, aproximadamente 780.000 linhas de Rust, dois revisores adversariais para cada unidade de implementação, e uma progressão de código que não compilava para uma versão que passou na suíte de testes e foi lançada.
A lição errada é que reescritas de linguagem se tornaram tarefas de um clique. A lição útil é que a produtividade de implementação e a produtividade de verificação são agora problemas de engenharia separados.
Agentes de IA podem gerar código mais rápido do que uma equipe humana consegue lê-lo. Quando isso acontece, a revisão convencional de pull requests não pode mais servir como o principal mecanismo de segurança. As equipes precisam de um sistema que converta uma mudança probabilística massiva em pequenas alegações apoiadas por evidências verificáveis por máquina.
O relatório de produção posterior da Bun tornou isso excepcionalmente concreto. A equipe relatou 19 regressões conhecidas, todas posteriormente corrigidas; 11 rodadas de revisão de segurança; fuzzing contínuo guiado por cobertura em analisadores sintáticos; e cerca de 27.000 linhas de Rust dentro de blocos unsafe em aproximadamente 780.000 linhas no total. Esses fatos não enfraquecem a história da migração. Eles mostram como é o trabalho de migração sério após a demonstração impressionante terminar.
Este guia transforma essa experiência em um manual de verificação reutilizável. O objetivo não é copiar a escala da Bun. É fornecer um método para qualquer migração—portabilidade de linguagens, substituições de frameworks, modernização de APIs, conversões de bancos de dados ou refatorações em todo o repositório—onde agentes de IA de codificação podem escrever mais código do que a equipe pode inspecionar linha por linha de forma responsável.
O relato de engenharia começou antes da geração de código em larga escala.
Jarred Sumner supostamente passou cerca de três horas criando PORTING.md, que mapeava padrões recorrentes de Zig para Rust. Um fluxo de trabalho separado analisou campos de estrutura, propôs tempos de vida (lifetimes) do Rust, enviou essas escolhas para dois revisores adversariais e serializou os resultados em LIFETIMES.tsv. Esses artefatos também foram revisados manualmente.
O primeiro
O ensaio de implementação abrangeu três arquivos, não todo o repositório. Para cada arquivo:
Somente após esse piloto o trabalho se expandiu para 1.448 arquivos Zig.
A primeira execução em larga escala falhou. Os agentes compartilhavam um espaço de trabalho e usavam comandos como git stash, git stash pop e git reset --hard. Suas alterações interferiam umas nas outras. O fluxo de trabalho foi então alterado para proibir comandos de coordenação inseguros e usar quatro árvores de trabalho, cada uma com 16 agentes.
Esse detalhe é mais importante do que a taxa máxima de geração de linhas. A codificação paralela é um problema de sistemas distribuídos. Estado compartilhado, escritores conflitantes, operações globais caras, propriedade e recuperação precisam de regras explícitas.
O código gerado não funcionou imediatamente. O Bun usou erros do compilador como uma fila e avançou uma crate de cada vez. Em um ponto, cerca de 16.000 erros do compilador foram atribuídos aos agentes. O loop usou um corretor, dois revisores e um agente de aplicação, ao mesmo tempo que limitava a frequência com que comandos caros como cargo check e operações Git podiam ser executados.
Esta não foi uma tradução mágica. Foi uma convergência em etapas impulsionada por feedback determinístico.
O anúncio do fluxo de trabalho dinâmico da Anthropic relatou que 99,8% do conjunto de testes existente passou no momento da redação inicial, enquanto observava explicitamente que a portabilidade ainda não estava em produção. O artigo posterior do Bun cobriu o trabalho que se seguiu: revisões de segurança, fuzzing, regressões de produção, correções semânticas e redução de código inseguro.
Lidos em conjunto, as fontes descrevem dois marcos diferentes:
Essas definições são importantes porque uma equipe não pode verificar uma migração até concordar sobre o que as evidências devem provar. Elas também separam a declaração de confiança de um agente de um resultado verificável externamente.
Uma portabilidade reimplementa software em uma nova linguagem, tempo de execução, plataforma ou estrutura, preservando um conjunto definido de comportamentos.
"Preservar comportamento" precisa de um limite. Uma portabilidade pode preservar APIs e saídas públicas enquanto altera intencionalmente a arquitetura interna, as características de desempenho, as mensagens de erro ou os casos extremos não suportados.
Um contrato de comportamento é uma lista explícita de propriedades que a nova implementação deve preservar.
Pode incluir:
O código existente contém comportamento, mas nem todo comportamento existente é intencional. O contrato separa os requisitos de acidentes históricos.
Um oráculo de teste determina se uma saída está correta.
Uma asserção de teste unitário é um oráculo. Uma implementação de referência, especificação de protocolo, arquivo dourado, invariante de banco de dados ou regra elaborada por humanos também pode atuar como um oráculo.
A orientação da Anthropic sobre execução de longa duração
A codificação científica enfatiza que o trabalho autônomo precisa de referências, metas mensuráveis ou suítes de teste para que os agentes possam determinar se estão progredindo.
O teste diferencial envia as mesmas entradas para as implementações antiga e nova e, em seguida, compara os resultados observáveis.
É especialmente útil quando a implementação antiga é confiável, mas não existe uma especificação formal completa. A concordância não prova que ambas as implementações estão corretas, mas a discordância cria uma fila de investigação precisa.
O teste metamórfico verifica relações entre múltiplas execuções quando é difícil escrever resultados esperados exatos.
Os exemplos incluem:
A superfície insegura é o código onde as garantias normais da linguagem alvo são enfraquecidas ou contornadas.
Em Rust, unsafe pode ser necessário nos limites de FFI com C ou C++, dentro de alocadores personalizados ou para integração de runtime de baixo nível. A contagem bruta não é um veredito. A equipe precisa de propriedade, invariantes, testes e um plano explícito para cada limite inseguro.
Um defeito escapado é um bug induzido pela migração descoberto após a barreira que deveria tê-lo detectado — após merge, implantação canário, teste de release-candidate ou lançamento em produção.
Defeitos escapados são feedback sobre o sistema de verificação, não apenas sobre a implementação.
O paralelismo de agentes muda a economia da implementação. Se 64 trabalhadores traduzem arquivos ao mesmo tempo, o tempo de geração de código pode diminuir drasticamente. O grafo de dependências, a semântica da linguagem alvo e o ambiente de teste compartilhado não desaparecem. A taxa de transferência simplesmente move o gargalo para downstream.
Arquivos individualmente razoáveis podem falhar quando compilados juntos.
Os cerca de 16.000 erros de compilador e dependências cíclicas de crates do Bun ilustram a lacuna entre a tradução local e a consistência global. O compilador é um oráculo determinístico excelente para tipos, propriedade, tempos de vida, nomes e algumas propriedades de fluxo de controle. Ele não é um oráculo para o comportamento do produto.
O Bun documentou bugs onde o código parecia quase idêntico entre linguagens, mas se comportava de forma diferente.
Os exemplos incluíam:
debug_assert! do Rust desaparecendo em builds de release, enquanto uma asserção Zig comparável ainda avaliava seus argumentos.unwrap_or desencadeando um comportamento que deveria ter permanecido preguiçoso.Essas são exatamente as falhas que a revisão superficial perde, porque o código traduzido parece plausível.
Se o mesmo modelo escreve e revisa uma alteração usando o mesmo contexto e suposições, ele pode reproduzir as
erro original.
A documentação de melhores práticas do Claude Code, da Anthropic, recomenda usar um contexto de revisor novo. O revisor vê a diferença e o padrão sem herdar o raciocínio do autor. A independência não garante a correção, mas reduz o viés de contexto compartilhado.
Os testes podem passar enquanto a latência dobra, o uso de memória aumenta, um destino de sistema operacional quebra ou a observabilidade desaparece.
Quanto maior a mudança, maior a probabilidade de a equipe descobrir um requisito violado somente após a implantação. É por isso que um plano de migração deve incluir canários, reversão, comparação de telemetria e um processo que converta cada defeito que escapa em uma nova regra de contrato ou teste.
A conclusão causal é simples:
A IA não elimina o custo da migração. Ela transfere o custo da digitação para a especificação, o design do harness, a revisão de evidências e o controle de implantação.
Uma equipe que ignora essa mudança pode terminar de gerar o código rapidamente e depois passar meses determinando se a reescrita realmente funciona.
A arquitetura tem quatro planos.
O plano de contrato armazena:
Humanos mantêm este plano, e o repositório o versiona.
O plano de execução contém agentes de implementação isolados.
Cada agente recebe:
O agente não pode alterar o contrato ou os testes globais. Ele edita apenas seu escopo designado e retorna tanto um commit quanto evidências.
O plano de verificação é independente da implementação.
Ele pode:
Agentes de verificação podem propor testes, mas a IC determinística decide se um portão é aprovado.
O plano de lançamento controla a integração e a exposição em produção.
Ele:
Um orquestrador de IA pode atuar entre esses planos como uma camada de orquestração e evidência. As equipes podem usar tarefas para atribuir fatias de migração, isolar árvores de trabalho, anexar contratos, coletar resultados de testes e exigir revisão antes que o trabalho prossiga.
O limite importante é que a orquestração coordena evidências. Ela não transforma a alegação de sucesso de um agente em permissão de lançamento.
Considere um serviço de pagamento em Python com 120.000 linhas sendo migrado para Go. O objetivo de negócios é reduzir
latência de cauda e simplificar a implantação.
Um prompt perigoso seria:
Reescreva este serviço em Go e faça todos os testes passarem.
Esse prompt deixa indefinidas as semânticas de transação, comportamento de erro, precisão monetária, idempotência e implantação gradual.
Para cada endpoint, a equipe registra:
Também marca alterações intencionais, como a remoção de um cabeçalho de depuração específico do Python. A equipe define a plataforma suportada e a matriz de dependências, depois estabelece orçamentos de latência p95 e p99 e um teto de pico de memória.
A equipe seleciona:
O primeiro testa a tradução mecânica. O segundo testa transações e concorrência. O terceiro testa a compatibilidade HTTP.
Um agente de implementação cuida de cada fatia. Revisores novatos recebem apenas o contrato, o código-fonte antigo, o diff proposto e os comandos de validação.
Um corpus sanitizado de requisições históricas é reproduzido em ambas as versões.
As respostas são normalizadas apenas onde o contrato permite diferenças, depois comparadas. Para caminhos de escrita, ambas as implementações são executadas em snapshots descartáveis de banco de dados. As linhas resultantes e os eventos emitidos são comparados.
Testes metamórficos então:
Antes que as escritas em produção sejam ativadas, o serviço Go recebe tráfego de sombra com escritas desabilitadas ou redirecionadas para um coletor isolado.
A equipe compara:
A equipe então envia 1% de tráfego canário de um grupo de comerciantes de baixo risco.
A expansão requer:
A implementação ainda pode avançar rapidamente. A segurança vem de transformar "reescrever o serviço" em afirmações observáveis.
Este exemplo também mostra por que o conhecimento de domínio continua essencial. Agentes podem traduzir código, mas especialistas em pagamentos sabem que eventos duplicados, diferenças de arredondamento e comportamento de repetição são requisitos de negócio.
Antes que qualquer agente edite código, decida o que conta como o mesmo produto.
Inventário:
Marque cada propriedade como uma das seguintes:
Desconhecidos não são permissão para adivinhar. Eles se tornam tarefas de descoberta.
Execute o sistema antigo, pesquise issues e changelogs, inspecione rastros de produção ou pergunte a mantenedores. Árvore-fonte pré-migração do Bun.
reorganização preservou o histórico do Git por meio de commits apenas de movimentação, tornando a proveniência um requisito intencional, e não um dano colateral.
Defina condições de parada rigorosas. Interrompa a expansão quando:
A parada protege o projeto do aumento de custos irreversíveis.
O contrato deve ser controlado separadamente da execução. Um agente não deve "corrigir" um teste com falha enfraquecendo o requisito. Alterações no contrato exigem uma emenda revisada por humanos explicando por que o comportamento antigo está obsoleto ou incorreto.
Crie mapeamentos explícitos para padrões comuns, sutis ou perigosos de origem para destino.
Abranja áreas como:
Os arquivos PORTING.md e LIFETIMES.tsv do Bun serviram a esse propósito.
Seu valor não se limitou a prompts melhores. Eles deram a centenas de trabalhadores uma estratégia semântica compartilhada. Sem esse mapa, cada agente inventa sua própria abordagem de tradução, e a inconsistência se torna um problema de integração.
Peça a agentes independentes para atacar o mapa:
Humanos devem inspecionar as regras de maior risco, especialmente aquelas que envolvem propriedade de memória, concorrência, limites de segurança, persistência e comportamento exclusivo de versão de lançamento.
Versionar o mapa. Cada incompatibilidade recém-descoberta deve atualizar as regras, identificar unidades de migração afetadas e acionar revalidação direcionada.
O mapa semântico é uma especificação viva, não um prompt colado uma vez no início.
Não escolha apenas os arquivos mais fáceis.
Um piloto útil inclui três formas:
O Bun usou três arquivos para validar o ciclo implementar-revisar-corrigir antes de traduzir 1.448 arquivos. O número exato importa menos do que a gama de modos de falha cobertos.
Meça o processo do piloto, não apenas sua saída:
Introduza falhas deliberadamente. Adicione uma diferença sutil de modo de lançamento, um dispositivo de teste de caso extremo ou um limite de desempenho e confirme que o sistema de verificação o detecta.
Um mecanismo que passou apenas por exemplos limpos ainda não foi testado.
A expansão deve começar apenas quando o piloto produzir evidências estáveis e repetíveis. Se os prompts, modelos ou políticas de ferramentas mudarem substancialmente depois, execute novamente o pequeno piloto. Fluxo de trabalho
configuração é código de produção e merece testes de regressão.
Descreva sua ideia uma vez e o We0 AI pode gerar um site de apresentacao, paginas e CMS, alem de ajudar a atrair clientes e trafego apos o lancamento.
Uma geração completa de projetos para registro gratuito
Melhor para experimentar um fluxo de geração completo e ver rapidamente um primeiro rascunho do projeto.
Crie unidades de migração alinhadas ao grafo de dependências.
A divisão por arquivos é conveniente, mas pode ser o limite errado quando o comportamento atravessa módulos. Atribua um escritor para cada unidade e torne a propriedade legível por máquina. Os trabalhadores podem ler dependências, mas só podem editar seu próprio escopo, a menos que solicitem uma alteração coordenada.
Use worktrees separados, contêineres ou máquinas virtuais efêmeras quando for prático.
A falha do workspace compartilhado do Bun mostra por quê. Restrinja comandos Git destrutivos e comandos globais de build caros para trabalhadores folha. Deixe um coordenador realizar a integração ordenada.
Credenciais de curta duração e listas de permissão de rede reduzem o impacto de injeção de prompt ou exfiltração de dependências. As orientações de sandboxing da Anthropic descrevem limites de sistema de arquivos e rede como bases para uma autonomia mais segura.
Cada unidade aceita deve produzir um commit atômico contendo:
O Git se torna tanto um mecanismo de coordenação quanto de recuperação.
As orientações da Anthropic para fluxos de trabalho de longa duração recomendam commits significativos e testes antes de cada commit, porque um histórico recuperável impede que uma longa execução de agente se torne um artefato opaco.
Não otimize para linhas por minuto. Otimize para unidades verificadas por hora.
Alta taxa de geração combinada com uma fila de integração crescente é um progresso negativo.
A saída do compilador cria trabalho estruturado.
Agrupe erros por unidade de propriedade ou camada de dependência, remova cascatas duplicadas e corrija causas raiz antes dos sintomas folha.
Proíba atalhos a menos que o contrato os permita explicitamente, incluindo:
allow amplosExecute testes em círculos crescentes:
Mantenha a saída com falha como um artefato. Uma execução verde final sem histórico pode esconder se os trabalhadores enfraqueceram repetidamente as verificações ao longo do caminho.
Quando possível, separe a autoria do teste da implementação.
Um agente pode derivar casos extremos do contrato e da implementação antiga, enquanto outro escreve a portabilidade. Bloqueie testes de compatibilidade aprovados para que os trabalhadores de implementação não possam modificá-los. Novos revisores devem perguntar se o código passa pelo motivo pretendido.
As regressões de produção do Bun demonstram a lacuna entre uma suíte verde e a completude semântica.
Uma falha de HMR apenas em release veio de um efeito colateral dentro de debug_assert!. Uma falha de UTF-16 de comprimento ímpar refletiu um comportamento diferente de slice. Cada defeito escapado deve se tornar tanto um teste de regressão permanente quanto uma nova regra de mapa semântico.
Execute as implementações antiga e nova contra o mesmo corpus.
Compare:
Códigos de saída
Saída normalizada
Categorias de erro
Efeitos colaterais
Estado do banco de dados
Eventos emitidos
Rastreamentos
Crie geradores de valores-limite para:
Execute fuzzing contínuo em analisadores sintáticos e limites de protocolo.
O Bun relatou que seus fuzzers orientados por cobertura executaram o código do analisador cerca de 100 bilhões de vezes e geraram aproximadamente 15 pull requests de correção. O número absoluto depende da carga de trabalho. O padrão transferível é conectar a descoberta de falhas a testes reproduzíveis, correções propostas por agente e pull requests revisados por humanos.
Quando os usuários dependem de desempenho, o desempenho faz parte do comportamento.
Benchmark:
Compare distribuições em vez de médias. Defina orçamentos antes da migração para que a equipe não possa justificar regressões após investir pesadamente na reescrita.
Execute também testes de longa duração. Vazamentos de memória, vazamentos de descritores, crescimento de filas, fragmentação de alocador e condições de corrida raras podem levar horas ou dias para se manifestar.
Uma linguagem com garantias mais fortes de segurança de memória pode eliminar classes inteiras de bugs, embora ainda introduza comportamentos diferentes de alocação, escalonamento ou desempenho.
Trate cada um dos seguintes como uma classe de revisão separada:
unsafeNa época do relatório de origem, o Bun descreveu aproximadamente 27.000 linhas dentro de blocos unsafe em cerca de 780.000 linhas de Rust, grande parte relacionada à integração com C e C++.
Essa superfície requer mais do que uma revisão de código comum.
Exija um comentário invariante perto de cada limite inseguro:
Agrupe padrões inseguros repetidos atrás de wrappers revisados. Acompanhe linhas e blocos inseguros por proprietário, em vez de tratar o total como uma métrica de vaidade.
Use:
As 11 rodadas de revisão de segurança do Bun são evidências de endurecimento contínuo, não evidências de que defeitos estavam ausentes.
A revisão de segurança automatizada deve complementar a revisão de domínio, especialmente em torno de autenticação, escape de sandbox, segredos e mudanças na cadeia de suprimentos.
Revise o próprio mecanismo de migração. Agentes executam conteúdo do repositório, scripts de compilação e saída de ferramentas. Uma dependência comprometida ou instrução oculta no código-fonte pode influenciar a execução.
Isolamento do sistema de arquivos, restrições de rede, tokens com escopo e verificações imutáveis de CI reduzem esse risco.
Mesclar não é lançar.
Construa artefatos versionados a partir de commits conhecidos, cadeias de ferramentas, travas de dependências e manifestos de evidência. Mantenha a implementação antiga compilável.
Se os binários antigos e novos puderem coexistir, adicione uma chave de tempo de execução ou camada de roteamento
em vez de substituir irreversivelmente o caminho.
Comece com a execução em modo de sombra quando os efeitos colaterais puderem ser isolados.
Em seguida, faça o lançamento gradual (canary) por:
Defina limites de reversão automática para:
Os humanos devem manter a capacidade de interromper a expansão mesmo quando os limites automatizados não forem atingidos.
Pratique a reversão.
Confirme que:
Documentação de reversão que nunca foi executada é apenas uma hipótese.
Após cada defeito que escapar, atualize o contrato, o mapa semântico, o corpus de testes e o modelo de risco.
As 19 regressões conhecidas do Bun são úteis porque expõem riscos recorrentes de tradução. Uma migração está completa quando a nova implementação é operável e a equipe aprendeu com ela — não quando o diff gerado é mesclado.
O YAML a seguir foi projetado como um artefato de equipe reutilizável. Adapte comandos, limites e responsáveis ao repositório.
O We0 AI ou outro sistema de orquestração pode anexar esta política a tarefas de migração e exigir o manifesto de evidências antes da revisão.
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
Esta política impede deliberadamente que os trabalhadores da implementação editem o contrato ou os testes de contrato aprovados.
Ela exige:
Exceções são possíveis, mas devem ser documentadas e aprovadas, em vez de ocultadas dentro de um prompt.
Linhas de código, número de agentes e dias decorridos são métricas interessantes de capacidade. Elas não medem o sucesso do produto.
Use um scorecard de migração equilibrado.
Acompanhe as unidades de migração que:
Meça as unidades aceitas por unidade de tempo.
Acompanhe as diferenças descobertas e se cada uma é:
Acompanhe os defeitos que passam por uma barreira que deveria tê-los detectado.
Cada defeito que escapar deve identificar uma regra de contrato, teste, oráculo, etapa de revisão ou limite de implantação ausente.
Meça o tempo que os humanos gastam:
A IA pode reduzir o tempo de implementação enquanto aumenta a qualidade da especificação. Essa é uma boa troca, não uma falha de automação.
Meça o custo total do modelo, computação e ferramentas por unidade aceita.
Fluxos de trabalho dinâmicos podem consumir mais tokens do que sessões comuns. O paralelismo é justificado quando reduz o tempo de espera para trabalhos de alto valor sem criar um acúmulo maior de verificação.
Acompanhe:
Uma migração que é entregue rapidamente, mas permanece opaca para a equipe, transferiu a dívida em vez de removê-la.
Escolha uma migração delimitada com uma implementação de referência ativa, como:
Escreva um contrato de comportamento de uma página e três casos piloto focados em risco.
Use tarefas de agente separadas para implementação e revisão, de modo que seus contextos permaneçam independentes.
Antes da implementação:
Mantenha um registro completo da execução:
Esse registro permite que a equipe compare versões de teste e investigue defeitos sem adivinhar o que o agente viu.
Use uma regra simples de adoção:
A autonomia deve ser conquistada.
Um fluxo de trabalho que produz repetidamente unidades verificadas pode receber um escopo de arquivo mais amplo ou um tempo de execução não supervisionado maior. Ele não recebe automaticamente permissão de implantação.
Capacidade, evidência e autoridade permanecem separadas.
Bun é um projeto incomum.
Seu criador liderou o
迁移工作需要对代码库有深入了解，并拥有直接的架构权限。旧实现拥有庞大的测试套件，Rust 提供了强大的编译器反馈，并且项目可以利用大量并行计算资源。
大多数团队不会拥有所有这些优势。
该案例也是通过 Anthropic 呈现的，原始文章提到这项工作使用了预发布的 Claude Fable 5 模型。这是一个有价值的主要证据，但并非独立的供应商对比。
关于人类团队需要多长时间的说法都是反事实的估计。团队不应仅凭一次成功的迁移就做出采购决策。
报告中指出的 19 个回归是已知的回归问题，并不能保证是完整数量。模糊测试执行和安全审查轮次衡量的是工作量，而非缺陷的缺失。
最有力的合理结论是适度的：
在强大的确定性反馈和专家协调的支持下，大型 AI 驱动迁移是可行的，但其风险在代码生成完成后仍然是一个工程问题。
这个结论仍然很有意义。团队可以尝试那些因成本问题而被推迟的现代化项目，前提是他们需要为规范制定、验证和受控推广投入与实现阶段同等规模的预算。
unsafe、FFI、认证、解析器和持久性的边界。Bun 将之前用 Zig 编写的一个主要实现迁移到了 Rust。已发布的报告描述了大约 78 万行 Rust 代码以及一个高度并行的 AI 辅助工作流程，随后进行了大量测试、安全审查、模糊测试和生产环境加固。
不是。人工编写的迁移规则、手动产物审查、隔离工作流程、编译器反馈、独立的代理评审者、安全审查、模糊测试和生产推广控制都发挥了重要作用。这个案例更适合被理解为 AI 加速的工程，而非无人值守的代码转换。
Migração de linguagem?
Os testes existentes geralmente cobrem apenas parte do comportamento observado. Eles podem ignorar semânticas exclusivas de versão, diferenças entre plataformas, regressões de desempenho, limites inseguros, alterações de telemetria ou casos extremos que nunca foram codificados no conjunto de testes.
O teste diferencial executa as implementações antiga e nova com as mesmas entradas e compara suas saídas observáveis e efeitos colaterais. É particularmente útil quando o sistema antigo é confiável, mas não existe uma especificação formal completa.
Um revisor novo tem menos probabilidade de herdar as suposições e erros de raciocínio do agente autor. O revisor pode se concentrar no contrato, diff, evidências e contraexemplos, em vez de defender o caminho de implementação que produziu a alteração.
unsafe durante a migração?Cada bloco unsafe ou limite de FFI deve ter um proprietário nomeado, invariantes documentados, testes direcionados e uma explicação clara da validade do ponteiro, tempo de vida e propriedade de thread. A análise estática, sanitizers, fuzzing, revisão de dependências e revisão manual de segurança devem ser aplicados separadamente da revisão de código comum.
Acompanhe a taxa de transferência de unidades verificadas, fechamento de incompatibilidades, defeitos escapados, atenção humana, custo computacional, saúde do lançamento e capacidade de manutenção pós-migração. Linhas geradas e contagem de agentes são métricas de capacidade, não prova de correção.
Sim. Comece com um componente delimitado, um contrato de comportamento escrito, três pilotos focados em risco, contextos separados de implementação e revisão, portões de CI determinísticos e um caminho de reversão testado. Escalone o fluxo de trabalho somente depois que ele produzir resultados verificáveis repetidamente.
unsafe explícitos.com/blog/introducing-dynamic-workflows-in-claude-code): Descrição da Anthropic sobre o fluxo de trabalho multiagente utilizado durante a migração do Bun.
A reescrita do Bun em Rust demonstra que agentes de codificação de IA podem comprimir drasticamente o tempo de implementação, mas também mostra por que a verificação deve se tornar um sistema de engenharia de primeira classe. Contratos, mapas semânticos, workers isolados, revisão independente, testes diferenciais, fuzzing, orçamentos de desempenho e implantação gradual são o que transformam código gerado em evidência de migração confiável.
A lição prática não é copiar o número de agentes ou linhas de código. É dividir uma migração em afirmações delimitadas, exigir prova determinística para cada afirmação e expandir a autonomia somente após o fluxo de trabalho produzir resultados confiáveis repetidamente.
Uma grande reescrita assistida por IA só está completa quando o novo sistema é verificado, operável, recuperável e compreendido — não quando o código gerado foi mesclado.
Comece com uma frase e tenha um site completo em minutos.
