El 70 % de los desarrolladores sabe que la IA escribe código con fallos, y aun así lo despliega en producción

Un nuevo estudio ha revelado una paradoja: el 70 % de los desarrolladores considera inseguro el código de la IA, pero el 30 % de ellos lo despliega en producción de todos modos, sin comprobaciones adicionales.

Cifras sin sensacionalismo

La encuesta abarcó a desarrolladores que usan activamente asistentes de IA como GitHub Copilot, ChatGPT, Claude y otras herramientas. El panorama es consistente: la mayoría es consciente de los riesgos, pero la presión de los plazos y la ilusión de fiabilidad se imponen.

El 70 % admite que la IA produce de forma sistemática código con vulnerabilidades, errores lógicos, patrones de seguridad obsoletos o directamente una mala arquitectura. Uno de cada tres despliega ese código en entornos reales, sin revisión, sin análisis estático y, a veces, sin pruebas. No son casos aislados de negligencia, sino el síntoma de un problema sistémico.

El autor de una columna en Habr, procedente del equipo de PVS-Studio, lo dice sin rodeos: para él no es ningún descubrimiento. Ya hablaba de las expectativas infladas sobre las herramientas de IA hace un año. Lo nuevo es que el sector ha empezado de repente a debatir el problema como si fuera inesperado.

Por qué el código de la IA parece fiable

La raíz del problema está en la naturaleza misma de los modelos de lenguaje. La IA genera código con seguridad y sin reservas. La sintaxis es correcta, la estructura resulta familiar y el linter no protesta. El desarrollador ve un resultado que "parece funcionar" y rebaja su espíritu crítico. Es un fenómeno psicológico bien estudiado: cuanto más autoridad tiene la fuente, más débil es el escepticismo.

La IA entrega el resultado al instante, lo que refuerza la sensación de que "el modelo ya lo ha comprobado todo". En la práctica, no es así.

"Las expectativas están infladas y hay una confianza excesiva en el

código generado, como ocurre con los textos en general."

Un modelo de lenguaje no conoce la lógica de negocio de un sistema concreto ni entiende qué datos llegarán en la explotación real. Puede reproducir patrones vulnerables, como inyecciones SQL, valores por defecto inseguros o falta de validación de entradas, simplemente porque aparecían con frecuencia en su corpus de entrenamiento. Las alucinaciones en el código no son raras; son la norma.

El progreso de las propias herramientas agrava el problema. Los desarrolladores ven mejoras de un mes a otro y tienden a extrapolar: "antes cometía errores, ahora es notablemente mejor". Pero "mejor" no equivale a "seguro", y esa brecha es el origen de los incidentes.

Preguntas que debieron plantearse antes

El sector vive ahora una reflexión tardía. Los equipos se hacen preguntas que debieron surgir al adoptar los asistentes de IA:

• ¿Hace falta una lista de comprobación específica para revisar el código generado por IA?
• ¿Cómo configurar el CI/CD para detectar automáticamente los errores típicos de los generadores?
• ¿Cómo formar a los júniors que ya se han acostumbrado a confiar en el autocompletado?
• ¿Qué papel deben tener los analizadores estáticos en un pipeline con IA?
• ¿Cómo explicar a la dirección que "generado en 10 segundos" no equivale a "listo para desplegar"?

La mayoría de los equipos busca las respuestas a base de ensayo y error, a veces al precio de incidentes reales en producción.

Qué significa esto

El problema no es la IA como tecnología. El problema es el posicionamiento: las herramientas se venden como sustituto del desarrollador, pero funcionan como un borrador que requiere revisión. Mientras los equipos no desarrollen una cultura de revisión obligatoria del código de IA, las estadísticas solo irán a peor.

La solución es vieja y aburrida: análisis estático, code review obligatorio, cobertura de pruebas y una comprensión clara de que la velocidad de generación no equivale a la calidad del resultado. Las herramientas para ello existen desde hace tiempo. La cuestión es la disciplina para aplicarlas.