A Retro para a Ressaca da Codificação por Vibe

Em algum lugar na sua base de código existe um módulo que ninguém quer tocar. Ele foi lançado em março, rapidamente, com um assistente de IA fazendo a maior parte da digitação. Funcionou na demonstração. Foi reescrito duas vezes desde então, aparece em cronogramas de incidentes, e o engenheiro que o "escreveu" não consegue explicá-lo completamente.

Esse módulo agora tem um nome. A indústria passou 2025 discutindo se ferramentas de codificação com IA tornam as equipes mais rápidas. Em 2026 a discussão acabou e a fatura chegou — não em dólares, mas em churn, filas de revisão e canais de incidentes. A Autonoma chama isso de "acerto de contas de 90 dias": o ponto em que a velocidade do primeiro mês se torna a dívida do terceiro mês. A Gizmodo reportou em setembro passado que empresas estão contratando engenheiros especificamente para corrigir erros de vibe-coding. Uma economia inteira de limpeza está se formando em torno de um problema que a maioria das equipes poderia capturar sozinha, quatro sprints antes, em uma cerimônia que já têm no calendário.

Este post é sobre executar essa cerimônia adequadamente.

A Ressaca É Mensurável

O impacto não é uma sensação. O Relatório de Engenharia com IA 2026 da Faros AI — dois anos de telemetria de 22.000 desenvolvedores em mais de 4.000 equipes — colocou números nas duas metades: a aceleração que todos celebraram e a deterioração que a seguiu downstream.

Fonte: Faros AI, "AI Engineering Report 2026," abril de 2026.

Leia as duas primeiras linhas e a IA está funcionando. Leia as cinco últimas e você pode ver a ressaca se formando em tempo real: o código é descartado quase nove vezes mais frequentemente, incidentes por PR mais que triplicaram, e quase um terço a mais de mudanças estão chegando à produção sem um único humano lendo-as.

O relatório DORA de 2025, agora renomeado "State of AI-Assisted Software Development", encontrou o mesmo padrão em escala de pesquisa: 90% dos desenvolvedores usam IA no trabalho, acima dos 76% do ano anterior, e a adoção de IA agora está positivamente ligada ao throughput. Mas ela "continua tendo uma relação negativa com a estabilidade de entrega de software". Mais rápido e mais instável, ao mesmo tempo, em toda a indústria.

Esta É uma Falha de Processo, Não uma Falha de Ferramenta

A IA fez exatamente o que foi solicitado. Ela produziu código plausível a uma taxa para a qual nenhum processo de revisão foi projetado. O que falhou foi tudo ao redor: ninguém decidiu quanta verificação um diff escrito por máquina merece, qual tamanho de lote mantém a revisão honesta, ou quem é responsável por código que nenhum humano escreveu.

Esses são acordos de trabalho. Acordos de trabalho são processo. E a evidência diz que processo é precisamente onde está a alavancagem. O Modelo de Capacidades de IA do DORA identifica sete condições que determinam se a IA amplifica uma equipe ou amplifica sua disfunção — e todas são organizacionais: uma postura clara e comunicada sobre IA, práticas sólidas de controle de versão, trabalho em pequenos lotes, ecossistemas de dados saudáveis. Nenhuma delas é "compre um modelo melhor".

O relatório de ROI 2026 do DORA adicionou o lado do custo. Equipes adotando IA enfrentam uma curva J (a produtividade cai antes de subir), e um grande impulsionador é o que o relatório chama de taxa de verificação: as horas humanas gastas verificando a saída da máquina. A pesquisa 2025 do Stack Overflow com mais de 49.000 desenvolvedores explica por que essa taxa é tão alta. A confiança na precisão da IA caiu de 40% para 29% em um ano, e a frustração número um, citada por 45% dos respondentes, é "soluções de IA que estão quase certas, mas não completamente". Código quase-certo é o tipo mais caro. Código errado falha rápido; código quase-certo passa na revisão e falha em produção.

Um problema de ferramenta teria uma solução de ferramenta. Um problema de acordo de trabalho tem exatamente um local onde as equipes renegociam como trabalham.

O Que É uma Retro de Ressaca de Vibe-Coding?

Uma retro de ressaca de vibe-coding é uma retrospectiva que examina como sua equipe produz código com IA, não apenas o que entregou. Ela substitui opiniões pelos próprios dados de entrega da equipe — churn de código, latência de revisão, links de incidentes, mesclagens não revisadas — e sua saída é um pequeno conjunto de acordos de trabalho para mudanças escritas por máquina, cada um mensurável no sprint seguinte.

Ela difere da sua retro regular em escopo, não em formato. Uma retro normal pergunta "como foi o sprint?" Esta pergunta algo mais preciso: "qual é nossa relação real com o código que não escrevemos?" Mesmos templates, mesma votação, mesmo timebox. Evidência diferente na mesa.

E deve acontecer em breve, não eventualmente. Os dados da Faros dizem que a deterioração se agrava: churn alimenta incidentes, incidentes alimentam carga de revisão, carga de revisão alimenta a tentação de mesclar sem revisão. Cada sprint sem uma correção de curso torna a correção maior.

Execute com Dados, Não com Vibes

Há uma ironia real em realizar uma retrospectiva sobre vibe coding e executá-la com base em vibes. Se o modo de falha foi "confiamos em resultados plausíveis sem verificação", a cerimônia que corrige isso não pode, ela mesma, funcionar com base em impressões plausíveis. Suas integrações já contêm as evidências — seus repositórios conhecem o churn, seu rastreador conhece o retrabalho, seu canal de incidentes conhece o rastro.

Coloque cinco perguntas no quadro, cada uma ancorada em um número que você pode obter antes da reunião:

1. Quais PRs dos últimos 90 dias já reescrevemos? Churn é a medida honesta de velocidade. Uma funcionalidade que você entregou duas vezes não foi entregue rapidamente.
2. Para onde a revisão está realmente indo? Se o tempo até a primeira revisão está aumentando enquanto os merges sem revisão também aumentam, seu processo de revisão está silenciosamente se racionando. Decida o racionamento de propósito.
3. Quais incidentes rastreiam de volta para mudanças que ninguém leu completamente? Não para culpar: para dimensionar o custo de verificação que você já está pagando no pior momento possível, em produção.
4. Qual é nosso acordo de trabalho para diffs escritos por máquina? Se a sala não consegue declarar isso em uma frase, você não tem um. Você tem uma vibe.
5. O último conjunto de itens de ação persistiu? /blog/why-retrospective-action-items-die. Se os seus morreram, essa é a primeira correção. Nada mais que você decidir hoje importa se evaporar até quinta-feira.

Faça as Correções Sobreviverem ao Contato com o Próximo Sprint

O resultado desta retro não é um resumo de sentimentos. São dois ou três acordos de trabalho, cada um formulado de modo que os dados do próximo sprint possam confirmá-lo ou negá-lo. O padrão que funciona: uma regra concreta, um número que se move se for seguida, e um check-in nomeado.

• "PRs gerados por agente com mais de 400 linhas são divididos antes da revisão." Check: distribuição de tamanho de PR, próxima retro.
• "Nada faz merge sem uma aprovação humana, CI verde ou não." Check: contagem de merges sem revisão, semanalmente.
• "Toda revisão de incidente pergunta se a mudança que o desencadeou foi criada por IA, e rastreamos a proporção." Check: template de postmortem de incidente, esta semana.

Lotes pequenos, revisão obrigatória, rastreabilidade de incidentes — você notará que essas são as capacidades de IA do DORA, traduzidas em frases com as quais uma equipe pode realmente concordar em uma terça-feira. Esse é o ponto. A pesquisa nomeia as capacidades; a retro é onde uma equipe as instala.

Então o ciclo se fecha da maneira /blog/ship-and-stick-measuring-whether-ai-is-working: a próxima retro abre verificando se os acordos se mantiveram e se os números se moveram. O churn diminuiu? A latência de revisão se recuperou? Persistiu? Melhoria que você não pode verificar é apenas mais uma vibe.

A Linha de Fundo

A ressaca nunca foi o preço de usar IA. É o preço de adotar uma nova forma de construir software sem nunca sentar como equipe para renegociar como você constrói software. As equipes que estão avançando em 2026 não são as que usam mais IA ou menos. São as que notaram o whiplash em seus próprios dados, convocaram a reunião e escreveram as regras — enquanto todos os outros ainda estavam discutindo sobre qual vibe estava certa.

Você não precisa de um especialista em limpeza. Você precisa de noventa minutos e seus próprios números.

Não menos IA. Mais reflexão.

Fontes

• https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways (abril de 2026)
• https://dora.dev/dora-report-2025/ e https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report (setembro de 2025)
• https://services.google.com/fh/files/misc/2025_dora_ai_capabilities_model.pdf (2025)
• https://www.infoq.com/news/2026/05/dora-roi-ai-assisted-dev-report/ (maio de 2026)
• https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/ (dezembro de 2025)
• https://gizmodo.com/after-ai-led-to-layoffs-coders-are-being-hired-to-fix-vibe-coded-screwups-2000657915 (setembro de 2025)
• https://getautonoma.com/blog/vibe-coding-technical-debt (abril de 2026)

Leitura Adicional

• /blog/why-retrospective-action-items-die — o problema de acompanhamento do qual esta retro depende para resolver.
• /blog/measuring-what-ai-actually-does — como ver o impacto real da IA em sua equipe sem vigilância.
• /blog/ship-and-stick-measuring-whether-ai-is-working — o quadro de resultado por trás de "persistiu?"
• /blog/beyond-sprints-continuous-improvement — por que a cadência de reflexão importa mais quando a implantação é contínua.