Abra um pull request com a maioria das ferramentas de revisão de código com IA e você recebe uma parede de comentários. Um por descoberta. Um por observação. Um por “considere extrair isso em uma função auxiliar”. Envie uma correção, rode a revisão de novo, e você recebe uma segunda parede empilhada em cima da primeira. Agora seu colega de equipe está rolando duas paredes pra achar o comentário que realmente importa.
O Surmado Code Review funciona diferente. Um PR, um comentário. Rode de novo e o mesmo comentário é editado no lugar.
Como funciona
Quando o Scout revisa um pull request, cada descoberta entra em um único comentário estruturado. Faixas de severidade no topo. Os problemas em si logo abaixo. Um breve resumo no final para que o revisor humano saiba por onde começar.
Quando você envia uma correção e comenta /rerun-review, o Scout lê duas coisas:
- O novo diff.
- A revisão anterior que ele postou.
Depois ele edita o mesmo comentário no lugar. Problemas que você corrigiu são marcados como resolvidos. Problemas que não foram corrigidos são sinalizados de novo com uma nota de que já haviam sido apontados antes. Novos problemas do novo código entram no final.
A thread de comentários do seu PR não cresce. A única revisão só fica mais precisa a cada vez que você envia código.
Por que isso importa
Uma thread de comentários de PR deveria ser uma conversa, não um outdoor. Cada comentário extra que um bot posta é um comentário que um colega de equipe precisa rolar pra encontrar o que importa. Depois de alguns ciclos, ninguém lê nenhum deles.
Essa é a mesma troca que apareceu no nosso texto sobre alternativas ao CodeRabbit e na nossa análise do Greptile. Taxa de detecção não é a única métrica. Sinal-ruído também é. Um revisor que detecta tudo mas enterra isso em 40 comentários tem o mesmo valor prático de um revisor que não detecta nada.
A parte “ciente do que já disse antes”
Editar no lugar é uma coisa. A parte mais difícil é tornar a nova execução útil, não só mais curta.
A nova execução do Scout se baseia na revisão anterior. Se ele te disse na primeira passada que uma função estava sem redação de PII, a nova execução olha especificamente se essa função agora redige PII. Não “existe algum problema de PII em algum lugar”, mas “a coisa que eu apontei foi corrigida”. Se sim, essa descoberta vai para uma seção de resolvidos. Se não, ela continua aberta com um marcador de que essa é a segunda vez que foi apontada.
Esse ciclo de feedback é o motivo pelo qual “um comentário” funciona. O comentário carrega seu próprio histórico. Você não precisa de uma thread cronológica de comentários de bot para lembrar o que foi sinalizado antes. O comentário atual já sabe.
Como é na prática
Envie um PR. Receba um comentário do Scout, ancorado nas regras do seu arquivo STANDARDS.MD. Leia. Corrija o que importa. Envie de novo. Comente /rerun-review. O mesmo comentário se atualiza com o que foi resolvido, o que ainda está aberto e o que é novo. Sem thread nova. Sem “você já foi notificado 17 vezes”.
Se você quiser a história mais longa de como a ferramenta foi construída, nosso texto sobre vibe coding cobre as partes que fizemos à mão e as partes que deixamos o Scout construir.
A conclusão
Spam de comentários em PR não é um recurso. É um hábito que outras ferramentas adotaram porque postar mais comentários é mais fácil do que saber quais importam.
O Surmado Code Review evita isso. Um comentário. Editado a cada nova execução. Ciente do que já disse.
Experimente o Surmado Code Review por $15 por mês. 100 PRs. Seu STANDARDS.MD. Cada PR, antes dos seus colegas de equipe abrirem.