Em fevereiro de 2026 tomei uma decisão: todo código novo nos meus projetos seria gerado por agentes de IA via Claude Code. Nada de “vou testar num projeto paralelo”. Produção, clientes, tudo.
Hoje, quatro meses depois, tenho dados concretos sobre o que funciona e o que não funciona.
Os números
Em cinco repositórios ativos — AdonisJS, Next.js, Go, React, Python — foram 3.362 commits entre fevereiro e maio de 2026. Praticamente tudo gerado por agentes.
As stacks envolvidas:
- AdonisJS 5/6 — dois backends REST com Lucid ORM
- Next.js 14 — frontend com App Router e Pages Router em migração
- Go — gateway e datahub
- Python — workers de processamento de dados
- React + Vite — frontend do Media Hub
Não é um projeto de laboratório. São sistemas em produção com clientes reais.
Como funciona na prática
O modelo que desenvolvi tem papéis bem separados:
Análise antes de codar. Antes de qualquer implementação, um agente lê o codebase, entende o contexto e produz “Dev Notes” — documentação pré-digerida que o agente de implementação vai consumir. Isso elimina o problema de agentes que assumem coisas erradas sobre a arquitetura.
Separação quem define o teste de quem implementa. Inspirado no TDD clássico, mas com agentes: um agente escreve os casos de teste, outro implementa. Isso cria uma separação de viés que melhora muito a qualidade.
Review obrigatório antes de mostrar pro usuário. Nenhum PR vai pra revisão humana sem passar por um agente de code review que verifica segurança, padrões e regressões.
O que surpreendeu positivamente
Velocidade em contexto. Quando o agente tem contexto rico — arquitetura documentada, padrões explícitos, exemplos de código existente — a velocidade é absurda. Features que levariam dias ficam prontas em horas.
Consistência. Agentes não têm dias ruins. Não esquecem o padrão de nomenclatura. Não ignoram o guia de estilo porque estão com pressa.
Debugging com root cause. Quando um agente de bugfix encontra um problema, ele explica o root cause de forma estruturada. É mais útil do que o típico “tentei isso e funcionou”.
O que ainda é difícil
Dependências implícitas entre sistemas. Quando uma mudança no backend quebra um comportamento sutil no frontend que nenhuma spec documenta — isso ainda escapa dos agentes. O conhecimento tácito do sistema ainda é humano.
Contexto de longa duração. Projetos grandes acumulam decisões arquiteturais que são difíceis de manter vivas no contexto de um agente. Resolvi isso com um sistema de memória estruturada que evolui a cada sessão.
Qualidade da especificação define o resultado. Isso parece óbvio mas na prática é o maior aprendizado: o agente entrega exatamente o que foi especificado. Se a especificação é vaga, o resultado é vago. Escrever boas specs virou uma habilidade core.
O papel do engenheiro hoje
Não escrevo mais código linha por linha no dia a dia. Escrevo especificações, reviso arquitetura, valido resultados, tomo decisões sobre trade-offs.
É mais parecido com um tech lead experiente do que com um desenvolvedor sênior no sentido tradicional.
A parte interessante: isso não é menos trabalho. É trabalho diferente. E, no meu caso, mais interessante.
Nos próximos posts vou detalhar a arquitetura de agentes que uso, como estruturo o contexto e o que aprendi sobre escrever especificações que funcionam.