Anthropic paga a sus ingenieros 80 000 dólares al mes. Esos ingenieros ahora integran 8 veces más código al día que hace un año. No porque el modelo sea más inteligente, sino porque dejaron de escribir prompts para Claude y empezaron a construir sistemas que los escriben por ellos.
Brian Cherny, jefe de Claude Code en Anthropic, afirma: "Ya no le escribo prompts a Claude. Tengo bucles en ejecución que le dan instrucciones a Claude y determinan qué hacer. Mi trabajo es escribir bucles".
La mayoría de los desarrolladores leen esto y no tienen idea de lo que significa en la práctica. Al final de este artículo lo sabrás, y tendrás todo lo necesario para construir tu primer bucle este fin de semana.
Qué es realmente un bucle
Un prompt es una instrucción única. Un bucle es un objetivo en el que la IA sigue trabajando hasta alcanzarlo.
La diferencia radica en quién toma el control. Con un prompt, guías a Claude manualmente en cada paso. Con un bucle, defines el objetivo una vez y el sistema ejecuta el ciclo completo por su cuenta: encuentra el trabajo, lo ejecuta, verifica el resultado y decide qué sigue. Todo sin que tú tengas que estar frente al teclado.
1Prompt | tú escribes, Claude responde, tú vuelves a escribir2Bucle | el sistema encuentra trabajo, Claude ejecuta,3 | el sistema verifica el resultado, repite hasta terminar
Todo bucle real tiene cinco etapas:
1Descubrimiento | encontrar qué hay que hacer2Planificación | decidir cómo hacerlo3Ejecución | hacer el trabajo4Verificación | comprobar respecto al objetivo5Iteración | ¿no está listo? reintroducir el resultado y repetir
Tres de estas etapas realizan todo el trabajo real.
La verificación es el corazón. Sin una comprobación real del resultado, no tienes un bucle, tienes a un agente poniéndose de acuerdo consigo mismo repetidamente. La verificación debe ser objetiva: una prueba que pasa o falla, una compilación que funciona o no, un linter que devuelve cero o un código de error. No sirve pedirle a un segundo agente que "revise". Dos optimistas poniéndose de acuerdo no es una verificación.
El estado es lo que hace que el bucle aprenda. En cada paso, la IA debe recordar lo que ya intentó o repetirá el mismo error para siempre. Un bucle real mantiene un registro fuera de la conversación: qué se hizo, qué falló y qué sigue. El agente olvida entre sesiones; el archivo, no.
Una condición de parada es lo que mantiene la cordura. Un bucle sin salida se ejecuta hasta que tiene éxito, se rompe o agota tu presupuesto. Todo bucle serio tiene dos formas de detenerse: éxito y un límite estricto. Sin esto, habrás construido una máquina que te factura en silencio.
La prueba de 4 condiciones antes de construir nada
Un bucle justifica su coste solo cuando se cumplen estas cuatro condiciones. Si falta una, mantenlo como un prompt manual.
1Condición 1 | la tarea se repite al menos semanalmente2 | si es menos frecuente, el coste de configuración nunca se recupera34Condición 2 | algo puede rechazar automáticamente los resultados malos5 | una prueba, compilación, linter o comprobación de tipos6 | sin un filtro automático, volverás a revisar cada diff78Condición 3 | el agente puede hacer el trabajo de principio a fin9 | sin devolverte la mitad de la tarea a mitad del proceso1011Condición 4 | "terminado" es objetivo, no una cuestión de criterio12 | si la calidad es cuestión de gustos, un humano sigue ganando
Buenos primeros bucles:
1Triaje de fallos de CI | diario, clasificar fallos, redactar correcciones2Actualización de dependencias | semanal, escanear actualizaciones, abrir PRs3Pasadas de lint-and-fix | en cada PR, aplicar correcciones de estilo automáticamente4Borradores de Issue-a-PR | en bases de código con buena cobertura de pruebas
Malos primeros bucles (mantén a un humano al mando):
1Reescrituras de arquitectura | cuestión de criterio, el bucle se desviará2Código de autenticación o pagos | errores irreversibles demasiado costosos3Despliegues a producción | necesita una aprobación humana4Trabajo de producto vago | "terminado" no es objetivo
Los cinco bloques de construcción
Cada bucle funcional se ensambla a partir de cinco partes. Claude Code incluye las cinco.
1 - La automatización (el latido)
Esto es lo que hace que un bucle sea un bucle real y no solo una ejecución única. Un disparador se activa según un horario o evento, entrega la tarea a Claude y devuelve los hallazgos sin que tengas que ir a comprobarlo.
1/loop | re-ejecuta un prompt con una cadencia determinada2/goal | continúa hasta que se cumpla una condición que escribiste3hooks | disparan comandos en puntos del ciclo de vida del agente4cron | se ejecuta después de cerrar el portátil mediante GitHub Actions
Lo más importante es /goal. Un modelo pequeño independiente comprueba si se cumple la condición, de modo que el agente que escribió el código no sea el mismo que lo evalúa.
1/loop 30m /goal "Todas las pruebas en test/auth pasan y el lint está limpio."2Escanear src/auth en busca de fallos, redactar correcciones, abrir PR cuando se cumpla el objetivo.
2 - Habilidades (escribe el conocimiento del proyecto una vez)
Una habilidad es la forma de dejar de explicar el mismo contexto del proyecto en cada sesión. Un archivo SKILL.md contiene las instrucciones, convenciones y reglas que el bucle lee en cada ejecución.
Sin habilidades, el bucle vuelve a deducir todo tu proyecto desde cero en cada ciclo. Con habilidades, la intención se acumula: las convenciones, los pasos de compilación, las cosas que salieron mal antes... escritas una vez, leídas para siempre.
1skills/2 ci-triage.md - reglas de clasificación, patrones de corrección, criterios de escalado3 frontend.md - reglas de Tailwind, Next.js, SEO, accesibilidad4 security.md - patrones de auth, validación de entrada, lista de "no tocar"5 deps.md - reglas de actualización, comprobaciones de compatibilidad, patrones de rollback
La automatización llama a la habilidad por su nombre. El trabajo recurrente sigue siendo mantenible en lugar de pudrirse dentro de un cronograma que nadie actualiza.
3 - Sub-agentes (mantén al creador alejado del revisor)
Es el elemento estructural más útil en cualquier bucle. Separa al agente que escribe del agente que comprueba.
El modelo que escribió el código es demasiado generoso al evaluar su propio trabajo. Un segundo agente con instrucciones diferentes (y a veces un modelo más potente) detecta lo que el primero pasó por alto.
1Agente creador | modelo rápido y barato: explora, implementa, redacta2Agente revisor | modelo potente, alto esfuerzo: revisa, verifica, rechaza
1.claude/agents/2 explorer.md | solo lectura, modelo rápido, encuentra qué hay que hacer3 implementer.md | escribe la corrección, ejecuta las pruebas4 reviewer.md | auditoría de seguridad, calidad de código, filtro objetivo
Un modelo. Tres especialistas. El bucle se ejecuta mientras no estás mirando y el verificador es la única razón por la que realmente puedes alejarte.
4 - Conectores (para que actúe, no sugiera)
La diferencia entre un bucle que dice "aquí está la corrección" y uno que abre el PR, vincula el ticket y avisa en Slack una vez que la CI está en verde.
1GitHub | leer repos, crear ramas, abrir PRs, reaccionar a webhooks2Linear | actualizar tickets, vincular PRs, cerrar elementos al verificar3Slack | publicar resultados de triaje, avisar a humanos sobre escalados4Sentry | investigar alertas en vivo, redactar correcciones para las frecuentes
Sin conectores, el bucle describe lo que haría. Con conectores, lo hace.
5 - El archivo de estado (el agente olvida, el archivo no)
La pieza que parece demasiado simple para importar, pero que es la columna vertebral de todo bucle funcional. Un archivo Markdown fuera de la conversación que registra lo que se hizo, lo que falló y lo que sigue.
1# Estado del bucle - ci-triage23## Última ejecución42026-06-09 03:30 UTC - 7 fallos clasificados, 3 correcciones redactadas, 4 escalados56## En progreso7- claude/fix-auth-token-refresh - pruebas pasando localmente, esperando CI89## Completado hoy10- claude/bump-axios-1.7.4 - fusionado, CI verde1112## Escalado a humanos13- src/billing/refund.ts - pruebas fallando de 3 formas, causa raíz poco clara1415## Lecciones aprendidas16- 2026-06-08: PowerShell tiene problemas de TLS en el runner de Windows. Usar bash.17- 2026-06-07: tests/e2e/checkout requiere secreto de webhook de Stripe. Omitir si falta.
La ejecución de mañana lee este archivo y se reanuda. Sin él, cada ejecución comienza desde cero.
Cómo se ve un bucle real
El triaje de fallos de CI es uno de los mejores primeros bucles porque la verificación es automática y los riesgos de un mal resultado son bajos.
1Disparador | diario a las 3 a.m. o ante un fallo de CI2Habilidad | ci-triage.md3Lectura de estado | STATE.md - qué falló ayer, qué se arregló
El bucle se ejecuta:
1Paso 1 | lee fallos de CI desde GitHub mediante conector2Paso 2 | clasifica cada uno: env / flake / bug / dependencia / infra3Paso 3 | para cada fallo corregible: abre worktree, envía agente implementador4Paso 4 | agente revisor comprueba la corrección contra pruebas y reglas de seguridad5Paso 5 | filtro pasa: abre PR y vincula ticket de Linear6Paso 6 | filtro falla: escala a la bandeja de entrada de triaje humano7Paso 7 | actualiza STATE.md8Paso 8 | publica resumen nocturno en Slack
Por la mañana te despiertas con un mensaje en Slack, una bandeja de entrada de triaje con solo los problemas difíciles y un conjunto de PRs que ya pasaron la revisión automática. No tuviste que escribir ni un solo prompt.
El bucle que se compone en todo el negocio
La versión más potente no es un solo bucle. Son múltiples bucles escribiendo en un sistema de artefactos compartido para que aprendan unos de otros.
En SuperDesign, sus bucles cubren soporte, SEO, crecimiento de producto y anuncios. Cada uno tiene su propio disparador y flujo de trabajo, pero todos escriben en el mismo almacén de señales compartido.
El bucle de soporte nota que cinco usuarios preguntan cómo exportar algo. Crea una señal:
1tipo: señal2título: Exportar es demasiado difícil de encontrar3frecuencia: 54categoría: fricción5etiquetas: [feedback, precios, conversión]
El bucle de SEO nota una página con mucho tráfico pero poca conversión. Crea otra señal. El bucle de crecimiento de producto lee ambas señales junto con la analítica e identifica que la fricción de exportación es mayor de lo que sugerían los datos brutos, porque ahora dos fuentes independientes confirman el mismo problema. El bucle de anuncios encuentra una brecha de palabras clave y la alimenta directamente al bucle de SEO.
1Bucle de soporte | encuentra fricción, escribe señal2Bucle de SEO | encuentra brecha de contenido, escribe señal3Bucle de producto | lee ambas señales, identifica prioridad4Bucle de anuncios | encuentra brecha de palabras clave, alimenta bucle SEO
Ninguno de estos bucles son automatizaciones aisladas. Operan desde una base de conocimiento compartida de lo que el negocio está aprendiendo. Cada bucle hace que todos los demás sean más inteligentes. Eso es composición.
Los fallos sobre los que nadie te advierte
El bucle "Ralph Wiggum". Un agente destinado a señalar la finalización solo cuando termina, lo hace antes de tiempo. El bucle sale del trabajo a medio hacer y sigue ejecutándose y facturando sin producir nada. Solución: un filtro estricto que pueda fallar el trabajo objetivamente, no un "me parece bien" subjetivo.
Desviación del objetivo en sesiones largas. Las restricciones desaparecen en el turno 47 a medida que el contexto se resume. Solución: un archivo AGENTS.md permanente que el agente vuelve a leer al inicio de cada ejecución.
Deuda de comprensión. Cuanto más rápido envíe el bucle código que tú no escribiste, mayor será la brecha entre lo que existe y lo que entiendes. La factura que duele no es la de los tokens, es el día que depuras un sistema que nadie en el equipo ha leído. Solución: lee cada diff que abra el bucle.
Rendición cognitiva. La tentación de dejar de formar una opinión y aceptar lo que devuelva el bucle. Diseñar el bucle es la cura cuando lo haces con criterio, y el acelerante cuando lo haces para evitar pensar. Misma acción, resultado opuesto.
Costes de tokens que se acumulan. Cada iteración del bucle vuelve a leer el contexto completo y la pila crece en cada paso. Rastrea el coste por cambio aceptado. Por debajo de una tasa de aceptación del 50 %, el bucle cuesta más de lo que ahorra.
El orden de construcción que realmente funciona
Todos los que envían bucles que sobreviven en producción lo hacen de la misma manera:
1Paso 1 | haz que UNA ejecución manual sea fiable primero2Paso 2 | conviértela en una habilidad: guarda las instrucciones en SKILL.md3Paso 3 | envuelve la habilidad en un bucle: añade el filtro y la condición de parada4Paso 4 | ENTONCES ponlo en un horario
Programar algo que no has hecho fiable a mano es exactamente cómo los bucles explotan mientras duermes. Pruébalo una vez. Refuérzalo. Luego automatízalo.
La métrica que importa no son los tokens gastados ni las tareas intentadas. Es el coste por cambio aceptado. Si el bucle te da diez resultados y rechazas seis, estás haciendo el trabajo de revisión que se suponía que debía ahorrarte.
El cambio que ya ocurrió
En 2024, la ventaja estaba en el prompt. Mejor prompt, mejor resultado, mejor desarrollador. En 2026, la ventaja está un piso más arriba: el sistema que decide en qué trabaja Claude, cuándo, con qué filtro y qué estado sobrevive entre ejecuciones.
Los ingenieros de Anthropic integran 8 veces más código al día no porque encontraron una mejor manera de hacerle preguntas a Claude. Porque dejaron de hacer preguntas y empezaron a construir sistemas que le hacen preguntas a Claude en su nombre, continuamente, durante la noche, mientras duermen.
El bucle no hace que el trabajo sea más fácil. Mueve dónde ocurre el trabajo. De escribir prompts a diseñar el sistema que escribe prompts. De sostener la herramienta a construir la fábrica.
La mayoría de los desarrolladores seguirán escribiendo prompts a mano y se preguntarán por qué la brecha sigue aumentando. Unos pocos pasarán un fin de semana construyendo su primer bucle (una automatización, una habilidad, un archivo de estado, un filtro) y nunca mirarán atrás.
