Una empresa de servicios financieros adoptó Cursor hace poco y casi de inmediato se encontró frente a un número que debería hacer parar a cualquier líder de ingeniería: pasó de producir 25.000 líneas de código al mes a 250.000. Una ganancia de productividad de 10x. En papel, eso suena exactamente a lo que la promesa de la IA de programación debería entregar.
La realidad fue un backlog de un millón de líneas de código sin revisar.
Esa historia — reportada esta semana por The New York Times — captura algo que vengo observando desarrollarse durante meses. El boom de la IA de coding no eliminó el trabajo duro del desarrollo de software. Lo relocalizó. El cuello de botella no desapareció; se desplazó aguas abajo, de escribir código a revisar y asegurar ese código. Y la mayoría de las organizaciones de ingeniería no están en absoluto preparadas para lo que llegó.
El Cuello de Botella Se Movió — Y Nadie Estaba Listo
Por décadas, la restricción en el desarrollo de software era la velocidad de escritura. Los ingenieros eran costosos, cuidadosos y lentos por necesidad. Quizás producías algunas docenas de líneas de código blindado por día. El proceso de revisión escalaba para acompañar ese ritmo.
Los agentes de IA cambiaron la ecuación fundamental. Herramientas como Cursor, Claude Code y Codex de OpenAI — especialmente tras mejoras significativas de capacidad a finales de 2025 — ahora pueden generar features completos, refactorizar codebases enteras y producir implementaciones listas para producción en horas. El resultado es que los equipos pueden publicar dramáticamente más código del que jamás pudieron antes.
Pero el código que se escribe todavía necesita ser revisado. Necesita ser testeado. Necesita ser auditado por vulnerabilidades de seguridad. Y esos pasos no han sido automatizados ni cerca del mismo ritmo que la generación de código.
Joni Klippert, CEO de StackHawk, describió la situación de la firma financiera sin rodeos: el volumen bruto de código entregado, y el correspondiente aumento de vulnerabilidades, es algo con lo que el equipo simplemente no puede mantener el paso. Y el efecto aguas abajo se extiende más allá de ingeniería — cuando el desarrollo de software acelera tan dramáticamente, crea presión sobre los equipos de ventas, marketing y soporte al cliente para igualar ese ritmo. El estrés se propaga por toda la organización.
La Crisis de Talento en AppSec Ahora Es Aguda
La dimensión de seguridad de este problema es la que más me preocupa. El rol responsable de detectar errores en código generado por IA — el ingeniero de seguridad de aplicaciones (AppSec) — ya está en una escasez desesperante. Joe Sullivan, asesor de Costanoa Ventures, lo dijo sin eufemismos al Times: no hay suficientes ingenieros de seguridad de aplicaciones en el planeta para satisfacer lo que solo las empresas americanas necesitan ahora mismo.
La propia encuesta de StackHawk a stakeholders de AppSec encontró que el 87% de las organizaciones ya adoptó herramientas de IA de coding en algún grado, y más de la mitad — el 53% — las considera un riesgo de seguridad moderado o significativo. Cuando se les preguntó por sus mayores desafíos para 2026, “mantener el ritmo con la velocidad de desarrollo y el código generado por IA” fue la preocupación más citada.
Esta es la tensión que define dónde estamos: las mismas herramientas que impulsan la productividad están creando una superficie de seguridad que se expande más rápido de lo que las organizaciones pueden instrumentarla. Mientras tanto, la IA también está introduciendo clases de vulnerabilidades completamente nuevas — inyección de prompts, envenenamiento de contexto, bypasses de guardrails — que las herramientas tradicionales de AppSec no fueron diseñadas para detectar.
“Ahora Todo el Mundo Dentro de tu Empresa Se Convierte en Desarrollador”
Hay otra dimensión en esto que recibe menos atención: la democratización de la producción de código. Michele Catasta, presidente de Replit, lo encuadró bien: con las herramientas de IA, cualquier persona en la organización — no solo los ingenieros — puede construir una idea de software en cuestión de horas.
Eso es genuinamente interesante. Desbloquea creatividad y autonomía en todos los equipos. Acelera los prototipos. Significa que un product manager o un analista financiero puede construir una herramienta funcional sin esperar meses por recursos de ingeniería.
También significa que código está siendo creado por personas que quizás no tienen ninguna formación en seguridad, confiabilidad o diseño de sistemas. Los proyectos de código abierto, que dependen de la contribución voluntaria y la revisión comunitaria, han sido inundados de envíos habilitados por IA. La carga de curación se volvió abrumadora.
Andrew Bosworth, CTO de Meta, señaló en un memo interno que proyectos que antes requerían cientos de ingenieros ahora pueden hacerse con decenas, y que trabajo que tomaba meses ahora puede tomar días. Tiene razón. Pero reducir el equipo de ingeniería mientras simultáneamente se escala la producción de código es una fórmula que pone una presión enorme sobre quienes quedan para hacer la revisión.
Lo que la Industria Está Construyendo en Respuesta
El mercado está comenzando a reaccionar. Cursor lanzó Automations a principios de marzo — un sistema de agentes siempre activos que se disparan automáticamente cuando se hace commit de código nuevo, ejecutando auditorías de seguridad y revisiones de bugs sin que un ingeniero necesite iniciarlo. Es un reconocimiento, desde una de las plataformas líderes de IA de coding, de que el problema de revisión es real y necesita soluciones sistemáticas.
Las herramientas de revisión de código por IA — CodeRabbit, Greptile, Qodo, Snyk Code — están viendo adopción acelerada. Los repositorios que usan revisión asistida por IA muestran tiempos de merge más rápidos y menos defectos post-merge. Estas herramientas se están convirtiendo en una capa necesaria entre la generación de código acelerada por IA y el deployment a producción.
Pero estas herramientas son multiplicadores de fuerza, no reemplazos del juicio humano. Manejan patrones repetibles y señalan riesgos no obvios. No son dueñas de la intención, los trade-offs o el diseño de sistemas. E incluso los mejores revisores de IA tienen límites duros: se vuelven sobreconfiados cuando el contexto está incompleto, y generan ruido que erosiona la confianza cuando están mal calibrados.
Lo que los Líderes de Ingeniería Necesitan Estar Pensando
El problema del code overload no es un argumento contra las herramientas de IA de coding. Son demasiado productivas, demasiado transformadoras y demasiado ampliamente adoptadas como para tratarlas como opcionales. Pero sí es un argumento de que la conversación de adopción ha sido incompleta.
La mayoría de los despliegues de IA de coding han sido evaluados en una sola métrica: ¿qué tan rápido podemos publicar? Ese es el marco equivocado. El marco correcto es: ¿qué le hace a nuestra capacidad de revisión, a nuestra postura de seguridad y a nuestra capacidad de mantener lo que construimos a lo largo del tiempo publicar 10 veces más código?
Los ingenieros senior con experiencia para detectar errores y monitorear riesgos sistémicos son más valiosos ahora, no menos. La inversión en AppSec necesita escalar junto con la velocidad de coding, no rezagarse. Y las organizaciones necesitan ser honestas sobre el hecho de que cuando le das a todos en la empresa la capacidad de producir código, también estás extendiendo tu superficie de ataque hacia cada equipo que decida usar esa capacidad.
La fábrica de software no se rompió porque las herramientas de IA de coding fallaron. Se rompió porque el resto de la fábrica no estaba listo para lo que esas herramientas iban a producir.
¿Tu equipo ya está sintiendo la presión del code overload? ¿Cómo están manejando la revisión y la seguridad a este ritmo? Contanos en los comentarios. 