Rutea code reviews por tipo de archivo con IA

Cuando un revisor de código con IA comenta de más, deja de ser útil. La solución es rutear los code reviews por tipo de archivo para que cada bloque reciba criterios especializados y menos ruido. Si trabajas con pull requests que mezclan Python, TypeScript e infraestructura, aquí verás cómo hacerlo.

El problema arranca con algo muy real en los equipos: cuando una herramienta habla demasiado, la gente deja de escucharla. Un revisor que aplica reglas genéricas suelta 20 comentarios por PR y mezcla un hallazgo crítico de seguridad con 15 observaciones de estilo. Lo crítico se pierde en el ruido [00:19].

Por qué un revisor genérico falla al comentar de más

Diseñar para destacar sobre el ruido no es una decisión estética, es lo que hace que la herramienta sea útil [00:38]. Un revisor que aplica las mismas reglas a un archivo Python y a uno TypeScript ignora que cada tecnología tiene riesgos distintos.

Un módulo de pagos en Python no corre los mismos peligros que un cliente en TypeScript. Por eso la respuesta es convertir el revisor en uno multiphase y ruteado: no todos los archivos se revisan igual [00:55].

¿Qué significa rutear un code review? Es separar los archivos por su extensión y enviar cada bloque a un revisor especializado, para que cada uno evalúe solo los riesgos propios de esa tecnología.

Cómo separar archivos por extensión y enviarlos a revisores especializados

La mecánica es directa: separas los archivos por extensión y mandas cada grupo a un revisor con foco propio [01:12]. Cada especialista mira lo que de verdad importa en su terreno.

Estos son los focos que definimos por tipo de archivo:

• Revisor de Python: SQL, autorizaciones y comportamiento async.
• Revisor de TypeScript: tipos, manejo de errores, idempotencia y fugas al cliente.
• Revisor de infra: secretos y permisos del workflow.

Con estos focos, el revisor deja de aplicar reglas genéricas y empieza a mirar riesgos reales de cada lenguaje [01:20].

Qué tres mecanismos controlan el volumen de comentarios

Incluso con el ruteo correcto, un revisor puede encontrar 30 problemas en un archivo grande y soltarte 30 comentarios [01:41]. Para evitar ese exceso, le indicas al prompt tres controles concretos.

1. Evaluar la severidad con etiquetas.
2. Limitar los comentarios por PR.
3. Aplicar desduplicación entre archivos [01:52].

Así los hallazgos importantes quedan arriba y lo menos relevante se queda abajo como consultivo o directamente no aparece.

Cómo funciona el prompt de ruteo con contrato JSON

En la rama de práctica hay código TypeScript en web/refunds, que consume refunds.py y actúa como cliente de él [02:12]. Al comparar los cambios contra develop, aparecen archivos de infra, de Python y de TypeScript juntos, y revisarlos por tipo resulta más eficaz y eficiente [02:35].

La clave está en tener tres prompts especializados, uno para infra, uno para Python y uno para TypeScript, más un prompt de ruteo que los orquesta [03:05]. Podrías escribir todo en cada prompt, pero es más eficiente que un gran prompt se encargue de rutear y genere revisiones usando cada especialista según el tipo de archivo [03:35].

¿Por qué usar un prompt de ruteo en vez de escribir todo en cada revisor? Porque centraliza las reglas de salida, el límite de comentarios y la desduplicación en un solo lugar, y deja que cada revisor especializado se enfoque solo en su tecnología.

El prompt de ruteo divide un diff de cambios contra develop por tipo de archivos, aplica el criterio del prompt especializado correspondiente y consolida un único review final [03:53]. Trata el diff como si fuera un pull request hacia develop, aunque no exista un PR real en GitHub, y usa solo el diff mostrado sin inventar información de Git [04:07].

Cómo se consolida un único JSON de hallazgos

El proceso interno del prompt sigue cuatro pasos claros para que la revisión sea separada pero la respuesta única [04:52].

1. Separar mentalmente el diff por tipo de archivo.
2. Evaluar cada bloque con el foco del prompt especializado correspondiente.
3. Consolidar hallazgos duplicados si varios bloques apuntan al mismo riesgo.
4. Devolver una sola lista JSON con todos los hallazgos accionables.

Y aquí viene lo interesante: no se separa el JSON por archivos [05:07]. La revisión sí es por archivo para generar comentarios más especializados, pero el JSON final combina todo con el mismo formato de clases anteriores [05:15]. El prompt de ruteo puedes hacerlo más específico para que los hallazgos vengan ordenados por severidad o solo queden los más importantes; esa organización queda a tu criterio [06:11].

Por qué el ruteo hace el review más eficiente y eficaz

El objetivo no es que la IA hable más, es que reciba menos contexto irrelevante y use mejores criterios según el tipo de archivo [06:31]. Ese cambio de enfoque es lo que transforma un revisor ruidoso en uno confiable.

Enrutar produce un doble beneficio directo sobre la revisión [06:45]:

• Es más eficiente porque reduce el ruido.
• Es más eficaz porque cada prompt mira riesgos propios de su tecnología.

Con el revisor rutando por lenguaje, graduando por severidad, limitando comentarios y quitando duplicados, se ve listo para producción [07:00]. Pero falta una pregunta que lo vuelve confiable de verdad: ¿coincide con lo que los humanos habríamos decidido? Un evaluador que nadie ha calibrado contra fallos humanos no sirve, solo es una opinión con formato JSON [07:20].

¿Tú prefieres un JSON combinado o uno separado por archivo? Cuéntame en los comentarios cómo organizarías tu revisor.