Sí, cuando la revisión con IA es una capa entre varias y no la única barrera. Un revisor de IA puede leer cada pull request a cualquier hora y detectar casos olvidados, patrones inseguros y código poco claro. También puede equivocarse o dejarse engañar, así que la configuración segura mantiene a su alrededor las pruebas, la protección de ramas y una persona para los cambios de riesgo.
Lo que la revisión con IA hace bien y lo que las personas hacen mejor
| Tarea | Revisor de IA | Persona |
|---|---|---|
| Detectar casos límite olvidados y pequeños errores | Fuerte | Bien, pero se cansa |
| Comprobar cada cambio con tus reglas, siempre | Fuerte | Varía de un día a otro |
| Juzgar si el cambio es la decisión de producto correcta | Débil | Fuerte |
| Notar un riesgo que no está en el código, como un contrato o un plazo | Débil | Fuerte |
Usa este reparto para decidir dónde debe seguir involucrada una persona. Las comprobaciones de rutina van a la IA. Las decisiones de criterio se quedan con las personas.
Cinco capas alrededor de cada pull request
Ninguna comprobación debería cargar sola con la decisión. Una configuración segura apila capas que atrapan cada una algo que las otras no ven, y la pull request tiene que pasarlas todas en orden.
- Comprobaciones automáticas: lint, build y tests dan un aprobado o suspenso que nadie puede discutir.
- Agentes revisores: agentes distintos leen el cambio y comentan lo que ven mal.
- Ciclo de corrección: los hallazgos vuelven a un agente corrector, y las comprobaciones y los revisores se ejecutan otra vez.
- Una persona: alguien que tú nombraste aprueba los cambios en las áreas donde un error sale caro.
- Protección de rama: tu plataforma de código exige las comprobaciones y revisiones obligatorias, diga lo que diga un agente.
Los riesgos a tener en cuenta
- Una falsa aprobación: el revisor dice que el cambio está bien cuando no lo está.
- Dejarse engañar: un texto oculto en un ticket, un comentario o un archivo puede intentar manipular al revisor. OWASP incluye la inyección de prompts como el primer riesgo de su lista para aplicaciones basadas en modelos de lenguaje grandes.
- Demasiado acceso: un revisor que puede leer secretos o modificar producción puede causar daños si lo engañan.
- Corregir su propio examen: un agente que revisa el código que escribió tiende a darse la razón.
Una configuración segura, paso a paso
- Separa al autor de los revisores. El agente que escribió el cambio nunca lo aprueba, y es mejor tener más de un revisor.
- Deja que los revisores comenten, no que editen. Los hallazgos vuelven al autor para que los corrija, así cada cambio tiene un solo responsable.
- Mantén las comprobaciones automáticas como barrera. Las pruebas, la verificación de tipos y las comprobaciones de calidad deben volver a pasar tras cada corrección. En GitHub, la protección de ramas puede exigir comprobaciones superadas y revisiones aprobadas antes de fusionar nada.
- Limita el acceso. Ejecuta los agentes en un entorno aislado, sin secretos de producción y solo con los permisos que el trabajo necesita.
- Elige dónde debe aprobar una persona, como las zonas sensibles del código y la salida a producción.
- Deja constancia. Cada comentario de revisión, corrección y aprobación debe verse en el pull request.
Un ejemplo real: un endpoint de reembolsos
Un ticket ilustrativo, PAY-301, "Añadir un endpoint de reembolsos": un agente lo construye y abre un pull request. Esto es lo que hace cada capa con él.
| Capa | Qué hizo | Resultado |
|---|---|---|
| Comprobaciones automáticas | Se ejecutaron lint, comprobación de tipos y tests. Falló un test de un importe de reembolso negativo. | Enviado al agente corrector. Un commit después, la segunda ejecución pasó. |
| Agentes revisores | Un revisor notó que el endpoint nunca comprueba que el usuario pueda reembolsar ese pago. Otro intentó romperlo y descubrió que un reembolso podía ser mayor que el pago original. | Dos hallazgos, escritos como comentarios en la pull request. |
| Ciclo de corrección | El agente corrector añadió la comprobación de permisos y el límite del importe. Las comprobaciones se ejecutaron de nuevo y los revisores leyeron la nueva versión. | Ambos hallazgos cerrados, todas las comprobaciones en verde. |
| Una persona | El cambio toca la carpeta de pagos, que está en la lista de aprobadores. El aprobador ve los hallazgos, las correcciones y las comprobaciones superadas en un solo lugar. | Aprobado, o devuelto con un comentario. |
| Protección de rama | Tu plataforma de código sigue exigiendo sus comprobaciones y su revisión. | La fusión se permite solo porque todo pasó. |
Fíjate en que los revisores nunca editaron el código y en que ninguna capa aprobó el cambio por sí sola. En un caso así, los dos hallazgos son de los que una persona cansada pasa por alto un viernes por la tarde.
Qué pasa dentro del ciclo de corrección
Un hallazgo va a un agente corrector junto con el comentario exacto o el log del fallo. El agente cambia el código, las comprobaciones se ejecutan de nuevo y los revisores leen la nueva versión. Esto se repite hasta que todo está en verde.
Dos salvaguardas mantienen el ciclo honesto. Si una corrección deja de acercarse al verde, o sube el riesgo del cambio, la ejecución se detiene y pregunta a una persona en lugar de reintentar. Y un test que falla al azar se reintenta y se repara automáticamente, para que un test poco fiable no bloquee un buen cambio.
Cómo lo hace Dutopilot
En Dutopilot, miembros virtuales del equipo de Dutopilot distintos de los que escribieron el código leen cada pull request. Lo que encuentran pasa a un paso de corrección automática, y las pruebas y las comprobaciones de calidad se ejecutan de nuevo antes de fusionar nada. El código se procesa en un entorno aislado, y tu protección de ramas y las revisiones obligatorias siguen aplicándose sin cambios.
Las personas deciden la arquitectura antes de escribir código y la salida a producción, y puedes añadir aprobaciones donde quieras. Cada ejecución deja un registro en tus pull requests. Consulta qué pasos necesitan la aprobación de una persona para ver cómo elegir.
Lo que los revisores pueden hacer
- Leen el cambio y el código que lo rodea, y escriben comentarios. No suben código.
- Se ejecutan en un sandbox aislado, sin secretos de producción.
- Son miembros virtuales del equipo de Dutopilot distintos del que escribió el cambio, así que ninguno corrige su propio examen.
- La opinión de un solo revisor nunca fusiona nada por sí sola. Las aprobaciones y la fusión ocurren solo donde las elegiste, y deciden las comprobaciones automáticas y la protección de tu rama.
Lo que configuras
- Protección de rama en tu rama principal, con las comprobaciones que ya ejecutas marcadas como obligatorias.
- Una lista de aprobadores y las partes del código, como pagos o inicio de sesión, que siempre necesitan uno.
- El nivel de exigencia que quieres: en qué tipos de problema deben bloquear los revisores y cuáles solo deben mencionar.
Lo que hace tu Forward Deployed Engineer
Cada cliente de Dutopilot tiene un Forward Deployed Engineer: un ingeniero de Dutopilot que trabaja con tu equipo. No escribe el código de tu producto. Hace que la revisión encaje con tu código y tus hábitos.
- Ajusta lo que buscan los revisores en tu código, como tus reglas de seguridad y tus convenciones de nombres.
- Elige contigo qué partes del código necesitan un aprobador designado.
- Revisa contigo los resultados del primer mes: lo que marcaron los revisores, lo que marcaron las personas después y lo que se coló.
- Endurece o afloja las aprobaciones según ese historial, y sigue ajustando a medida que cambian tu código y tu equipo.
Cómo saber si funciona
Lleva un registro sencillo durante el primer mes. En cada pull request, anota lo que señaló el revisor de IA, lo que señaló después una persona y si algo se coló y obligó a una corrección posterior. Si las personas siguen encontrando problemas reales que la IA pasó por alto, endurece la configuración. Si los hallazgos de la IA son sobre todo ruido, ajusta lo que le pides que busque antes de confiarle más.
Empieza poco a poco y amplía
Empieza con la revisión con IA en una parte del código de bajo riesgo, con una persona aprobando aún cada fusión. Tras unas semanas, mira con qué frecuencia la IA encontró problemas reales y con qué frecuencia dejó pasar uno que detectó una persona. Relaja las aprobaciones donde el historial sea limpio y mantenlas donde no.
Preguntas frecuentes
¿La revisión con IA debería sustituir a la revisión humana?
No en cambios costosos o difíciles de deshacer. Deja que la IA detecte los problemas de rutina para que las personas dediquen su tiempo al criterio, como decidir si el cambio es el correcto.
¿Puede un revisor de IA aprobar y fusionar por su cuenta?
Solo donde tú lo elijas, y solo para cambios de bajo riesgo. Las aprobaciones y la fusión ocurren solo donde las elegiste, y la opinión de un solo revisor nunca fusiona nada por sí sola: las comprobaciones automáticas y la protección de tu rama siguen siendo la barrera. Empieza estricto y afloja solo después de ver los resultados.
¿Qué pasa con los secretos y los datos de clientes?
Mantenlos fuera del alcance del revisor. En Dutopilot el código se procesa en un entorno aislado, nunca guardamos una copia de tu repositorio y los registros de ejecución y los resultados de las comprobaciones se eliminan a los 90 días.