¿Te acuerdas de tus primeras semanas con ChatGPT?
Yo recuerdo perfectamente, aunque haya pasado ya 4 años, las primeras veces que empecé a usar ChatGPT para que me ayudara con mi trabajo.
En esa época todavía trabajaba en una consultora de Francia, en proyectos de Airbus y fue una mezcla de fascinación absoluta y, para qué mentir, un punto de alivio.
Me gustaría decir que fui pionero y usaba la IA como un experto, pero mentiría.
Mi relación con la IA consistía en lo mismo que para el 99% de los desarrolladores: abrir una pestaña en el navegador, escribir un prompt y esperar con los dedos cruzados.
“Explícame este error”, “Refactoriza esta función”, “Optimiza esta consulta SQL”.
Y para qué mentir, eso ya parecía magia y veía que iba a ser una herramienta bastante útil (aunque tampoco me vi venir todo lo que ha ido pasando hasta ahora).
En esa época ya me ahorró horas de peleas con expresiones regulares y subconsultas cruzadas. Respuestas que antes nos costaba media tarde encontrar en Stack Overflow o buceando en documentación desactualizada…
De repente aparecían en la pantalla en tres segundos.
Pero mi romance idílico con Chatty (así, cariñoso) me duró poco. Al cabo de unas semanas, la fricción se hizo evidente: me di cuenta de que era imposible delegarle trabajo de verdad.
Me pasaba el día haciendo de niñera del chat: copiaba un archivo de mi editor, lo pegaba en la web, añadía contexto, corregía la alucinación de turno, me llevaba el código corregido de vuelta al IDE, ejecutaba los tests, fallaban, copiaba el error de la consola, volvía a la pestaña del navegador…
Sí, la IA respondía muy bien, pero el que seguía picando piedra y haciendo de “puente” era yo.
Me había convertido en un transportador de texto de lujo entre mi terminal y un chatbot.
Estaba usando una tecnología revolucionaria como si fuera un buscador un poco más espabilado.
Hasta que pasó el tiempo y llegó un punto inflexión.
Y no, el verdadero cambio de chip no me llegó cuando los modelos se volvieron “más inteligentes”.
Llegó cuando empecé a usar herramientas con acceso real a mi entorno: capaces de leer el repositorio, ejecutar comandos, corregir archivos, pasar la suite de tests y crear un commit por sí mismas.
El empleado brillante en la habitación vacía
Para entender la diferencia entre un LLM (un modelo de lenguaje) y un agente, me gusta usar una analogía muy de calle.
Imagina que contratas en tu equipo a un desarrollador junior que es un genio teórico absoluto. Se sabe de memoria las especificaciones del lenguaje, ha leído sobre todos los patrones de diseño y tiene una memoria fotográfica.
Sin embargo, el primer día de trabajo lo metes en una oficina completamente vacía. Sin mesa, ni ordenador, ni acceso a Slack, ni credenciales de GitHub, ni de bases de datos. Solo tiene una silla en el centro de la habitación y a ti, que entras de vez en cuando a hacerle preguntas.
Si le preguntas cómo implementar un algoritmo de ordenación complejo, te lo dirá al toque. Pero si le pides que arregle un bug en producción, no podrá hacer absolutamente nada. No puede ver el código, no puede ejecutar los tests, no puede experimentar. Ese desarrollador brillante en la habitación vacía es un LLM.
Un agente es ese mismo desarrollador, pero al que finalmente le hemos dado un escritorio, acceso al repositorio, una consola para ejecutar comandos y un entorno de pruebas.
Un agente no funciona mediante una única pregunta y respuesta, funciona mediante un bucle de retroalimentación continuo (Agentic Workflow):
- Recibe un objetivo: “Corrige el fallo en la pasarela de pago que duplica transacciones”.
- Planifica: desglosa la tarea en pasos pequeños para no perderse.
- Usa herramientas: lee archivos, busca referencias en el código y modifica lo necesario.
- Verifica: ejecuta los tests automáticamente para comprobar si ha roto algo.
- Corrige: si los tests fallan, lee el error, planifica y vuelve a intentar hasta que todo está en verde.
Los LLM responden, los agentes trabajan.
La trampa de la dependencia: mi mayor miedo para la nueva generación
Si estás empezando en esta profesión, tienes a tu disposición el mayor superpoder de la historia del desarrollo de software. Pero quiero ser muy sincero contigo: también tienes delante la trampa más peligrosa para tu carrera.
He visto a muchos desarrolladores junior usar la IA como un generador de código mágico.
Le piden una solución, copian el resultado sin mirarlo y lo pegan en su IDE cruzando los dedos para que funcione. Si funciona, pasan a otra cosa.
Hacer esto es pegarte un tiro en el pie: te estás convirtiendo en un mero operador de chat y estás delegando el pensamiento crítico, que es lo único que te da valor como profesional.
El día que tu empresa configure un agente autónomo real para que haga ese flujo de “copiar y pegar” de forma automática tu rol dejará de tener sentido.
¿Y cómo evitarlo? Dejando de ser el usuario perezoso del agente para convertirte en el ingeniero que sabe diseñarlo, guiarlo y auditarlo.
Para mí, entender cómo funcionan los agentes es la mejor escuela de ingeniería de software que existe hoy en día. Para interactuar de forma madura con ellos y no depender ciegamente de sus respuestas, necesitas aplicar en tu día a día tres hábitos que acelerarán tu camino a senior:
1. Diseña el arnés de pruebas antes de pedir código
Un agente no tiene criterio propio para saber si su trabajo es correcto a menos que tenga un marco objetivo contra el que contrastarlo. Si te acostumbras a escribir los tests unitarios, de integración y a configurar las reglas del linter antes de dejar que la IA proponga código, estarás haciendo verdadero trabajo de diseño. Estarás forzando a tu mente a entender el problema de raíz y a definir los casos límite. El código de producción acabará siendo un detalle de implementación que puedes delegar; el diseño del test es donde tú demuestras tu nivel.
2. Domina la gestión del contexto y la arquitectura
Un agente es extremadamente sensible al desorden. Si le inyectas un repositorio caótico, lleno de dependencias circulares y código ultraacoplado, el agente se perderá, alucinará y consumirá tu presupuesto de tokens en minutos.
Aprender a modularizar tu código, a separar responsabilidades (aplicando el principio de responsabilidad única) y a estructurar APIs limpias no solo hará que tus agentes trabajen mejor; te obligará a ti a pensar como un arquitecto de software. Si aprendes a estructurar el contexto para que lo entienda una máquina, habrás aprendido a estructurar el sistema para que lo entienda cualquier humano de tu equipo.
3. Aplica verificación determinista: confía, pero verifica
A veces nos da pereza leer código ajeno, y más si lo ha escrito una máquina que parece muy segura de sí misma. Pero el mayor error de un junior es asumir que si compila, está bien. Tienes que ser el revisor más estricto de tu agente.
¿Esta solución escala? ¿Maneja correctamente las excepciones de red? ¿Introduce problemas de seguridad?
Forzarte a auditar y corregir el código generado por la IA entrenará tu capacidad de lectura y análisis técnico mucho más rápido que si te pasaras el día picando código repetitivo a mano.
[Workshop Online] De Developer a AI Champion: Harness Engineering
Descubre cómo dar el salto de Developer a AI Champion aprendiendo a aplicar Harness Engineering para construir flujos agénticos reales, fiables y listos para producción. Verás cómo diseñar el sistema que rodea a tus agentes (contexto, herramientas, restricciones, memoria y mecanismos de verificación) para que dejen de improvisar y produzcan resultados consistentes. Construiremos un caso práctico en directo donde aprenderás a diseñar un Harness desde cero y a incorporar validaciones automáticas antes de llevar los cambios a producción. Además, te llevas el repositorio de código para aplicarlo en tus proyectos.
¡Plazas limitadas!
El arte del Harness Engineering y el protocolo MCP
Cuando aceptas que el LLM es una pieza probabilística (y a veces caótica) dentro de un sistema que necesita ser determinista, dejas de hacer Prompt Engineering y empiezas a hacer Harness Engineering.
El Harness es todo el andamiaje de software tradicional que construimos alrededor del modelo para guiarlo, limitarlo y protegerlo.
Es el sistema que levanta un contenedor aislado para que el agente ejecute comandos de forma segura, el que valida que la salida del modelo cumpla estrictamente con un esquema JSON y el que controla el presupuesto para que el bucle no se quede colgado gastando dinero en bucles infinitos.
Para que este arnés funcione sin tener que escribir integraciones personalizadas para cada herramienta, la industria está adoptando el MCP.
Aprender cómo funciona MCP y cómo exponer tus propios servicios bajo este protocolo es una de las habilidades más valiosas y con más futuro que puedes adquirir hoy como desarrollador.
La inteligencia necesita límites
Otra palabra clave que debes grabar a fuego en tu flujo diario es restricciones.
Al principio, esto puede parecer contradictorio. Si estamos construyendo sistemas autónomos e inteligentes… ¿por qué querríamos limitar lo que pueden hacer? ¿No estamos frenando su capacidad?
He aprendido que en la ingeniería de software ocurre todo lo contrario.
Un sistema robusto no depende de que los desarrolladores nunca cometan errores (porque los van a cometer), sino de las salvaguardas que impiden que esos errores tiren abajo el negocio.
En tu día a día no permites que nadie haga un push —force directo a producción, ni despliegas sin pasar por el pipeline de integración continua.
Con los agentes el enfoque es idéntico.
Diseñar restricciones claras (limitar los directorios donde pueden escribir, restringir sus llamadas de red o capar el acceso a credenciales sensibles) es lo que transforma un script débil en un sistema fiable apto para producción.
Una reflexión para llevarte a casa
Hace no tantos años, cuando empecé en esto, pensaba que ser un buen programador consistía únicamente en picar líneas de código muy rápido y saber de memoria la sintaxis de un lenguaje. Me frustraba si no recordaba el nombre exacto de una función.
Con el tiempo, los errores y los proyectos caídos a las espaldas, descubrí la realidad: el verdadero trabajo de un ingeniero consiste en entender problemas ambiguos de negocio, diseñar arquitecturas limpias que toleren el cambio, automatizar lo repetitivo y construir sistemas mantenibles que no requieran que estés despierto a las tres de la mañana.
Con la llegada de los agentes va a ocurrir exactamente lo mismo.
Dentro de unos años, probablemente escribiremos muchos menos prompts de los que hoy imaginamos.
No pasaremos el día susurrándole palabras clave a una caja de texto. Lo que realmente diseñaremos y programaremos serán sistemas robustos capaces de decidir qué contexto inyectar, qué herramientas invocar bajo qué condiciones, qué verificaciones de seguridad ejecutar y cuándo dar un objetivo por cerrado de forma determinista.
El modelo de lenguaje seguirá siendo una pieza clave del engranaje, por supuesto. Igual que lo sigue siendo un compilador, una base de datos o un navegador. Pero dejará de ser el centro absoluto de nuestra atención.
La próxima revolución tecnológica no pertenece a quien mejor sabe hablarle a una IA en un chat, pertenece al desarrollador que sabe diseñar los sistemas para que la IA pueda, por fin, ponerse a trabajar de forma segura. Y ese es el peldaño de abstracción que te convertirá en el desarrollador senior que toda empresa querrá tener en su equipo.
Nos leemos en la próxima.
Julián