Durante los últimos meses he visto una explosión de herramientas que prometen revolucionar el desarrollo de software mediante agentes especializados. Claude Code, Cursor, Codex, Gemini CLI y muchas otras plataformas han popularizado conceptos como agentes autónomos, Skills, Workflows inteligentes y sistemas multi-agente capaces de resolver tareas complejas de forma prácticamente automática.
La teoría resulta atractiva. Si un desarrollador puede cometer errores, un agente también. Entonces la solución parece sencilla: crear más agentes. Un agente planifica, otro implementa, otro revisa el código, otro valida la documentación y un último verifica el resultado final. Sobre el papel parece una evolución natural del trabajo en equipo.
Sin embargo, cuando se empieza a trabajar con estos sistemas en proyectos reales, la experiencia suele ser bastante diferente.
El auge de los agentes de IA en el desarrollo de software
Una de las primeras conclusiones a las que hemos llegado muchos equipos es que los errores no desaparecen cuando aumentamos el número de agentes. De hecho, en determinados escenarios ocurre justo lo contrario.
Supongamos que disponemos de una skill perfectamente definida para implementar una funcionalidad sencilla. El proceso indica claramente que primero debe analizarse el requisito, después generar un plan, crear pruebas, implementar la solución, ejecutar validaciones y actualizar la documentación.
Aun así, el modelo puede saltarse alguno de esos pasos. Puede generar código sin haber realizado el análisis previo. Puede olvidarse de actualizar la documentación. Puede interpretar incorrectamente una parte del requisito o asumir información que no existe.
Lo más interesante es que esto puede ocurrir incluso cuando únicamente interviene un agente y una única Skill.
Esto nos obliga a plantearnos una pregunta incómoda: si un agente puede ignorar instrucciones relativamente simples, ¿por qué pensamos que diez agentes coordinándose entre sí van a comportarse de forma perfecta?
Los LLM no ejecutan procedimientos
Muchas veces se habla de los modelos de lenguaje como si fueran motores de ejecución. Un pipeline tradicional ejecuta instrucciones de forma determinista. Si definimos una secuencia de pasos, el sistema recorrerá exactamente esos pasos salvo que aparezca una excepción.
Un LLM funciona de forma diferente. El modelo genera la respuesta más probable a partir del contexto disponible. Las instrucciones ayudan a orientar el comportamiento, pero no garantizan que todas las acciones se ejecuten siempre de la misma manera.
Por eso podemos observar situaciones aparentemente contradictorias:
- La misma tarea genera resultados distintos en ejecuciones diferentes.
- Un requisito claramente especificado se interpreta de manera incorrecta.
- Una instrucción importante se ignora mientras otra secundaria recibe más atención.
- El modelo sigue una parte del procedimiento, pero omite otra.
No se trata necesariamente de un fallo de la herramienta. Es una característica inherente a la tecnología que no permite nunca tener soluciones deterministas.
Más contexto tampoco es la solución definitiva
Otro error habitual consiste en pensar que el problema se resolverá aumentando el contexto. Actualmente disponemos de modelos capaces de procesar cientos de miles de tokens. Esto permite incluir documentación, especificaciones, conversaciones previas e incluso repositorios completos.
Sin embargo, más contexto no implica automáticamente mejores resultados. Cuando proporcionamos una enorme cantidad de información aparecen nuevos problemas:
- El modelo debe decidir qué partes son relevantes.
- Algunos fragmentos importantes pueden perder peso frente a información secundaria.
- Las instrucciones pueden entrar en conflicto.
- El ruido contextual aumenta.
En proyectos grandes resulta bastante habitual observar que un modelo trabaja mejor cuando recibe únicamente los archivos y requisitos necesarios para completar una tarea concreta que cuando tiene acceso a todo el repositorio.
En cierto modo, ocurre algo parecido a lo que sucede con los desarrolladores humanos. Tener acceso a toda la información disponible no siempre facilita la toma de decisiones.
El coste oculto de los sistemas multiagente
Los sistemas multiagente suelen venderse como una forma de repartir responsabilidades. La realidad es que también introducen nuevos puntos de fallo.
Imaginemos un flujo formado por cuatro agentes:
- El primero analiza requisitos.
- El segundo genera un plan técnico.
- El tercero implementa el código.
- El cuarto revisa el resultado.
A simple vista parece una mejora respecto a un único agente. Pero ahora debemos gestionar la comunicación entre ellos.
- ¿Qué ocurre si el primer agente interpreta mal el requisito?
- ¿Qué sucede si el segundo genera un plan basado en una premisa incorrecta?
- ¿Qué pasa cuando el tercero implementa algo diferente a lo que el segundo esperaba?
Cada transición introduce posibilidades adicionales de error. En muchos casos, la complejidad de coordinación crece más rápido que la reducción de errores individuales.
Por eso numerosos equipos terminan simplificando arquitecturas que inicialmente parecían muy sofisticadas.
Lo que suele funcionar mejor en la práctica
Después de trabajar con asistentes de desarrollo durante un tiempo aparece un patrón bastante repetido. Los mejores resultados suelen obtenerse mediante procesos simples y verificables.
Un único agente principal suele ser más fácil de controlar que una red compleja de agentes especializados. Las tareas pequeñas suelen producir mejores resultados que los objetivos excesivamente amplios.
Las Skills específicas suelen comportarse mejor que las instrucciones genéricas. Pero existe un elemento todavía más importante: la verificación automática.
No confíes en que la IA tenga razón
Probablemente este sea el cambio de mentalidad más relevante. Muchos desarrolladores todavía utilizan los asistentes como si fueran expertos que validan sus propias respuestas. Sin embargo, un modelo no puede garantizar que una solución sea correcta simplemente porque afirme que lo es.
La única forma fiable de validar una implementación sigue siendo la misma que antes de la aparición de la IA:
- Pruebas automatizadas.
- Análisis estático.
- Validaciones de seguridad.
- Compilación.
- Revisión técnica.
Los equipos que están obteniendo mejores resultados no intentan eliminar los errores del modelo. Diseñan procesos capaces de detectarlos rápidamente. La diferencia es importante.
En lugar de buscar una IA perfecta, construyen mecanismos que permiten corregir errores de forma eficiente.
La verdadera utilidad de los asistentes actuales
A veces se genera una expectativa poco realista sobre lo que pueden hacer herramientas como Claude Code o Cursor.
No son desarrolladores autónomos capaces de mantener un proyecto complejo sin supervisión. Tampoco son sistemas infalibles que ejecutan procedimientos exactamente igual que un programa tradicional.
Su mayor valor aparece cuando actúan como aceleradores:
- Reducen tiempo de implementación.
- Ayudan a generar documentación.
- Facilitan tareas repetitivas.
- Permiten explorar soluciones con rapidez.
- Pero siguen necesitando contexto adecuado, validaciones y supervisión.
Conclusión
La evolución de los asistentes de programación durante los próximos años probablemente traerá modelos más capaces, mejores mecanismos de razonamiento y sistemas de agentes más sofisticados. Aun así, existe una realidad que conviene tener presente.