Crear software siempre ha tenido fricción. Había que convertir una idea en requisitos, escribir el código, conectar sistemas, preparar entornos, probar y desplegar. Esa fricción imponía un límite bastante físico a la cantidad de software que un equipo podía producir.
Ese límite se está moviendo.
Los asistentes de código ya no se limitan a completar una línea. Los agentes pueden recorrer un repositorio, proponer cambios en varios archivos, escribir pruebas, revisar una incidencia y preparar un pull request. Todavía fallan y necesitan supervisión, pero el coste de pasar de una intención a una primera implementación ha caído de forma visible.
La pregunta interesante no es si esto permite escribir más código. Ya lo permite. La pregunta es qué ocurre después con todo ese software.
Porque cada servicio que llega a producción necesita alguien que entienda cuándo está sano, qué dependencias tiene, cómo se recupera, cuánto cuesta y qué se puede cambiar sin romperlo. Generar código más deprisa no elimina ese trabajo. Puede multiplicarlo.
Construir es solo el principio
Un repositorio que compila no es todavía un sistema operable. Entre ambos hay decisiones sobre identidad, red, datos, secretos, capacidad, despliegue, telemetría, seguridad y recuperación. También hay decisiones menos visibles: quién responde a una alerta, qué significa una degradación aceptable o qué parte del sistema puede perderse sin comprometer el negocio.
La IA ayuda en muchas de esas tareas. Puede proponer un Dockerfile, una pipeline o un módulo de infraestructura como código. Pero producir el artefacto no resuelve si encaja en la arquitectura, si respeta el modelo de amenazas ni si alguien podrá mantenerlo dentro de dieciocho meses.
Esa diferencia importa porque la velocidad local engaña. Un equipo puede ahorrar dos horas al crear un servicio y comprometer semanas futuras si introduce otra base de datos, otra cola o una nueva forma de desplegar sin una razón suficiente.
El software tiene una vida después del deploy
En producción, el software deja de vivir dentro de la intención de quien lo escribió. Recibe tráfico que no estaba en las pruebas, datos incompletos, reintentos, latencias de terceros y cambios de configuración. Comparte presupuesto, límites de API y ventanas de mantenimiento con otros sistemas.
Operarlo significa conservar contexto durante todo ese recorrido. Hay que saber:
- qué servicio es responsable de una respuesta lenta;
- qué cambio precedió a una degradación;
- qué SLO se está consumiendo y a qué ritmo;
- si un reintento protege al usuario o amplifica una caída;
- cómo restaurar los datos y cuánto se perdería;
- quién puede autorizar una acción irreversible.
Esto no se resuelve añadiendo más logs. La observabilidad y la práctica de SRE sirven cuando conectan señales técnicas con comportamiento de usuario, objetivos de fiabilidad y decisiones operativas. De lo contrario, solo generan más información que alguien tendrá que interpretar bajo presión.
Y ahora podemos producir muchísimo más
La aceleración ya no es solo una impresión. El informe DORA 2025 sobre desarrollo asistido por IA reunió respuestas de casi 5.000 profesionales: el 90 % declaró usar IA en el trabajo y más del 80 % percibió un aumento de productividad. El mismo estudio observó una relación positiva con el throughput de entrega, pero negativa con la estabilidad.
Conviene leer esas cifras con cuidado. Son relaciones observadas, no una promesa causal para cualquier equipo. Aun así, describen bien la tensión: acelerar la producción de cambios no garantiza que el sistema pueda absorberlos.
La encuesta de Stack Overflow de 2025 aporta otro matiz. Un 66 % señaló como frustración principal las soluciones de IA «casi correctas», y un 45 % indicó que depurar código generado por IA consume más tiempo. La primera versión llega antes; la última milla puede seguir requiriendo mucho criterio.
El cuello de botella puede estar cambiando de sitio
Durante años, muchas organizaciones optimizaron el tiempo que transcurre desde una idea hasta el código. Ahora ese tramo puede dejar de ser el más lento. El límite aparece en revisión, integración, validación, seguridad y operación.
No siempre se verá como una cola evidente. Puede adoptar formas más discretas:
- pull requests que crecen más rápido de lo que el equipo puede comprender;
- servicios con propietario nominal, pero sin capacidad real de guardia;
- pipelines que despliegan rápido y recuperan despacio;
- dependencias nuevas sin presupuesto de fiabilidad ni coste;
- alertas que nadie sabe relacionar con una decisión de producto;
- documentación generada que describe archivos, pero no explica por qué existe el sistema.
Esto es deuda operativa: obligaciones futuras creadas por software que ya está en producción, aunque nadie haya reservado capacidad para cumplirlas. Se parece a la deuda técnica, pero se manifiesta en guardias, permisos, dashboards, runbooks, parches, backups y decisiones de recuperación.
Porque producción no suele fallar de forma elegante
Los ejemplos limpios son raros. Una aplicación no suele pasar de «bien» a «rota» con una causa única. Puede fallar solo para una región, un tipo de cuenta o una combinación de datos. Puede seguir respondiendo mientras pierde eventos. Puede consumir su presupuesto de error sin activar una alerta porque cada métrica aislada parece razonable.
Además, la producción conserva historia. Una decisión antigua de esquema condiciona una migración nueva. Un límite configurado hace seis meses aparece justo cuando una campaña multiplica el tráfico. Una credencial que debía ser temporal termina siendo crítica.
Por eso staging no predice producción por sí solo. Las pruebas reducen incertidumbre, pero no sustituyen mecanismos de despliegue progresivo, rollback, límites de impacto, trazabilidad y recuperación ensayada.
Cuanto más código pueda proponer un agente, más importante será limitar el radio de explosión de cada cambio. La velocidad segura no consiste en acertar siempre. Consiste en detectar pronto, contener el daño y volver a un estado conocido.
Quizá el criterio se vuelva más valioso que el código
Si generar una implementación cuesta menos, escoger la implementación correcta vale más. El trabajo se desplaza hacia formular restricciones, comparar consecuencias y rechazar complejidad innecesaria.
Una IA puede producir tres arquitecturas plausibles. Alguien sigue teniendo que decidir si el volumen justifica eventos, si el equipo puede operar Kubernetes, si la consistencia eventual es aceptable o si un servicio gestionado crea una dependencia razonable. Esas respuestas no están dentro del repositorio. Dependen del negocio, del equipo, del riesgo y de la fase del producto.
El criterio también entra en la revisión. No basta con comprobar que el código sea válido. Hay que preguntar qué nueva responsabilidad introduce: ¿otro dato que proteger?, ¿otra ruta de escalado?, ¿otra factura variable?, ¿otro componente que actualizar?, ¿otra manera de fallar?
La escasez puede dejar de estar en escribir y pasar a comprender. Comprender el sistema completo, no solo el diff.
Esto también cambia el papel de Platform Engineering
Platform Engineering suele describirse como la creación de una plataforma interna que ofrece caminos de autoservicio a los equipos. En este contexto, su función no es únicamente mejorar la experiencia del desarrollador. También consiste en definir la envolvente segura dentro de la que personas y agentes pueden moverse rápido.
Un buen golden path incorpora decisiones que no deberían reinventarse en cada servicio: identidad, secretos, telemetría, políticas de red, escaneo, despliegue, rollback, ownership y costes. No impide salir del camino, pero hace que la excepción sea consciente y visible.
Esto convierte la automatización de DevOps y Platform Engineering en una forma de gobernar el cambio sin convertir cada entrega en un comité. Las mejores plataformas no ofrecen infinitas opciones. Ofrecen unas pocas opciones bien operadas, con feedback rápido y límites claros.
DORA llegó a una conclusión relacionada: la calidad de la plataforma interna amplifica la capacidad de obtener valor de la IA. Tiene sentido. Si el agente trabaja sobre repositorios incoherentes, pipelines frágiles y ownership difuso, automatizará también esa incoherencia.
La IA también llegará a operaciones
Ya está llegando. Puede resumir incidentes, correlacionar eventos, proponer consultas, detectar anomalías y convertir un runbook en una secuencia ejecutable. Con suficiente contexto, también podrá preparar cambios de infraestructura o aplicar remediaciones acotadas.
Pero operar no es solo reconocer patrones técnicos. Es actuar con consecuencias. Reiniciar un proceso puede recuperar un servicio y destruir la evidencia necesaria para entenderlo. Escalar capacidad puede proteger un SLO y disparar el coste. Bloquear tráfico puede contener un ataque y dejar fuera a un cliente legítimo.
Por eso la automatización operativa necesita algo más que acceso a herramientas. Necesita permisos mínimos, estados verificables, límites de gasto, aprobaciones según riesgo, registros de decisión y una salida segura cuando la confianza sea baja. «El agente puede ejecutar el comando» no equivale a «el agente tiene autoridad para tomar la decisión».
La propia encuesta de Stack Overflow encontró que el despliegue y la monitorización son las tareas con mayor resistencia: el 76 % de los participantes no planeaba delegarlas en IA. Esa cautela no invalida la automatización. Indica dónde la auditabilidad y el control importan más.
Quizá estamos entrando en una época diferente
Durante mucho tiempo, el software era caro de producir y relativamente escaso. Las organizaciones decidían con cuidado qué construir porque cada producto competía por un número limitado de personas.
Si esa restricción disminuye, podemos acabar con mucho más software de vida corta: herramientas internas, integraciones específicas, agentes, microservicios y automatizaciones creadas para problemas pequeños. Parte será valiosa. Parte quedará sin dueño después de que cambie la prioridad o se marche quien aportaba el contexto.
El problema no será solo el volumen de código. Será el volumen de sistemas con capacidad para afectar a datos, clientes y costes. Incluso una aplicación pequeña puede merecer inventario, ownership, política de acceso, telemetría mínima y un procedimiento de retirada.
Eso obliga a tratar la eliminación como una capacidad de ingeniería. Un sistema fácil de crear también debería ser fácil de observar, transferir y apagar.
La pregunta ya no es solo cuánto podemos construir
La IA en el desarrollo de software abre una posibilidad real: dedicar menos tiempo a la mecánica y más a los problemas que merecen atención. Pero esa posibilidad no se cumple por acumular más cambios.
La pregunta útil es si nuestra capacidad de operación crece al mismo ritmo que nuestra capacidad de construcción. Si cada nueva pieza llega con ownership, límites, observabilidad y una forma segura de retirarla, la velocidad puede convertirse en ventaja. Si no, solo estaremos creando obligaciones más rápido.
Antes de aumentar el throughput conviene mirar el sistema completo: cómo entra un cambio, cómo sabemos que funciona, quién responde cuando deja de hacerlo y qué evidencia permite decidir bajo presión. El Cloud Reliability Scorecard reúne esas preguntas en una revisión breve y puede servir como punto de partida, incluso si la decisión posterior es no cambiar ninguna herramienta.
Escribir software será cada vez más barato. Operarlo con criterio seguirá teniendo un coste. La diferencia entre ambas curvas puede definir la fiabilidad de la próxima generación de productos.
