En 1995, mi idea de "automatización" era escribir el autoexec.bat correcto para que mi 386SX cargara los controladores adecuados, liberara suficiente memoria y me dejara arrancar Wolfenstein 3D. No sabía que estaba aprendiendo a orquestar ordenadores. Creía que intentaba jugar.
Treinta años buscando rodeos al juicio humano
El verdadero truco por aquel entonces era acertar con la configuración del cable serie para aquella primera versión de Warcraft. Multijugador por serial-link, dos máquinas, dos amigos, una tarde. Lo que realmente me voló la cabeza fue Norton Commander sobre un cable serie: podías copiar archivos de un ordenador a otro por el cable. Una especie de FTP temprano, básicamente, años antes de saber qué era FTP.
Luego llegó Linux, y el instinto de orquestar encontró salida real. Aprendí Perl, luego bash, y empecé por lo obvio: scripts de backup, rutinas de actualización, las tareas pesadas que nadie quería hacer un viernes. Luego monitorización. Luego rutinas de auto-reparación que atrapaban el mismo fallo a las 3 de la madrugada por tercera vez y simplemente lo arreglaban. Uno de los trabajos que más me formó fue construir un sistema interno de despliegue para un equipo de desarrollo de 20 personas. Esto era sobre SVN, posiblemente CVS, años antes de que existiera git. Merge de ramas, pushes a dev y a live. Un auténtico "git workflow" antes de que "git workflow" fuera una expresión.
El muro que no se movía
Cada año los scripts se volvían más listos. Pero siempre chocaban con el mismo muro: en el momento en que una tarea pedía juicio, tenía que intervenir una persona.
Podías automatizar el backup, pero no la decisión de qué respaldar cuando el disco iba justo. Podías automatizar el despliegue, pero no la llamada de "¿hacemos rollback?". ¿Procesar facturas? Podías scriptear partes. No la parte en la que lees un correo, decides si de verdad es una factura, identificas al proveedor y la cuadras con la cuenta correcta.
El muro ha caído
La primera vez que usé Claude Code — el agente de codificación que corre en tu propia máquina — supe que habíamos cruzado una línea. No era hacer prompts a un chatbot. Era programar un agente. Darle herramientas, memoria y capacidad de decidir qué hacer a continuación.
Hoy ejecuto agentes de IA que hacen el trabajo que los viejos scripts nunca pudieron. Vigil, mi agente de CI/CD, revisa cada repositorio del que dependemos por si hay actualizaciones, las integra en nuestra base de código, resuelve los conflictos de merge sobre la marcha y tiene un pull request listo en mi mesa cada mañana. Reviso, hago merge, sigo. En la parte financiera, otro agente lee mi bandeja de entrada, extrae las facturas, las sube a nuestro software de contabilidad y las reconcilia contra los datos del sistema de facturación vía API. Durante años fue uno de los mayores drenajes de energía de mi semana. Ahora ocurre mientras duermo.
Las herramientas son ahora el trabajo
No son experimentos de laboratorio. Están funcionando todos los días. Y aquí está lo que he averiguado, y por qué se siente como un momento culminante de carrera: construir herramientas para agentes de IA es la misma disciplina que construir herramientas para automatización de sistemas. Los mismos instintos, la misma paciencia con los casos límite que siempre te comen el fin de semana. Los agentes son buenos, muy buenos de hecho, pero se vuelven dramáticamente mejores cuando les das las herramientas y el entorno adecuados. Ese es un trabajo de ingeniería, no de escribir prompts.
El Model Context Protocol (MCP) es donde va la mayor parte de mi energía estos días. Es la manera limpia de construir herramientas que los agentes puedan descubrir, entender y usar. Las herramientas inteligentes son donde vive el salto de productividad: herramientas que hacen varias acciones relacionadas en una sola llamada, con buenas entradas y salidas limpias. Una herramienta tonta que solo envuelve un endpoint de API es un regalo mediocre para un agente. Una herramienta que sabe comprobar, actuar, verificar y reportar de vuelta en una sola pasada es un force multiplier.
Mismo oficio, nuevo sustrato
Mi carrera fue ingeniería de sistemas, redes y código, apilados uno sobre otro. Pasé décadas aprendiendo a hacer que las máquinas asumieran más trabajo para que los humanos pudiéramos concentrarnos en lo que realmente necesita humanos. Resulta que esas mismas habilidades son exactamente las que hacen falta para que los agentes de IA sean eficaces. El sustrato ha cambiado. El oficio no.
Vaya momento para dedicarse a esto
Treinta años scripteando esquivando el muro del juicio, y el muro por fin se ha movido. Los agentes que ejecuto hoy hacen el trabajo que las rutinas de auto-reparación de las 3 de la madrugada de 2005 jamás pudieron alcanzar. Los mismos instintos, un nuevo sustrato. Me gustaría poder volver atrás y contarle a mi yo de aquel 386SX adónde llevaba todo esto.