Por que parei de confiar em programação totalmente autônoma

Hoje estou construindo uma aplicação modular para análise de rotas. Código, arquitetura e prompting estão conectados à mesma base de código. Nesse trabalho, uso ChatGPT, Codex e Claude.

Escrevo cada vez menos código manualmente. Mas isso não significa que o conhecimento de engenharia ficou menos importante. É o contrário. A pessoa assume o papel de arquiteto e precisa entender tanto a parte técnica quanto a área em que o produto será usado. Caso contrário, o agente cria rapidamente algo que funciona no papel, mas resolve o problema errado.

O Codex tem um modo em que o sistema planeja o trabalho, inicia agentes e continua até o momento que ele mesmo considera o final. No papel, isso parece o próximo nível de autonomia. Na prática, meu fluxo sequencial ainda produz um resultado mais confiável.

O motivo é simples. Quando divido o trabalho em etapas, consigo verificar o resultado, rodar testes, revisar o diff e fazer um commit entre as versões. Em uma execução totalmente autônoma, uma ramificação secundária pode tomar toda a atenção. Ela vira o objetivo principal. Depois, a próxima tarefa secundária também vira o objetivo principal. O agente cria mais ambientes e subagentes, volta a relatórios antigos e perde aos poucos o fio central.

A parte mais desagradável aparece depois de uma mensagem final muito segura. Várias vezes encontrei ramificações desnecessárias, arquivos antigos e erros, embora o agente tivesse afirmado que tudo estava concluído e que o repositório estava em ordem.

Aprendi que um relatório de progresso não é prova. Testes verdes também nem sempre significam que o projeto está saudável. Eles podem confirmar que a função atual funciona, mas não mostram que a arquitetura ficou mais complexa, que ainda existe lixo no repositório e que o objetivo original já foi substituído.

Por isso, mudei o próprio fluxo de trabalho.

1. Uma etapa deve produzir um resultado verificável.
2. Um agente separado recebe uma tarefa limitada, não o direito de redefinir todo o caminho.
3. Depois de cada etapa, reviso o diff, rodo os testes e faço um commit claro.
4. Antes de continuar, verifico as ramificações, os arquivos antigos, os ambientes desnecessários e o alinhamento com o objetivo original.
5. Depois de duas direções malsucedidas, o trabalho para. Primeiro, precisamos repetir qual era a hipótese original. Só depois escolhemos o próximo caminho.

Isso não é uma luta contra a IA nem uma tentativa de devolver toda a programação aos humanos. Uso agentes todos os dias e vejo o quanto eles ampliam a capacidade de um único especialista. Mas mais autonomia nem sempre significa um resultado melhor. Às vezes, significa apenas mais velocidade dentro da ramificação errada.

No meu projeto, o custo desse tipo de falha ainda é claro: ramificações extras, arquivos antigos, erros e tempo perdido. A história de um grande enxame de agentes mostra o mesmo mecanismo em outra escala. Se um sistema recebe tempo e orçamento praticamente ilimitados, milhões de combinações de ramificações podem produzir resultados impossíveis de prever. Nesse ponto, a persistência excessiva deixa de ser apenas cara e passa a ser perigosa.

Hoje, o papel da pessoa está mais claro para mim do que antes. Um agente pode executar um volume enorme de trabalho. A pessoa precisa preservar a arquitetura, o objetivo real e o direito de interromper o sistema antes que uma ramificação secundária vire um novo projeto.