La revisión de código y de infraestructura antes de llegar a producción sigue siendo una de las tareas que más problemas evita y que, al mismo tiempo, más se resuelve de forma improvisada. El clásico “revísalo a ver si ves algo raro” funciona mal porque depende demasiado de la memoria, del cansancio y de la experiencia concreta de quien mira el cambio. En entornos con despliegues frecuentes, contenedores, infraestructura como código y aplicaciones expuestas a Internet, ese enfoque ya no basta.
La aparición de asistentes de IA ha añadido una nueva capa al proceso, pero no elimina la necesidad de método. Pedirle a un modelo que “revise mi código” suele producir respuestas genéricas: recomendaciones sobre nombres de variables, avisos vagos para mejorar el manejo de errores o sugerencias que suenan bien pero no localizan el fallo real. La diferencia no está solo en el modelo utilizado, sino en cómo se plantea la revisión.
Una estrategia útil combina dos mundos: herramientas deterministas, que se ejecutan siempre igual y detectan problemas conocidos, y prompts bien diseñados, que ayudan a la IA a razonar con contexto y a encontrar relaciones que un linter no ve. La clave está en convertir la revisión en un proceso sistemático, no en una conversación improvisada.
Seis dimensiones para revisar sin dejar huecos
Una revisión completa no debería limitarse a comprobar si el software funciona. También debe mirar seguridad de aplicación, ciberseguridad e infraestructura, rendimiento, accesibilidad, usabilidad y mantenibilidad. Cada dimensión toca a perfiles distintos, pero todas terminan conectando.
La seguridad de aplicación se centra en inyecciones, XSS, control de acceso, criptografía o exposición de datos sensibles. La parte de ciberseguridad e infraestructura habla más el lenguaje de los administradores de sistemas: secretos en repositorios, contenedores ejecutándose como root, dependencias vulnerables, IAM con permisos excesivos, puertos abiertos, TLS mal configurado o pipelines de CI/CD que filtran tokens en los logs.
El rendimiento obliga a revisar consultas N+1, concurrencia, memoria, caché o escalabilidad. La accesibilidad pone el foco en teclado, lectores de pantalla, contraste y formularios. La usabilidad no se limita a interfaces web: una CLI confusa o una API con errores crípticos también generan coste operativo. La mantenibilidad, por su parte, mide si el código podrá entenderse, probarse y evolucionar sin convertirse en una trampa para el equipo.
Herramientas primero, IA después
La base debería estar formada por herramientas que no inventan nada y pueden integrarse en CI. En seguridad de aplicación entran linters con reglas específicas, SAST como Semgrep, SonarQube o CodeQL, y pruebas dinámicas con OWASP ZAP o Burp Suite. En infraestructura aparecen Trivy, Grype, gitleaks, trufflehog, Hadolint, Checkov, tfsec, kube-score o benchmarks CIS.
Para rendimiento, los profilers del lenguaje, las pruebas de carga y los APM siguen siendo imprescindibles. En accesibilidad, herramientas como Lighthouse, Pa11y, WAVE o axe DevTools ayudan a detectar problemas repetibles. En calidad, los linters, formatters, métricas de complejidad y cobertura de tests siguen poniendo orden.
La IA entra mejor en una segunda fase. Su valor no está en reemplazar esos controles, sino en interpretar el contexto, enlazar fallos, explicar impacto y proponer parches. Para eso necesita prompts maestros, no órdenes vagas.
Un buen prompt de revisión debe definir el rol del modelo, el alcance, el método, el formato de salida y las preguntas de aclaración. No es lo mismo pedir “mira si hay problemas” que ordenar una revisión adversaria con rastreo de datos desde la entrada hasta el punto peligroso, severidad, ubicación exacta, escenario de explotación, impacto y arreglo listo para aplicar.
Un flujo realista para equipos técnicos
El flujo más práctico combina automatización, IA y criterio humano. Primero corren las herramientas deterministas en CI: linters, escáneres de dependencias, análisis de secretos, pruebas de infraestructura como código y validaciones de seguridad conocidas. Esa fase debe bloquear lo evidente.
Después llega la revisión con IA sobre el diff de la pull request, usando un prompt maestro y el complemento del stack correspondiente. No se revisa igual un proyecto Laravel que un manifiesto de Kubernetes, un Terraform o un script Bash. Los problemas concretos cambian: desde unserialize() en PHP hasta runAsRoot en Kubernetes, 0.0.0.0/0 en Terraform o variables sin comillar en Bash.
La última palabra debe seguir siendo humana. La IA puede acelerar la detección y ordenar los hallazgos, pero sus resultados son pistas cualificadas, no dogmas. El revisor debe validar los problemas críticos, comprobar los falsos positivos y decidir si el cambio puede publicarse, si necesita arreglos o si debe bloquearse.
La regla sencilla es bloquear cualquier hallazgo crítico o alto, venga de una herramienta automática o de una revisión asistida por IA. Así el proceso deja de depender del ojo clínico de una persona concreta y se convierte en una red de seguridad más estable.
La revisión moderna no necesita escoger entre IA y herramientas tradicionales. Necesita integrar ambas con un proceso claro. Las herramientas ponen el suelo; la IA aporta contexto y razonamiento; el equipo técnico conserva el criterio. Esa combinación es la que puede evitar que un secreto commiteado, un contenedor mal configurado o una vulnerabilidad de negocio lleguen a producción.
Preguntas frecuentes
¿La IA puede sustituir una revisión de código tradicional?
No debería. La IA ayuda a razonar con contexto y a explicar problemas, pero debe combinarse con linters, SAST, escáneres de dependencias, pruebas y revisión humana.
¿Por qué un prompt genérico no funciona bien?
Porque no define alcance, método ni formato de salida. Un buen prompt debe indicar qué revisar, cómo priorizar hallazgos, cómo evitar falsos positivos y qué tipo de solución entregar.
¿Qué partes de infraestructura puede revisar una IA?
Puede ayudar a revisar Dockerfiles, manifiestos de Kubernetes, Terraform, scripts Bash, pipelines CI/CD, permisos IAM, secretos, configuraciones inseguras y riesgos de exposición.
Más información en GitHub Awesome Code Review Prompts
