4 millones de desarrolladores usan agentes de código con IA. ¿Alguien revisa el resultado?
Qué ocurrió
OpenAI tuvo una semana intensa. Codex, su agente de codificación con IA, creció de 3 millones a más de 4 millones de desarrolladores semanales en las primeras dos semanas de abril. Lanzaron GPT-5.5, su modelo de frontera más reciente, que posicionan como su modelo de codificación más potente hasta la fecha, resolviendo el 58,6% de los problemas reales de GitHub en el benchmark SWE-Bench Pro en un solo intento. También presentaron Codex Labs, un programa que integra ingenieros de OpenAI directamente dentro de los equipos empresariales, junto con alianzas con grandes integradores de sistemas para llevar Codex de la experimentación a los flujos de trabajo en producción.
La misma semana, ProjectDiscovery publicó su Informe de Impacto de Codificación con IA 2026. El 100% de los profesionales de seguridad encuestados reportaron un aumento en la producción de ingeniería durante el último año, y casi la mitad atribuyó la mayor parte de esa aceleración a las herramientas de codificación con IA. Pero aquí está el dato que debería preocuparle: el 78% de esos mismos profesionales calificó «exponer secretos» como el principal desafío de seguridad introducido o amplificado por la codificación asistida por IA. Dos tercios de ellos dedican más de la mitad de su tiempo a validar hallazgos manualmente en lugar de corregirlos.
Así que tenemos una herramienta de codificación con IA que suma un millón de nuevos desarrolladores cada dos semanas, mientras los equipos de seguridad ya están desbordados.
La brecha de la que nadie habla con honestidad
Quiero ser cuidadoso aquí. Nosotros mismos usamos herramientas de codificación con IA en nuestro trabajo. Son genuinamente útiles para código repetitivo, andamiaje de pruebas y exploración de bases de código desconocidas. Cuando desarrollamos aplicaciones cloud-native y APIs para clientes empresariales, los asistentes de IA pueden ahorrar tiempo real en código de infraestructura repetitivo.
Pero hay una diferencia entre usar estas herramientas con salvaguardas y tratar su resultado como algo de confianza. En este momento, la industria avanza con fuerza hacia lo segundo.
La investigación de GitGuardian de 2026 encontró que los commits asistidos por IA en repositorios públicos de GitHub filtraron secretos a aproximadamente el doble de la tasa base humana: alrededor del 3,2% frente al 1,5% de los commits escritos por humanos. Las pruebas de Veracode con más de 100 LLMs mostraron que el código generado por IA contiene 2,74 veces más vulnerabilidades que el código escrito por humanos. Una firma forense que evaluó docenas de aplicaciones construidas con IA entre enero y abril de 2026 encontró que el 54% de las bases de código tenían vulnerabilidades de inyección SQL y el 91% no tenía ningún registro de seguridad significativo.
Esos no son casos extremos. Ese es el resultado mediano cuando los equipos lanzan código generado por IA sin una revisión adecuada.
Por qué esto importa para su equipo ahora mismo
La velocidad a la que Codex se está incorporando a los flujos de trabajo empresariales es la verdadera historia aquí. Ya no se trata solo de desarrolladores individuales usando autocompletado. OpenAI se está asociando con grandes firmas de consultoría para desplegar Codex en organizaciones de ingeniería enteras. Han lanzado plugins empresariales, integraciones de CI/CD y un navegador integrado para servidores de desarrollo locales. Codex ahora puede leer la salida de su terminal mientras trabaja.
Eso es mucha superficie de ataque. A partir de nuestro trabajo de pruebas de penetración con estudios de videojuegos y plataformas de viajes, seguimos viendo el mismo patrón: cuanto más rápido se lanza el código, más creativas se vuelven las vulnerabilidades. No siempre son las obvias. Son roles IAM excesivamente amplios en Terraform generado, tokens codificados en archivos .env que se confirman porque nadie revisó el andamiaje inicial de la IA, o endpoints de API sin límite de velocidad porque el modelo no pensó en añadirlo.
En nuestros proyectos nativos de iOS y Android, hemos visto cómo los asistentes de IA sugieren código de red que silenciosamente recurre a HTTP cuando un certificado falla. En una aplicación de salud que maneja datos de pacientes, ese tipo de cosa no es solo un error. Es un incidente de cumplimiento normativo. Cuando desarrollamos aplicaciones móviles para industrias reguladas, tratamos cada línea de código generado de la misma manera que tratamos el código de un desarrollador junior nuevo: se revisa, se prueba y no se lanza hasta que alguien que entiende el dominio lo aprueba.
Qué debería hacer realmente
Aquí está la versión práctica, basada en lo que hemos implementado en nuestros propios proyectos:
Añada hoy mismo una barrera de seguridad para el código generado por IA. Si no tiene hooks de pre-commit ejecutando escaneo de secretos y SAST básico, ya va por detrás. Herramientas como Gitleaks y la edición de código abierto de Semgrep son gratuitas y tardan menos de una hora en configurarse. Este único cambio captura la categoría más peligrosa de errores de codificación con IA: las credenciales filtradas.
Deje de tratar el resultado de la IA como una entrada de confianza. El OWASP LLM Top 10 es explícito al respecto. El resultado de un modelo debe validarse y sanearse de la misma manera que trataría la entrada de un usuario en un formulario. Si su asistente de IA genera una consulta de base de datos, debe estar parametrizada. Si genera un endpoint de API, necesita autenticación. Si escribe infraestructura como código, alguien debe verificar que los permisos no estén completamente abiertos. Cuando configuramos seguridad en la nube y protección DDoS para clientes, encontramos regularmente que los scripts de infraestructura generados por IA tienen configuraciones excesivamente permisivas por defecto. Según los datos de amenazas de CrowdStrike de 2026, el 41% del código de backend generado por IA incluye permisos excesivamente amplios.
Haga seguimiento del porcentaje de su base de código que es generado por IA. No puede delimitar sus pruebas de seguridad si no sabe qué parte de su código proviene de un modelo. Esto es especialmente importante para los equipos sujetos a SOC 2, GDPR o HIPAA, donde los registros de auditoría importan y «lo escribió una IA» no satisface los requisitos de cumplimiento.
No omita las tareas básicas solo porque la IA las hizo rápido. La revisión de código existe por una razón. El código generado por IA que compila y pasa el lint puede seguir haciendo cosas incorrectas. Lo hemos visto. El código se ve limpio, las pruebas pasan, y luego un pen tester encuentra una ruta de escalación de privilegios el primer día.
El panorama general
No creo que las herramientas de codificación con IA vayan a desaparecer. No deberían. Las ganancias en productividad son reales. Pero estamos en esa fase familiar en la que la adopción supera a la seguridad, y las organizaciones que establezcan salvaguardas ahora estarán en una posición mucho mejor que las que se apresuren después de su primera brecha asistida por IA.
El mercado de seguros ya lo está notando. Las aseguradoras están empezando a limitar los pagos por pérdidas cibernéticas vinculadas al uso de IA. Si su cobertura se encarece o se reduce porque su equipo lanzó código generado por IA sin revisar, eso es un problema de negocio, no solo técnico.
Desde nuestra experiencia combinada de más de 30 años en videojuegos, viajes y software empresarial, el patrón es siempre el mismo: cada gran cambio tecnológico, ya sea la nube, los contenedores o las APIs, atravesó una fase en la que la capacidad superó a la seguridad. Los equipos que salieron bien librados fueron los que trataron la seguridad como parte de la adopción, no como algo que añadir después del primer incidente.
Los agentes de código con IA no son diferentes. Úselos. Pero revise el resultado.
Si su equipo está lanzando código generado por IA y no está seguro de cómo es realmente su postura de seguridad, hablemos.