La evolución de la automatización: de scripts de shell a organizaciones de IA

Primero automatizamos tareas

Las primeras formas de automatización con las que trabajé eran pequeñas y locales. Un script de shell sustituía una serie de comandos. Un cron hacía que algo ocurriera de forma programada. Un script en Perl o Python convertía un flujo repetitivo en algo repetible.

Los ejemplos típicos eran cosas como:

• Renombrar o mover grandes lotes de archivos
• Procesar datos siempre de la misma manera
• Copiar archivos entre sistemas
• Ejecutar comandos de despliegue repetitivos
• Programar tareas de mantenimiento periódicas

La abstracción era sencilla: sé exactamente qué quiero que haga el ordenador, puedo describirlo con suficiente precisión y prefiero dedicar el tiempo a enseñárselo una vez antes que seguir haciéndolo yo para siempre. A veces eso significaba invertir dos horas en automatizar una tarea que a mano llevaba cinco minutos, lo cual parece ridículo si solo piensas hacerla una vez. Si piensas hacerla cientos o miles de veces, resulta evidente.

Ese mismo patrón se fue repitiendo a medida que los sistemas de software se volvían más complicados.

Después automatizamos la infraestructura

La computación en la nube amplió el alcance de lo que se podía programar. En lugar de automatizar una tarea dentro de una máquina, empezamos a automatizar la creación y la configuración de las propias máquinas.

Terraform nos permitió describir la infraestructura como código. Kubernetes nos permitió describir cómo debían ejecutarse, escalar, reiniciarse y comunicarse las aplicaciones distribuidas. Los sistemas de CI/CD automatizaron el camino del software desde el control de versiones hasta producción.

De repente, cosas que tradicionalmente exigían un trabajo operativo manual considerable podían declararse y recrearse:

• Servidores
• Redes
• Bases de datos
• Balanceadores de carga
• Permisos
• Despliegues de aplicaciones
• Reglas de escalado
• Entornos completos

Lo que antes implicaba que alguien fuera haciendo clic por consolas, configurara sistemas a mano y coordinara despliegues pasó a ser algo que se podía versionar, revisar, probar y reproducir.

El coste inicial creció porque creció aquello que se automatizaba. Una buena automatización de infraestructura es más difícil que un script de shell de diez líneas. Exige más reflexión, más casos límite, más depuración y más mantenimiento. El beneficio, en cambio, escala junto con la complejidad. Una vez definido correctamente un entorno, sistemas enteros que antes requerían horas o días de configuración manual se pueden recrear con muy poco esfuerzo humano.

El principio de la automatización siguió siendo exactamente el mismo. Simplemente subimos un nivel.

Ahora estamos automatizando flujos de trabajo

Los agentes de IA vuelven a empujar esa abstracción hacia arriba. Al principio, el uso evidente era tratar al agente como un script muy capaz: darle una tarea, dejar que la ejecute y recuperar el resultado.

Eso es útil, pero también es una forma bastante estrecha de entender lo que está pasando. El cambio de fondo es que ahora podemos automatizar no solo tareas individuales, sino la coordinación de tareas entre varios trabajadores inteligentes.

Un flujo de trabajo agéntico moderno podría parecerse a esto:

• Un agente escribe el código.
• Otro revisa la implementación.
• Otro ejecuta las pruebas.
• Otro busca problemas de seguridad.
• Otro verifica que realmente se cumplieron los requisitos originales.
• Un flujo decide qué ocurre cuando algo falla.
• Unas puertas de aprobación determinan qué necesita a una persona y qué puede seguir automáticamente.

En ese punto ya no estás programando el trabajo. Estás programando el sistema que organiza el trabajo. Eso es un salto mucho mayor que sustituir simplemente una tarea manual por una tarea de IA. La frontera de la automatización se está desplazando de la ejecución a la coordinación.

Orgabot es la última versión de la misma idea

Así es como pienso en Orgabot. Es fácil mirar la orquestación de agentes de IA y creer que es algo radicalmente distinto de las herramientas de automatización anteriores, pero en un plano abstracto es el mismo patrón que llevo usando décadas.

La progresión es bastante directa:

• Un script de shell automatizaba comandos que no quería teclear una y otra vez.
• La infraestructura como código automatizaba sistemas que no quería configurar una y otra vez.
• CI/CD automatizaba flujos de despliegue que no quería coordinar a mano.
• La orquestación de agentes automatiza trabajo que no quiero gestionar paso a paso.
• Orgabot lleva eso hacia la automatización de la propia estructura que rodea a los trabajadores.

La diferencia es la escala. Con algo como Orgabot, lo que se automatiza ya no es un comando ni siquiera una tubería de despliegue. Puede ser un flujo completo de desarrollo de software con varios agentes especializados, permisos, puertas de revisión, pasos de verificación y lógica de despliegue.

La transición va de programar una tarea del tipo «construye esta función» a definir un sistema capaz de decidir repetidamente cómo deben construirse las funciones, quién debe construirlas, cómo debe revisarse el trabajo y cuándo está listo para publicarse. Eso empieza a parecerse menos a automatizar a un programador y más a automatizar partes de una organización.

La automatización sigue subiendo por la pila de abstracciones

Mirando hacia atrás, la progresión es notablemente coherente:

• Automatizamos comandos.
• Luego automatizamos tareas repetitivas.
• Luego automatizamos despliegues.
• Luego automatizamos la infraestructura.
• Luego automatizamos tuberías y flujos de trabajo.
• Ahora automatizamos a los trabajadores dentro de esos flujos.
• Y cada vez más, automatizamos la coordinación entre esos trabajadores.

Cada paso desplaza la frontera de la automatización hacia arriba. Lo interesante es que cada etapa tiende a parecer la cima. Cuando la infraestructura se volvió programable, aquello pareció un salto enorme de abstracción. Cuando los agentes de IA empezaron a escribir software, era fácil imaginar que habíamos llegado al final natural: basta con decirle a la IA lo que quieres y dejar que lo construya.

Pero incluso eso empieza a parecer ya un paso intermedio. En lugar de decirle a un agente qué hacer, estamos construyendo sistemas que deciden qué agentes deben trabajar, cómo deben colaborar, cómo debe evaluarse su trabajo y qué debe ocurrir después. Eso plantea la pregunta obvia: ¿qué hay por encima de la orquestación automatizada?

¿Qué será programable dentro de diez años?

Si el patrón continúa, la próxima abstracción puede ser mucho mayor que cualquier cosa que hoy llamemos flujo de trabajo. Quizá la unidad que automatizamos pase a ser una organización entera.

Podrías describir un objetivo de negocio y hacer que un sistema ensamble los equivalentes de:

• Desarrollo de producto
• Ingeniería
• Infraestructura
• Marketing
• Atención al cliente
• Finanzas
• Procesos legales
• Analítica
• Operaciones

Puede que con el tiempo la entrada sea menos procedimental y más intencional. En lugar de especificar tareas, flujos o agentes, quizá baste con expresar un objetivo del tipo «creo que debería existir un producto que haga esto», y que el sistema resuelva todo lo necesario para hacer real esa idea.

Aquí hay además un patrón histórico más amplio. La interacción entre personas y ordenadores no deja de avanzar hacia niveles más altos de intención:

• El código máquina dio paso a los lenguajes de programación.
• Los lenguajes de programación ganaron bibliotecas y frameworks.
• Los servidores se convirtieron en declaraciones de infraestructura.
• Los comandos se convirtieron en prompts.
• Los prompts se están convirtiendo en objetivos.

El punto final lógico es que dediquemos menos tiempo a describir cómo debe ocurrir algo y más a describir qué queremos que exista. Puede que dentro de diez años incluso la idea de orquestar agentes de forma explícita nos parezca primitiva. Quizá simplemente expresemos una intención y dejemos que un sistema construya la combinación de agentes, herramientas, flujos, infraestructura, organizaciones y procesos que haga falta por debajo.

Llevado al extremo, la interfaz puede parecerse menos a programar y más a manifestar: piensa algo, descríbelo y observa cómo un sistema automatizado convierte esa intención en algo real. Suena grandilocuente, pero cualquier capa de abstracción anterior habría sonado grandilocuente antes de existir.

La economía de la automatización nunca cambió realmente

Lo que más me llama la atención es que, pese a todo este avance, el trato sigue siendo casi idéntico al que hacía cuando escribía scripts de shell hace décadas. La automatización todavía exige una inversión inicial. Hay que definir el proceso, construir el sistema, cubrir los casos límite, depurar los fallos y decidir qué debe pasar cuando la realidad no coincide con tus suposiciones.

El trabajo manual suele parecer más fácil al principio porque evita esa inversión inicial. Después la automatización empieza a funcionar, las repeticiones se acumulan y el beneficio se vuelve evidente.

Eso era cierto cuando la automatización era un script de shell de diez líneas. Lo era cuando pasó a ser miles de líneas de configuración de infraestructura. Lo es ahora que empezamos a orquestar equipos de agentes de IA. La escala no deja de crecer, pero el principio apenas ha cambiado: invierte el esfuerzo una vez para no tener que invertirlo siempre.

Y si el patrón continúa, la pregunta más interesante no es qué podemos automatizar hoy. Es qué seguirá pareciendo demasiado grande para automatizar mañana.