Abres un pull request con la mayoría de las herramientas de revisión de código con IA y recibes un muro de comentarios. Uno por hallazgo. Uno por cada detalle menor. Uno por cada “considera extraer esto en una función auxiliar”. Subes una corrección, vuelves a ejecutar la revisión, y obtienes un segundo muro apilado sobre el primero. Ahora tu compañero de equipo está desplazándose por dos muros para encontrar el comentario que realmente importa.
Surmado Code Review funciona diferente. Un PR, un comentario. Lo vuelves a ejecutar y el mismo comentario se edita en su lugar.
Cómo funciona
Cuando Scout revisa un pull request, cada hallazgo va dentro de un único comentario estructurado. Bandas de severidad arriba. Los problemas en sí abajo. Un breve resumen al final para que el revisor humano sepa dónde mirar primero.
Cuando subes una corrección y comentas /rerun-review, Scout lee dos cosas:
- El nuevo diff.
- La revisión anterior que publicó.
Después edita el mismo comentario en su lugar. Los problemas que corregiste se marcan como resueltos. Los que no corregiste se vuelven a señalar con una nota de que ya se habían mencionado antes. Los problemas nuevos del código nuevo aparecen al final.
El hilo de comentarios en tu PR no crece. La única revisión simplemente se vuelve más precisa cada vez que subes cambios.
Por qué esto importa
Un hilo de comentarios en un PR se supone que es una conversación, no una cartelera. Cada comentario adicional que publica un bot es un comentario que un compañero de equipo tiene que desplazar para encontrar el que realmente importa. Después de algunos ciclos, nadie lee ninguno de ellos.
Esta es la misma disyuntiva que surgió en nuestro artículo sobre alternativas a CodeRabbit y en nuestro análisis de Greptile. La tasa de detección no es la única métrica. La relación señal-ruido también lo es. Un revisor que detecta todo pero lo entierra en 40 comentarios tiene el mismo valor práctico que un revisor que no detecta nada.
La parte de “consciente de lo que dijo antes”
Editar en su lugar es una cosa. La parte difícil es hacer que el rerun sea útil, no solo más corto.
El rerun de Scout se fundamenta en la revisión anterior. Si te dijo en el primer pase que a una función le faltaba redacción de PII, el rerun revisa específicamente si esa función ahora redacta PII. No “hay algún problema de PII en algún lugar”, sino “¿se corrigió lo que señalé?”. Si es así, ese hallazgo pasa a una sección de resueltos. Si no, permanece abierto con una marca de que esta es la segunda vez que se señala.
Ese ciclo de retroalimentación es por lo que “un comentario” funciona. El comentario lleva su propia historia. No necesitas un hilo cronológico de comentarios del bot para recordar qué se señaló antes. El comentario actual ya lo sabe.
Cómo se ve en la práctica
Subes un PR. Recibes un comentario de Scout, anclado a las reglas de tu archivo STANDARDS.MD. Lo lees. Corriges lo que importa. Subes de nuevo. Comentas /rerun-review. El mismo comentario se actualiza con lo que está resuelto, lo que sigue abierto y lo que es nuevo. Sin hilo nuevo. Sin “te hemos notificado 17 veces”.
Si quieres la historia más larga de cómo se construyó la herramienta, nuestro artículo sobre vibe-coding cubre las partes que hicimos a mano y las partes que dejamos que Scout construyera.
La conclusión
El spam de comentarios en PR no es una función. Es un hábito que otras herramientas adoptaron porque publicar más comentarios es más fácil que saber cuáles importan.
Surmado Code Review lo evita. Un comentario. Editado en cada rerun. Consciente de lo que ya dijo.
Prueba Surmado Code Review por $15 al mes. 100 PRs. Tu STANDARDS.MD. Cada PR, antes de que tus compañeros de equipo la abran.