No último sábado, o CTO da Monest publicou um thread respondendo a pergunta de como o time deles lida com volume de PRs, code review e herança de contexto com IA. Vale a leitura completa — ele descreve um sistema bem pensado.
O resumo do que ele montou:
- RFC antes de tudo: antes de escrever uma linha, o time documenta a decisão num repositório central. A RFC precisa de aprovação de dois tech leads.
- Contexto distribuído via git submodule: a RFC vai junto pra cada repositório. Claude lê a RFC, lê a issue do Linear, lê um arquivo de guidelines (~1000 linhas por repo) e só então começa a codar.
- CodeRabbit em loop: com a PR aberta, o CodeRabbit revisa. Uma skill fica num feedback loop infinito avaliando os comentários do Rabbit e aplicando os fixes pertinentes na PR.
- PR com no máximo 500 linhas: não é capricho. Eles fizeram um estudo interno — PRs maiores recebem 4x menos comentários. Se o dev não lê, não consegue explicar o edge case pro cliente.
- ADR após a feature: depois que tudo está pronto, documentam a decisão arquitetural com um detalhe específico: o entry point. Onde começa a bagaça, por onde passa.
É um sistema maduro. O que me interessa é que chegamos em pontos parecidos por caminhos diferentes.
O mesmo problema, outra abordagem
O problema central é o mesmo que ele identificou:
“o gargalo não é shippar código, mas garantir qualidade no código gerado e que tudo gerado está indo de acordo com a visão de futuro da empresa”
Isso é preciso. Quando a geração de código acelera 10x, o review vira o novo bottleneck. E review feito de qualquer jeito é pior do que não ter review — dá uma falsa sensação de segurança.
Aqui, resolvi com uma cadeia de agentes especializados onde cada um tem uma responsabilidade específica:
Antes de implementar — análise de contexto:
Um agente analisa o codebase, identifica os arquivos relevantes, entende o contexto arquitetural e produz um documento pré-digerido que o agente de implementação vai consumir. É análogo à RFC deles, mas gerado automaticamente a partir do código existente. O dev não precisa explorar o repositório — ele já chega com o mapa.
Durante a implementação — TDD obrigatório:
Separação deliberada entre quem define os testes e quem implementa. O agente que escreve os casos de teste nunca é o mesmo que vai implementar. Isso cria uma tensão saudável — o implementador não pode fazer o teste passar de qualquer jeito porque não tem viés sobre o que os testes deveriam testar.
O ciclo é sempre: Red → Green → Refactor. Sem testes escritos antes, sem merge.
Depois de implementar — quality gate:
Um agente de review lê o código com uma lista de verificações não-negociáveis:
- Zero hardcode de tenant ou cliente
- Zero
anyem TypeScript - Testes cobrem os critérios de aceite
- Sem breaking changes em contratos externos
Se qualquer item falha, a PR volta pro implementador antes de chegar no humano.
O que aprendi sobre o limite cognitivo humano
O ponto que o CTO da Monest tocou sobre limite cognitivo humano é o mais importante de todo o thread.
A tentação quando você tem IA gerando código rápido é aprovar PRs sem ler. Afinal, “o Claude gerou e o CodeRabbit aprovou, deve estar certo”. Esse é o pior caminho possível.
O dev que não lê o código que aprova:
- Não consegue explicar como funciona pra um stakeholder
- Não consegue debugar quando quebra em produção
- Não acumula conhecimento sobre o sistema
- Vira um aprovador de carimbo, não um engenheiro
A solução do limite de 500 linhas por PR é elegante porque força a granularidade. Você não consegue aprovar o que não consegue ler.
Aqui uso uma regra parecida mas por critério de aceite: cada PR implementa exatamente uma feature ou corrige um bug específico. Nada de “aproveitei e refatorei enquanto estava aqui”. Isso mantém o diff revisável e o raciocínio claro.
O que ainda não resolve
Ambas as abordagens resolvem bem o problema de qualidade técnica imediata. O que é mais difícil de resolver é o alinhamento com a “visão de futuro da empresa” que ele menciona.
RFC e guidelines ajudam. Mas guidelines se desatualizam. RFC aprovada hoje pode estar errada daqui a três meses. O sistema que funciona hoje foi construído com decisões que faziam sentido no passado.
O que tenho feito pra mitigar: manter um arquivo de decisões arquiteturais ativas, revisado toda vez que uma decisão nova é tomada. Não é documentação histórica — é o estado atual da arquitetura, com o porquê de cada escolha. Quando o porquê muda, a decisão muda junto.
O ponto de convergência
O que o thread da Monest e minha experiência têm em comum:
- Contexto explícito é tudo. IA sem contexto chuta. Com contexto bom, ela acerta.
- O humano valida, não gera. O papel muda — você lê, decide, direciona.
- Qualidade não é acidente. Você precisa de guardrails estruturais, não de esperança.
- Documentar entry points é subestimado. Saber onde o código começa economiza horas de orientação de agente.
O que diverge é o tooling e a granularidade do processo. A Monest usa CodeRabbit, Linear e submodules. Eu uso agentes especializados em cadeia. Ambos resolvem o problema — a escolha depende do contexto e do tamanho do time.
O campo ainda está em formação. Daqui a um ano teremos padrões mais consolidados sobre como times de engenharia funcionam na era agêntica. Por enquanto, cada um está descobrindo o que funciona pra sua realidade.
Esse thread foi um dos melhores registros públicos que vi sobre isso. Vale salvar.