Hace dos años, el código generado por IA era una curiosidad: lo usabas para completar una función y seguías. Hoy es diferente. Los agentes de código escriben módulos completos, proponen arquitecturas, migran bases de datos y hasta abren pull requests sin supervisión constante. La velocidad es real, y también lo es el problema que pocos quieren admitir: ese código llega a producción con riesgos que no se ven a simple vista.

No se trata de volver a escribir todo a mano. Se trata de entender dónde falla el código generado por IA y montar las barreras correctas para que la velocidad no se convierta en una deuda de seguridad impagable.

El problema: velocidad sin red de seguridad

Cuando un modelo genera código no lo “entiende”: predice la siguiente pieza de texto con altísima probabilidad estadística. Por eso reproduce patrones que vio en su entrenamiento — incluyendo los malos. Los riesgos más comunes que he visto en equipos reales:

Vulnerabilidades clásicas reproducidas sin vergüenza. Inyección SQL, XSS, deserialización insegura, rutas sin autenticación: los LLM han memorizado miles de ejemplos de código inseguro en internet, y cuando el prompt no especifica lo contrario, los regurgitan con total confianza. La investigación académica de 2022 de Pearce y colaboradores (Stanford y York) ya detectaba vulnerabilidades en aproximadamente el 40% de los programas generados por asistentes de código.

Dependencias inventadas (o “hallucinated packages”). El modelo sugiere un paquete que parece legítimo pero no existe, o peor, uno que existe pero con un nombre ligeramente distinto al oficial. Estudios recientes estiman que alrededor del 20% de los paquetes recomendados por LLMs son alucinaciones. Un atacante puede registrar esos nombres en el registro público y esperar: cuando tu equipo instala el paquete “equivocado”, el código malicioso ya está dentro de tu build.

Secretos y datos sensibles incrustados. En su afán por “ayudar”, el agente a veces incrusta credenciales de ejemplo, URLs internas o fragmentos con datos reales que viste en el contexto del proyecto. Un API key que aparece en un commit público es un incidente de seguridad esperando a ocurrir.

Código desactualizado o con APIs deprecadas. Los modelos entrenados con datos viejos sugieren funciones obsoletas o versiones vulnerables de librerías. No es un error de sintaxis: es un agujero de seguridad silencioso.

“El código generado por IA no es inseguro porque la IA sea mala: es inseguro porque reproduce los patrones que aprendió — y muchos de esos patrones son malos.”

Ejemplos reales: cómo se materializan los riesgos

Un caso típico: un equipo acelera el desarrollo de una API interna con agentes de código. El agente genera un endpoint de búsqueda que arma la consulta SQL concatenando el input del usuario directamente. Funciona perfecto en las pruebas. En producción, un request con ' OR 1=1 -- devuelve toda la tabla de clientes. No fue malicia del modelo: faltó especificar seguridad en el prompt y revisar el código.

Otro caso: el agente sugiere usar una librería para manejar fechas que “todos usan”. El nombre real es date-fns, pero el modelo sugiere date-fns-helper, que alguien registró hace una semana con una versión que roba variables de entorno. Si tu pipeline instala dependencias sin verificar, ese paquete entra en producción.

Y el caso más silencioso de todos: el código que copia patrones inseguros de Stack Overflow — validación de entrada inexistente, comparaciones de contraseñas hechas a mano, permisos por defecto abiertos. Hallazgos clásicos de pentest, ahora generados automáticamente a escala.

Mitigación: la lista de prácticas que sí funcionan

La buena noticia: los riesgos son conocidos y tienen contramedidas concretas. Esto es lo que aplicamos en DojoFullStack y recomendamos a los equipos que construyen con agentes:

1. Trata el código generado como un borrador de un junior talentoso. El modelo es rápido, entusiasta y a veces brillante, pero comete errores de principiante con total seguridad. Ningún fragmento generado debería ir a producción sin revisión humana.

2. Automatiza el escaneo antes de la revisión humana. No confíes solo en los ojos: integra herramientas SAST en el pipeline, escaneo de dependencias (npm audit, pip-audit, Dependabot) y detección de secretos en cada PR. El costo de un scan automático es centavos; el costo de un leak es una notificación a tus clientes.

3. Blinda el contexto que le das al agente. Si el agente tiene acceso al repo completo, puede (y va a) copiar secretos de archivos de configuración. Aísla credenciales con variables de entorno, usa .gitignore estricto y nunca pegues API keys en el chat. Mínimo privilegio: el agente solo ve lo que necesita.

4. Verifica cada dependencia nueva. Antes de instalar un paquete sugerido: confirma que existe en el registro oficial, revisa su autor y su historial, y fija versiones exactas en el lockfile.

5. Prueba como si el código fuera tuyo (porque lo es). Tests unitarios, pruebas de seguridad básicas y un mínimo de fuzzing sobre inputs del usuario. El OWASP Top 10 sigue siendo el mejor checklist: SQLi, XSS, auth rota, control de acceso, config insegura — cada categoría, una pregunta.

6. Ejecuta en sandbox lo que no confías. El código generado que llega de una fuente no verificada se ejecuta primero en un contenedor o en CI con permisos mínimos, nunca directamente en tu máquina con acceso a producción.

La revisión humana no se delega

Aquí está el punto que más cuesta aceptar: el agente puede escribir el código, pero la responsabilidad sigue siendo tuya. Si un fragmento generado por IA filtra datos de clientes, el responsable legal y técnico no es el modelo: es el equipo que lo desplegó sin revisar.

La revisión humana no es un trámite: es el filtro que convierte la velocidad de la IA en calidad real. Un checklist simple por PR puede ser suficiente: ¿valida entradas? ¿usa consultas parametrizadas? ¿maneja errores sin filtrar información sensible? ¿las dependencias nuevas son legítimas?

En la práctica, los equipos que mejor usan agentes de código son los que tienen el hábito de la revisión más fuerte. La IA no reemplaza el criterio: lo multiplica. Con criterio de seguridad, revisas diez PRs generados por IA en el tiempo de uno escrito a mano — y salen mejores.

El futuro es con IA, pero con barreras

El código generado por IA no va a desaparecer, y no debería: es la mayor ganancia de productividad en desarrollo de software de la última década. La pregunta no es “¿usamos agentes?” sino “¿cómo los usamos sin comprometer la seguridad?” La respuesta está en el proceso: escaneo automatizado, verificación de dependencias, prompts que especifican requisitos de seguridad y, sobre todo, revisión humana disciplinada en cada paso.

Si estás construyendo con agentes de código — o quieres aprender a hacerlo bien desde el principio — la seguridad no es un plugin opcional: es parte del oficio. Sigue explorando estos temas en el blog de DojoFullStack, donde profundizamos en agentes de código, automatización y buenas prácticas de ingeniería. Y si quieres llevar tu carrera al siguiente nivel, en el bootcamp de DojoFullStack aprendes no solo a generar código con IA, sino a revisarlo, blindarlo y llevarlo a producción con criterio profesional.