70% de los desarrolladores saben que la IA escribe código defectuoso — y aun así lo despliegan en producción

70% de los desarrolladores saben que la IA escribe código defectuoso — y aún así lo implementan en producción

Una nueva investigación revela una paradoja: 70% de los desarrolladores consideran inseguro el código de IA, pero 30% de ellos aún lo implementan en producción — sin verificaciones adicionales.

Números sin sensacionalismo

La encuesta cubrió desarrolladores que utilizan activamente asistentes de IA — GitHub Copilot, ChatGPT, Claude y otras herramientas. El cuadro es consistente: la mayoría reconoce los riesgos, pero la presión de plazos y la ilusión de confiabilidad prevalecen. 70% admiten que la IA produce consistentemente código con vulnerabilidades, errores de lógica, patrones de seguridad obsoletos o arquitectura claramente mala.

Uno de cada tres de ellos implementa tal código en entornos de combate — sin revisión, sin análisis estático, a veces sin pruebas. No se trata de casos aislados de negligencia — es síntoma de un problema sistémico. El autor de una columna en Habr, exmiembro del equipo de PVS-Studio, habla directamente: para él esto no es un descubrimiento.

Tenía conversaciones sobre expectativas infladas de herramientas de IA hace un año. Lo nuevo es que la industria de repente comenzó a discutir el problema como algo inesperado.

Por qué el código de IA parece confiable

La raíz del problema radica en la naturaleza misma de los modelos de lenguaje. La IA genera código con confianza, sin salvedades. La sintaxis es correcta, la estructura es familiar, el linter está silencioso. El desarrollador ve un resultado "parece que funciona" — y disminuye la percepción crítica. Este es un fenómeno psicológico bien estudiado: cuanto más autoritaria es la fuente, más débil es el escepticismo. La IA produce resultados al instante — lo que crea adicionalmente la impresión de que "el modelo ya verificó todo". En la práctica, no es así.

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

código generado — como en los textos en general".

Un modelo de lenguaje no conoce la lógica empresarial de un sistema particular, no entiende qué datos vendrán durante la operación real. Puede reproducir patrones vulnerables — inyecciones SQL, valores por defecto inseguros, falta de validación de entrada — simplemente porque aparecieron frecuentemente en el corpus de entrenamiento. Las alucinaciones en el código no son raras sino una consecuencia natural. El problema se agrava por el progreso de las herramientas mismas. Los desarrolladores observan mejoras mes tras mes y tienden a extrapolar: "antes cometía errores, ahora notablemente mejor". Pero "mejor" no es igual a "seguro" — esta brecha es la fuente de incidentes.

Preguntas que debieron haberse hecho antes

Ahora la industria se somete a una reconsideración tardía. Los equipos se hacen preguntas que debieron plantearse cuando se desplegaron por primera vez los asistentes de IA:

• ¿Se necesita una lista de verificación separada para revisar el código generado por IA?
• ¿Cómo configurar CI/CD para detectar automáticamente errores típicos de generadores?
• ¿Cómo enseñas a los juniors que ya se han acostumbrado a confiar en el autocompletado?
• ¿Qué papel deben jugar los analizadores estáticos en un pipeline con IA?
• ¿Cómo explicas a la gerencia que "generado en 10 segundos" no es lo mismo que "listo para desplegar"?

La mayoría de los equipos tantean respuestas por prueba y error — a veces a costo de incidentes reales en producción.

Qué significa esto

El problema no es con la IA como tecnología. El problema es con el posicionamiento: las herramientas se venden como reemplazo de desarrollador, pero funcionan como un borrador que requiere verificación. Hasta que los equipos desarrollen una cultura de revisión obligatoria de código de IA — las estadísticas solo empeorarán. La solución es vieja y aburrida: análisis estático, revisión de código obligatoria, cobertura de pruebas y una comprensión clara de que la velocidad de generación no es igual a la calidad del resultado. Las herramientas para esto han existido durante mucho tiempo. La cuestión está en la disciplina de su aplicación.