Por qué los mejores flujos de código con IA son bucles, no prompts

Cuando alguien describe cómo usa Claude Code, suele decir algo como: «le escribo lo que quiero y me da el código». Esa descripción es cómoda, pero cada vez más incompleta. Un artículo publicado esta semana en skilldb.dev pone nombre a algo que muchos equipos ya practican sin haberlo formalizado: los flujos de trabajo realmente productivos con agentes de código no son prompts únicos, sino bucles agénticos — ciclos de observación, acción, verificación y corrección que se repiten hasta alcanzar un objetivo.

El punto de partida del artículo es sencillo pero incómodo: un prompt único tiene un techo de calidad. Puede generar código que compila, pero difícilmente puede validarlo, detectar efectos secundarios o ajustarse a feedback real del entorno. Un bucle, en cambio, incorpora ese feedback como parte del diseño.

Qué es exactamente un bucle agéntico

La estructura básica que describe el artículo sigue este patrón:

1. Observar — el agente analiza el estado actual (archivos, tests, logs, salida de herramientas).
2. Planificar — decide qué acción tomar a continuación.
3. Actuar — ejecuta la acción (escribe código, llama a una herramienta, lanza un comando).
4. Verificar — comprueba el resultado contra algún criterio de éxito.
5. Iterar — si el criterio no se cumple, vuelve al paso 1 con nueva información.

Este esquema no es nuevo en ingeniería de software — recuerda a los bucles de control clásicos — pero su aplicación a agentes LLM cambia bastante la forma en que se diseña la interacción. El prompt inicial deja de ser «la instrucción» para convertirse en «la definición del objetivo y los criterios de parada».

Por qué importa esto en el ecosistema Claude

En el contexto de Claude Code, este modelo mental tiene implicaciones concretas. Los hooks de ciclo de vida (`PreToolUse`, `PostToolUse`, `Stop`) son precisamente el mecanismo que permite insertar lógica de verificación entre iteraciones: se puede, por ejemplo, ejecutar una suite de tests en `PostToolUse` y devolver el resultado al agente para que decida si continuar o corregir. Los subagentes encajan aquí también: delegar la fase de verificación a un subagente especializado (uno que solo ejecuta tests y reporta) desacopla responsabilidades y hace el bucle más robusto.

Los MCP servers juegan otro papel relevante. Cuando el agente necesita observar estado externo — una base de datos, una API, los resultados de un linter — lo hace a través de herramientas MCP. Sin esa capa de observabilidad, el bucle se cierra solo sobre el código estático y pierde gran parte de su utilidad.

Lo que el artículo señala, con acierto, es que la mayoría de tutoriales y demos todavía muestran el flujo lineal: prompt → respuesta → copiar y pegar. Eso funciona para tareas simples, pero no escala. Los equipos que obtienen resultados consistentes con agentes de código han dejado de pensar en «qué le pregunto» y han empezado a pensar en «qué condición de salida defino y cómo verifico cada paso».

Para quién es útil este enfoque

El cambio de mentalidad es especialmente relevante para:

• Equipos de backend que automatizan generación de tests o migraciones de esquema, donde la corrección es verificable de forma objetiva.
• Ingenieros de plataforma que construyen pipelines de CI asistidos por agentes, donde cada etapa tiene criterios de éxito bien definidos.
• Desarrolladores en solitario que usan Claude Code para mantener proyectos legacy: el bucle permite al agente explorar el código, hacer un cambio, comprobar que no rompe nada y continuar sin supervisión constante.

No es un enfoque sin fricción. Diseñar buenos criterios de parada es más difícil que escribir un prompt. Y los bucles mal diseñados pueden volverse caros en tokens o, peor, converger en soluciones incorrectas que pasan los tests por las razones equivocadas. El artículo no entra en esas trampas con el detalle que nos gustaría, pero la dirección es la correcta.

---

Opinión EP: El término «bucle agéntico» no aporta nada que «agente con feedback» no dijera ya, pero la formalización es útil si sirve para que más equipos dejen de tratar a Claude Code como un autocompletado sofisticado. El modelo mental importa.