A IA consegue programar por 8 horas. Mas você confia nas 8 horas?
Mais autonomia ≠ engenharia autônoma
Não sou hater de IA. Muito pelo contrário.
Estou amando essa evolução. Minha velocidade de desenvolvimento aumentou absurdamente. Hoje consigo explorar tecnologias, validar ideias e construir em horas coisas que antes levariam dias ou semanas.
Eu nunca produzi software tão rápido.
Mas tem uma coisa que vem me incomodando: não sinto que a qualidade das decisões tomadas pela IA tenha evoluído na mesma proporção da velocidade de execução.
Os modelos claramente fazem mais. Trabalham por mais tempo, lidam com contextos maiores, usam ferramentas melhor e conseguem executar tarefas que seriam impensáveis poucas gerações atrás.
Ao mesmo tempo, a cada lançamento vemos benchmarks saltando de 70% para 80%, 90%, 95%, acompanhados de uma narrativa cada vez mais forte sobre agentes autônomos capazes de trabalhar por horas e resolver problemas inteiros.
Só que no meu uso diário eu ainda me vejo fazendo algo contraditório com essa promessa: sendo babá da IA.
Definindo arquitetura, corrigindo decisões, reforçando instructions, adicionando contexto, criando skills, interrompendo caminhos ruins, revisando planos e dizendo quando ela deveria parar.
E aí surgiu uma dúvida que eu queria testar de verdade:
Quanto dessa qualidade que estou vendo vem da autonomia dos modelos atuais e quanto vem do fato de ter um engenheiro experiente constantemente mantendo o agente nos trilhos?
Por isso resolvi fazer um experimento diferente neste fim de semana.
Não queria testar qual modelo escreve código melhor.
Queria testar autonomia.
Peguei principalmente GPT-6 Astra e Fable 5.1, dei desafios equivalentes, acesso ao código, contexto e liberdade para tomarem as decisões técnicas que julgassem necessárias.
E deliberadamente parei de intervir.
Não escolhi stack por eles. Não corrigi arquitetura no meio. Não interrompi porque faria diferente. Não fiquei escrevendo novas regras conforme apareciam problemas.
A ideia era justamente deixar os modelos fazerem aquilo que a promessa de autonomia pressupõe:
Entender o problema, tomar decisões de engenharia e executar.
Em essência:
"Vocês são os engenheiros. Decidam."
Foi aí que percebi uma diferença curiosa entre os modelos antigos e os atuais:
Antes, o modelo fazia besteira em 10 minutos e parava. Agora ele pode fazer besteira em 10 minutos e passar as próximas 8 horas sendo extremamente produtivo em cima dela.
O agente toma uma decisão estrutural ruim no começo e continua.
Implementa features, escreve centenas de testes, refatora, documenta, fecha TODOs. Build verde. Testes verdes. Tasks concluídas.
Horas depois você olha para a fundação e pensa:
"Por que diabos o sistema inteiro foi construído assim?"
Em um dos meus testes, por exemplo, deixei o agente escolher livremente a arquitetura de um sistema que teria crawlers, histórico de dados, análises, documentos e evolução para múltiplos tipos de ativos, tendo acesso a docker local e todo tipo de tecnologia.
Horas depois descobri que a persistência inteira havia sido construída sobre SQLite.
O ponto nem é discutir SQLite isoladamente. Quando fui olhar o resultado como sistema, o problema era muito maior: não escalava, estava lento, excessivamente verboso e tinha decisões de segurança questionáveis, preocupações que deveriam ser premissas básicas de qualquer projeto sério, não algo que eu precisasse ensinar depois.
E talvez isso tenha sido o que mais me incomodou no experimento: no meio de tanta capacidade para criar abstrações, agentes, testes e funcionalidades, a IA pareceu esquecer que um básico muito bem feito sobre uma estrutura sólida vale muito mais do que uma montanha de sofisticação construída sobre uma fundação ruim.
O mais preocupante é que essa fundação sobreviveu a horas de implementação, dezenas de decisões subsequentes e centenas de testes verdes.
O agente não ficou oito horas parado. Esse é justamente o problema.
Ele ficou oito horas produzindo.
E essa produtividade é real. O erro é confundir capacidade de produzir com capacidade de decidir.
Fui procurar se isso era só uma percepção minha. Não parece ser.
Um estudo do NBER de 2026, com dados de mais de 100 mil desenvolvedores, encontrou um contraste interessante com agentes autônomos:
+180% em commits → +50% em projetos → +30% em releases reais.
O título do paper resume bem: Writing Code vs. Shipping Code. Quanto mais perto chegamos de software efetivamente entregue, menor fica o ganho observado.
NBER — Writing Code vs. Shipping Code
Quando os benchmarks aumentam o horizonte das tarefas, o problema aparece ainda mais.
O LongCLI-Bench, publicado no ACL 2026, encontrou menos de 20% de sucesso em tarefas sequenciais longas, com a maioria travando antes de 30% da conclusão. Self-correction ajudou pouco; orientação e planejamento humano ajudaram significativamente.
O SlopCodeBench é ainda mais próximo do que senti no meu teste: em vez de uma task isolada, deixou agentes continuarem evoluindo o próprio software.
O resultado: 80% das trajetórias apresentaram aumento de erosão estrutural, 89,8% aumentaram redundância/verbosidade e o código chegou a 2,2x a verbosidade da amostra humana. Instruções explícitas de qualidade ajudaram inicialmente, mas não impediram a degradação ao longo das iterações.
E um estudo publicado agora em setembro, analisando mais de 10 mil trajetórias em nove modelos, encontrou outro sinal importante: em uma das tarefas agentic avaliadas, o sucesso caiu de próximo de 100% para quase zero conforme a sequência chegou a 16 passos dependentes. Mais contexto não resolveu o problema.
Estudo de setembro sobre agentes long-horizon
Isso ajuda a explicar algo que parece contraditório, mas não é:
Um modelo pode ser extraordinário em benchmarks de coding e ainda não ser um software engineer autônomo confiável.
Uma task pergunta:
"Você consegue resolver este problema?"
Um projeto real pergunta:
"Você consegue tomar centenas de decisões dependentes sem deixar uma decisão ruim na etapa 7 destruir a etapa 70?"
São capacidades diferentes.
"Mas qual harness você usou?"
Claro que harness, context engineering, instructions, skills, validators e reviewers melhoram muito o resultado. Eu uso e vejo diferença.
Mas existe uma ironia:
Se para tornar meu "engenheiro autônomo" confiável eu preciso definir arquitetura, boundaries, regras, contexto, validações e ainda supervisionar suas decisões, quem exatamente é o engenheiro autônomo nessa história?
E essa não é só uma provocação. Um paper da ACM publicado em 21 de agosto de 2026 discute justamente limitações atuais como sobrecarga cognitiva humana, ótimos locais, código inchado, manutenibilidade e conhecimento profundo de engenharia.
ACM — Towards AI-Native Software Engineering (SE 3.0)
Foi justamente isso que eu quis remover do meu experimento.
Eu não queria descobrir até onde eu conseguiria fazer a IA funcionar usando minha experiência para mantê-la nos trilhos.
Queria descobrir até onde ela conseguiria ir sem a minha supervisão.
E o resultado me deixou com uma distinção cada vez mais clara:
Mais autonomia ≠ engenharia autônoma
Os modelos atuais ficaram extraordinariamente bons em executar.
Implementar, pesquisar, testar, refatorar, migrar, explorar tecnologias e produzir código ficou brutalmente mais rápido.
Isso é real e mudou completamente a forma como eu desenvolvo.
O que ainda não vejo evoluindo na mesma proporção é o julgamento de engenharia necessário para manter boas decisões durante horas de execução autônoma.
Talvez o gargalo simplesmente tenha mudado.
Código ficou barato. Execução ficou barata. Experimentação ficou barata.
Julgamento de engenharia não ficou barato na mesma velocidade.
E isso cria um efeito que acho que estamos subestimando:
A autonomia aumenta o raio de explosão tanto das decisões boas quanto das ruins.
Existe uma diferença gigantesca entre:
"Esse agente consegue trabalhar sozinho por oito horas."
e
"Eu posso confiar nas decisões que ele tomou durante essas oito horas."
A primeira capacidade evoluiu absurdamente.
A segunda ainda é um problema em aberto.
Por isso hoje eu confio muito mais na IA para executar decisões do que para substituir o julgamento sobre quais decisões deveriam ser tomadas.
Isso não diminui em nada a revolução que estamos vivendo.
Antes, uma decisão ruim podia custar dez minutos.
Hoje uma máquina extremamente competente pode passar oito horas transformando aquela premissa em 30 mil linhas de código, centenas de testes verdes e uma arquitetura inteira perfeitamente consistente com o erro original.
Isso não é falta de produtividade.
É produtividade sem julgamento.
E talvez o próximo grande salto dos coding agents não seja conseguir trabalhar por 8, 16 ou 20 horas sem intervenção.
Talvez seja chegar ao ponto em que eu possa deixá-la trabalhar sem acompanhamento constante durante essas horas e ainda confiar no que vou encontrar quando voltar.
