ChatOps: El deployment que no debió ser.

Quiero empezar este artículo con algo que, curiosamente, la IA me trajo y que pude, en un momento de estupidez brillante, reconocer como quizá el mejor intro posible para este artículo; y es que en la búsqueda de un título para el mismo he encontrado que elegir un mal título me ayudaría a poner mejores palabras en mi contenido, y es que la lista de nombres que he autogenerado resume todo lo que quiero hablar a continuación:

Pienso que los que se han topado con la infra como código con solo leer estos títulos han comprendido la idea de todo lo que quiero dejar dicho aquí; los que no estaban interesados en el tema se han marchado y los que no son ni el uno ni el otro aún siguen en estas líneas.

A estos que aún siguen por acá, y unos cuantos que se me han escapado, me gustaría traerlos a mi mente por un momento con este artículo, llevarlos a entender de dónde viene el repudio a utilizar la IA como sistema de “ponerlo en producción”, y el porqué la IA nunca será la máquina adecuada de deployment.

La situación actual

El problema que describo es el siguiente: al parecer un montón de personas que recién llegan al mundo de la tecnología, y otros cuantos que ya tenían un rato por acá, al ver que la IA puede escribir su CSS y sus endpoints de CRUD, han decidido que la IA es no solo un ingeniero, sino todos los ingenieros, y han empezado, por falta de comprensión o por simplemente ni siquiera haber imaginado que poner algo en producción no es lo mismo que solo hacerlo, a utilizar la IA para hacer Ops.

“¿Cuál es el problema con esto, mi querido Black Cloud?” — grita eufóricamente el público — (OMG, un emdash, te descubriiii), pues el problema, como casi todo lo importante en la vida, no puede ser descrito en dos palabras, pero sí en tres: Esto no sirve.

Básicamente vemos personas pidiendo a sus “agentes” que, por favor, sube la pagina al servidor y listo, ya estamos. Pues su LLM de confianza, siendo un fiel sirviente (uno muy bien pagado, por cierto, $$$ token prices amirite), va a obedecer y va a resolver el problema.

A ojos de aquellos poco entrenados esto parecerá magia, habrán descubierto con cero esfuerzo el mítico y para siempre inexistente “NoOps”, un futuro donde no hay que hacer operaciones porque el bot las hace por ti, y como el bot es código, esto es automatización ¿No? Jaque mate, devops guy.

Pero el problema es que nunca fue el cansancio que produce el trabajo manual el problema; esto es, de ciertas formas, lo de menos, pues siempre hay hombres baratos que podemos darle a la gran máquina para que coma, siempre se ha podido hacer, pero todos abandonaron eso por razones muy distintas.

Por la misma razón que Ops se volvió DevOps, necesitamos pasar de AI-Ops a AI-DevOps.

Las necesidades de las operaciones automáticas

Para entender por qué son peligrosas e ineficientes estas formas de operar, necesitamos mirar exactamente qué es lo que están diseñadas para resolver las herramientas de DevOps y IaC (infra as code). La principal solución que traen todas estas herramientas a la mesa no es de ahorro de personal o tiempo, pues los devops existen; lo principal en estas herramientas son la estabilidad, confiabilidad, capacidad de repetición, observabilidad e incluso fungibilidad (palabra compleja que significa “to lo mismo”, igual que un billete de cien pesos y otro de cien pesos son la misma cosa cuando te los deben).

Aquí el asunto es que la conversación como infraestructura falla literalmente en todas y cada una de las partes que he mencionado anteriormente, y de manera catastrófica.

La trampa del no determinismo

La infraestructura moderna depende del concepto de idempotencia (como multiplicar por cero: no importa si multiplicas un número por cero una vez o 528, va a resultar lo mismo). Esto es muy necesario porque la forma en que se distribuyen las aplicaciones no puede garantizar que todo se ha aplicado consistentemente, o no pueden garantizar que no haya dos personas haciendo deploy a la vez; por eso necesitamos garantizar que se pueda repetir la acción sin repercusiones y que el estado deseado sea el estado buscado: esto es a lo que se llama determinismo.

Los LLM, y casi todas las otras arquitecturas que llamamos IA, son POR DISEÑO probabilísticas, pues son una máquina de predicción de texto. ¿Quieres adivinar qué dos palabras que aprendiste hoy son antónimos? Así es, Timmy: determinismo y probabilismo.

Si ejecutas por IA un deploy dos veces (sí, aun con un skill bien mamalón y que te lo ha validado Cristo mismo), puede en un momento usar npm install y en otro npm ci, y en un momento reiniciar el servicio X antes de cambiar la config mientras en otra ocasión hace lo contrario.

Entonces estás teniendo software no en base a unos planos, sino en base a puro vibe, viejo. Qué onda, radical. Esto significa que eventualmente tu ambiente va a fallar de una forma totalmente única que no podrás anticipar por software, debido a la naturaleza probabilística del deploy.

El estado de desconexión

Uno de los más grandes logros de la infraestructura como código es precisamente el poder tratar nuestra infra justo como tratamos el código. Lo tenemos en git, tiene versiones, si todo explota podemos recuperarlo, podemos replicar código viejo porque tenemos la forma vieja de hacerle deploy, podemos tener infra idéntica en múltiples ambientes y así por el estilo.

Cuando le dices a la IA que haga deploy, entonces tu chat se ha convertido en la fuente de la verdad, y aún peor, los logs de ese chat con el pensamiento y nombramiento de herramientas que se han ejecutado y que tú definitivamente no estás guardando también serán parte de la verdad, verdad que ahora no tienes. No tengo temor a equivocarme que a esto se refería la Biblia en el pasaje que dice “conoceréis la verdad, y la verdad os hará libres”; pues ahora con esto de usar el chat como verdad, decidiste quedar preso :) .

El hecho de que necesitemos reiniciar el contexto a cada rato en los modelos actuales hace esto aún peor: pedazos de distintas sesiones no conectadas ahora son tu fuente de verdad. Bienvenidos a una caja de Pandora por descubrir cuando tengas que reparar algo en el server.

Seguridad ¿Quién es ese?

Usar la IA como infra no es seguro: tú lo sabes, yo lo sé, nosotros lo sabemos. No pienso pasar mucho por esta sección, no quiero irritar sensibilidades.

Tener ssh keys, secretos, API keys, credenciales de DB… todas esas mágicas y hermosas cosas en un chat es una horrible, terrible, horrorosa y terrorosa (y para los hackers, sabrosa) idea.

Esto sin contar que 100% vas a joder todo el rastro de auditoría, algo que si en algún momento quieres trabajar con grandes clientes, ganar dinero serio, o hacer algo más que un juguete, vas a necesitar; pues nadie te dejará tener ninguna clase de certificación con tales cosas como parte esencial de tu empresa.

El elemento autobús

Esto se llama así porque es una analogía extraña sobre contar cuál es el número mínimo de personas de tu equipo que necesita chocar un autobús para hacer que pierdas tanta información crítica que tu empresa ya no podría funcionar aun si encuentras más profesionales. Deberíamos mantener esto bajito.

Pues bueno, el punto es que en este caso el “bus factor” podría ser de solo uno o técnicamente menos de uno: perder tu historial de chat o el empleado que entendía el chat sería suficiente para perder todo el estado de como funciona la empresa y, pues, ya perdiste.

No dejes que te lleve el autobús.

El verdadero rol de la IA en DevOps

ESTE ARTÍCULO NO ES UN ARTÍCULO ANTI IA. La IA es una herramienta poderosa.

El asunto está en la manera en como utilizamos la IA:

La IA en DevOps tiene un lugar: generando código que crea deployments determinísticos e infraestructura con versiones. Los LLM no deberían fungir nunca como la máquina que ejecuta el deploy, quizá solo (y tampoco lo aconsejo) como un trigger.

Crea líneas de producción (pipelines), no prompts

La velocidad es atractiva. Todos queremos hacer delivery rápido de nuestro código. Pero velocidad sin estabilidad solo nos llevaría a chocar más pronto y más fuerte con la pared.

Usar LLMs haciendo Ops manuales es solo flojera aplicada. No te dejes engañar por esto: tendrás un sistema caótico, inestable, frágil, no auditable y no reproducible. Esto está destinado al peor de los destinos.

NO LE DIGAS A LA IA QUE HAGA DEPLOY DE TU WEBSITE. Literalmente no hay ningún detalle de implementación en el planeta que haga que tu caso sea diferente si tienes clientes reales, y con las facilidades que puede traer la propia IA… No creo que haya excusas.

EL MANIFIESTO (AI generated)

Aquí tienes la traducción del manifiesto al español, manteniendo ese tono solemne y contundente que requiere un documento de este tipo.

Manifiesto por la Infraestructura Determinista
Nosotros, los abajo firmantes, estamos cansados de arreglar cosas que no deberían estar rotas.

Reconocemos que la complejidad de la infraestructura moderna en la nube puede ser inmensa y que la tentación de buscar soluciones rápidas es fuerte. Sin embargo, sostenemos que ciertas verdades son evidentes por sí mismas: la estabilidad de un negocio depende directamente de la estabilidad de su código y de su entorno.

Al entrar en una era donde la Inteligencia Artificial puede generar acciones, debemos comprometernos de nuevo con los principios fundamentales que hacen que el software sea confiable. Por la presente, declaramos este manifiesto por la Infraestructura Determinista.

I. Valoramos la Reproducibilidad sobre la Conveniencia
Un proceso de despliegue que no puede repetirse de forma fiable no es un proceso; es una apuesta. Rechazamos el parche de "una sola vez" y la configuración manual. Cada sistema que construimos debe ser reproducible desde el código fuente, permitiéndonos recrear entornos enteros en minutos, no en horas de depuración frenética.

II. Exigimos la Definición Declarativa
Declaramos que la "Infraestructura como Código" (IaC) no es opcional para el software de nivel de producción. Creemos que el estado deseado de un sistema debe estar definido explícitamente en un formato versionado (código o configuración), permitiendo que sea leído, revisado y auditado tanto por humanos como por máquinas. Un sistema que solo existe en el historial de chat de un LLM o en la memoria difusa de un ingeniero es un sistema que ya está fallando.

III. Rechazamos el No-Determinismo en las Operaciones
La varianza es el enemigo de la estabilidad. Rechazamos cualquier flujo de trabajo de despliegue basado en modelos probabilísticos o "conversaciones". Si proporcionamos la misma definición de infraestructura a nuestras herramientas varias veces, estas deben producir exactamente el mismo entorno, cada vez. La "Infraestructura como Conversación" es un error de categoría fundamental que introduce aleatoriedad donde necesitamos precisión absoluta.

IV. Requerimos Observabilidad Obsesiva y Trazas de Auditoría
Si se realiza un cambio en un sistema de producción, debemos saber: Qué cambió, Quién lo cambió, Cuándo se cambió y Por qué se cambió. Los despliegues manuales a través de un intermediario de IA borran fundamentalmente esta traza de auditoría. Exigimos que cada cambio sea rastreable, versionado en Git y registrado por sistemas deterministas.

V. Afirmamos el papel de la IA como Asistente, No como Operador
La IA es una herramienta de generación, no una herramienta de ejecución. Fomentamos el uso de la IA para escribir código, generar archivos de configuración, traducir protocolos y optimizar pipelines existentes. Rechazamos absolutamente el uso de la IA como un administrador de sistemas ad-hoc con acceso directo a secretos de producción y autoridad para ejecutar comandos. La IA debe escribir el plan; un sistema determinista debe ejecutar el plan.

Conclusión
Construimos infraestructura destinada a perdurar. Construimos infraestructura que pueda ser entendida por otros. Construimos infraestructura que respete los principios de la confiabilidad en la ingeniería. No seremos la generación de ingenieros que permita que las "buenas vibras" reemplacen a un pipeline de CI/CD adecuado.

Elegimos el determinismo.

Creado por Oscar J. Rodriguez B. (2023)