Revisar código na ordem em que chega

Durante o processo de desenvolvimento, eu costumo revisar o código na ordem em que as novas funcionalidades ou ajustes são entregues. Sempre fiz assim e nunca tinha parado pra pensar se essa ordem fazia sentido ou não.

Pra quem não é desenvolvedor: antes de uma mudança entrar na aplicação, alguém do time precisa ler o que foi escrito e dizer se está liberado pra seguir. Essa "leitura" é a revisão de código. Como escrever sempre levou bem mais tempo do que revisar, isso consumia uma parte pequena do dia.

Com a chegada das ferramentas de geração de código por IA, a escrita em si ficou barata. Una isso à verbosidade dos assistentes e ao volume bem maior de solicitações. Pronto. Um processo que deveria levar minutos ou horas passa a consumir uma parte considerável do dia.

A fila de alterações aguardando revisão cresceu, mas não mudou de formato. Continuo revisando na ordem de chegada. Uma correção de texto numa tela e uma mudança de regra de negócio aparecem uma abaixo da outra, com o mesmo destaque, pedindo a mesma ação.

O que eu percebi olhando o meu próprio jeito de trabalhar é desconfortável. As mudanças fáceis, que dão pra entender por completo, acabam recebendo (proporcionalmente) muito mais atenção. Já as mais complexas recebem uma "leitura dinâmica", porque ler tudo levaria o dia inteiro e a fila não para de acumular. A atenção segue a ordem da fila, que não tem nada a ver com o tamanho da atividade, ou com o "estrago" se houver erro.

A resposta natural é "então revisa com mais cuidado". Já me cobrei várias vezes. Não funciona. Tomar mais cuidado dando a mesma prioridade pro perigoso e pro simples não resolve.

Pensando nisso, li na semana passada o texto do Gergely Orosz no Pragmatic Engineer sobre o que está acontecendo com a revisão de código. Ele parte de um dado do GitHub: o volume de mudanças propostas cresceu perto de cinco vezes em três anos, e disparou do fim de 2025 pra cá. Daí ele lista práticas que vários times estão adotando. Nenhum dos caminhos envolve "ler mais".

O mais comum tem sido botar uma IA pra revisar antes e o humano fazer a "revisão da revisão". O problema é o ruído. Ele cita a Uber filtrando comentários de baixa confiança antes de alguém ver. Outra abordagem é separar a fila pelo impacto potencial. O que mexe em acesso ou no formato dos dados passa por gente. O de baixo risco pode seguir só com a IA. Ele cita OpenAI e Anthropic com esse tipo de regra. Um terceiro grupo passou a revisar o plano, os testes e o desenho do banco antes de o agente escrever. E tem quem só produza mudanças menores, porque cabem numa leitura.

O próprio Gergely fecha dizendo que não existe uma resposta que sirva pra todo mundo.

Eu ainda não escolhi qual abordagem seguir, mas o texto ajudou a moldar a minha percepção. Antes, isso me parecia falta de cuidado meu. Mas a fila é que não vinha sendo priorizada de forma adequada, e eu estava tentando compensar isso com a minha atenção.