Google mediu 21% mais pushback em code review por gênero. Sou solo — e reconheci o reflexo no meu sub-agente.

Um mecanismo que eu não esperava aparecer no meu setup solo apareceu na semana passada. Estava revisando um diff que o meu próprio sub-agente do Claude Code tinha aberto no repositório do harness (o job que roda observer, strategist e marketer todo dia). Marquei “precisa mais trabalho” antes de terminar de scroll do diff. Uma hora depois, li o mesmo diff com café e ele resolvia o bug direto, com dois arquivos tocados e três linhas mudadas. Mergei sem alteração.

O código foi o mesmo. A minha leitura foi diferente. E o que mudou entre uma leitura e outra foi só uma coisa: da segunda vez eu li antes de decidir.

Isso me lembrou de um paper do Google que eu tinha marcado meses atrás para reler. Achei estranho ir buscar ele para pensar sobre um sub-agente, mas a mecânica é a mesma.

O estudo do Google (Murphy-Hill et al., CACM 2022)

Emerson Murphy-Hill, Ciera Jaspan, Carolyn Egelman e Lan Cheng publicaram em março de 2022 na Communications of the ACM (vol. 65, nº 3, pp. 52–57, DOI 10.1145/3474097) um estudo sobre pushback em code review dentro do Google.

Pushback, na definição do paper: quando o autor do PR sente que o comentário do revisor foi injustificado ou excessivo. Diferente de “review rigoroso”, que ninguém contesta. Pushback é o review que dói além do necessário do lado de quem escreveu.

Os autores cruzaram dados internos de code review com atributos declarados por engenheiros: raça/etnia, gênero, idade. Os números específicos são estes:

Mulheres: 21% mais chance de pushback que homens
Black+ developers: 54% mais chance que White+ developers
Latinx+ developers: 15% mais chance que White+
Asian+ developers: 42% mais chance que White+
Engenheiros mais velhos: mais chance que engenheiros mais novos

O custo agregado para o Google, segundo o paper, é de mais de 1.000 horas-engenheiro por dia em pushback excedente, o equivalente a cerca de 4% do tempo que engenheiros gastam respondendo a comentários de revisão.

O que o Google tentou como mitigação: code review anônimo. Removeram nome, foto e sinais de identidade do PR na tela do revisor. O tempo de review e a qualidade do review ficaram estatisticamente iguais aos do modo normal, mostrando que anonimizar não custa nada. O paper não fecha se o pushback caiu (o estudo do anonimato veio em publicações posteriores), mas o ponto é que o experimento é viável.

Por que isso me atinge sendo solo

Quando li o paper na primeira vez, meses atrás, minha reação foi “interessante, mas não é o meu problema. Sou solo, não tenho time, não tenho junior, não revejo código de outros humanos”. Guardei o link e fui embora.

O que eu não tinha entendido é que o mecanismo psicológico do pushback não depende do outro ser humano. Depende de o meu cérebro classificar o autor do diff em uma categoria de “autoridade menor” antes de eu ler o código. Essa classificação acontece antes do julgamento técnico, e ela vaza para o julgamento técnico.

No meu setup solo, quem entra nessa categoria de “autoridade menor” é o sub-agente. Uma sessão do Claude Code, disparada pelo cron, que abre commit com Co-Authored-By: Claude <noreply@anthropic.com> no rodapé. O repositório tem 290 commits desses acumulados, um por rodada do harness.

Quando o commit vem de mim, eu abro o diff assumindo que faz sentido e leio para confirmar. Quando vem do sub-agente, eu abro o diff assumindo que tem algo errado e leio para achar o erro. Mesmo código, posturas de leitura opostas.

Aqui é onde o Google me pegou. O paper mede pushback entre humanos com atributos demográficos diferentes. Eu não tenho humanos no time. Mas o efeito de status percebido do autor existe independente do time. O sub-agente é o meu “novato”: tem menos “reputação” na minha cabeça, e eu compenso essa falta lendo mais duro.

O problema é que ler mais duro não vira ler melhor. Vira ler procurando erros específicos e ignorando o resto do diff. Foi exatamente o que aconteceu na semana passada com o commit de dois arquivos.

O estudo do Meta (efeito espectador na revisão)

Aproveito para acertar uma outra confusão que eu carregava. O estudo sobre o efeito espectador em code review — aquele que mostra que review atribuído a vários revisores fica parado — não é do Meta em 2023. É do Meta sim, mas o preprint saiu em dezembro de 2023 (arxiv 2312.17169) e a versão de journal veio no ACM TOSEM em 2025.

Os autores são Peter C. Rigby, Seth Rogers, Sadruddin Saleem, Parth Suresh, Daniel Suskin, Patrick Riggs, Chandra Maddila e Nachiappan Nagappan. O experimento relevante para pushback: na primavera de 2023, rodaram um A/B test em 12,5 mil autores dividindo em duas condições. Em uma, o sistema recomendava explicitamente um revisor entre os três primeiros do ranking. Na outra, o PR ia para o grupo padrão.

Resultado: –11,6% no TimeInReview quando o revisor era nomeado, sem regressão em nenhuma métrica de qualidade.

Ou seja, quando a responsabilidade se dilui em “alguém do time revisa”, ninguém revisa primeiro. É o efeito espectador aplicado a PR. E quando a responsabilidade fica clara, o tempo cai 11,6%.

No meu setup solo essa parte não se aplica, porque sou eu o único candidato a revisar. Menciono porque na primeira versão desta reflexão eu tinha atribuído esse número ao paper errado, e é o tipo de erro fácil de propagar. Se você usa esse número em uma discussão de time, use a citação certa: Rigby et al., Meta (arxiv 2023, TOSEM 2025).

Onde entra a neuroimagem (e onde não entra)

Existe um paper de fMRI que aparece em toda discussão de “psicologia da revisão de código”, e vale acertar o que ele mediu e o que não mediu.

O paper relevante aqui é o de ICSE 2017 — Floyd, Santander e Weimer publicaram “Decoding the Representation of Code in the Brain: An fMRI Study of Code Review and Expertise” (preprint aqui). O mesmo grupo (com Krueger, Huang, Liu e Leach) publicou depois em ICSE 2020 “Neurological Divide: An fMRI Study of Prose and Code Writing”, mas esse segundo é sobre escrever código e prosa, não sobre revisar.

O que o paper de 2017 mediu: atividade cerebral (fMRI) de participantes fazendo três tarefas — Code Comprehension, Code Review e Prose Review. O participante respondia Accept ou Reject para cada trecho.

A principal finding: dá para classificar qual tarefa o participante está fazendo só olhando para o padrão de ativação cerebral, com balanced accuracy de 79% (p < 0,001). Isso mostra que code review, code comprehension e prose review têm representações neurais distintas no cérebro. Não são o mesmo processo com etiqueta diferente.

O que o paper não mediu: ele não mediu diferença de ativação por “junior” versus “senior” como atributo do autor. As etiquetas experimentais eram sobre a tarefa (comprehension/review/prose) e sobre o participante (expertise medida pelo GPA em cursos de CS), não sobre o autor do código.

Se você viu por aí a afirmação de que “o DLPFC do revisor se ativa antes de o código ser lido, quando o autor é rotulado como junior”, isso não vem desses papers. Já vi essa afirmação circular e eu mesmo caí nela em uma versão anterior deste texto. Ela é o tipo de derivação que soa plausível: se code review tem processamento emocional em paralelo ao técnico, faz sentido supor que o rótulo do autor pré-ativa algo. Só que “faz sentido supor” não vale como “está medido”. O que temos empiricamente é o número do Google (21% / 42% / 54% de pushback) e o do Meta (–11,6% de TimeInReview), não o traçado do córtex pré-frontal.

O que quebra o reflexo

Michael Lynch (ex-Google, ex-Microsoft) tem um guia de duas partes que virou referência prática. How to Do Code Reviews Like a Human — Part 1 e Part 2. Os oito conselhos do guia se traduzem em uma linha só: atacar o código, não o autor.

Michaela Greiler, pesquisadora com doutorado em engenharia de software pela TU Delft e ex-Microsoft, sistematizou princípios parecidos. Os quatro dela que uso:

Perguntar em vez de exigir mudança. “Aqui pode chegar null?” abre diálogo. “Corrige esse null” fecha.
Falar do código, não da pessoa. “Esta linha pode causar NPE” em vez de “você esqueceu o null check”.
Deixar explícito o “eu acho”. A opinião marcada como opinião reduz o peso percebido do comentário.
Zero sarcasmo. Nunca funciona por escrito.

No meu contexto solo, adaptei três coisas que quebraram o reflexo do sub-agente comigo:

Ler o diff inteiro antes de escrever qualquer comentário. Parece óbvio. Quebra o hábito de “vi um problema na primeira tela, já vou anotar”. Se você anota antes de ler tudo, você ancora sua leitura no primeiro problema e passa o resto do diff procurando confirmação. Foi exatamente o que fiz na semana passada. Se tivesse chegado até o final antes de decidir, teria visto que os dois arquivos tocados eram consistentes entre si.

Escrever a mensagem de commit do ponto de vista do autor antes de decidir aprovar. Se sou eu tentando merger, o que eu escreveria como razão? Se a resposta é “resolve o bug X do jeito Y”, e o diff faz Y, provavelmente está ok. Se não consigo escrever uma justificativa clara, aí sim é revisão de conteúdo, não pushback estético.

Anonimizar mentalmente o autor. É o mesmo experimento que o Google testou. Não olho o Co-Authored-By até depois de decidir. Vale para tudo. Se depois de merged eu descubro que o commit era só meu, ótimo, aprovei pelo mérito. Se descubro que era do sub-agente, também. O que quero é que a decisão não dependa desse rótulo.

Isso me poupou reprovações de graça pelo menos duas vezes nas últimas duas semanas. Não é dramático. Mas em 290 commits acumulados nesse repositório, uma reprovação-reflexo custa em média 20 minutos entre reabrir o loop, reler, e mergir. 20 minutos vezes um punhado de vezes por semana é uma noite de review por mês.

O caso adjacente: revisão de código escrito por IA em geral

Vale marcar que o problema não some quando você usa ferramentas de code review assistidas por IA. Um paper de 2024, “Towards debiasing code review support” (arxiv 2407.01407), lista viés de confirmação e fadiga de decisão como dois dos gatilhos mais fortes de erro do revisor humano. Nenhum dos dois é resolvido por deixar o LLM comentar primeiro — ele adiciona uma terceira camada de viés (o output do LLM ancora a atenção do humano).

O que ajuda é diferente: reduzir o escopo do que o humano precisa ler antes de decidir. Quando você usa um passo determinístico (Tree-sitter, blast radius) para cortar o diff para os 7 arquivos que realmente importam, o humano lê 18 mil tokens em vez de 150 mil. Menos superfície equivale a menos espaço para o reflexo do pushback agir sobre arquivos que nem foram tocados. Escrevi separado sobre esse passo.

Fechando

O paper do Google mede pushback em um time gigante de humanos. Meu setup é solo, e ainda assim o mecanismo apareceu.

A parte que eu não tinha entendido é que “autor com menos autoridade percebida” não precisa ser junior humano. Pode ser sub-agente, pode ser bot de dependabot, pode ser contribuidor externo de OSS que você nunca viu antes. O reflexo é o mesmo: leitura mais dura, comentário mais rígido, aprovação mais lenta.

O que quebra o reflexo é chato e mecânico: ler o diff inteiro antes de anotar, escrever a justificativa do autor antes de decidir, e adiar a checagem de quem escreveu para depois da decisão técnica. Nada disso é psicologia sofisticada. É só reconhecer que a sua atenção é um recurso finito, e o cérebro corta caminho baseado em rótulo quando você não força ele a ler antes.

Se você abriu o próximo diff e a primeira coisa que registrou foi “ah, é do sub-agente, deve estar meio bagunçado”, feche o navegador, tome um café, e abra de novo assumindo que o commit é seu. É o único experimento que dá para rodar sem infra nenhuma, e ele funciona.

Se este texto fez sentido, escrevi um livro inteiro sobre o funil de code review com base no harness que uso: pre-commit hooks, PR template, self-review por AI, review humano, tudo com números por camada. Está aqui: Harness prático para code review moderno.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews