# 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**](https://www.nber.org/papers/w35275)

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.

[**LongCLI-Bench — ACL 2026**](https://aclanthology.org/2026.findings-acl.1497/)

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.

[**SlopCodeBench**](https://arxiv.org/abs/2603.24755)

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**](https://arxiv.org/abs/2609.01660)

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)**](https://doi.org/10.1145/3807901)

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.