Como acompanhamos as revisões de PR na era da IA?

1. Limite cada PR a uma única coisa

A maneira mais rápida de matar o ritmo de revisão é um PR que faz três coisas ao mesmo tempo. Quem revisa não deveria ter que desembaraçar mentalmente quais mudanças pertencem ao bug fix e quais pertencem ao refactor que você enfiou junto.

• Um bug fix, um campo, uma feature, não os três no mesmo PR.

• Um PR focado de ~1.000 linhas que resolve um problema claro está tudo bem. Um PR de 300 linhas com três preocupações não está. Se você passou bem de 1.000 linhas, isso é um forte sinal para dividir.

• Use PRs empilhados para mudanças maiores.

• Faça um teste de sanidade antes de abrir: alguém consegue revisar isso de uma vez? Isso faz exatamente uma coisa? Você faria merge?

2. Não peça revisão até estar realmente pronto

Rascunhos existem por um motivo. Tirar um PR do rascunho é um sinal para o time de que você fez sua diligência e que isso merece o tempo de outra pessoa. Se esse sinal não for confiável, todo o sistema de revisão quebra.

Só tire do rascunho se você puder responder sim a tudo isso:

• Você fez uma auto-revisão

• Todos os testes passam, incluindo e2e

• Zero comentários sem resolução (incluindo os do Devin)

• Você testou localmente para mudanças de UI/UX

• Para mudanças que podem ser cobertas por testes automatizados, você verificou que estão 100% cobertas

• Todos os jobs de CI estão verdes (exceto as chatas prévias do Vercel)

Se qualquer resposta for não, deixe como rascunho. Rascunhos pedindo revisão poluem a fila e atrasam PRs que realmente estão prontos.

3. Limite seus PRs abertos em 5 (rascunhos contam)

PRs abertos são estoque. Eles trazem custo de troca de contexto, risco de conflito de merge e dívida de revisão. Se você tiver mais de cinco abertos ao mesmo tempo, a conta não fecha. Você está produzindo mais rápido do que o time consegue absorver.

Se você tiver 5 PRs abertos, somando rascunho e não rascunho, não comece nada novo. Vá revisar os PRs dos seus colegas ou conclua seu trabalho mais antigo.

4. Coloque uma voz humana na descrição do seu PR

A descrição não precisa ser escrita inteiramente por você. IA é ótima para criar a estrutura e resumir o diff. O problema do que estamos vendo agora são as descrições gigantes geradas por IA que parecem uma checklist genérica com a qual ninguém se envolveu. Está faltando o elemento humano de que um revisor realmente precisa.

• Uma nota do autor em uma frase sobre o trade-off que você escolheu, ou sobre por que essa correção importa agora, vai muito mais longe do que um bloco longo de "Key Review Points" / "Human Review Checklist".

• Se você estiver enviando código que ainda não é consumido em lugar nenhum, diga por quê.

• Se a IA redigiu a descrição, enxugue e adicione o contexto que só você tem.

5. Prove que a correção funciona

Um PR que diz "corrige o bug X" sem evidência está pedindo para o revisor acreditar por fé. Não faça isso com ele.

• Capturas de tela, gravações de tela, dashboards de antes/depois, qualquer coisa que mostre que o bug morreu e que nada mais regrediu.

• QA funcional é obrigatório para mudanças de UX/UI, não opcional.

6. Mudanças em SQL e performance precisam de validação real

Só a revisão de código não consegue confirmar que uma reescrita de query se sustenta sob carga de produção. Ler um diff de query e dizer "parece certo" não é validação. Para PRs que mexem em caminhos de query ou reescritas:

• EXPLAIN ANALYZE em um conjunto de dados com cara de produção

• Números de latência antes/depois ou capturas de tela de dashboards

• Rollout com feature flag para mudanças arriscadas

7. IA é um acelerador, não um cérebro

A IA consegue gerar código rápido. Ela não consegue decidir se esse código deveria existir. O raciocínio ainda precisa vir de você.

• Primeiro, desenhe. Esboce a abordagem, pense nos casos extremos, escreva uma nota rápida e só então faça o prompt.

• Depois que o agente gerar, leia de verdade. A auto-revisão pega chamadas Prisma no lugar errado, diretrizes do agente ignoradas, estrutura frágil etc.

• Antes de abrir, pergunte: o que isso impacta? Algum efeito no usuário? Implicações de performance ou segurança? Qual é o raio de impacto se estiver errado?

8. Valide PRs de segurança antes de abri-los

Confirme se a vulnerabilidade realmente se aplica à forma como usamos o código. PRs de "corrigir vulnerabilidade X" que mexem em caminhos sensíveis podem introduzir mais risco do que o relatório original.

9. Direcione PRs para o revisor certo

O revisor errado desperdiça o tempo de duas pessoas: do revisor, que não consegue dar feedback útil, e do autor, que precisa esperar uma segunda rodada com a pessoa certa.

• PRs pesados em domínio (roteamento Salesforce/CRM, migrações de perfil de equipe etc.) devem ir para o dono do domínio, e não para a Foundation carimbar uma suíte de testes gerada por IA.

• Mudanças em caminhos centrais/da Foundation (query infra, hasTeamAccess etc.) merecem um alinhamento rápido com o time responsável antes de o PR abrir.

10. Conversas de arquitetura acontecem cedo

Remendar a mesma área três vezes é um sinal, não uma coincidência. Se você estiver contornando a mesma limitação de novo, a ação certa é uma conversa e uma possível reescrita, não outro remendo.

Fale com a Foundation/Head of Engineering antes de implementar. Foi assim que os módulos de infra se juntaram, e a consistência se acumula.

11. Caminho mais leve para correções triviais

Nem tudo precisa de revisão da Foundation. Devemos gastar banda de revisão onde ela mais importa.

Ajustes de toast, tamanho de botão, renomeações mecânicas, mudanças de copy, features de mainline - isso pode passar por revisão da IA e/ou revisões no nível do time. Reserve a revisão da Foundation para mudanças que realmente precisam dela.

12. Não abra PRs em nome de outras pessoas

Se o engenheiro X está fazendo o trabalho, o engenheiro X abre o PR. Caso contrário, os comentários vão parar com a pessoa errada, as perguntas ficam sem resposta e o PR emperra.