Tu equipo ya acepta código escrito por IA y el volumen de revisión se disparó. Un método para revisar con criterio, automatizar lo repetitivo y cuidar la seguridad.
Un martes cualquiera, un desarrollador abre un pull request de 600 líneas que escribió casi todo el asistente. Compila, los tests pasan y se ve prolijo. El revisor, con otros tres PR pendientes, lo lee en diagonal y aprueba. Dos semanas después aparece un endpoint que cualquier usuario autenticado podía llamar para ver datos de otro cliente.
No es un problema de "la IA escribe mal". Es que el código llega más rápido de lo que tu proceso de revisión fue diseñado para absorber. Esta guía es para equipos pequeños de desarrollo que ya usan Claude Code, Cursor, Copilot u otro asistente y quieren revisar con criterio sin frenar al equipo.
¿Por qué el código de una IA se escapa de la revisión?
Por tres razones que se refuerzan entre sí. Primero, el código generado se ve bien: nombres coherentes, comentarios, formato limpio. Esa apariencia de calidad baja la guardia del revisor. Segundo, el volumen: un asistente produce en minutos lo que una persona escribe en horas, y quien revisa no crece al mismo ritmo. Tercero, el autor muchas veces no escribió cada línea y no puede explicar por qué algo está hecho de cierta manera.
Hay datos que confirman que la sospecha es razonable. Veracode, una empresa de seguridad de aplicaciones, analizó el código generado por más de 100 modelos de lenguaje en Java, JavaScript, Python y C#, y reportó que introdujo fallos de seguridad riesgosos en el 45% de las pruebas (actualización de octubre de 2025 de su informe). También señala que los modelos más grandes y nuevos no produjeron código más seguro. Es un estudio de un proveedor, sobre tareas de prueba y no sobre tu proyecto, así que úsalo como señal de alerta y no como cifra para tu equipo. Lo útil es la conclusión práctica: no asumas que el código de la IA es más seguro que el de una persona.
Las herramientas lo dicen sin rodeos. La documentación de seguridad de Claude Code indica que eres responsable de revisar el código y los comandos propuestos antes de aprobarlos, y GitHub recomienda complementar la revisión automática de Copilot con una revisión humana.
¿Qué debe mirar siempre una persona?
No necesitas leer cada línea con la misma atención. Concentra el tiempo humano donde un error cuesta caro. La lista de OWASP Top 10 de 2025 sirve como mapa de categorías: control de acceso roto, errores de configuración, fallos en la cadena de suministro de software, fallos criptográficos, inyección y fallos de autenticación, entre otras. En la práctica, para un PR escrito con IA, revisa esto primero:
- Autorización, no solo autenticación. ¿Cada endpoint verifica que el usuario puede ver o modificar ese registro concreto? Es el error clásico de un asistente que implementó "login" y dio por hecho lo demás.
- Entradas que llegan a una consulta, un comando o una plantilla. Busca SQL armado con concatenación, comandos de sistema con texto del usuario y HTML sin escapar.
- Dependencias nuevas. ¿Existe el paquete, es el correcto (cuidado con nombres parecidos), está mantenido y de verdad lo necesitábamos? Revisa también el archivo de bloqueo (lockfile).
- Secretos y datos. Claves, tokens y datos de clientes en el código, en logs o en mensajes de error.
- Manejo de errores. Qué pasa cuando algo falla: si el código "traga" excepciones o devuelve detalles internos al usuario.
- Cambios fuera del alcance. Archivos de configuración, permisos o pruebas tocados sin que nadie lo pidiera.
¿Qué conviene automatizar para que la revisión humana rinda?
Lo repetitivo se automatiza para que las personas gasten su atención en lo que requiere juicio. Un esquema razonable para un equipo pequeño:
1. Pruebas y análisis estático en cada PR
Tests, linter y verificación de tipos corriendo en el sistema de integración continua, y bloqueando el merge si fallan. No dependas de que el asistente "recuerde" ejecutarlos. Si tu equipo usa Claude Code, puedes pedirle además que ejecute las pruebas antes de dar un cambio por terminado, pero la barrera real es la del servidor.
2. Detección de secretos antes de que salgan del equipo
GitHub ofrece "push protection", que revisa los pushes mientras se transmiten y los bloquea si detecta un secreto conocido. Su disponibilidad depende del tipo de repositorio y del plan (en repositorios de organización requiere tener activado GitHub Secret Protection), así que confirma qué te incluye. Otras plataformas y herramientas independientes hacen algo parecido.
3. Una segunda lectura automática, sin reemplazar a la primera
Claude Code incluye el comando /security-review, que analiza los cambios de tu rama frente a la rama principal del repositorio en busca de riesgos como inyección, problemas de autenticación y exposición de datos. GitHub Copilot ofrece revisión de código en pull requests. Ambas son útiles como segundo par de ojos, pero GitHub aclara que Copilot no garantiza detectar todos los problemas y que a veces se equivoca. Trátalas como una lista de sospechas para investigar, nunca como un visto bueno.
4. Reglas escritas en el repositorio
Si tu equipo ya tiene un archivo de reglas del proyecto (como CLAUDE.md o las reglas de Cursor), agrega ahí tus exigencias de seguridad: cómo se valida una entrada, cómo se manejan los secretos, qué librerías están aprobadas. El asistente las lee en cada sesión y reduce errores repetidos. Es una guía, no una garantía, así que la revisión sigue siendo necesaria.
¿Cómo cambia el proceso de revisión con la IA en el equipo?
- PR pequeños. Fija un tamaño máximo razonable y divide lo que lo supere. Es la medida que más mejora la calidad de la revisión.
- El autor responde por el código. Quien abre el PR lo leyó completo y puede explicarlo. "Lo hizo la IA" no es una justificación.
- Descripción honesta. Indica en el PR si el cambio fue generado con ayuda de IA y qué pruebas hiciste tú mismo.
- Pruebas escritas con intención. Si el mismo asistente escribe el código y sus pruebas, pueden compartir el mismo malentendido. Revisa que las pruebas verifiquen el comportamiento correcto, incluidos los casos en que alguien no debería tener acceso.
- Cuidado con las zonas críticas. Pagos, autenticación, permisos y datos personales merecen siempre una segunda persona, venga el código de donde venga.
Para marcos de referencia más formales, el NIST publica el Secure Software Development Framework (SP 800-218), un conjunto de prácticas de desarrollo seguro que se puede integrar en cualquier ciclo de vida de desarrollo. No es específico de IA, pero es un buen punto de partida si un cliente te pide evidencia de tu proceso.
¿Qué riesgos y límites debes tener presentes?
- Datos de clientes en el prompt. No pegues bases de datos reales, tokens ni claves en un asistente. Si necesitas depurar con datos, anonimízalos. Recuerda que la Ley 1581 de 2012 exige una base legítima para tratar datos personales, y enviarlos a una herramienta externa es un tratamiento.
- Permisos del agente. Un asistente que ejecuta comandos puede hacer daño con un error. Configura qué puede ejecutar sin preguntar y usa entornos aislados para lo delicado. Claude Code, por ejemplo, ofrece permisos y aislamiento (sandbox) configurables.
- Contenido no confiable. Un asistente que lee páginas web, issues o archivos de terceros puede recibir instrucciones maliciosas escondidas (inyección de prompts). Revisa los comandos que propone antes de aprobarlos.
- Falsa tranquilidad. Que pasen los tests, el linter y la revisión automática no demuestra que el código sea seguro.
Esto es información general y no reemplaza una auditoría de seguridad ni asesoría legal. Si manejas pagos, salud o datos sensibles, contrata una revisión independiente.
Un plan para esta semana
- Lunes: acuerden un tamaño máximo de PR y una plantilla con la lista de revisión de arriba.
- Martes: activa en integración continua las pruebas, el linter y la detección de secretos, y haz que bloqueen el merge.
- Miércoles: agrega las exigencias de seguridad a tu archivo de reglas del proyecto.
- Jueves y viernes: prueba una revisión automática (por ejemplo /security-review) sobre tres PR ya aprobados y compara qué encontró con lo que vio el equipo.
- Siguiente semana: ajusta la lista según lo aprendido y decide qué zonas del código exigen siempre una segunda persona.
Si quieres que alguien externo ayude a definir estándares de revisión y a configurar estas herramientas en tu equipo, ahí puedo acompañarte.