Líderes de opinión

El código está siendo escrito por IA, pero ¿puede su infraestructura seguir el ritmo?

mm

Estamos viviendo una de las inversiones más extrañas en la historia de la ingeniería de software. Durante décadas, el objetivo era el determinismo; construir sistemas que se comporten de la misma manera cada vez. Ahora estamos agregando agentes de IA probabilísticos sobre esa base, generando código a una escala y velocidad alarmantes. Y honestamente, la mayoría de nuestra infraestructura no fue diseñada para esto.

He pasado años trabajando en herramientas de DevOps, coautor de investigaciones y ayudando a equipos de ingeniería a alcanzar su máximo rendimiento. Lo que estoy viendo ahora con el desarrollo impulsado por IA es más que una evolución. Está exponiendo cada grieta en nuestros flujos de trabajo existentes.

El problema ya está aquí

Un estudio de GitClear de 2025 encontró que casi el 7% de los commits ahora contienen código generado por IA. Su análisis anterior de 153 millones de líneas de código cambiado reveló el costo: “la rotación del código” – código reescrito o eliminado dentro de dos semanas – se duplicó en 2024 en comparación con las líneas base pre-IA.

Las implicaciones de seguridad son igualmente impactantes. Un análisis reciente de 80 tareas de codificación curadas a través de más de 100 grandes modelos de lenguaje encontró que el código generado por IA introduce vulnerabilidades de seguridad en el 45% de los casos. El impacto en el mundo real: uno de cada cinco CISOs ahora informan incidentes importantes causados directamente por código generado por IA.

Las ganancias de velocidad son reales, pero también lo son los costos de estabilidad.

El efecto de amplificación

Una cosa que he aprendido es que la IA amplifica todo. Si tienes buenas prácticas, la IA las hace mejores y más rápidas. Si tus procesos son desordenados, la IA exacerba ese desorden también. Esto se refleja en un patrón que aparece año tras año en los informes de DevOps de DORA: menos variables conducen a mejores resultados. Los equipos exitosos estandarizan en menos sistemas operativos, menos lenguajes de programación, menos formas de hacer las cosas. Reducen la complejidad deliberadamente.

Los agentes de IA siguen el mismo patrón. Si les das un entorno consistente donde Python significa la misma versión en cada máquina de desarrollador, donde las dependencias están bloqueadas y rastreadas, y excelan. Si les haces navegar 17 configuraciones diferentes, cada una con diferencias sutiles, estás quemando tokens para figurar las rarezas ambientales en lugar de resolver problemas reales.

La paradoja del determinismo

Esto crea una tensión fascinante. Durante años, la ciencia de la computación persiguió el determinismo como el objetivo final. Ahora estamos ejecutando cargas de trabajo probabilísticas, modelos de IA que literalmente no pueden garantizar la misma salida dos veces, sobre sistemas diseñados para la previsibilidad.

Mi respuesta es mantener tanto de la pila como sea posible determinista. Si puedes mantener el 80% de tu infraestructura a un nivel determinista, tus agentes de IA tienen menos variables para gestionar. No están gastando ventanas de contexto en “¿Por qué no se instaló esta dependencia?” o “Voy a intentar este comando de compilación de nuevo”. Están enfocados en el trabajo real que les estás pidiendo que hagan.

Piensa en ello: cuando un agente intenta compilar algo y los enlaces nativos fallan porque ImageMagick no está instalado, eso es un desvío costoso en tokens. Si tu entorno ya incluye todo lo necesario (compiladores, bibliotecas, el árbol de dependencias completo hasta libc), el agente simplemente funciona. No hay depuración, no hay prueba y error, solo progreso.

Especificación y validación son clave

Lo que está quedando claro es que el desarrollo impulsado por IA nos obliga a pensar más en dos habilidades históricamente subestimadas: especificación y validación. Necesitas articular lo que estás construyendo en realidad, y necesitas formas robustas de verificar que lo lograste.

He notado algo interesante: las personas con antecedentes en gestión de productos o ingeniería de productos a menudo tienen más éxito con los agentes de IA en este momento. Ya están entrenados para pensar en términos de requisitos, criterios de éxito y compensaciones. Están cómodos preguntando “¿Por qué tomaste esa decisión?” y ajustando según la razón.

La validación, saber si la cosa es realmente correcta, siempre ha sido el problema más difícil de la ingeniería de software. La QA ha sido subestimada durante décadas, y sin embargo, es la parte más desafiante: determinar si el software resuelve la necesidad real del usuario. La IA no resuelve esto. De hecho, lo hace más crítico, porque ahora estás validando salidas probabilísticas contra requisitos deterministas.

Confía, pero verifica (y controla)

Hay un sentimiento que estoy empezando a abrazar: debemos asumir que el código generado por IA es hostil hasta que se demuestre lo contrario. No porque la IA sea maliciosa, sino porque simplemente no lo sabemos. No podemos auditar cada línea cuando los agentes están generando miles de líneas por día.

Esto significa cambiar los puntos de control. Si no podemos bloquear todo en el momento del desarrollo, necesitamos controles más fuertes en tiempo de ejecución. Los operadores, los equipos de SRE, los equipos de plataforma, quienquiera que sea responsable de la producción, necesitan una mejor visibilidad de lo que se está ejecutando, un seguimiento completo de dependencias y una procedencia clara para cada artefacto.

Aquí es donde la reproducibilidad se vuelve esencial. Cuando puedes demostrar matemáticamente que el artefacto que probaste localmente es idéntico a lo que se está ejecutando en producción – mismas entradas, mismas salidas, mismo cierre de dependencias – puedes empezar a tomar decisiones inteligentes. Tal vez no necesites volver a ejecutar las pruebas unitarias en CI si ya las ejecutaste localmente y nada cambió. Tal vez puedas mapear la cobertura de pruebas a los cambios de código y saltar las suites de pruebas irrelevantes.

Qué viene a continuación

Estamos en un punto de inflexión. Los equipos que ya tenían buenas prácticas están viendo ganancias de productividad masivas con la IA. Los equipos que estaban luchando ahora luchan más rápido.

La infraestructura que impulsa el desarrollo impulsado por IA necesita ser construida para la reproducibilidad desde el principio. No soldada después con herramientas de escaneo y auditorías, sino horneada en cómo los desarrolladores trabajan desde el día uno. Cuando tu entorno de desarrollo es idéntico en Mac y Linux, cuando cada dependencia está rastreada y bloqueada, cuando tienes una procedencia completa para cada artefacto, los agentes de IA se convierten en multiplicadores de fuerza en lugar de generadores de caos.

Aquí está mi mayor consejo para los equipos que intentan tener éxito en la era de la IA:

  • Estandariza sin piedad. Menos variables se correlacionan con un mejor rendimiento. Bloquea tu pila de tecnología, aplica entornos consistentes en todas las plataformas y elimina la deriva de configuración antes de que la IA la amplifique. Si las incompatibilidades de versión de Python causan problemas ahora, causarán 10 veces más problemas cuando la IA esté generando código a gran escala.

  • Construye la validación en tu flujo de trabajo, no al final. Con la IA generando código más rápido de lo que los humanos pueden revisar, no puedes confiar solo en la revisión de código manual. Implementa pruebas automatizadas que validen no solo que el código se ejecute, sino que resuelva el requisito real. Haz que tu canalización de CI/CD sea tu red de seguridad, con puertas fuertes en tiempo de ejecución para las implementaciones de producción.

  • Invierte en reproducibilidad como infraestructura. Trata la consistencia del entorno como una preocupación de infraestructura de primera clase. Cuando puedas demostrar matemáticamente que tu entorno local, el entorno de CI y el entorno de producción son idénticos, eliminás una clase completa de problemas de “funciona en mi máquina”. Esta base determinista es lo que te permite agregar de manera segura cargas de trabajo de IA probabilísticas encima.

La pregunta no es si la IA escribirá la mayoría de nuestro código. Ya lo hace para muchos equipos. La pregunta es si nuestra infraestructura puede seguir el ritmo.

Michael Stahnke es un ejecutivo de ingeniería experimentado, con más de 15 años de experiencia en el espacio de herramientas de desarrollo y operativas, donde también ha realizado investigaciones y ha sido autor de los informes State of DevOps de Puppet.

Michael es actualmente VP de Ingeniería en Flox. Anteriormente, ocupó puestos de liderazgo en ingeniería senior en CircleCI y Puppet, donde creció equipos de ingeniería en un 5x o más. Ha pasado tiempo construyendo equipos de alto rendimiento, organizaciones y investigando la efectividad de la ingeniería, además de trabajar en sistemas de empaquetado y lanzamiento. Ha estado hablando en eventos de DevOps y Automatización desde 2007. Fundó el repositorio de paquetes Extra Packages for Enterprise Linux (EPEL) y escribió un libro sobre OpenSSH en 2005.