Diseña el proceso en el que un agente revisa cada cambio antes que tú: qué dimensiones cubre, cómo evitar el ruido de sugerencias irrelevantes y dónde encaja en el flujo de pull requests.
Cuándo usarlo: Diseñar una revisión de código asistida por agentes que aporte hallazgos verificables sin inundar de ruido las pull requests
Herramienta recomendada: Claude Code
Actúa como ingeniero de plataforma con experiencia montando revisión asistida de código en equipos reales. Quiero una revisión automática que ahorre trabajo a los revisores humanos en lugar de inundarlos de comentarios. ## Contexto que necesito 1. Lenguajes, framework y tamaño del repositorio. 2. Herramientas de calidad que ya pasan en integración continua (lint, tipos, tests, análisis estático). 3. Qué se te escapa hoy en las revisiones: los tipos de fallo que llegan a producción. 4. Volumen de pull requests por semana y número de revisores. ## Paso 1 — Decidir qué no debe revisar el agente Antes de nada, quita del alcance todo lo que ya cubre una herramienta determinista: formato, orden de imports, reglas de lint, tipos. Que un agente comente sobre eso es ruido, y el ruido es lo que hace que la gente deje de leer los comentarios. Deja en el alcance lo que las herramientas no ven: | Dimensión | Qué busca | Ejemplo | |---|---|---| | Corrección | Casos límite y errores lógicos | Condición invertida, `off by one`, nulos no tratados | | Concurrencia y estado | Efectos no evidentes | Escritura sin transacción, condición de carrera | | Contrato | Cambios que rompen a otros | Respuesta de API modificada sin versión | | Rendimiento | Coste que crece con los datos | Consulta dentro de un bucle, N+1 | | Seguridad | Entradas sin validar, secretos | Consulta construida por concatenación | | Reglas del proyecto | Convenciones documentadas | Lo que dice el archivo de instrucciones | ## Paso 2 — Definir el skill de revisión Escribe el procedimiento que ejecutará el agente: 1. Cómo obtiene el diff y el contexto necesario (ficheros relacionados, tests existentes). 2. Las dimensiones a revisar, en orden. 3. El formato de salida obligatorio: fichero, línea, dimensión, gravedad, qué falla, cómo se reproduce y arreglo propuesto. 4. La regla de descarte: si no puede describir un escenario concreto en el que falla, no se reporta. Esto es lo que separa una revisión útil de una lista de opiniones. 5. Límite de hallazgos por revisión, ordenados por gravedad. ## Paso 3 — Verificación adversarial Para los hallazgos de mayor gravedad, añade un segundo paso donde otro agente intenta refutarlos: buscar en el código la razón por la que el supuesto fallo no ocurre. Solo sobreviven los que resisten. Esto reduce drásticamente los falsos positivos, que son la causa número uno de abandono de estas herramientas. ## Paso 4 — Encaje en el flujo Propón las tres opciones y recomiéndame una según mi contexto: - **Local, antes del commit**: el más rápido y el que menos molesta a nadie. - **En la pull request como comentarios**: útil en equipos, exige control estricto del ruido. - **En integración continua, sin bloquear**: informe adjunto, decide el humano. ## Entregables 1. El skill de revisión completo, con el formato de salida especificado. 2. El paso de verificación adversarial redactado. 3. Configuración concreta para el flujo recomendado. 4. Cuadro de control: cuántos hallazgos, cuántos aceptados, cuántos falsos positivos. Si la tasa de aceptación baja del 50%, hay que endurecer la regla de descarte. 5. Qué NO delegar a la revisión automática en mi caso.