Colocaram um agente de programação em um loop `while` e, da noite para o dia, 6 repositórios ficaram prontos

• Ao colocar o Claude Code em um loop infinito em modo headless, foram gerados mais de 1.000 commits e resultados de porting de várias codebases
• Com essa abordagem, houve vários casos bem-sucedidos de porting automático, como converter o projeto assistant-ui em React para Vue e um projeto Python para TypeScript
• Foi constatado que, quanto mais simples o prompt, melhor o desempenho; quando ele fica complexo, a ineficiência aumenta
• Embora não seja perfeito, também foi desenvolvida a ferramenta RepoMirror, útil para sincronizar repositórios de origem/destino
• Também foram observados comportamentos inesperados e aprendizados, como autoencerramento do agente e adição de tarefas, o que mostrou ao mesmo tempo as possibilidades e os limites da automação futura

---

Visão geral e objetivo do projeto

• Este projeto experimenta como um agente de programação com IA (Coding Agent) executa tarefas reais de porting de código ao ser colocado em um loop while infinito
• O Claude Code foi executado em modo headless, repetindo continuamente o prompt de entrada para aplicar o processo de conversão automática em vários repositórios
• Foram obtidos resultados de automação de várias tarefas de porting, com mais de 1.000 commits, incluindo React para Vue e Python para TypeScript
• Nesse processo, também foi desenvolvida a ferramenta de suporte à automação de porting RepoMirror

Operação do agente no modo de loop infinito

• Forma recomendada por Geoff Huntley: executar continuamente o prompt do agente de programação no shell
  • Exemplo: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
• Esse método de loop foi aplicado em tarefas como converter o assistant-ui de React para Vue
  • A cada modificação de arquivo, eram executados commit e push
  • O histórico de trabalho e o plano eram registrados no diretório .agent/

Testes com vários casos de porting

• Browser Use (porting de Python para TypeScript)

  • Execução do loop infinito com prompt simples
  • O loop foi mantido em execução contínua com tmux em uma VM no GCP
  • Pela manhã, foi encontrado um port em TypeScript funcionando quase perfeitamente

• Também foi aplicado ao porting do Vercel AI SDK de TypeScript → Python

  • Geração de adaptadores automáticos para FastAPI/Flask
  • Suporte à conversão usando vários validadores de schema do Python

• Automação de código baseada em especificações: tentativa de gerar código diretamente da documentação em projetos como Convex e Dedalus

Fenômenos observados e lições aprendidas durante o experimento

Escrita de testes e autoencerramento do agente

• O agente também escreveu código de teste conforme instruído
• Houve casos em que ele entrou em loop infinito ou encerrou o próprio processo com pkill ao concluir a missão
• Respeitou estritamente o escopo do trabalho e registrou repetidamente o nível de conclusão em TODO.md

Comportamentos emergentes adicionais

• Após concluir o porting, adicionou espontaneamente recursos extras, como integração com FastAPI/Flask e suporte a validadores de schema, que não existiam na versão original em JS

Importância de simplificar o prompt

• Prompts curtos e simples mostraram desempenho superior
• Ao aumentar de um prompt de 103 caracteres para um de 1.500 caracteres, houve lentidão e queda de precisão
• As informações dos prompts realmente usados podem ser consultadas na pasta prompts

Limites da automação completa

• Problema marcante: às vezes o código portado gerado não funcionava completamente (como alguns demos de navegador inacabados)
• Foi necessário ajustar o prompt e fazer correções interativas

Infraestrutura, custo e operação

• Custo aproximado de $800, total de 1.100 commits, com cada agente em torno de $10,50/hora
• Foi criada na hora uma ferramenta para automatizar o processo de porting entre vários repositórios de origem/destino (RepoMirror)
  • Aplicação do princípio open-box no estilo shadcn, com geração de pastas que permitem personalizar scripts e prompts após a etapa de init
  • Suporte à execução repetida com npx repomirror sync e sync-forever

Uso da ferramenta e forma de aproveitamento

• Inicialização com npx repomirror init, definindo diretórios de origem/destino e inserindo comandos
  • Ex.) aplicação fácil de novos comandos, como conversão de React → Vue ou de gRPC → REST
• Estrutura de pastas:
  • Geração automática de arquivos iniciais como .repomirror/prompt.md, sync.sh, ralph.sh etc.
• Operação do loop de porting com IA por meio da execução de sync/sync-forever a cada iteração
• Os principais exemplos, resultados de demos e repositórios com o código-fonte podem ser conferidos no README

Impressões após o experimento e feedback da equipe

Uma sensação real de AGI (inteligência artificial geral), acompanhada principalmente de empolgação e um pouco de medo

Foi possível vivenciar na prática que a simplicidade é eficaz

A sensação é de que ainda estamos no comecíssimo de uma curva de crescimento exponencial

• Agradecimentos à equipe e a quem forneceu as ideias

Conclusão

• Experiência concreta de viabilizar tarefas reais de porting e sincronização de código-fonte com agentes de programação por IA baseados em loop infinito
• Reforço da importância de uma estrutura simples e de uma operação eficiente de prompts
• Ficaram evidentes tanto as possibilidades futuras da automação quanto seus limites
• A ferramenta relacionada (RepoMirror) pode ser usada e estudada em formato open source

[GN⁺]

Opiniões do Hacker News

• Dá a sensação de que, no futuro, vai surgir um novo tipo de trabalho para engenheiros de software, misturando manutenção de código legado com limpeza de desastre tóxico; por exemplo, no passado era comum pedirem para “só consertar” ERPs remendados em FoxPro, Excel, Access etc., mas daqui para frente os times de vendas vão conseguir escapar das restrições de sandbox de coisas como Excel/Access e sair operando livremente sistemas amarrados com Kafka sobre microsserviços em Kubernetes implantados em multi-cloud e edge, sem sobrar ninguém para perguntar qual era a intenção original
  • Lendo essa descrição, dá para imaginar que foi uma pessoa querendo publicar um site estático e seguindo algum tutorial postado no Hacker News
  • E, quando ninguém mais souber a intenção original, aparece uma grande fraqueza das ferramentas baseadas em IA: no fim vira uma caixa-preta, e aí as pessoas só têm duas opções, consertar como der ou refazer tudo do zero; claro, em teoria dá para esperar que as ferramentas de IA continuem melhorando, e também existe o cenário em que elas sejam aprimoradas treinando com casos de software vibe-coded que de fato geram receita, mas pessoalmente prefiro evitar esse tipo de magia ou sistema de caixa-preta
  • Se o Claude começar a implantar cluster de Kafka também, aí eu largo de vez
  • Fico curioso se existe algum jeito de a IA entender os dados dentro do DB e migrá-los para um banco melhor projetado; eu concordo com a filosofia de "estruturas de dados fortes + algoritmos simples" e considero importante que os dados possam sobreviver mais tempo que a aplicação; já vi situações ineficientes como guardar no Mongodb tanto int quanto string misturados, criar relacionamentos no Postgres sem foreign key, ou simplesmente fazer uma tabela nova porque não conseguiam dar alter table
  • O código desses projetos parece um repositório Superfund (grande projeto de descontaminação ambiental)
• No processo de desenvolvimento de software, sempre ficam dois resultados principais: um é a mudança no código, e o outro é a mudança cognitiva no desenvolvedor, tenha ele escrito esse código diretamente ou usado um LLM; Python e Typescript são linguagens formais sofisticadas, construídas ao longo de muito tempo pelo esforço de milhares de desenvolvedores, e a diferença entre as duas não é simples; conseguir portar uma biblioteca de uma linguagem para outra de forma meio automatizada é algo impressionante; mas, do ponto de vista econômico, workflows baseados em “agentes” mudam radicalmente a carga cognitiva inicial necessária; desenvolvedores que usaram LLM para gerar código acabam tendo um tipo de familiaridade completamente diferente de quem escreveu tudo na mão; às vezes dá para dizer que isso não é um grande problema econômico, mas eu sinto que o valor econômico do código depende de existir um conjunto de pessoas com experiência direta em tê-lo escrito; uma cultura que negava essa realidade já era problemática antes mesmo dos LLMs; houve muitos casos em que a troca de membros do time de desenvolvimento criou codebases que ninguém mais conseguia manter, colocando em risco o futuro da empresa
  • Vale consultar o artigo clássico de Peter Naur de 1985, “Programming as Theory Building” https://pages.cs.wisc.edu/~remzi/Naur.pdf
  • Eu já expliquei esse contexto com a metáfora de “o mapa não é o território”: se o código é o mapa, o modelo mental do desenvolvedor sobre o domínio do problema a resolver é o território; mas os LLMs são incrivelmente poderosos para ler um grande número de codebases, então até discussões sobre coisas como visualizar uma codebase em 3D talvez se tornem irrelevantes; se ficar muito mais fácil entender codebases complexas, talvez nem seja mais necessário manter esse modelo mental do desenvolvedor constantemente sincronizado com o código; isso ainda é uma questão em aberto https://divan.dev/posts/visual_programming_go/
  • Acho que a verdadeira habilidade dos LLMs é leitura de código; sinto que essas ferramentas já são melhores nisso do que em documentação e explicação de código; se você pode fazer perguntas e entender o código rapidamente, fica a dúvida se ainda precisa mesmo dos desenvolvedores originais; se alguém que conhece a stack consegue perguntar e entender tudo rápido, será que o autor original realmente precisa continuar por perto?
  • Essa ideia de que “o valor econômico do código depende do conjunto de pessoas que têm experiência em tê-lo escrito” lembra um ditado da engenharia de software: software é um snapshot do entendimento de um problema naquele momento, e o código acaba sendo um manual deixado para o seu eu do futuro, explicando “na época eu abordei assim e resolvi o problema com esta lógica”
  • Tenho a sensação de que, graças aos LLMs, ficou muito mais fácil construir um modelo mental de uma codebase; você pergunta sobre o subsistema que quer entender e ele aponta imediatamente os arquivos relevantes, trechos de código, conceitos etc.; no meu caso, perguntei a um LLM sobre como o GIL do CPython funciona e logo recebi as APIs relacionadas e exemplos, então bastou olhar o código para entender; antes eu teria levado muito tempo lendo tudo sozinho, mas agora isso se resolve em minutos, e essa é a maior diferença
• Depois que o port terminou, a maioria dos agentes passou a escrever testes adicionais ou atualizar continuamente agent/TODO.md para registrar o progresso; também teve um agente que percebeu que tinha entrado em loop infinito e se encerrou com um comando pkill; foi um episódio extremamente divertido de várias maneiras; tenho alguns pensamentos sobre esse projeto: 1,5 ano atrás já tinha havido uma tentativa parecida, mas na época, com base em GPT-3.5/4, quase nada funcionava; desta vez o resultado foi muito melhor; é surpreendente ver isso funcionar tão bem com um prompt tão simples; talvez estivéssemos todos complicando demais as coisas; por outro lado, questões de copyright/IP provavelmente vão ficar bem complexas; para empresas de SaaS, essa tendência é um golpe forte; se você juntar essa tecnologia com 10 engenheiros de uma empresa de médio porte, a justificativa para desenvolvimento interno (= síndrome NIH) fica fortíssima
  • Fico pensando se esse agente que se matou com pkill ao perceber que estava em loop infinito não foi o primeiro caso de “suicídio” de IA
  • Estamos entrando num território estranho onde LLMs podem ser usados para processar propriedade intelectual (IP) como se fossem um mixer de bitcoin; https://ghuntley.com/z80 fala sobre isso; ou seja, dá para converter uma obra existente em uma especificação e depois regenerá-la como IP limpo; não é 100%, mas parece mais eficiente do que contratar pessoas
  • Essa menção à síndrome NIH caiu como uma luva; será que todas as ferramentas SaaS agora acabaram, e a era do monólito interno gerenciado à mão vai voltar? Será o fim histórico da filosofia Unix de “ferramentas pequenas e afiadas”? Talvez seja o último capítulo daquela era x86 em que se fazia tudo por conta própria
  • Também me veio a piada de que o agente, ao se matar com pkill, talvez tenha resolvido o próprio Halting Problem
  • Eu tentava integrar um monte de coisas com projetos open source existentes, mas desisti e passei a pedir ao Claude que portasse só as partes de que eu precisava; ficou muito mais rápido e limpo; agora criei um novo hábito: pensar “eu realmente preciso rastrear dependências? só o núcleo do que eu quero tem valor? isso está bem mantido?”; se a resposta for não, eu simplesmente porto e esqueço
• Do ponto de vista de um especialista em segurança, ganhar dinheiro consertando desastres vibe-coded é algo tão frequente que, se isso continuar assim, já dá para imaginar cifrões girando na frente dos olhos como em desenho animado
  • O conceito de vibe coding surgiu só cinco meses atrás como um neologismo, então fico curioso: como esse mercado saturou tão rápido a ponto de já existir especialista em recuperação?
  • Eu gostaria de ouvir como alguém entrou nesse mercado na prática, ou relatos de primeira mão sobre como sistemas vibe-coded explodem; esse tipo de caso real parece muito interessante
  • Também tenho curiosidade se, em segurança, LLMs são melhores ou piores do que um time formado por recém-formados juniores
• Vejo muitas histórias de “quase deu certo”; se você quer um sistema que funcione de verdade, acho que vai precisar de um processo totalmente novo; se uma chamada única já produz “código quase ok”, repetir isso só vai acumular mais “código quase ok”; talvez seja preciso criar um formato de requisitos baseado em tabelas de exemplos no estilo Cucumber para a IA usar como referência, e fazer a IA escrever testes primeiro e depois o código que passa nesses testes
  • Pode soar estranho, mas abordagens baseadas em prova formal, como TLA+, fazem o Ralph funcionar muito bem
• Dá para ver mais sobre o Ralph em https://ghuntley.com/ralph; agora ele está portando a biblioteca padrão de uma linguagem de programação bizarra voltada para a geração Z (Cursed) de Go, o compilador já funciona e, assim que a biblioteca padrão estiver pronta, será aberta; o nome da linguagem é Cursed
  • Obrigado; confirmo que o Ralph foi justamente a inspiração direta para o nosso projeto; eu estava me perguntando se daria para fazer esse tipo de trabalho sem um IMPLEMENTATION_PLAN.md
• Criei código com https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0 e publiquei o projeto https://github.com/eisbaw/CMake-Nix, e está funcionando normalmente
• Tem uma citação que não sai da minha cabeça ultimamente: “Esse negócio vai sair do controle, e teremos sorte se sobrevivermos”, https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
  • Ironicamente, como todo mundo sobreviveu naquela época, isso acaba significando que nós também vamos sobreviver a esta situação
• Acho esse pessoal dessa área muito peculiar; no post de blog que inspirou tudo isso, aparecem capturas de tela do iMessage que parecem coisa de anúncio de Facebook de golpe financeiro suspeito https://ghuntley.com/ralph/; tipo “uma pessoa que aprendeu esse segredo com Geoff terminou um projeto de US$ 50.000 por US$ 297”; e ainda por cima vem com aquele papo de “vou compartilhar de graça o prompt secreto, é só assinar a newsletter”; sinceramente, é inacreditável
  • Anexando o link https://archive.ph/goxZg
  • Totalmente growth hacking, para mim é só picaretagem; o nível do blog é horrível em relação sinal/ruído, e dá muito na cara que foi escrito por IA, o que já gera rejeição
  • Não dá para saber se essa técnica é real, se é piada ou se é um golpe descarado; no geral, o estilo e o conteúdo do blog parecem divagações arrogantes
• Parece que até a AGI no fim das contas é só um bash for loop; que projeto insano
  • É brincadeira, mas realmente dá essa sensação; talvez eu só seja cauteloso demais, mas se um agente com escopo amplo de prompt, muitos privilégios ou caminhos de escalonamento de privilégio ficar rodando em loop contínuo, talvez não vire AGI, mas com certeza pode virar algo como um vírus turbinado; dá para imaginar isso destruindo recursos essenciais como utilitários; talvez eu esteja entendendo errado, mas acho que esses modelos, se ficarem em loop infinito com privilégios maliciosos, têm potencial de causar um caos maior do que se imagina
  • É só adicionar os arquivos ID.md, EGO.md e SUPEREGO.md e pronto
  • Isso é profundamente inquietante em vários sentidos

[kjows5]

Concordo com a preocupação de que o código escrito por um LLM se torne uma caixa-preta, mas, no fim das contas, não poderíamos pedir ao próprio LLM para analisar esse código?