IA não gera produtividade. Estrutura gera.

Toda semana aparece alguém no Twitter dizendo:

“Copilot, Claude, GPT só gera código que não funciona.
Perco mais tempo corrigindo do que se tivesse escrito eu mesmo.”

E toda semana aparece outra pessoa dizendo:

“Aqui funciona muito bem.
Entrego feature em horas que levariam dias.”

Os dois estão certos.

Eu e o Claude Opus analisamos juntos mais de 1.500 interações reais de desenvolvimento.
Para isso, executei um script que coletou o histórico de uso de VS Code, Cursor e Claude Code de pessoas que aceitaram participar do experimento.

O resultado não foi um prompt mágico.
Foi um padrão de uso.

Um framework que venho aplicando há mais de um ano nos meus projetos e que agora faz sentido compartilhar.
Mas antes disso, vale entender melhor o problema.

O vazio de contexto

Pesquisadores de Stanford deram nome ao fenômeno: workslop.

Conteúdo gerado por IA que parece polido, passa em lint, segue boas práticas genéricas, mas não tem substância real para aquele projeto específico.

Código que está “certo”, mas não serve.

A Workday mediu isso na prática:

Para cada 10 horas economizadas com IA, cerca de 4 são gastas em retrabalho.
Corrigindo, validando, refazendo.

A explicação deles é direta: Context Void.

A IA produz output tecnicamente correto, mas sem o contexto institucional do projeto.
Ela não sabe decisões históricas, restrições implícitas, acordos informais do time ou limites que nunca foram escritos.

Então ela gera código “bom”, mas deslocado da realidade.

E alguém precisa consertar.

Quem está pagando essa conta

Estudos em repositórios open source mostram um efeito curioso após a adoção massiva de IA.

A produtividade geral sobe, principalmente entre desenvolvedores menos experientes.
Mas o custo aparece em outro lugar.

O código gerado exige mais revisão para se adequar aos padrões do projeto.
Essa carga cai sobre desenvolvedores mais experientes, que passam a revisar mais código enquanto a própria produtividade deles cai.

Na prática, parte do tempo dos melhores devs passa a ser consumido corrigindo workslop.

Isso ajuda a explicar por que a galera mais sênior costuma reclamar mais.
Não porque a IA “não funciona”, mas porque eles absorvem o custo do vazio de contexto.

O erro silencioso que quase ninguém percebe

O maior dano do Context Void não é apenas o retrabalho técnico.

É o desalinhamento cognitivo.

Quando a IA gera código fora do contexto, o time começa a discutir o código que já foi escrito, não o problema original que precisava ser resolvido.

A conversa muda de:

“qual é a melhor solução para esse domínio?”

para:

“como consertamos isso aqui agora?”

Esse deslocamento é caro.

Correções acontecem sob pressão, com viés de ancoragem e pouco espaço para questionar decisões fundamentais.

O retrabalho é só o sintoma visível.
A perda real é de qualidade de decisão.

O problema não é gerar código. É pedir código cedo demais.

Quando você pede código sem uma spec, você não está usando IA.
Está terceirizando o pensamento.

O padrão que mais consistentemente elimina retrabalho, na minha experiência, é simples:

preencher o Context Void antes de pedir qualquer linha de código

Todo projeto meu tem uma pasta /docs na raiz.
Antes de qualquer módulo novo existir, existe um arquivo de especificação ali.

Não é documentação de produto.
É documentação de decisão.

É o mesmo processo que usamos com um desenvolvedor humano novo no time.
Primeiro alinhamos contexto, expectativas e restrições.
Só depois pedimos implementação.

Com IA, esse onboarding acontece em toda sessão.

O fluxo que funciona para mim

O pedido nunca começa com “implementa”.

Começa assim:

“Preciso de um módulo de notificações.
Antes de codar, cria um arquivo docs/SPEC-NOTIFICACOES.md descrevendo o que precisa existir.”

A IA cria um rascunho.
A partir daí começa o trabalho real:

• “Faltou considerar retry quando o serviço de email falha.”
• “O modelo de priorização não faz sentido para o meu contexto.”
• “Adiciona requisitos não funcionais como latência máxima e throughput esperado.”

Isso se repete dezenas de vezes.

O documento vai ficando mais específico, mais alinhado com a realidade do projeto.

Aqui o Context Void vai sendo preenchido.
Cada correção adiciona contexto institucional que a IA não tinha.

Só quando a spec está clara:

“Agora lê docs/SPEC-NOTIFICACOES.md e implementa exatamente o que está ali.
Se algo não estiver claro, pergunta antes de decidir.”

O código que sai não inventa.
Não assume.
Não extrapola.

50 interações refinando um .md valem mais do que 500 corrigindo código.

Documentação como ferramenta, não como fim

Essas specs de desenvolvimento não são documentação eterna.

Na maioria dos casos, entram no .gitignore.

O que é útil para o projeto no longo prazo permanece.
O que serviu apenas para alinhar a implementação é descartado.

O valor não está no arquivo.
Está no processo de construir contexto antes de executar.

A spec não serve para limitar a IA.
Serve para limitar ambiguidades.

Muitas vezes, o maior ganho acontece antes do código existir.
Durante a escrita da spec, fica claro que o problema ainda não estava bem definido.

Três princípios que refinam o uso de IA

Com a spec como base, três práticas fazem diferença real.

1. Contexto explícito

O que é óbvio para você não existe para a IA.

Pedidos vagos forçam a IA a adivinhar.
Pedidos específicos reduzem drasticamente retrabalho.

2. Ciclos curtos

Se a IA vai gerar muito código, quebre em etapas.

Planeje.
Valide.
Ajuste.
Avance.

Menos código jogado fora.
Mais direção.

3. Correção imediata

Se você percebe que a IA entendeu errado, pare na hora.

Trinta segundos de correção economizam vinte minutos de código inútil.

O que muda depois de alguns meses usando esse fluxo

Com o tempo, algo curioso acontece.

As specs ficam mais curtas.
Os ciclos de refinamento diminuem.
Os pedidos à IA ficam mais precisos.

Não porque você documenta menos.
Mas porque passa a pensar de forma mais estruturada desde o início.

O processo não cria dependência.
Ele cria competência.

A IA deixa de ser um risco a ser contido e passa a ser um acelerador previsível.

O papel de cada um

Sua responsabilidade:

• Definir o problema real
• Trazer o contexto de negócio
• Decidir trade-offs
• Validar o resultado

Responsabilidade da IA:

• Propor soluções técnicas
• Aplicar boas práticas
• Executar o que foi definido
• Perguntar quando algo não estiver claro

O erro comum é tratar a IA como um oráculo.

O frame correto é tratá-la como um desenvolvedor excelente no primeiro dia de empresa.

O verdadeiro critério de sucesso

No fim, o uso maduro de IA não se mede por velocidade inicial ou quantidade de tarefas concluídas.

Mede-se por algo mais simples e mais difícil de atingir:

quantas decisões certas foram tomadas antes do código existir

Quando a IA funciona bem, ela não impressiona.
Ela desaparece no fluxo.

O trabalho deixa de parecer rápido e passa a parecer inevitável.

Conclusão

A diferença entre “IA é inútil” e “IA me deixa muito mais produtivo” não está na ferramenta.

Está no contexto.

Quando você pula a documentação, assume que a IA sabe o que você sabe e pede código direto, o resultado é workslop.
Código que parece bom, mas não serve.

Quando você documenta antes de codar, preenche o Context Void e só depois pede implementação, o resultado é código cirúrgico.

A IA não gera retrabalho.
Vazio de contexto gera retrabalho.

Esse framework saiu de mais de 1.500 interações reais entre desenvolvedor e IA.
Funciona para mim. Teste e veja se funciona para você.

Este próprio texto foi escrito assim.
Análise, refinamento iterativo e contexto explícito antes da execução.

Cria uma pasta /docs no seu próximo projeto e me conta o que mudou.

Referências

• Workday. Transforming the Friction of AI Into Flow. Janeiro 2026.
• BetterUp Labs & Stanford Social Media Lab. Workslop: The Hidden Cost of AI-Generated Busywork. Setembro 2025.
• Xu, F. et al. AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing Technical Debt and Maintenance Burden. arXiv:2510.10165. Outubro 2025.