Deixamos nossa IA escrever código, revisar PRs e se implantar sozinha.

O loop que se fechou

3 de fevereiro de 2026. A mensagem do commit diz: “feat(ci): adicionar validação em loop fechado para o Claude autônomo no GitHub Actions.”

Esse commit completou um circuito que estava se formando há semanas. O resultado: um loop de desenvolvimento totalmente autônomo onde a IA escreve código, testa, revisa, cria um PR e valida o resultado — tudo sem um humano tocar no teclado.

Veja como o loop funciona:

1. Um problema é registrado no GitHub
2. Claude lê o problema e o código
3. Claude escreve uma correção em um novo branch
4. Claude executa os testes
5. Se os testes falharem, Claude lê os erros e corrige o código
6. Quando os testes passam, Claude cria um PR com um resumo
7. Uma instância separada do Claude revisa o PR
8. Um humano revisa tudo e decide se deve fazer o merge

Os passos 1 a 7 acontecem automaticamente. O passo 8 é a única intervenção humana.

Como chegamos aqui

Isso não aconteceu em um dia. Foi construído de forma incremental ao longo de seis semanas, uma capacidade de cada vez.

Semana 1: Resolução de problemas (25 de dezembro). Começamos com a versão mais simples: Claude lê um problema no GitHub, escreve uma correção e envia um branch. Sem testes. Sem revisão. Apenas “aqui está um branch com uma correção potencial, dê uma olhada.”

Semana 2: Criação de PR (26-27 de dezembro). Em vez de apenas enviar um branch, Claude cria um pull request adequado com um título, descrição e problema vinculado. Agora a correção é visível para a equipe sem precisar checar os branches manualmente.

Semana 3: Revisão de código (início de fevereiro). Um fluxo de trabalho separado do Claude é acionado em novos PRs. Ele revisa o código em busca de bugs, problemas de segurança e violações de estilo. Comentários aparecem no PR assim como os comentários de um revisor humano.

Semana 4: Validação em loop fechado (3 de fevereiro). A peça final: Claude executa os testes antes de enviar o PR. Se os testes falharem, ele lê a saída de erro, modifica o código e tenta novamente. O PR só é criado quando a suíte de testes passa.

Cada semana adicionou uma camada. Cada camada tornou o sistema todo mais confiável.

O que aprendemos sobre desenvolvimento com IA

A IA precisa de restrições, não de liberdade. No início, Claude às vezes “corrigia” um pequeno bug de UI refatorando três módulos e mudando o esquema do banco de dados. Aprendemos a adicionar restrições explícitas: “Modifique apenas arquivos diretamente relacionados ao problema. Não refatore. Não adicione funcionalidades. Corrija o bug.”

Resumos concisos superam explicações detalhadas. As primeiras descrições de PR do Claude tinham 2.000 palavras. Ninguém as lia. Ajustamos o prompt para exigir resumos com menos de 200 palavras. “O que mudou e por quê” em duas frases. É tudo que um revisor precisa para começar sua revisão.

A revisão de código captura problemas reais. Fomos céticos quanto a uma IA revisando código gerado por IA encontrar algo útil. Ela encontra. Tratamento de erro ausente. Referências nulas potenciais. Imports não utilizados. Problemas de segurança. O revisor de código da IA não é perfeito, mas captura 80% dos problemas que humanos pegam com uma rápida olhada — e faz isso em segundos.

Separação de preocupações é importante. A IA que escreve o código e a IA que revisa o código devem ser separadas. Mesmo modelo, contexto diferente, prompt diferente, preocupações diferentes. O escritor é otimista (“aqui está minha solução”). O revisor é cético (“o que pode dar errado?”). Ambas as perspectivas são necessárias.

A realidade meta

Vamos afirmar o óbvio: estamos construindo uma plataforma para agentes de IA autônomos, e estamos usando agentes de IA autônomos para construí-la.

Nossos usuários executam agentes de IA que executam código em ambientes isolados, leem e escrevem arquivos e completam tarefas de forma autônoma. Nosso processo de desenvolvimento executa agentes de IA que executam código em ambientes de CI, leem e escrevem arquivos e completam tarefas de forma autônoma.

A diferença é superficial: nossos usuários usam a interface web do LikeClaw, e nosso CI usa GitHub Actions. O padrão subjacente é idêntico: defina uma tarefa, deixe a IA executá-la, revise os resultados.

Isso não é uma coincidência. Construímos o pipeline de desenvolvimento usando os mesmos princípios que ensinamos a nossos usuários. E as coisas que aprendemos ao rodar esse pipeline melhoram o produto que construímos para eles. É um ciclo virtuoso.

Os números

Desde que ativamos o pipeline de desenvolvimento autônomo:

• PRs criados pela IA: dezenas
• Tempo médio do problema ao PR: minutos, não horas
• Falhas de teste capturadas antes da submissão: múltiplas por semana
• Incidentes em produção causados por código escrito por IA: zero (até agora)

Esse último número é o que mais importa. Zero incidentes em produção. Cada mudança escrita por IA passou por testes, revisão da IA e revisão humana antes do merge. A rede de segurança em três camadas funciona.

Isso é apenas o começo

Hoje, a IA lida com correções de bugs, atualizações de dependências e implementações de funcionalidades simples. Amanhã, lidará com tarefas mais complexas: refatoração de múltiplos arquivos, otimização de desempenho, geração de testes.

A grande sacada não é que a IA pode escrever código. É que a IA pode participar de um fluxo de trabalho de desenvolvimento com as devidas proteções. Testes, revisões e supervisão humana tornam o código gerado por IA seguro. Remova qualquer uma dessas camadas e você terá um risco. Mantenha todas as três e você terá uma ferramenta que multiplica a produção da sua equipe.

Somos uma equipe pequena entregando 7,5 commits por dia. Alguns desses commits são escritos por humanos. Alguns são escritos por IA. Todos eles são aprovados por humanos.

Esse é o futuro do desenvolvimento de software. Não a IA substituindo desenvolvedores. A IA acelerando desenvolvedores. Com as devidas proteções. Às 3 da manhã. Enquanto a equipe dorme.