No passado, migrações de linguagens de programação de grande porte eram o tipo de projeto que as equipes de engenharia adiavam por anos. Ess...
No passado, migrações de linguagens de programação de grande porte eram o tipo de projeto que as equipes de engenharia adiavam por anos. Esse tipo de migração é caro, disruptivo e arriscado. Uma empresa podia passar trimestres mantendo duas implementações simultâneas, apenas para obter um substituto com comportamento inconsistente em relação ao original.
O Claude Code está mudando esse cenário.
A Anthropic divulgou recentemente seu processo de uso de agentes de IA para migrações de código em larga escala. O caso mais notável foi o de Jarred Sumner, criador do Bun, que migrou o núcleo do Bun de Zig para Rust. Em menos de duas semanas, o fluxo de trabalho do Claude Code gerou mais de um milhão de linhas de código, e o conjunto de testes existente do Bun já passava na integração contínua antes da mesclagem.
Este projeto não foi concluído simplesmente pedindo ao modelo para "reescrever o Bun em Rust" e esperando pela resposta perfeita. Ele dependeu de um sistema cuidadosamente projetado, incluindo um manual de regras, mapeamento de dependências, fila mecânica, revisores adversariais, compiladores, testes de fumaça e verificações de consistência de comportamento.
A lição central é direta: para migrações dessa escala, os desenvolvedores não devem gastar a maior parte do tempo corrigindo arquivos individuais. Eles devem melhorar o processo de geração, revisão e validação desses arquivos.
Jarred Sumner construiu inicialmente o Bun com Zig. Essa linguagem permitiu que um desenvolvedor independente obtivesse controle de baixo nível e desempenho semelhante ao C, sem enfrentar toda a complexidade do ecossistema de uma linguagem de sistemas de grande porte.
Essa escolha ajudou o Bun a crescer rapidamente no início. Sumner afirmou que escreveu a primeira versão em um pequeno apartamento em Oakland, em cerca de um ano, antes da existência de modelos de codificação modernos.
Em 2026, o Bun já era um runtime JavaScript e TypeScript, gerenciador de pacotes, executor de testes e bundler amplamente utilizado. Sua ferramenta de linha de comando recebia dezenas de milhões de downloads por mês, e produtos como o Claude Code dependiam fortemente do Bun.
O crescimento também tornou as antigas compensações de engenharia impossíveis de ignorar.
O Bun combina um motor JavaScript com coleta de lixo com memória nativa gerenciada manualmente. Em Zig, os desenvolvedores precisam raciocinar explicitamente sobre alocações, limpeza, caminhos de erro e ciclos de vida de objetos. A equipe do Bun investiu pesadamente em sanitizadores, fuzzing, compilações de verificação de segurança e testes de vazamento de memória, mas erros de uso após liberação, dupla liberação, vazamentos e erros de ciclo de vida ainda ocorriam.
O Rust oferece uma base diferente. Seu sistema de ownership, borrow checker e limpeza automática podem transformar muitos problemas de memória em tempo de execução em erros de tempo de compilação.
Historicamente, esse benefício não era suficiente para justificar uma reescrita completa. O Bun continha centenas de milhares de linhas de código Zig, além de inúmeras integrações nativas. Uma reescrita tradicional poderia consumir um ano ou mais de uma pequena equipe de engenharia, ao mesmo tempo que atrasava o desenvolvimento de funcionalidades e correções de segurança.
O Claude Code tornou viável uma migração puramente mecânica.
Sumner usou uma versão pré-lançamento do Claude Fable 5 e os fluxos de trabalho dinâmicos do Claude Code para realizar a migração.
Escrita e revisão principais
O processo foi executado continuamente por 11 dias. Cerca de 50 fluxos de trabalho dinâmicos lidaram com diferentes estágios, incluindo:
.zig para arquivos .rsNo pico de throughput, o fluxo de trabalho produzia cerca de 1300 linhas de código por minuto. Cada unidade de código gerada passava por dois revisores adversariais independentes, e um reparador aplicava as alterações confirmadas.
O pull request final adicionou mais de um milhão de linhas de código em mais de 2000 arquivos alterados.
Antes da mesclagem, o conjunto de testes existente do Bun passava na CI. Após a mesclagem, surgiram 19 regressões, que a Anthropic relatou terem sido todas corrigidas posteriormente. A versão em Rust foi lançada com o Claude Code em junho de 2026.
Esse resultado não prova que o milhão inicial de linhas de código geradas estava correto. Sumner deixou claro que as primeiras saídas de tradução não funcionavam. A chave do sucesso foi o sistema de feedback, que gradualmente transformou saídas não funcionais em código compilado, testado e com comportamento compatível.
A migração do Bun consumiu aproximadamente:
É um valor significativo, mas ainda muito inferior ao custo tradicional de uma migração que exigiria vários engenheiros em tempo integral por anos.
A Anthropic estima que migrações anteriores desse porte poderiam levar quatro anos, consumindo cerca de US$ 3 a 4 milhões em recursos de engenharia. A IA mudou a lógica de negócios, pois a migração não precisa mais resolver uma crise de sobrevivência para justificar seu custo.
Erros de memória persistentes, ecossistemas de linguagem envelhecidos, processos de build caros ou gargalos de manutenção recorrentes agora podem ser motivos suficientes para tornar a migração viável.
No entanto, as comparações devem ser feitas com cuidado. O custo em tokens não é o custo total do projeto. A equipe ainda precisa de planejamento humano, infraestrutura, testes, revisão de código, trabalho de segurança e manutenção pós-mesclagem.
Esta migração foi motivada principalmente por questões de confiabilidade, e não por velocidade bruta.
O Bun já tinha bom desempenho em Zig. O problema era coordenar com segurança a memória nativa gerenciada manualmente com o runtime JavaScript com coleta de lixo.
As categorias comuns de falhas incluíam:
Em Rust seguro, muitos desses erros não passam pela compilação. Os valores têm ownership claro, a limpeza de recursos está vinculada ao ciclo de vida dos objetos e o compilador verifica referências antes da execução do programa.
O objetivo desta migração foi preservar a arquitetura, estrutura de dados, comportamento e desempenho existentes do Bun. Foi intencionalmente mais próxima de uma portabilidade mecânica do que de um redesenho completo.
Essa decisão foi crucial. Se o sistema fosse redesenhado ao mesmo tempo em que a linguagem fosse trocada, a comparação de comportamento se tornaria extremamente difícil.
Jarred Sumner não foi o único engenheiro da Anthropic a usar o Claude Code para uma migração significativa.
Mike Krieger, cofundador do Instagram e co-líder da Anthropic Labs, migrou uma base de código Python interna para aproximadamente 165.000 linhas de TypeScript em um fim de semana.
O processo principal de migração consumiu cerca de 27 milhões de tokens, envolvendo:
A ferramenta original precisava ser entregue como um único binário. Com a toolchain Python, a compilação levava cerca de oito minutos por plataforma, e a matriz completa de builds atrasava cada lançamento em cerca de 30 minutos.
Após a migração para TypeScript:
Krieger não dependia de um conjunto de testes abrangente e multilíngue existente. Em vez disso, o Claude
Um framework de testes de consistência foi criado, abrangendo sete cenários reais, e os resultados das implementações antiga e nova foram comparados.
Claude também projetou testes de ponta a ponta adicionais, executando-os por quatro noites consecutivas, corrigindo os casos com falha e repetindo o processo. Isso revelou diferenças sutis de comportamento que não eram previstas nos cenários originais.
Grandes migrações são intimidantes porque envolvem um enorme volume de alterações repetitivas. E são exatamente essas características que as tornam adequadas para fluxos de trabalho com agentes inteligentes.
Grandes bases de código geralmente podem ser divididas em arquivos, pacotes, crates, módulos ou grupos de dependências. Agentes inteligentes independentes podem processar unidades mutuamente independentes simultaneamente.
O grafo de dependências determina quais unidades podem avançar em paralelo e quais precisam esperar.
A implementação original já contém o comportamento necessário, casos limite, estruturas de dados e detalhes de integração.
O modelo não precisa criar funcionalidades do produto; sua tarefa é preservar o sistema existente em uma nova linguagem ou framework.
Agentes inteligentes trabalham melhor quando podem avaliar mecanicamente sua própria saída.
Compiladores, suítes de teste, diffs de saída, benchmarks ou frameworks de teste de consistência fornecem sinais concretos ao sistema. Com base nisso, o agente pode melhorar continuamente, sem necessidade de julgamento humano a cada tentativa intermediária.
Erros de compilação se tornam a próxima tarefa, testes com falha se tornam a próxima tarefa, e crashes de programa também se tornam a próxima tarefa.
Isso transforma uma grande tarefa de migração em uma fila que pode ser reduzida iterativamente.
Quando um revisor encontra o mesmo problema em vários arquivos, a melhor solução não é corrigir manualmente cada arquivo individualmente.
Deve-se atualizar o manual de regras e regenerar os lotes afetados. Isso impede que o mesmo erro se repita no trabalho futuro.
A ideia mais importante no fluxo da Anthropic é: tratar o código gerado como produto da saída do sistema.
Suponha que 200 arquivos traduzidos contenham o mesmo erro de ownership. Corrigir esses arquivos manualmente pode resolver os erros visíveis, mas o fluxo de trabalho ainda pode produzir o mesmo erro novamente.
A abordagem mais eficaz é:
O código melhora porque o processo de produção foi otimizado.
Isso é semelhante à engenharia de software comum. Um defeito de produção recorrente deve levar à melhoria de testes, regras de tipos, verificações estáticas ou processos — e não apenas a mais um patch isolado.
Antes de iniciar uma migração em larga escala, é necessário definir como a equipe provará a correção da nova implementação.
Sem um mecanismo de julgamento, não é possível determinar uma condição de conclusão confiável.
O mecanismo de julgamento deve avaliar a implementação original e a implementação alvo sob as mesmas condições. Testes existentes podem depender de funções privadas ou mecanismos internos específicos da linguagem, que desaparecem durante a portabilidade.
A Anthropic recomenda três preparações:
Uma suíte de testes que não consegue detectar falhas conhecidas não pode ser usada como um mecanismo de julgamento válido para migração.
Bun tem uma vantagem significativa: a maior parte de sua suíte de testes é escrita em TypeScript, e não em Zig, portanto, a mesma suíte pode testar a implementação em Rust.
Para projetos sem essa vantagem, ferramentas de teste de pares podem ser usadas para comparar a entrada e saída reais entre as duas versões.
A Anthropic resume a experiência desses projetos no seguinte processo de seis etapas.
A primeira fase cria todos os documentos compartilhados que os agentes subsequentes seguirão.
O manual de regras define como os conceitos da linguagem de origem são mapeados para a linguagem de destino.
Para migrações que mantêm a estrutura inalterada, o manual de regras pode incluir:
Em redesigns, o manual de regras se aproxima mais de um documento de arquitetura.
Jarred Sumner, por meio de diálogo com o Claude e revisão manual, criou o guia de portabilidade do Bun. O produto final tinha centenas de linhas.
O repositório deve ser dividido de acordo com a ordem de dependências.
Um script determinístico pode gerar o mapeamento de dependências verificando imports, manifestos, arquivos de build e relações de símbolos. O resultado ajuda o orquestrador a determinar quais arquivos podem ser convertidos independentemente e quais precisam ser processados em conjunto.
A linguagem de origem e a de destino seguem regras diferentes.
Para a migração de Zig para Rust, a principal lacuna é a ownership de memória. Para a migração de Python para TypeScript, as formas implícitas de objetos e interfaces devem ser transformadas em contratos explícitos.
O inventário de lacunas deve registrar aspectos que a tradução pura não consegue resolver, incluindo:
O manual de regras deve ser criado antes do inventário de lacunas, pois este depende parcialmente do que as regras regulares não conseguem tratar.
Não traduza milhares de arquivos imediatamente.
Primeiro, selecione alguns arquivos complexos e representativos para uma execução experimental única e pequena. O objetivo é expor falhas nas regras antes que elas se espalhem por todo o repositório.
Na execução experimental do Bun:
O produto desta fase é o manual de regras otimizado — não código de produção.
Para migrações de redesign, o teste equivalente é fazer um revisor adversarial atacar o documento de design e, em seguida, realizar uma execução única de ponta a ponta.
Assim que as regras forem validadas pela execução experimental, o repositório pode ser processado por filas paralelas.
Uma unidade típica inclui:
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.
A fila deve suportar retomada de ponto de interrupção. Deve ser possível determinar se o trabalho está concluído verificando arquivos ou registrando artefatos, e não dependendo da memória de um único agente.
Os agentes devem sempre marcar trabalhos não concluídos de forma consistente, por exemplo:
TODO(portabilidade): explicar por que esta parte não pode ser traduzida com segurança
Não é necessário usar o modelo mais caro para cada unidade. Modelos de configuração mais baixa podem lidar com tradução de alto volume, enquanto modelos mais fortes podem ser reservados para revisores, decisões arquiteturais e modificações de regras.
A primeira compilação completa transforma erros do compilador em uma fila de trabalho estruturada.
Dependendo do custo da compilação, o compilador pode ser executado dentro de cada loop de agente ou através de um orquestrador separado.
Para o projeto Bun, compilar todo o workspace é caro, portanto, durante a tradução dos arquivos, o agente Claude não executa comandos cargo indiscriminadamente. O fluxo alternativo é:
Isso impede que dezenas de agentes iniciem compilações igualmente caras simultaneamente.
Erros sistemáticos do compilador devem levar à atualização das regras. Por exemplo, a linguagem de destino pode rejeitar dependências circulares que o compilador de origem tolera em modo de carregamento preguiçoso. Isso é um problema no nível do fluxo de trabalho, e não um mero conjunto de erros isolados em arquivos.
Uma compilação bem-sucedida apenas prova que a linguagem de destino aceita o código.
A próxima fase utiliza testes básicos de execução e fumaça para detectar falhas, falhas de inicialização, recursos ausentes, suposições inválidas e falhas de integração.
Casos de falha ainda devem ser classificados por causa.
Se 40 testes de fumaça falharem devido ao mesmo padrão de inicialização incorreto, a regra de migração deve ser corrigida e o código afetado deve ser regenerado, em vez de atribuir 40 correções independentes.
O estágio final é a consistência comportamental.
Execute suítes de testes portáteis das duas bases de código simultaneamente, ferramentas de verificação de conformidade, comparação de saídas e benchmarks relacionados.
Para cada caso de falha:
A base de código original é sempre a referência factual, a menos que o projeto tenha a intenção explícita de alterar o comportamento.
A falta de uma suíte de testes não pode pular esta etapa. A equipe pode usar o Claude para criar ferramentas externas de verificação de conformidade com base em cenários reais e validar a eficácia dessas ferramentas por meio de comportamentos intencionalmente quebrados.
A Anthropic lançou um kit de início público contendo prompts genéricos, modelos e scripts baseados no fluxo de trabalho de migração.
Este repositório é material de referência, e não um produto de migração totalmente gerenciado. Seus prompts são modelos de refatoração, não um registro exato do processo do projeto Bun.
Em sistemas macOS ou Linux:
curl -fsSL https://claude.ai/install.sh | bash
Em sistemas Windows PowerShell:
irm https://claude.ai/install.ps1 | iex
Antes de executar scripts de instalação remotos, revise o conteúdo do script e as políticas de segurança da sua organização.
No repositório a ser migrado, execute:
git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit
Esta etapa opcional copia a habilidade de migração para o diretório local de habilidades do Claude Code:
cp -r migration-kit/skill ~/.claude/skills/code-migration
Siga as instruções para atualizar o caminho do kit de ferramentas no SKILL.md instalado.
Repositório.
Primeiro, use o prompt de viabilidade somente leitura do kit de ferramentas:
prompts/00-feasibility.md
O resultado deve responder a três perguntas:
"Não migrar" é um resultado válido.
Antes de iniciar a tradução:
Em seguida, execute os prompts de migração em ordem, em vez de pular diretamente para a tradução em larga escala.
A migração do Bun não começou bem.
Quando muitos agentes começaram a trabalhar em um único repositório, suas operações Git interferiram umas nas outras. Um agente executou git stash, outro usou git stash pop e um terceiro redefiniu a árvore de trabalho.
Sumner mudou o fluxo de trabalho para impedir que os agentes executassem livremente comandos Git destrutivos. Mais tarde, ele dividiu o trabalho em quatro fragmentos de fluxo de trabalho, cada um usando uma árvore de trabalho independente, cada um coordenando vários agentes.
Este exemplo destaca um ponto-chave: as permissões do agente devem corresponder ao design do fluxo de trabalho.
Agentes de codificação com amplo acesso ao shell podem:
A camada de orquestração deve restringir comandos, definir propriedade de arquivos, serializar operações de alto custo e tornar a recuperação simples.
As lições aprendidas publicadas pela Anthropic podem ser resumidas em algumas regras práticas.
Cada base de código tem diferentes sistemas de construção, cobertura de teste, comportamento em tempo de execução, restrições de implantação e tolerância ao risco.
Use a estrutura de seis etapas como ponto de partida e, em seguida, peça ao Claude para ajustar com base no repositório real.
Agentes de correção podem lidar com falhas individuais. O valor humano é maior quando usado para identificar padrões repetitivos, regras ausentes, suposições inseguras e problemas de arquitetura.
O agente de implementação não deve ser seu único revisor.
Forneça aos revisores contexto independente e informe-os de que a suposição é que o código gerado está errado. Sua tarefa é descobrir por que o código falha, desvia ou viola o manual de regras.
Use compiladores, testes, ferramentas de linting, diferenças de saída, benchmarks e scripts determinísticos como ferramentas de avaliação.
Revisões subjetivas de "parece correto" não podem verificar com segurança alterações na escala de milhões de linhas.
Tarefas de tradução de alto volume podem ser atribuídas a modelos menores ou mais baratos. Os modelos mais fortes devem ser responsáveis pela criação de regras, arquitetura, falhas ambíguas e revisão.
O trabalho humano de maior valor deve ser concluído antes da geração em larga escala:
Uma vez que essas bases estejam sólidas e confiáveis, a maior parte do trabalho restante se torna uma tarefa de fila mecanizada.
Tarefas de migração que precisam ser executadas por dias devem ser capazes de suportar falhas, reinicializações, falhas de modelo e interrupções de infraestrutura.
O status de conclusão deve ser determinado com base em artefatos persistentes em disco, registro de commits, resultados de teste e status da fila, e não em uma única conversa longa.
A Anthropic relatou que o código Bun escrito em Rust está em uso em produção.
A migração não eliminou todas as compensações. Cerca de 4% do código Rust ainda reside em blocos unsafe, principalmente em operações de ponteiro de pequena escala nos limites de C e C++.
No entanto, a nova implementação trouxe melhorias significativas:
Esses resultados demonstram claramente o propósito da migração. O objetivo não é gerar grandes quantidades de código escrito por IA, mas sim construir um sistema mais seguro, mais enxuto e mais fácil de manter, preservando o comportamento original.
Os fluxos de trabalho com agentes são adequados para migrações em larga escala quando as seguintes condições são atendidas:
Por outro lado, pode ser menos adequado quando:
A capacidade de gerar rapidamente milhões de linhas de código não torna uma migração justificável por si só.
Foi reescrito em Rust?
Sim. Jarred Sumner usou o fluxo de trabalho dinâmico do Claude Code e um modelo Claude pré-lançamento para migrar o núcleo do Bun de Zig para Rust. O processo gerou mais de um milhão de linhas de código em menos de duas semanas, seguidas de compilação, testes, revisão e correções pós-merge.
O relatório da Anthropic indica que foram consumidos aproximadamente 5,9 bilhões de tokens de entrada não armazenados em cache e 690 milhões de tokens de saída. Com base nos preços da API, o custo do modelo é estimado em cerca de 165 mil dólares, sem incluir custos de mão de obra e infraestrutura.
A Anthropic afirma que, antes do merge, o conjunto de testes existente do Bun foi aprovado na CI. Após o merge, foram identificados 19 problemas de regressão, que foram posteriormente corrigidos.
O principal objetivo foi melhorar a segurança da memória e reduzir problemas recorrentes de ciclo de vida, como corrupção de memória, uso após liberação, dupla liberação e vazamentos de memória. O sistema de propriedade e tipos do Rust pode capturar muitos desses problemas em tempo de compilação.
Não. Uma migração bem-sucedida requer avaliadores rigorosos, regras claras, análise de dependências, permissões controladas, filas reproduzíveis, revisão adversarial e supervisão humana. Alguns projetos simplesmente não devem ser migrados.
Revisores adversariais recebem as alterações geradas em um ambiente independente, com a função de encontrar falhas, não de aprovar as alterações. Os papéis de implementador e revisor são distintos, reduzindo o risco de o autor defender seu próprio trabalho.
Idealmente, deve haver um conjunto de testes existente e robusto, especialmente se ele puder testar o comportamento público independentemente da linguagem de implementação. Caso contrário, a equipe pode construir uma estrutura de validação para comparar as diferenças entre cenários reais e saídas dos sistemas antigo e novo.
Não. A Anthropic descreve o repositório como um kit inicial generalizado e reestruturado. A migração real do Bun usou artefatos mais específicos, incluindo um manual de regras de projeto detalhado e um fluxo de trabalho dinâmico personalizado.
Testes de equivalência de comportamento.
O sucesso da migração do Bun com o Claude Code não se deve à geração perfeita de um milhão de linhas de reescrita em uma única tentativa. O ponto crucial do sucesso do projeto foi a construção, pela equipe, de um sistema de produção rigoroso em torno do modelo: manual de regras, mapeamento de dependências, lista de lacunas, projeto piloto, fila de tradução paralela, revisão adversarial, ciclo do compilador, teste de fumaça e verificação de consistência de comportamento.
O mesmo método ajudou a Anthropic a migrar uma grande base de código Python para TypeScript em um fim de semana. Em ambos os casos, a importância da validação objetiva superou em muito a velocidade bruta de geração.
A IA pode reduzir significativamente o custo e o ciclo de migrações em larga escala, mas apenas se o processo for interrompível e recuperável, as permissões forem controladas e os defeitos recorrentes aprimorarem continuamente as regras de geração de código.
O verdadeiro avanço não está na capacidade da IA de escrever um milhão de linhas de código — mas em loops cuidadosamente projetados que geram, questionam, testam e corrigem repetidamente esse código, até que o comportamento do novo sistema seja idêntico ao do antigo.
Comece com uma frase e tenha um site completo em minutos.
