- A estrutura em que, quanto mais aumentam as etapas de aprovação e revisão dentro da organização, mais a velocidade de execução do trabalho desacelera de forma exponencial é explicada, com exemplos mostrando que cada etapa de aprovação causa cerca de 10 vezes mais atraso
- Mesmo que ferramentas de programação com IA aumentem drasticamente a velocidade de escrita de código, a latência na fila de revisão posterior não diminui, então o ganho total de velocidade é pequeno
- Aplicando a filosofia de qualidade na manufatura de W. E. Deming ao software, o texto aponta que adicionar etapas de QA acaba piorando tanto a qualidade quanto a velocidade
- É preciso reduzir as revisões e, ao mesmo tempo, substituí-las por modularidade e uma cultura de qualidade baseada em confiança; o essencial é uma melhoria estrutural que torne a própria revisão desnecessária
- Equipes pequenas têm vantagem na era da IA, e é necessário redesenhar organizações e sistemas de modo a combinar componentes pequenos e bem feitos
A lei de que etapas de revisão criam atrasos de 10 vezes
- Assim como na lei dos efeitos de rede, quando o tamanho da equipe cresce surge sobrecarga de coordenação, e dobrar a equipe não faz a velocidade dobrar
- Uma regra prática encontrada décadas atrás: cada etapa adicional de revisão torna o processo 10 vezes mais lento
- Não há base teórica, mas é um fenômeno observado repetidamente na prática
- O tempo medido aqui não é esforço (
effort), e sim tempo de relógio (wall clock time); a maior parte do tempo adicional é espera
- Exemplos concretos:
- Codificar uma correção simples de bug: 30 minutos
- Revisão de código por um colega ao lado: 300 minutos (cerca de 5 horas, meio período)
- Aprovação de documento de design pela equipe de arquitetura: 50 horas (cerca de 1 semana)
- Colocar na agenda de outra equipe (ex.: solicitação de recurso de cliente): 500 horas (12 semanas, 1 trimestre fiscal)
- A etapa seguinte, de 10 trimestres (cerca de 2,5 anos), também não é irrealista; até em uma empresa relativamente pequena como a Tailscale esse nível de atraso ocorre quando se muda a direção do produto
A IA não consegue resolver esse problema
- Mesmo que o Claude faça em 3 minutos uma tarefa de programação de 30 minutos, resta escolher entre economizar 27 minutos para iterar diretamente com a IA ou entregar código não verificado a um revisor
- O revisor ainda leva 5 horas, e se você passar código que nem leu, o revisor fica irritado
- Diz-se que o verdadeiro valor da programação agentic é concluir em poucas horas um grande projeto de 1 semana, mas o resultado fica grande demais para um revisor avaliar de uma vez
- É preciso dividir em unidades menores, e cada uma gera um ciclo de revisão de 5 horas
- Sem documento de design, também não há arquitetura intencional, então no fim tudo converge para uma reunião de revisão de design
- Como resultado, um projeto concluído em 2 horas volta a levar 1 semana
O único caminho é reduzir as revisões
- A premissa da teoria da Singularity: sistemas constroem sistemas cada vez mais inteligentes, e se o tempo por unidade de melhoria converge para 0, ocorre crescimento explosivo
- A razão para não acreditar nisso: a maior parte do tempo para concluir algo não é tempo de trabalho real, e sim tempo de relógio, isto é, espera e atraso
- Latência não pode ser vencida na força bruta
Mas não dá para simplesmente deixar de revisar, certo?
- Muitas pessoas já percebem o sintoma: a primeira etapa do pipeline (código gerado por IA) ficou rápida, mas as etapas seguintes de revisão são o gargalo
- A solução intuitiva: parar de revisar → mesmo que o resultado fique tosco, se for 100 vezes mais barato, basta entregar 1% do valor para empatar
- Por trás dessa lógica há uma suposição bastante tola
- A curva de descida à loucura do desenvolvedor de IA (AI Developer's Descent Into Madness):
- Faz um protótipo numa velocidade impressionante → sensação de superpoder
- O protótipo apresenta bugs → pede à IA para corrigir
- A cada mudança, corrige uma coisa e surgem novos bugs
- Passa a acreditar que, se um agente de IA revisar o próprio código, ele encontrará seus bugs
- Dá por si mesmo passando dados diretamente entre agentes
- Percebe que precisa de um framework de agentes
- Usa agentes para escrever um framework de agentes
- Volta ao passo 1
- Como o Claude Code só ficou realmente utilizável há poucos meses, esse ciclo só começou recentemente, e muitos colegas e pessoas respeitadas estão presos nele
Por que fazemos revisões?
- À medida que a empresa cresce, aumentam as etapas de colaboração, revisão e gestão → para evitar erros, porque o custo dos erros cresce com a escala
- Chega um ponto em que o valor agregado médio de um novo recurso fica menor que a perda média causada por novos bugs
- Como não há como aumentar o valor do recurso, passa-se a reduzir o prejuízo
- Se aumentarmos inspeções e controles, a velocidade cai, mas a qualidade parece crescer monotonically increasing → parece a base de melhoria contínua
- Porém, “mais inspeções e controles” não é a única forma de melhorar qualidade, e é uma forma perigosa
“Garantia de qualidade (QA)” na verdade reduz a qualidade
- Referência à filosofia de qualidade popularizada por W. E. Deming na manufatura automobilística japonesa
- O problema da etapa de QA na fábrica: fabricar widget → inspeção/QA → remover os reprovados → para evitar falhas, adiciona-se uma segunda QA
- Num modelo matemático simples, isso parece racional (se cada etapa de QA detectar 90% dos defeitos, com 2 etapas há redução de 100 vezes)
- Mas em um ambiente de humanos autônomos (
agentic humans), os incentivos se distorcem:
- A equipe de QA secundária passa a avaliar a equipe de QA primária → não há incentivo para procurar com empenho algo que possa levar colegas à demissão
- A equipe de QA primária espera que a secundária capture os problemas e reduz seu esforço
- A equipe que fabrica os widgets também relaxa sua própria verificação porque existe QA → um índice de descarte de 10% parece melhor que ficar 20% mais lenta
- Um redesenho completo de engenharia para melhorar a qualidade é evitado por ser caro demais
- O Toyota Production System removeu completamente as etapas de QA e deu a todos um botão de “parar a linha”
- Montadoras americanas instalaram o mesmo botão, mas ninguém apertava → medo de ser demitido
Confiança (Trust)
- A diferença entre o sucesso do sistema japonês e o fracasso do sistema americano é a confiança
- Confiança entre indivíduos: convicção de que o chefe realmente quer saber de todos os defeitos e que a linha deve ser parada quando eles forem encontrados
- Confiança entre gestores: convicção de que a liderança leva a qualidade a sério
- Confiança entre executivos: convicção de que, com o sistema e os incentivos corretos, as pessoas farão trabalho de alta qualidade e encontrarão seus próprios defeitos
- Condição adicional: confiança de que o sistema realmente funciona → primeiro é preciso ter um sistema que funcione
Falibilidade (Fallibility)
- Programadores com IA frequentemente escrevem código ruim e, nisso, não diferem de programadores humanos
- A abordagem de Deming não traz solução mágica → engenheiros precisam projetar a qualidade de baixo para cima em todo o sistema
- Sempre que houver um problema, deve-se perguntar “como isso pôde acontecer?” e usar postmortem e Five Whys para encontrar e corrigir a causa raiz
- “O programador errou” não é causa raiz, e sim sintoma → é preciso encontrar a causa estrutural que permitiu o erro
- O verdadeiro papel do revisor de código não é revisar código, e sim tornar desnecessários os próprios comentários de revisão
- Melhorar o sistema para que esse tipo de comentário não volte a aparecer no futuro
- O objetivo deve ser chegar a um estado em que não seja preciso revisar
- Exemplo: as pessoas que criaram o
go fmt → eliminaram permanentemente comentários de revisão sobre espaçamento → isso é engenharia de verdade
- Quando a revisão detecta um erro, o erro já aconteceu → a causa raiz já passou
Modularidade (Modularity)
- O pipeline de revisão (etapas de QA) não funciona e, ao desacelerar tudo, esconde as causas raiz → fica mais difícil resolvê-las
- O apelo da programação com IA: a primeira etapa do pipeline ficou esmagadoramente rápida → sensação de superpoder
- Talvez agora exista motivação suficiente para resolver problemas escondidos por 20 anos de cultura de code review e substituí-los por uma verdadeira cultura de qualidade
- Os otimistas acertam pela metade: é preciso reduzir etapas de revisão, mas reduzi-las sem nada no lugar termina em casos como o Ford Pinto ou os aviões recentes da Boeing
- Assim como Deming fez na manufatura, é necessária uma virada completa de pacote (
table flip) → um sistema de “qualidade total” não pode ser adotado pela metade
- Ao remover revisões, é preciso torná-las desnecessárias ao mesmo tempo
- Dá para adotar o novo sistema integralmente em unidades pequenas:
- Análogo a uma montadora americana antiga comprar peças de alta qualidade de fornecedores japoneses
- Se as peças são bem feitas, dá para eliminar etapas de QA em outros lugares → a complexidade do trabalho de “montagem de peças” cai muito
- É possível combinar coisas pequenas e bonitas para criar algo grande e bonito
- Pequenas equipes que confiam umas nas outras sabem o que é qualidade para elas e produzem componentes individuais
- A equipe cliente explica com clareza o que é qualidade para ela → a qualidade se espalha de baixo para cima
Equipes pequenas e desenho organizacional na era da IA
- Startups pequenas podem ter mais vantagem no novo mundo → há menos pessoas e, portanto, naturalmente menos etapas de revisão
- Algumas startups vão descobrir como produzir componentes de alta qualidade rapidamente, enquanto outras fracassarão → qualidade por seleção natural
- Grandes empresas já estão presas a sistemas lentos de revisão e, se os removerem, pode haver caos completo
- Independentemente do tamanho da empresa, as equipes de engenharia podem ficar menores e as interfaces entre equipes podem ser definidas com mais clareza
- Dentro de uma mesma empresa, pode haver um modelo em que várias equipes desenvolvem competitivamente o mesmo componente
- Cada equipe é formada por poucas pessoas e bots de programação
- Tentar 100 abordagens e escolher a melhor → qualidade por evolução
- Código é barato, mas boas ideias continuam caras → novas ideias podem ser testadas mais rapidamente que antes
- Pode surgir um novo ponto ótimo no continuum monólito-microsserviços
- Microsserviços ganharam má fama por serem pequenos demais, mas no termo original um serviço “micro” tinha tamanho adequado para ser construído e operado por uma equipe de duas pizzas
- Na era da IA, seria algo como “uma pizza e alguns tokens”
- Com a nova velocidade de programação, dá para experimentar mais rápido os próprios limites entre módulos
- Recursos (
feature) continuam difíceis, mas refatoração e testes de integração automatizados são áreas em que a IA vai bem
- Dá para tentar separar módulos que antes davam medo → o número de linhas de código aumenta, mas isso sai barato comparado à sobrecarga de coordenação de uma grande equipe mantendo ambos os lados
- Toda equipe tem um monólito grande demais e etapas de revisão demais
- Mesmo que não cheguemos à Singularity, é possível projetar um mundo muito melhor → o problema tem solução
- A chave é a confiança
2 comentários
Eu quando vi
go fmtpela primeira vez: ué, por que não posso formatar do meu jeito..?Agora: pra que precisa ter preferência pra formatação?
Comentários do Hacker News
Talvez nem seja preciso fazer review
Se você puxar o review para a esquerda e transformá-lo em sessões de design de código, levantar problemas no daily e resolver as partes difíceis com pair programming, a maior parte do propósito do review desaparece
Os 10% restantes — nomes de variáveis, espaços, padrões — podem ser automatizados com um linter
No fim, o importante é criar uma cultura de equipe baseada em confiança, na qual a equipe possa confiar no código que foi acordado e escrevê-lo
Só durante a implementação real é que você percebe os problemas
Quase nunca aconteceu de tudo sair exatamente como planejado. No fim, são necessárias reuniões iterativas de arquitetura, mas isso acaba virando outro pântano de reuniões semanais
Quando nem revisam mais o código que eles próprios escreveram, a confiança construída desmorona em um instante
Assim como no Toyota Production System, para eliminar a etapa de QA é preciso haver confiança para que qualquer pessoa possa parar tudo imediatamente ao encontrar um defeito
O pipeline de review só esconde problemas e reduz a velocidade
Essa frase por si só parece a definição do inferno
Isso funciona bastante bem. As pessoas escrevem testes por conta própria e também fazem validação manual
Também foi criada uma rede de segurança capaz de reverter um deploy errado em 10 minutos
Code review é um dilema do voluntário
Porque “revisei muitos PRs” pesa menos na avaliação do que “entreguei muitas funcionalidades”
No fim, as pessoas só tendem a revisar ativamente quando isso afeta diretamente o próprio trabalho
Mas, como código é flexível, fazer merge rápido e corrigir depois pode até levar a uma convergência mais rápida
Especialmente quando a motivação é encontrar bugs antes e reduzir o estresse do on-call
Mesmo sem entender tudo, deixar perguntas ajuda muito no aprendizado
Se quiser se tornar líder, precisa revisar bastante código e também documentos de design
Este texto foi uma organização clara da minha intuição e experiência
Eu já gostava do produto da Tailscale, mas agora acho que vou virar fã do CEO
Obrigado ao autor, Avery; pretendo compartilhar este texto amplamente
A Valve é uma das poucas empresas que entendem os limites da largura de banda de comunicação
Quanto maior a organização, a carga de comunicação aumenta exponencialmente
Outras empresas já deveriam ter percebido também, mas ainda não perceberam
É surpreendente que reviews sejam processados em até 5 horas
Na maioria dos casos, isso leva dias
Mas, se existir uma cultura em que todo desenvolvedor pode parar tudo imediatamente ao encontrar um bug, talvez o review nem seja necessário
Na realidade, é comum haver uma estrutura em que a pessoa é prejudicada se não cumprir a meta de release
Na empresa atual, os reviews terminam em minutos, mas a dívida técnica disparou
Depois de certo tempo, chegava automaticamente uma mensagem de “aguardando review”
Tudo era medido, e a pressão por desempenho era intensa
Se o tamanho da equipe for adequado, esse hábito pode ser aprendido e difundido
Nem o negócio, nem os desenvolvedores se importam muito com isso
A relação entre valor e esforço do review costuma ser ignorada
Se o review não melhora de fato a qualidade, esse tempo é desperdiçado
Em vez de discutir minúcias, é mais eficiente só confirmar “funciona?” e fazer merge rápido
Depois, dá para melhorar em commits posteriores
O review deveria ser um checkpoint curto para confirmar a direção
Concordo totalmente com a frase: “o trabalho do revisor é eliminar a necessidade de review”
O texto parte do pressuposto de um processo serializado, mas na prática as coisas andam em paralelo
Se vários bugs forem tratados ao mesmo tempo, o atraso no review não é um grande problema
O essencial é controlar o número de trabalhos simultâneos (N)
link
Quanto mais lento for o review de PR, maior será o custo de troca de contexto
Os cálculos mostram que aumentar a velocidade de review melhora bastante a produtividade
Concordo com a ideia de que “o objetivo do revisor é tornar o review desnecessário”,
mas a história muda quando o alcance da confiança se estende para fora da empresa
Por exemplo, se um código malicioso for distribuído por meio de
npm update, reagir depois já será tarde demaisMesmo em um modelo baseado em confiança, às vezes existem pontos em que a validação humana é necessária
Os gerentes enfatizam produtividade, mas ao mesmo tempo mantêm processos que reduzem a velocidade
É um problema complexo, então não dá para dizer simplesmente que é bom ou ruim
Os operadores precisam responder ao mesmo tempo por produtividade e segurança
Antes de um incidente, a produtividade é enfatizada; depois, a segurança ganha destaque
Quem está de fora não entende bem o equilíbrio desse duplo papel
link relacionado