SINTOMA 04
O código sai rápido e trava na revisão
A fila de pull requests não diminui. Os seniores passam o dia revisando em vez de projetar. E quanto maior a fila, mais superficial fica a revisão — até o ponto em que aprovar vira formalidade.
atualizado em
Como isso aparece no dia a dia
- a fila de pull requests abertos cresce semana após semana
- os desenvolvedores mais experientes passam mais tempo revisando do que projetando
- revisões grandes recebem aprovação com poucos comentários
- defeitos que a revisão deveria pegar aparecem em produção
- discussões de padrão se repetem em pull requests diferentes, com conclusões diferentes
Por que acontece
A revisão é o único ponto do fluxo onde o critério arquitetural é efetivamente aplicado. Como esse critério não está escrito, ele só existe na cabeça de quem tem tempo de casa — e isso torna a revisão impossível de distribuir para o resto do time.
Quando a geração de código acelera e a revisão continua tendo a mesma capacidade, a fila cresce. Fila grande produz revisão superficial, e revisão superficial devolve para produção justamente os defeitos que ela existia para impedir.
O efeito colateral é organizacional: o profissional mais caro do time vira o recurso mais disputado, gastando em triagem o tempo que deveria gastar em arquitetura.
Por que a correção óbvia não resolve
Exigir dois revisores por pull request, ou criar um SLA de revisão.
Ambos aumentam a pressão sobre a mesma capacidade escassa. Dois revisores dobram o custo por pull request sem aumentar o critério disponível; um SLA transforma revisão apressada em meta atingida.
O que muda o quadro
Isso não se resolve com mais uma ferramenta. Resolve-se instalando, no repositório, o sistema que a IA precisa ler — o que chamamos de Sistema Operacional de Engenharia.
O caminho é separar o que é verificável do que exige julgamento. Padrão, fronteira de domínio, dependência proibida, cobertura e convenção são verificáveis: viram regra versionada e um agente revisor com escopo definido aplica no pipeline, antes de qualquer humano abrir o pull request.
O que sobra para a pessoa é o que só pessoa faz: se a solução resolve o problema certo, se a decisão tem consequência de longo prazo, se há um caminho mais simples. A decisão final continua humana — o que muda é o que chega até ela.
No framework de transformação, isso é o pilar AI Engineering Workflow. A definição completa da categoria está em Sistema Operacional de Engenharia.
Como saber se melhorou
Nenhuma dessas métricas significa alguma coisa sem o valor de partida. O baseline é levantado antes de qualquer mudança, com a janela e a fórmula registradas junto — o método está em métricas.
- Tempo médio de revisão de pull request
- da abertura ao primeiro parecer humano
- Change failure rate
- percentual de deploys que exigem correção ou rollback
- Incidência de regressões
- bugs reabertos ou reintroduzidos por trimestre
- Consistência arquitetural
- violações de regra detectadas por ciclo
Por onde se começa
Para este problema, o degrau adequado costuma ser AI-Native Repository Foundation — 4 a 8 semanas, time que já sabe onde dói e quer o sistema instalado em um produto antes de escalar para os outros.
Antes disso, o diagnóstico gratuito já indica se o gargalo é mesmo este. Os outros quatro sintomas estão em problemas.