Doze Acordos de Trabalho para Código Escrito por Máquina

A retro foi a parte fácil.

Sua equipe realizou a retro da ressaca de vibe-coding. Os dados de churn estavam no quadro, a sala concordou que a fila de revisão estava silenciosamente se racionando, e todos saíram com aquela rara sensação pós-retro de ter decidido algo. Dois sprints depois, os acordos vivem em um documento resumo que ninguém abre, e o gráfico de churn não notou nada.

Esse modo de falha está bem documentado: cerca de dois terços dos itens de ação de retrospectivas morrem sem mudar nada. Acordos de trabalho morrem mais rápido, porque um acordo é uma norma, e uma norma não recebe número de ticket nem responsável a menos que você dê um.

Este é o manual de regras da metade da retro da ressaca. Doze acordos de trabalho para equipes que entregam código escrito por máquina, construídos a partir da mesma pesquisa pública que nomeou o problema. Os três exemplos do post original estão aqui, acompanhados por mais nove, todos no mesmo formato: uma regra que a equipe pode declarar em uma frase, o número que se move quando a regra é seguida e o check-in onde você olha.

O Que É um Acordo de Trabalho para Código Escrito por Máquina?

Um acordo de trabalho para código escrito por máquina é uma regra que uma equipe escreve para si mesma sobre como mudanças geradas por IA são produzidas, revisadas e apropriadas. Ele difere de uma política tanto na origem quanto na aplicação: uma política é imposta de cima e auditada, enquanto um acordo de trabalho é negociado em uma retrospectiva, verificado contra os próprios dados de entrega da equipe e reescrito quando esses dados dizem que não está funcionando.

O caso de pesquisa para eles é direto. O relatório de 2025 da DORA descobriu que 90% dos desenvolvedores agora usam IA no trabalho, com adoção positivamente ligada ao throughput e negativamente ligada à estabilidade de entrega. Seu Modelo de Capacidades de IA identifica o que separa equipes que a IA amplifica de equipes que ela desestabiliza, e cada capacidade na lista é organizacional: uma postura de IA clara e comunicada, lotes pequenos, práticas fortes de controle de versão. Um acordo de trabalho é a menor unidade de postura organizacional — uma frase com a qual toda a equipe concordou em ser responsabilizada.

Uma Regra, um Número, um Check-In

A maioria dos acordos de trabalho falha estruturalmente, não culturalmente. Estão faltando uma de três partes.

A regra precisa caber em uma frase que um colega de equipe possa declarar de cabeça. Se leva um parágrafo, é orientação, e orientação perde para um prazo toda vez.

O número torna a regra falsificável. A verificação é exatamente onde a intuição engana: a pesquisa de 2025 do Stack Overflow com mais de 49.000 desenvolvedores descobriu que a principal frustração com ferramentas de IA, citada por 45%, é código que está "quase certo, mas não exatamente" — e código quase-certo parece bom até a produção discordar. Sentimentos não arbitram isso. Números sim.

O check-in dá ao número uma data e um local, geralmente os primeiros cinco minutos da próxima retro. Uma regra sem um número é uma opinião. Um número sem um check-in é papel de parede.

Os Doze

Roube livremente. Os números nas regras (400 linhas, 90 dias, duas tarefas) são pontos de partida para ajustar, não leis.

A Revisão Está se Racionando. Racionalize-a de Propósito.

A telemetria da Faros AI de 2026 em 22.000 desenvolvedores encontrou tempo mediano até a primeira revisão aumentado em 156,6% e PRs mesclados sem nenhuma revisão aumentados em 31,3%. Quando a capacidade de revisão se esgota, as equipes não decidem pular a revisão — ela se decide sozinha, um "parece bom" de cada vez.

1. "Nada é mesclado sem uma aprovação humana, CI verde ou não." O acordo básico. Quase um terço a mais de mudanças agora chegam à produção sem que um único humano as leia, e código quase-certo é precisamente o tipo que passa no CI. Verificar: contagem de mesclagens sem revisão, semanalmente.

2. "PRs escritos por máquina com mais de 400 linhas são divididos antes da revisão." Lotes pequenos são a capacidade mais importante no modelo DORA, e o tamanho do lote é a entrada que uma equipe controla mais diretamente. Um revisor consegue segurar 400 linhas honestamente; ninguém segura 2.000. Verificar: distribuição de tamanho de PR, próxima retro.

3. "Mudanças que tocam autenticação, pagamentos ou migrações de dados recebem um segundo revisor, independentemente de quem foi o autor." Escale a verificação com o raio de impacto, não com a confiança na ferramenta. Os caminhos críticos são onde seus incidentes já se concentram; nomeie-os explicitamente no acordo. Verificar: taxa de duas aprovações em PRs de caminhos críticos, próxima retro.

A Responsabilidade Sobrevive ao Autocompletar

O módulo que ninguém quer tocar tem um autor que não consegue explicá-lo. Esses dois acordos mantêm a autoria significando algo.

4. "Se você não consegue explicar o diff, não pode mesclá-lo." Explicação é a verificação mais barata disponível: custa dez minutos e pega a classe de bug que a revisão passa por cima. Se explicar uma mudança leva mais tempo do que regenerá-la, isso é informação sobre a mudança. Verificar: na preparação de demo, um PR mesclado escrito por máquina por engenheiro é explicado em voz alta, cada sprint.

5. "A descrição do PR registra o que o humano verificou, não o que o modelo gerou." "Executei a migração localmente, testei o rollback, verifiquei o plano de consulta" diz a um revisor onde a atenção humana foi. O relatório de ROI 2026 da DORA chama o custo de verificar a saída da máquina de taxa de verificação; este item de linha torna a taxa visível em vez de ambiente. Verificar: participação de PRs mesclados com nota de verificação, próxima retro.

Churn É a Métrica de Velocidade Honesta

O churn de código aumentou 861% nos dados da Faros. Uma funcionalidade que foi entregue duas vezes não foi rápida na primeira vez, independentemente do que o relatório da sprint disse.

6. "Uma reescrita em 90 dias é retrabalho, e retrabalho gera um ticket." A janela de 90 dias vem do padrão que a Autonoma chama de acerto de contas de 90 dias: velocidade do mês um se tornando dívida do mês três. Retrabalho que nunca aparece no rastreador é um custo que a equipe paga mas nunca conta. Verificar: tickets de retrabalho e taxa de churn por módulo, próxima retro.

7. "Código descartável é declarado descartável no nascimento." Spikes e protótipos são um uso legítimo da velocidade da IA. Rotule-os quando forem criados, para que as estatísticas de churn permaneçam honestas e nenhum spike seja promovido para produção porque todos esqueceram o que era. Verificar: participação de churn vindo de spikes rotulados, mensalmente.

Incidentes São Onde a Taxa É Cobrada

Proporção incidentes-para-PR: aumentou 242,7%. Bugs por desenvolvedor desde a adoção: aumentou 54%. A verificação que você pula no momento da revisão é realizada em produção, na pior taxa horária possível.

8. "Toda revisão de incidente pergunta se a mudança que o desencadeou foi escrita por máquina, e rastreamos a proporção." Não para culpar — a proporção substitui a anedota mais alta da sala pelo próprio número da equipe, e é o número que diz se os acordos 1 a 5 estão funcionando. Verificar: campo de template de postmortem; proporção revisada mensalmente.

9. "Um humano é responsável pela asserção de cada teste." A IA escreve testes plausíveis da mesma forma que escreve código plausível, e um teste que não afirma nada é pior do que nenhum teste, porque compra confiança sem comprar verificação. Rascunhar testes é delegável. Decidir o que deve ser verdadeiro não é. Verificar: contagem de bugs escapados, próxima retro.

Não Inunde a Fila

10. "Duas tarefas de agente em andamento por pessoa, no máximo." A velocidade de digitação costumava ser um limite natural de trabalho em andamento; os agentes a removeram. Um engenheiro agora pode abrir PRs mais rápido do que três podem revisá-los, e o excesso se torna latência de revisão ou mesclagens não revisadas — os mesmos dois números já se movendo na direção errada. Um limite WIP na delegação mantém o orçamento de verificação humana solvente. Verificar: PRs abertos por autor, semanalmente.

Acordos Sobre os Acordos

Os dois últimos existem porque os primeiros dez, de outra forma, se juntarão aos dois terços de itens de ação que morrem.

11. "Todo acordo tem uma data de expiração." Três sprints é um padrão sensato. Na expiração, a equipe revota: manter, reescrever ou aposentar. Um acordo que se renova automaticamente para sempre é uma política disfarçada, e uma lista cheia de regras mortas ensina à equipe que a lista é decoração. Verificar: a lista ativa e suas idades, cada retro.

12. "A retro começa com o scorecard." Primeiros cinco minutos, antes de novos tópicos: cada acordo ativo, seu número e se ele se moveu. Este é o loop entregando e fixando em vez de entregando e evaporando. Verificar: é o primeiro item da agenda, toda retro.

Rotule o Código, Nunca o Programador

Vários desses acordos rastreiam se uma mudança foi escrita por máquina. Nenhum deles rastreia quem usou o modelo, e essa distinção sustenta todo o sistema. Dados no nível da mudança descrevem como o processo da equipe lida com um novo tipo de código. Dados no nível da pessoa se tornam um ranking, e um ranking corrompe cada número que exibe: no momento em que os engenheiros suspeitam que a taxa de incidentes alimenta uma avaliação de desempenho, eles param de rotular honestamente, e a retro volta a funcionar com base em impressões.

Este é o mesmo argumento que fizemos sobre medir o impacto da IA em geral: meça resultados no nível da equipe, nunca atividade no nível da pessoa. Os acordos acima só funcionam porque todos na sala sabem que os números julgam o processo, não as pessoas.

Como Adotar Esses Sem Matá-los

Adote dois ou três, não doze. Uma equipe mantendo doze novas regras não verifica nenhuma delas; o menu existe para que você possa combinar acordos com seus próprios piores números.

• Comece pelos seus dados, não por este post. Se o churn está estável mas os incidentes estão subindo, você quer 8 e 9, não 6 e 7. Puxe os números antes da retro e deixe a equipe escolher.
• Vote na retro. Um acordo imposto por um gerente é uma política fantasiada — obtém conformidade, não apropriação. A equipe que escreveu a regra é a equipe que a defende sob pressão de prazo.
• Registre a linha de base na adoção. "Merges sem revisão: 14 no último sprint" transforma a primeira verificação em uma comparação em vez de um debate. Sem linha de base? Então encontrá-la é o primeiro item de ação.
• Dê a cada acordo um responsável. Não um fiscal — um relator. Uma pessoa traz o número para a retro para que o scorecard nunca dependa da memória coletiva.

FAQ

Quantos acordos de trabalho uma equipe deve ter de cada vez?

Dois ou três acordos ativos por vez. Cada um precisa de um número puxado, uma verificação realizada e um responsável relatando, e esse orçamento de atenção se esgota rápido. Equipes que adotam uma lista longa não verificam nada; equipes que adotam três e os aposentam ou substituem no vencimento constroem o hábito que torna os próximos três baratos.

Pull requests devem ser rotulados como gerados por IA?

Sim, no nível da mudança — um rótulo ou uma nota na descrição do PR é suficiente para tornar as taxas de churn e incidentes computáveis. Nunca no nível da pessoa: rastreamento de uso de IA por engenheiro corrompe os dados que coleta, porque as pessoas manipulam o que é observado. A questão útil é como o processo lida com mudanças escritas por máquina, não quem as produziu.

E se o número não se mover?

Então a verificação funcionou. Ou a regra não foi seguida, o que geralmente significa que era cara demais como escrita e precisa ser renegociada, ou foi seguida e não ajudou, o que significa aposentá-la e gastar a atenção em outro lugar. Um acordo que pode falhar visivelmente é o único tipo que pode ter sucesso de forma crível.

Esses funcionam sem sprints?

Sim. As verificações se conectam a qualquer ritmo de reflexão que a equipe tenha — semanal, por release ou orientado a eventos. A cadência importa menos que o local: um momento recorrente onde os números estão no quadro e a equipe tem permissão para mudar as regras.

A Linha de Fundo

O argumento da retro da ressaca era que a dívida técnica de vibe-coding é uma falha de processo, e a retrospectiva é onde o processo é renegociado. Esta é a outra metade: o que sai daquela sala tem que ser falsificável, ou a próxima retro re-argumenta do zero. As equipes superando a ressaca não são as com as regras de IA mais rígidas ou mais frouxas. São as que escrevem regras que podem perder um argumento com os dados — e as deixam perder.

Roube três. Defina o vencimento. Abra a próxima retro com o scorecard.

Fontes

• Faros AI — "Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (abril de 2026)
• DORA — State of AI-assisted Software Development 2025 (setembro de 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — "New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment" (maio de 2026)
• Stack Overflow — 2025 Developer Survey results (dezembro de 2025)
• Autonoma — "Vibe Coding Technical Debt: The 90-Day Reckoning" (abril de 2026)

Leitura Adicional

• A Retro para a Ressaca do Vibe-Coding — a retrospectiva de onde vem este manual de regras.
• Por Que 2/3 dos Itens de Ação de Retrospectivas Morrem (E Como Consertar) — a mecânica de acompanhamento por trás dos acordos 11 e 12.
• Medindo o Que a IA Realmente Faz com Sua Equipe — o argumento de medição no nível da equipe, neutro em relação à IA, completo.
• Ship and Stick: Como Medir Se a IA Está Realmente Funcionando — o padrão de resultado em que o scorecard se fecha.