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

1. Define o âmbito de cada PR para uma só coisa

A forma mais rápida de matar o ímpeto da revisão é um PR que faz três coisas ao mesmo tempo. Os revisores não deviam ter de desenredar mentalmente quais as alterações que pertencem à correção do bug e quais pertencem ao refactor que meteste lá pelo meio.

• Uma correção de bug, um campo, uma funcionalidade, não as três no mesmo PR.

• Um PR focado, com cerca de ~1.000 linhas, que resolva um problema claro, está bem. Um PR de 300 linhas com três preocupações não está. Se estiveres muito para lá das 1.000 linhas, isso é um forte sinal para dividir.

• Usa PRs em stack para alterações maiores.

• Faz um teste rápido antes de abrir: alguém consegue rever isto numa só sessão? Faz exatamente uma coisa? Ias fazer merge?

2. Não peças revisão até estar mesmo pronto

Os drafts existem por uma razão. Tirar um PR de draft é um sinal para a equipa de que fizeste o teu trabalho de casa e que isto merece o tempo de outra pessoa. Se esse sinal não for fiável, o sistema de revisão inteiro desmorona-se.

Só tires do draft se conseguires dizer sim a tudo isto:

• Fizeste uma auto-revisão

• Todos os testes passam, incluindo e2e

• Zero comentários por resolver (incluindo os do Devin)

• Testaste localmente as alterações de UI/UX

• Para alterações que possam ser cobertas por testes automatizados, verificaste que estão 100% cobertas

• Todos os jobs de CI estão verdes (exceto os irritantes previews da Vercel)

Se alguma resposta for não, deixa-o como draft. Drafts a pedir revisão poluem a fila e atrasam PRs que estão mesmo prontos.

3. Limita os teus PRs abertos a 5 (drafts contam)

PRs abertos são inventário. Trazem custo de mudança de contexto, risco de conflito de merge e dívida de revisão. Se tiveres mais de cinco abertos ao mesmo tempo, a conta não fecha. Estás a produzir mais depressa do que a equipa consegue absorver.

Se tens 5 PRs abertos, draft e não draft juntos, não comeces nada novo. Em vez disso, vai rever os PRs dos teus colegas ou avança o teu trabalho antigo.

4. Dá voz humana à descrição do teu PR

A descrição não tem de ser escrita totalmente por ti. A IA serve bem para dar estrutura e resumir o diff. O problema com o que estamos a ver agora são as descrições maciças geradas por IA, que parecem uma checklist genérica com a qual ninguém se envolveu. Falta-lhes o elemento humano de que um revisor realmente precisa.

• Uma nota do autor numa só frase sobre a troca que escolheste, ou sobre por que razão esta correção importa agora, vale mais do que um bloco longo de "Key Review Points" / "Human Review Checklist".

• Se estás a enviar código que ainda não é usado em lado nenhum, diz porquê.

• Se a IA redigiu a descrição, reduz-a e acrescenta o contexto que só tu tens.

5. Prova que a correção funciona

Um PR que diz "corrige o bug X" sem provas está a pedir ao revisor que acredite por fé. Não o faças passar por isso.

• Capturas de ecrã, gravações de ecrã, dashboards antes/depois, o que quer que mostre que o bug morreu e que nada mais regrediu.

• QA funcional é obrigatório para alterações de UX/UI, não opcional.

6. Alterações de SQL e de performance precisam de validação real

A revisão de código por si só não confirma que uma reescrita de query aguenta a carga de produção. Ler um diff de uma query e dizer "parece certo" não é validação. Para PRs que mexem em caminhos de query ou reescritas:

• EXPLAIN ANALYZE num dataset com forma de produção

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

• Rollout com feature flag para alterações arriscadas

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

A IA consegue gerar código depressa. Não consegue decidir se esse código deve existir. O raciocínio continua a ter de vir de ti.

• Primeiro o design. Esboça a abordagem, pensa nos casos extremos, escreve uma nota rápida e só depois faz o prompt.

• Depois de o agente gerar, lê mesmo o resultado. A auto-revisão apanha chamadas Prisma no sítio errado, diretrizes do agente ignoradas, estrutura frágil, etc.

• Antes de abrir, pergunta: o que é que isto toca? Há impacto no utilizador? Implicações de performance ou segurança? Qual é o raio de impacto se estiver errado?

8. Valida PRs de segurança antes de os abrires

Confirma que a vulnerabilidade se aplica realmente à forma como usamos o código. PRs do tipo "corrige a vulnerabilidade X" que tocam caminhos sensíveis podem introduzir mais risco do que o relatório original.

9. Envia os PRs para o revisor certo

O revisor errado faz perder tempo a duas pessoas: o revisor que não consegue dar feedback útil e o autor que tem de esperar por uma segunda ronda com a pessoa certa.

• PRs muito centrados em domínio (Salesforce/CRM routing, migrações de perfis de equipa, etc.) pertencem ao dono desse domínio, não a uma validação automática da Foundation sobre um conjunto de testes gerado por IA.

• Alterações a caminhos centrais/de base (query infra, hasTeamAccess, etc.) merecem um alinhamento rápido com a equipa dona antes de o PR ser aberto.

10. As conversas de arquitetura acontecem cedo

Fazer remendos na mesma área três vezes é um sinal, não uma coincidência. Se estás outra vez a contornar a mesma limitação, o movimento certo é uma conversa e uma possível reescrita, não mais um remendo.

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

11. Caminho mais leve para correções triviais

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

Ajustes em toast, tamanho de botões, renomeações mecânicas, alterações de copy, funcionalidades de mainline - isto pode passar por revisão por IA e/ou revisões ao nível da equipa. Reserva a revisão da Foundation para as alterações que realmente precisam dela.

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

Se o Engineer X está a fazer o trabalho, é o Engineer X que abre o PR. Caso contrário, os comentários vão parar à pessoa errada, as perguntas ficam sem resposta e o PR bloqueia-se.