La IA ya escribe el 80% del código en algunos equipos, pero el 45% tiene vulnerabilidades críticas
Greg Brockman, presidente de OpenAI, declaró esta semana que las herramientas de codificación con inteligencia artificial escriben hoy hasta el 80% del código en algunos equipos de desarrollo. En diciembre pasado, esa cifra era del 20%. El salto en cuatro meses es llamativo, pero la estadística que lo acompaña no lo es menos: según la empresa de análisis de seguridad Veracode, el 45% del código generado por modelos de lenguaje grande presenta vulnerabilidades clasificadas en el OWASP Top 10, las diez categorías de fallos más peligrosos en software empresarial.
Del 20% al 80% en cuatro meses: qué hay detrás del salto
El dato de Brockman no es una proyección ni una estimación optimista. Corresponde a mediciones internas de equipos que han adoptado herramientas como Codex, el sistema de generación de código de OpenAI. La velocidad del cambio tiene explicación técnica: los modelos de 2025 y 2026 no solo completan líneas o funciones aisladas, sino que generan bloques completos de lógica, tests automáticos y documentación a partir de una descripción en lenguaje natural. Lo que antes requería horas de un desarrollador senior ahora tarda segundos.
Google confirma una tendencia parecida. Sundar Pichai, CEO de la compañía, ha revelado que el 75% del nuevo código que llega al repositorio de Google ya está generado por inteligencia artificial y revisado posteriormente por ingenieros humanos. Meta va un paso más allá en sus estimaciones: espera que el 65% de sus ingenieros en la división de creación utilicen IA para generar más del 75% del código que finalmente confirman. Y Dario Amodei, CEO de Anthropic, proyecta que la IA podría escribir el 90% del código en los próximos tres a seis meses en los equipos más avanzados.
El problema que los titulares no cuentan: vulnerabilidades en casi la mitad del código
La aceleración tiene un coste que las métricas de productividad no capturan. Veracode analizó muestras de código generado por los principales modelos de lenguaje y encontró que el 45% fallaba las pruebas de seguridad contra el OWASP Top 10. Esta lista incluye vulnerabilidades como inyección SQL, control de acceso roto, configuraciones inseguras y exposición de datos sensibles, categorías que llevan décadas siendo la causa principal de brechas de datos en empresas.
El problema no es que la IA genere código malicioso de forma intencionada. El problema es que los modelos aprenden de repositorios de código públicos que históricamente han incluido patrones inseguros, y los replican con la misma eficiencia con la que replican los patrones correctos. Sin una capa de revisión humana activa y herramientas de análisis estático, el código llega a producción con fallos que un desarrollador experimentado habría detectado en la revisión.
La postura de OpenAI, Google y Meta ante el riesgo
OpenAI ha sido explícita en su posición: exige que haya un humano responsable de todo código que se confirme al repositorio. La empresa rechaza de forma oficial el enfoque de merge ciego, es decir, aprobar automáticamente el código generado sin revisión humana. Google aplica la misma lógica: el 75% de código generado por IA se acompaña del dato de que cada línea ha sido aprobada por un ingeniero.
Meta, por su parte, ha diseñado flujos de trabajo donde la IA genera y el equipo humano evalúa, pero el ritmo de adopción es tan acelerado que la pregunta práctica surge sola: cuánto tiempo dedica realmente un desarrollador a revisar código que no escribió y que llega en bloques de cientos de líneas. La presión por velocidad y la comodidad de aprobar con un clic son factores humanos que ninguna política técnica resuelve por sí sola.
Qué significa esto para los equipos de desarrollo en empresas medianas
Las grandes tecnológicas tienen divisiones enteras dedicadas a seguridad de código, auditorías automáticas y pipelines de integración con herramientas como SonarQube, Snyk o Checkmarx. Para una empresa mediana que adopta GitHub Copilot o Cursor sin ese contexto de infraestructura, el escenario es diferente. El equipo gana velocidad de desarrollo pero hereda el riesgo de vulnerabilidades que los modelos de lenguaje introducen sistemáticamente.
La solución no pasa por frenar la adopción. Pasa por tres medidas concretas: primero, integrar herramientas de análisis estático de seguridad (SAST) en el pipeline de CI/CD antes de que el código llegue a producción. Segundo, establecer revisiones de código con criterios explícitos de seguridad, no solo de funcionalidad. Tercero, formar al equipo para identificar los patrones inseguros más frecuentes en código generado por IA, que se concentran en gestión de autenticación, validación de inputs y manejo de secretos.
La estadística de Stack Overflow de 2025 añade otra capa al problema: solo el 29% de los desarrolladores confía plenamente en las herramientas de IA que usa a diario. El 71% restante tiene reservas, pero el ritmo de adopción en las empresas sigue acelerándose. La brecha entre confianza individual y adopción organizacional es exactamente el espacio donde los fallos de seguridad encuentran su oportunidad.
Conclusión
El salto del 20% al 80% de código generado por IA en cuatro meses no es solo una métrica de productividad. Es un cambio en cómo se construye el software empresarial y en quién asume la responsabilidad de que ese software sea seguro. Las cifras de OpenAI, Google y Meta confirman la tendencia. Las cifras de Veracode confirman el riesgo. La pregunta para cualquier equipo de desarrollo en 2026 no es si adoptar estas herramientas, sino con qué infraestructura de control hacerlo para que la velocidad no se convierta en deuda técnica de seguridad imposible de saldar.
