Durante los últimos meses he dedicado bastante tiempo a experimentar con agentes de desarrollo asistido por IA. He probado distintas herramientas, modelos, enfoques de planificación y muchas maneras de automatizar tareas de ingeniería de software.
Curiosamente, la conclusión a la que he llegado no tiene tanto que ver con los modelos como con el software que los rodea. Pero es pronto para saber si esta dirección se impondrá; por ahora, es la que me parece más prometedora.
De la ilusión del cerebro artificial a la realidad del código
Hace un año, entre pruebas en mi GPU y experimentos con modelos de OpenAI y Anthropic, me topé con una realidad distinta a la del hype: la tecnología aún estaba incompleta. Sentía que a los modelos frontera les faltaba algo esencial. Me transportaba a las novelas de ciencia ficción, donde los LLM parecían ser solo el motor de predicción de un cerebro artificial que aún no había terminado de construirse. Es una metáfora que me ayuda a situar el problema: aunque hoy sabemos que de su arquitectura emerge un razonamiento real, todavía nos falta el resto del ‘organismo’ para que sean verdaderamente autónomos.
En ese momento, decidí dejar de intentar descifrar los fundamentos de los LLM. Reconocí que, sin una base profunda en deep learning o machine learning, el esfuerzo para replicar tecnologías ya existentes no era el camino más eficiente. Mi objetivo no era reinventar la rueda en un campo ajeno, sino encontrar formas de aplicarla de manera efectiva.
La trampa de la probabilidad
Por aquel entonces, utilizaba VSCode con diferentes plugins como Continue o Aider. Después vinieron los IDEs con pilas incluidas que prometían otra revolución, como Windsurf o Cursor. Ayudaban, pero era más de lo mismo: mucho hype y pocas nueces. Seguía faltando algo y, aunque ya se empezaba a hablar de agentes de IA, el concepto era muy incipiente; eran frameworks y más frameworks que replicaban la estructura de una industria en pleno cambio. El camino estaba claro, pero los LLM necesitaban una capa de control para domar esa capacidad de razonamiento en bruto.
Un año después, a mediados de 2026, empiezo a probar Codex y Opencode (herramientas que actúan como un “harness” de programación). Son un paso importante para que los modelos sean más deterministas, aunque todavía dependan del modelo subyacente. Mediante máquinas de estados y procesos, logran que los modelos probabilísticos de los LLM encaucen sus enormes conocimientos hacia un área específica y una tarea concreta. Está claro que todavía falta camino por andar, pero esta aproximación da algo de esperanza.
Para que estos procesos sean sostenibles, es necesario añadir una arquitectura de memoria. Podríamos pensar en las bases de datos vectoriales como un módulo de memoria asociativa (que la IA consulta bajo demanda), mientras que el contexto del LLM es su memoria de trabajo inmediata. Por otro lado, proyectos como el ‘Second Brain’ de Andrej Karpathy, junto con Obsidian, permiten construir una memoria a largo plazo curada por el humano: una estructura de conocimiento navegable que nos permite inspeccionar y conectar ideas de forma consciente.
Con los modelos frontera actuales y una estrategia de agentes bien estructurada, los resultados en la generación de código son muy prometedores, aunque la supervisión humana sigue siendo clave en los puntos de decisión críticos. Los modelos más potentes ya son capaces de proponer arquitecturas, detectar fallos estructurales y sintetizar documentación compleja.
Ahora, la sensación es muy diferente.
Pero hay una diferencia importante entre ser bueno resolviendo una tarea acotada y ser bueno ejecutando un proceso abierto. Ahí es donde empiezan los problemas.
Un modelo puede decidir rehacer una implementación completa porque considera que es una solución mejor. Puede perder contexto. Puede cambiar de estrategia a mitad del desarrollo. Puede introducir cambios fuera del alcance original. No porque sea un mal modelo, sino porque esa es precisamente la naturaleza de un sistema probabilístico. Cuando se le da demasiada libertad, tiende a desviarse.
El verdadero reto
Desde mi punto de vista, cada vez estoy más convencido de que el problema más interesante pendiente de resolver no es conseguir un modelo más inteligente. El problema interesante es construir un sistema que siga siendo predecible aunque el componente principal no lo sea.
Eso implica cambiar el foco. En lugar de invertir tiempo escribiendo prompts cada vez más complejos, quizá deberíamos invertirlo en diseñar mejores workflows. Workflows donde el estado sea explícito, las transiciones sean deterministas, los contratos estén escritos, los eventos sean observables y cualquier ejecución pueda recuperarse después de un fallo.
En ese modelo, la IA deja de ser el centro del sistema y pasa a ser un actor más dentro de un proceso bien definido. No es que los agentes no sirvan; es que necesitan estar orquestados por un workflow. El agente es el actor; el workflow es el guion.
Para que se entienda mejor, pongamos un ejemplo concreto. En mi último proyecto experimental, diseñé un workflow con tres agentes: uno escribe tests, otro implementa el código y otro revisa el resultado. El estado se guarda en archivos JSON y cada paso se ejecuta solo si el anterior pasa. Esto me permitió reducir errores y, sobre todo, tener la tranquilidad de que podía interrumpir y reanudar el proceso sin perder el hilo. No es magia, es ingeniería.
Una idea que me parece especialmente interesante
He encontrado una frase que resume muy bien este enfoque:
Write the loop, not the prompt.
Es una idea sencilla, pero cambia completamente la perspectiva. El valor deja de estar en una conversación concreta con el modelo. Pasa a estar en el proceso que puede ejecutarse una y otra vez con resultados consistentes. Esa frase cambió mi forma de pensar sobre el diseño de sistemas con IA.
Una consecuencia curiosa
Resulta increíble, pero por ahora, cuanto mejores son los modelos, menos inteligencia debería contener el workflow. Las decisiones importantes no deberían vivir en el modelo; deberían vivir en la máquina de estados, en los contratos, en las pruebas y en las reglas del proceso. Piénsalo como un sistema de raíles: el workflow es el riel que garantiza la dirección y la seguridad, mientras que la inteligencia del modelo es el motor que proporciona la potencia. El workflow debe ser determinista y predecible; la inteligencia, solo la justa para la tarea.
Eso sí, la potencia del modelo sigue siendo el motor; sin un modelo capaz de procesar el lenguaje con precisión, el workflow más perfecto del mundo no produciría nada de valor.
El modelo debería dedicarse únicamente a aquello para lo que es realmente bueno: identificar patrones, programar y revisar. Tareas que están alineadas con su fortaleza principal: el procesamiento de lenguaje natural (NLP). Todo lo demás pertenece al sistema.
Eso sí, esta relación podría cambiar si los modelos futuros son cualitativamente distintos. Por ahora funciona, pero conviene no dogmatizar.
En qué estoy pensando ahora
Últimamente me interesan especialmente temas como workflows deterministas para desarrollo asistido por IA, separación de responsabilidades entre agentes, estado persistente y recuperación tras fallos, contratos verificables entre fases del desarrollo, observabilidad de procesos largos y automatización basada en eventos en lugar de conversaciones.
Creo que todavía estamos al principio de esta forma de trabajar y que durante los próximos años veremos más innovación en la ingeniería que rodea a los modelos que en los propios modelos. Y, personalmente, esa parte me parece incluso más interesante.
Mi predicción es que en 2027 veremos los primeros frameworks de desarrollo donde el workflow sea el producto, no el modelo. Y entonces, la pregunta dejará de ser “¿qué modelo usas?” para convertirse en “¿cómo está diseñado tu proceso?”.