Sus herramientas de IA para programar son rápidas. Su pipeline no. Ese es el verdadero problema.
Dos cosas ocurrieron esta semana que, tomadas en conjunto, le dicen todo lo que necesita saber sobre hacia dónde se dirige el desarrollo de software en 2026.
Primero, el informe State of DevOps Modernization 2026 se publicó el 11 de marzo, basado en una encuesta a 700 ingenieros en Estados Unidos, Reino Unido, Alemania, Francia e India. El hallazgo principal: los equipos que usan herramientas de IA para programar varias veces al día despliegan a producción más rápido, pero el 69% de esos mismos usuarios intensivos afirma experimentar problemas de despliegue «siempre», «casi siempre» o «con frecuencia» cuando hay código generado por IA de por medio. Mientras tanto, el 51% reporta más problemas de calidad de código y el 53% reporta más incidentes de seguridad desde que adoptó estas herramientas.
Dos días antes, Anthropic lanzó Code Review para Claude Code, un sistema multiagente que revisa automáticamente los pull requests en busca de errores lógicos. Sus propios números internos explican por qué lo construyeron: la producción de código por ingeniero en Anthropic creció un 200% en el último año, y la empresa pasó de tener un 16% de PRs con comentarios de revisión sustanciales a un 54% tras desplegar su sistema de revisión internamente.
¿Ve el patrón? La IA está haciendo que producir código sea barato y rápido. Todo lo que viene después del código —las pruebas, el escaneo de seguridad, el despliegue, la revisión— es ahora el cuello de botella. El informe de Harness llama a esto la «Paradoja de Velocidad de la IA». Nosotros simplemente lo llamamos el día a día.
Lo hemos visto suceder en tiempo real
A partir de nuestro trabajo con PHP y Docker para clientes empresariales, especialmente en industrias reguladas como las finanzas suizas, llevamos meses viendo una versión de este problema. Los equipos adoptan asistentes de IA para programar, la producción aumenta y entonces el pipeline de CI/CD diseñado para los volúmenes de commits de la era 2022 empieza a atascarse. Las compilaciones se acumulan en cola. Las pruebas tardan más porque simplemente hay más código que probar. Los escaneos de seguridad que antes eran una molestia menor se convierten en una barrera de 45 minutos entre un desarrollador y su despliegue.
Los datos de Harness lo respaldan: el 73% de los líderes de ingeniería afirma que «prácticamente ningún» equipo tiene plantillas estandarizadas o rutas óptimas para sus pipelines. Solo el 21% puede poner en marcha un pipeline de compilación y despliegue funcional en menos de dos horas. Los desarrolladores dedican aproximadamente el 36% de su tiempo a tareas manuales como perseguir aprobaciones y volver a ejecutar trabajos fallidos.
Ese último número debería preocuparle. Un tercio de su capacidad de ingeniería, quemado en tareas tediosas. No construyendo funcionalidades. No corrigiendo errores. Solo vigilando un pipeline que no fue diseñado para este volumen de trabajo.
El cuello de botella en la revisión de código es real, y es un problema de seguridad
Aquí es donde la situación se vuelve incómoda desde una perspectiva de seguridad. Durante nuestros trabajos de pruebas de penetración, encontramos regularmente errores que deberían haberse detectado en la revisión. Casos límite de autenticación, lógica de autorización que casi es correcta pero no del todo, validación de entradas que cubre el 90% de los casos y pasa por alto el 10% que realmente le importa a un atacante.
Ahora multiplique eso por el volumen de código generado por IA que inunda los pull requests. La entrada del blog de Anthropic es honesta al respecto: antes de su herramienta de revisión de código, la mayoría de los PRs se revisaban por encima, no se leían a fondo. Los ingenieros tienen demasiado trabajo. Ven un PR de 400 líneas, lo hojean en busca de problemas obvios, lo aprueban y siguen adelante. Eso no es un defecto de carácter. Es un problema de capacidad.
La herramienta de Anthropic es interesante porque se enfoca en errores lógicos en lugar de detalles de estilo. En PRs grandes (de más de 1.000 líneas), el 84% de las revisiones detecta hallazgos, con un promedio de 7,5 problemas. En PRs pequeños de menos de 50 líneas, eso baja al 31%. También detectaron internamente un cambio que rompía la autenticación: una única edición de aspecto inocente que habría interrumpido su propio sistema de autenticación.
Sigo pensando en ese caso. Una sola línea. En un servicio de autenticación. Detectada por un revisor automatizado. Ese es el tipo de error que encontramos durante las pruebas de penetración, semanas o meses después de que se publicó. Detectarlo en el PR es infinitamente más económico.
Lo que debería hacer realmente
No vamos a decirle que vaya a comprar la plataforma de un proveedor específico. Pero basándonos en lo que vemos en nuestros proyectos web y móviles, esto es lo que está funcionando:
Audite su pipeline post-código esta semana. En serio, solo mapéelo. ¿Cuánto tiempo pasa desde el merge hasta producción? ¿Dónde están los traspasos manuales? ¿Dónde se forman colas? La mayoría de los equipos con los que hablamos nunca han medido esto de principio a fin. Saben que su compilación tarda 8 minutos, pero no tienen idea de que están perdiendo 3 horas en cadenas de aprobación y aprovisionamiento de entornos. Ese es su punto de partida.
Automatice el escaneo de seguridad antes, no después. Cuando configuramos la protección WAF y DDoS para plataformas de viajes, siempre impulsamos que las verificaciones de seguridad estén lo más cerca posible del desarrollador. El mismo principio aplica a su pipeline. El análisis estático, el escaneo de dependencias y la detección de secretos deben ejecutarse en cada PR, automáticamente, antes de que ningún revisor humano lo vea. Si todavía ejecuta escaneos de seguridad solo en staging, o peor aún, como puerta de entrada antes de producción, está encontrando los problemas demasiado tarde para corregirlos de forma económica.
No omita la revisión humana solo porque agregó revisión con IA. La herramienta de Anthropic no aprobará PRs. Esa es una decisión de diseño deliberada, y es la correcta. En nuestros proyectos nativos para iOS y Android, hemos comprobado que las herramientas de IA detectan clases de errores distintas a las que detectan los humanos. La IA es buena identificando inconsistencias lógicas en un diff extenso. Los humanos son mejores preguntando «espera, ¿por qué estamos haciendo esto en absoluto?». Necesita ambos.
Estandarice sus rutas de despliegue. Los datos de Harness indican que el 73% de los equipos carece de rutas óptimas. Si cada servicio se despliega de forma diferente, no puede automatizar las verificaciones posteriores y cada despliegue es un riesgo único. A partir de nuestro trabajo construyendo aplicaciones cloud-native en AWS, la inversión de mayor retorno que hemos visto hacer a los equipos es una plantilla de despliegue bien mantenida que cada nuevo servicio hereda por defecto.
La incómoda verdad
La historia real de esta semana no es que la IA esté haciendo a los desarrolladores más rápidos. Eso ya lo sabíamos. La historia real es que la mayoría de las organizaciones construyeron su infraestructura de entrega para un mundo más lento, y las herramientas de IA para programar están sometiendo esos sistemas a una prueba de estrés hasta el punto de quiebre.
El informe de Harness encontró que el 77% de los equipos está bloqueado regularmente esperando a otros equipos para tareas rutinarias de entrega. Eso no es un problema de herramientas. Es un problema de arquitectura y procesos. Ninguna cantidad de código generado por IA va a solucionarlo.
Si su equipo escribe código 2 veces más rápido pero despliega con 2 veces más incidentes, no ha ganado velocidad. Ha ganado caos con mejor sintaxis.
Ponga en orden su pipeline. Luego deje que la IA vuele.
Si algo de esto le suena a la semana de su equipo, hablemos. Hemos ayudado a startups y equipos empresariales a superar exactamente este tipo de dolores de crecimiento, en web, móvil y seguridad.