Acompanhei recentemente um time de doze engenheiros que adotou pair programming obrigatório em resposta a uma sequência de incidentes em produção. O racional, apresentado em reunião de planejamento, foi que duas pessoas olhando pro mesmo código produziriam menos defeitos, com o efeito colateral desejado de forçar a transferência de contexto entre seniores e juniores. Três meses depois, a métrica de defeitos não tinha melhorado de forma estatisticamente relevante e dois dos seniores tinham pedido pra trabalhar sozinhos em tarefas classificadas como exploratórias, enquanto os juniores relatavam em 1:1s que as sessões de par tinham se tornado exercícios silenciosos nos quais o sênior digitava enquanto o outro assistia. A prática foi mantida por mais um trimestre por inércia política, depois abandonada sem uma retrospectiva honesta.
Pra mim, esse desfecho é característico de uma classe de falha que aparece sempre que uma prática colaborativa é adotada pela forma, sem o mecanismo embaixo. Pair programming, mob programming e code review compartilham uma propriedade que as define: são canais de circulação de contexto técnico dentro do time. Operam bem quando o time as trata como infraestrutura de aprendizado e calibragem, e mal quando as trata como controle de qualidade ou vigilância disfarçada. Na minha análise, a diferença entre os dois regimes está menos na prática em si e mais em quem decide quando usar, com que objetivo, e em que grau de reciprocidade.
O mecanismo do pair programming, quando funciona, é o alinhamento contínuo de dois modelos mentais sobre o mesmo problema, com verbalização obrigatória das decisões. O ganho está na exposição dos atalhos cognitivos que cada engenheiro toma em silêncio ao escrever código, e na possibilidade de que o outro os questione no momento em que ocorrem, antes que se consolidem em padrão. Isso pressupõe reciprocidade: ambos os engenheiros precisam ter mandato pra interromper, pra discordar e pra propor caminho alternativo. Quando a hierarquia técnica é forte demais, a sessão degrada pra dictation: o sênior escreve e explica enquanto o júnior registra sem processar, e o benefício se dissolve num formato que apenas parece colaborativo. O custo permanece: duas pessoas no mesmo tempo, o dobro do ciclo alocado pra tarefa, e um cansaço cognitivo que quem planeja o sprint costuma subestimar.
Mob programming opera numa escala diferente e com propósito distinto. O formato concentra o time inteiro, ou uma fração substancial dele, sobre um problema único, em geral um de alta ambiguidade técnica ou de alto impacto arquitetural. O mecanismo é a construção sincrônica de um entendimento compartilhado sobre uma decisão que, tomada isoladamente, geraria retrabalho de revisão posterior. O trade-off é o custo agregado de horas de engenharia por decisão tomada, que só se justifica quando a decisão é suficientemente estrutural pra que o retrabalho evitado pague o investimento. Times que adotam mob como cadência regular, sem filtrar o tipo de problema, convertem a prática em reunião longa com laptop aberto, e o efeito que vejo é desengajamento dos participantes que não estão dirigindo a sessão.
Code review carrega a tensão mais difícil das três práticas, até porque opera de forma assíncrona e o revisor costuma ter menos contexto do que o autor. O fluxo é consistente: o autor submete; o revisor lê sob pressão de outros trabalhos e responde com aprovação superficial ou com pedidos que não foram discutidos antes da escrita. O padrão do time se estabelece pela média do rigor aplicado, e essa média cai quando a revisão é tratada como gate administrativo. O ponto de inflexão costuma ser o momento em que o time começa a medir tempo de aprovação como indicador de produtividade, o que transfere o incentivo do revisor pra aprovar rápido e reduz o espaço pra contestação substantiva. A dívida técnica discutida em artigos anteriores é, em uma parte significativa, produto direto desse deslocamento.
Um exemplo recente envolveu um time que tinha adotado a regra de dois aprovadores por pull request, com o objetivo declarado de distribuir conhecimento. A análise dos comentários ao longo de seis meses mostrou que 80% das aprovações eram lgtm sem comentário substantivo, enquanto os mesmos dois engenheiros concentravam 60% dos comentários técnicos. A regra formal tinha sido atendida e a intenção tinha sido perdida no caminho: o time operava com a ilusão de revisão distribuída enquanto a calibragem técnica real acontecia entre duas pessoas. Na minha avaliação, a correção certa não estava em mudar a regra, mas em introduzir sessões curtas nas quais os PRs mais complexos da semana eram discutidos em grupo, o que restabeleceu o canal de circulação de contexto que o review assíncrono tinha deixado de cumprir.
Essas três práticas, observadas em conjunto, não são substitutas. Operam em camadas diferentes do ciclo de trabalho, e a escolha de qual usar depende da característica do problema e do estágio de maturidade do time. Pair serve pra calibragem contínua entre pares com reciprocidade real, mob pra decisões estruturais de alta ambiguidade, e review pra sustentação do padrão técnico nos meses seguintes, desde que permaneça como conversa. Quando qualquer uma delas é imposta como obrigação uniforme, sem leitura do que o time precisa, a prática perde a propriedade que a justificava e passa a produzir o oposto do efeito desejado: engenheiros que cumprem o formato e evitam a substância, e que aprendem a performar colaboração enquanto trabalham num isolamento crescente.