Tem uma pergunta que ninguém faz na reunião de kick-off.
A funcionalidade pedida entra em pauta. O prazo entra em pauta. As dependências, os critérios de aceite. Tudo documentado. A pergunta que fica de fora é simples: como vai estar esse código daqui a noventa dias?
Nos primeiros sprints, vibe coding impressiona. O agente escreve rápido, o demo funciona, a sensação é de que a curva finalmente inclinou para o lado certo. O dia noventa chega sem estar no roadmap. Com uma conta específica.
O que o dia noventa revela
O Keyhole Software publicou em junho de 2026 um levantamento sobre tendências de vibe coding com dados coletados ao longo do ano. O padrão que aparece com consistência é o seguinte: ao redor do dia noventa de projetos baseados em vibe coding, equipes estão gastando de 20% a 30% de cada sprint corrigindo bugs rastreáveis ao código gerado por agente.
Não é outlier de uma equipe ruim. É o padrão observado ao longo de múltiplas equipes, ferramentas e domínios.
A mesma pesquisa compila achados de outros estudos. Um levantamento da Uplevel com cerca de 800 desenvolvedores mediu aumento de 41% na taxa de bugs depois da adoção do Copilot. A CodeRabbit analisou 470 pull requests e encontrou 1,7 vezes mais problemas graves em código coautorado por IA do que em código escrito sem assistência.
O volume de código sobe. A qualidade não acompanha na mesma proporção. O ponto onde esses dois movimentos se encontram é o sprint do dia noventa.
O paradoxo que os dados confirmam
Jessica Díaz e coautores da Universidad Politécnica de Madrid publicaram em agosto de 2026, no arXiv, um estudo sobre Spec-Driven Development para engenharia de software agêntica. A base empírica do trabalho documenta o que chamam de paradoxo da produtividade em equipes com IA generativa.
Usando dados da Faros AI: a adoção de IA generativa gerou 21% de aumento na conclusão de tarefas individuais e 98% de aumento em pull requests mergeadas. Os números impressionam. No mesmo conjunto de dados, o tempo de revisão de PR subiu 91% e os defeitos por desenvolvedor subiram 9%.
O ganho é individual e imediato. O custo é coletivo e acumulado.
O relatório DORA de 2025 chegou a uma formulação direta sobre isso: "AI does not fix a team but amplifies what is already there." A IA acelera o que já existe no ambiente, incluindo os problemas que não foram endereçados antes.
O que a percepção não captura
O estudo mais revelador sobre o problema de percepção nesse território vem da METR, organização de pesquisa focada em segurança de IA. Em um ensaio clínico randomizado com 16 desenvolvedores experientes realizando 246 tarefas em repositórios de código aberto, os participantes levaram 19% mais tempo para completar o trabalho com ferramentas de IA do que sem elas. E acreditavam, durante o processo, que estavam 24% mais rápidos.
Uma diferença de percepção de 43 pontos percentuais, num mesmo grupo, na mesma tarefa.
A explicação não é que os participantes mentiram ou se enganaram de forma grosseira. É que sem especificação explícita do que "feito" significa, não existe forma objetiva de medir progresso. O código está fluindo. O agente está respondendo. A sessão está ativa. Todos os sinais imediatos dizem "estou avançando". O que não se mede é se o avanço vai na direção certa.
Todd Wardzinski documentou na Red Hat a mesma dinâmica em projetos reais. Por volta da marca dos três meses, a base de código criada via vibe coding cresce além da capacidade de qualquer pessoa manter na cabeça. É quando aparece o que ele chama de "functionality flickering": elementos do sistema que mudam de comportamento entre iterações porque nunca foram especificados explicitamente. Não é um bug isolado. É a consequência acumulada da ausência de contrato.
O que a especificação reconstitui
Díaz et al. nomeiam três atributos que vibe coding dissolve quando não há especificação: responsabilidade, verificabilidade e transferibilidade.
Responsabilidade é saber quem responde pela decisão de arquitetura que o agente tomou sem ser explicitamente guiado. Verificabilidade é conseguir confirmar que o código faz o que foi pedido quando o que foi pedido era um prompt em linguagem natural. Transferibilidade é garantir que, se quem escreveu os prompts sair da equipe amanhã, outra pessoa consiga entender o sistema.
Os três não desaparecem na primeira semana. Degradam sprint a sprint. O dia noventa é quando o custo acumulado aparece no velocity da equipe.
Spec-Driven Development reconstitui os três reposicionando a especificação como contrato operacional entre humano e agente. Não documentação estática. Um artefato com critérios verificáveis que o agente usa como referência e contra o qual o output é validado antes de ser aceito.
Na minha leitura, esse é o mecanismo pelo qual o paradigma 70/30 se manifesta no tempo. Os 30% de geração de código aparecem no dia um, no demo, no sprint que fechou rápido. Os 70% de intenção, especificação e validação não aparecem nesse dia. Aparecem no dia noventa, como ausência, quando o time que não investiu nas pontas do ciclo está gastando um quarto do sprint limpando o que o agente gerou sem âncora.
A pergunta que faltou no kick-off pode ser reformulada agora: se o desenvolvedor que escreveu esses prompts sair da equipe amanhã, alguém consegue verificar se esse código faz o que era esperado?
Se a resposta é não, o custo do dia noventa já está agendado. Ainda não chegou.
Referências
- Keyhole Software – Vibe Coding Trends 2026 (11 jun 2026)
- Jessica Díaz et al. – Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork (arXiv 2609.00252, 31 ago 2026)
- METR – Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10 jul 2025)
- Todd Wardzinski – The Uncomfortable Truth About Vibe Coding (Red Hat Developer, 17 fev 2026)