"Ya no escribo prompts para Claude. Es el bucle el que está corriendo, y es el bucle el que decide qué hacer a continuación pidiéndole a Claude. Mi trabajo se ha convertido en escribir los bucles."
Estas son las palabras pronunciadas públicamente por Boris Cherny, quien lidera Claude Code (destacado en The New Stack y en artículos de Addy Osmani).
Mientras muchos de nosotros seguimos refinando prompts para mejorar la precisión, la persona que construye la herramienta ya ha dejado de ser el "prompter".
Si lo piensas, mientras esté involucrado el "turno humano"—sentarte frente a una pantalla, esperar una respuesta de IA, verificarla y dar instrucciones de nuevo—el límite de velocidad lo determina la velocidad de tus propias manos.
Loop Engineering es la idea de eliminar ese turno humano de la estructura. Boris está completamente comprometido con esto; dice que eliminó su IDE en noviembre de 2024 y no lo ha vuelto a abrir desde entonces. Afirma que casi todas sus contribuciones a Claude Code en el último mes fueron escritas por el propio Claude Code (reportadamente más de 200 PRs).
El creador de la herramienta no escribe código él mismo, sino que se ha pasado al lado de "vigilar si el bucle gira correctamente". Hoy voy a desglosar esto a nivel de especificaciones técnicas, no solo como una vibra. También estoy en proceso de migrar hacia el lado del bucle, y puedo sentir que mis manos se vuelven más libres cuanto más me muevo.
Artículo relacionado: Introducción al Vibe Coding: 6 pasos para personas que no saben programar y construyen apps con Claude. Ha llegado la era de la producción casera los fines de semana
https://note.com/nobel/n/n8192ec07d689
Loop Engineering Significa un Cambio de Roles
En otras palabras, tu posición cambia. Antes, los humanos se sentaban en medio de un ida y vuelta donde el humano instruía, la IA respondía, y el humano verificaba y corregía. En el diseño de bucles, los humanos son responsables de diseñar el mecanismo de circulación (el bucle), mientras que el ensayo y error y la verificación de resultados se trasladan al lado de la IA. Simplemente esperas una notificación cuando termina.
Addy Osmani, de Google, escribió lo mismo en un artículo titulado Loop Engineering, describiéndolo como "reemplazar a la persona que escribe prompts por un mecanismo que escribe prompts en su nombre". El punto de apalancamiento ha pasado de la habilidad de escribir buenos prompts a cómo diseñar un sistema que permita a la IA escribir prompts por ti. Eso es el núcleo.
Sin embargo, el propio Addy advierte: "Todavía está en etapas tempranas, y soy algo escéptico. Hay que tener mucho cuidado con los costos de tokens". Volveremos a esta trampa en la segunda mitad.
Las Especificaciones Técnicas de /loop
Claude Code tiene una habilidad integrada llamada /loop (a partir de v2.1.72). Esta es la puerta de entrada más fácil al loop engineering. Como las explicaciones en línea suelen tener errores, me centraré en los puntos clave basándome en la documentación oficial de ejecución programada.
El comportamiento cambia según lo que le pases:
- Tanto intervalo como prompt:
/loop 5m check if the deployment is finished and let me knowse ejecutará a intervalos fijos. - Solo prompt:
/loop check if the CI passed and respond to review comments. Claude decidirá el intervalo por sí mismo entre 1 minuto y 1 hora (a su propio ritmo). - Sin pasar nada:
/loop. Se ejecutará el prompt de mantenimiento incorporado (continuar trabajo pendiente, atender PRs, limpieza ligera) o un archivoloop.mdque hayas colocado.
El intervalo se puede poner al principio, como 30m, o al final, como every 2 hours. Las unidades son s / m / h / d. También puedes pasar otros comandos, como /loop 20m /review-pr 1234, para ejecutar habilidades guardadas cada vez. Para detenerlo, presiona Esc mientras esperas (las tareas creadas mediante solicitudes en lenguaje natural no se detienen con Esc; debes pedir que se eliminen). En modo a su propio ritmo, si Claude determina que la tarea está realmente terminada, finalizará sin programar la siguiente ejecución.
El modo a su propio ritmo tiene una ventaja sutil: se ajusta automáticamente, esperando un tiempo corto si una compilación está casi terminada y más tiempo si no está pasando nada. A veces se usa un mecanismo llamado "Monitor" para transmitir salida en segundo plano en lugar de hacer polling, lo que suele ser más barato que lanzar un prompt a intervalos fijos.
Déjame corregir un error común que se encuentra en los artículos fuente. A veces se escribe que las tareas se "eliminan automáticamente 3 días después de su creación", pero con precisión, las tareas recurrentes caducan 7 días después de su creación (se ejecutan una última vez y desaparecen). Además, /loop tiene ámbito de sesión y desaparece cuando inicias una nueva conversación. Si lo cierras, puedes volver con --resume si no ha caducado.
Hay tres métodos de programación, elegidos según el caso de uso:
- Cloud (Routines): Se ejecuta en el lado de Anthropic. Funciona incluso si tu máquina está cerrada. El intervalo mínimo es 1 hora.
- Desktop Scheduled Tasks: Se ejecuta en tu máquina y puede tocar archivos locales.
- /loop: Solo mientras la sesión está abierta. Mínimo 1 minuto, conveniente para polling durante una sesión.
La división del trabajo es: usar Routines o GitHub Actions para residencia permanente sin intervención humana, y /loop para monitoreo durante una sesión.
Tareas Estándar Donde los Bucles Son Efectivos
Las tareas en tu rutina donde repites "verificar y corregir un poco" son generalmente adecuadas para bucles. Hay tres patrones comunes:
- Patrulla de errores: Detectar problemas o fallos en pruebas, leer la causa, corregirla, ejecutar pruebas y crear un PR a intervalos regulares.
- Revisión continua: Monitorear cambios en el código y señalar áreas de preocupación continuamente. Los humanos solo deciden si aceptan las sugerencias.
- Sincronización de documentos: Detectar cambios en la fuente y mantener actualizados el README o las especificaciones.
Lo común entre estos tres es que el objetivo se puede juzgar claramente, como "las pruebas pasan" o "el PR está creado". Por el contrario, las tareas con criterios ambiguos no son adecuadas para bucles. Si el punto de parada no está claro, seguirá ejecutándose y consumiendo tokens. Para tu primera tarea, es más seguro elegir una donde el éxito o fracaso sea obvio de un vistazo.
Prevenir Desbocamientos y Olvidos con "Archivos de Estado"
Hay dos miedos con los bucles: repetir el mismo fallo y consumir tokens sin fin.
Aquí es efectivo diseñar con un único archivo de estado en el proyecto. Ya sea STATE.md o todo.md, la IA lee y escribe el objetivo actual / elementos completados / próximos pasos / puntos atascados durante cada bucle. Incluso si la sesión se corta, la IA no pierde la noción de "dónde está y hacia qué apunta".
Esto no es solo una práctica aleatoria; la propia Anthropic llegó a casi la misma conclusión en Effective harnesses for long-running agents (noviembre de 2024). Su configuración utiliza dos roles: un agente inicializador para configurar el entorno y un agente de codificación para avanzar una funcionalidad por sesión. El progreso se transfiere entre sesiones mediante commits de git y un archivo claude-progress.txt. Para trabajos largos, la compresión mediante resumen es insuficiente. La política es escribir en un archivo estructurado una vez y reconstruir el contexto.
En mis propias operaciones, uso tasks/state.md como centro de estado compartido, que tanto el lado de lluvia de ideas como el de implementación leen antes de actuar. Es lo mismo que el artículo: "No confíes en el contexto, confía en el archivo". Es simple, pero sin esto, el bucle se pierde en la segunda vuelta.
El Método Ralph y la Separación de Creador y Verificador
Existe una versión extrema del bucle llamada el método "Ralph". Popularizado por Geoffrey Huntley, la fuente original es solo un bucle bash simple:
Al alimentar el mismo prompt sin cesar y usar un archivo Markdown con el plan como estado compartido en disco, la IA lo lee cada vez y decide "qué hacer a continuación" por sí misma. Parece imprudente, pero como hay un archivo de estado, avanza en cada vuelta. Claude Code también tiene un plugin oficial ralph-loop que sigue reenviando el mismo prompt hasta que se cumple una condición de finalización (promesa de finalización). Hay una restricción: la declaración de finalización solo debe emitirse cuando realmente se haya logrado.
Sin embargo, si dejas todo a una sola IA, dirá "OK" al código que ella misma escribió. Aquí es efectivo separar la IA que crea (Creador) y la IA que inspecciona (Verificador). En mis propias operaciones, separo la implementación y la verificación en diferentes agentes, y no le doy al lado de verificación la intención de implementación—solo le muestro los requisitos y lo dejo evaluar de forma independiente. Aprendí por las malas que las auto-revisiones en la misma sesión son inevitablemente indulgentes.
Incorporar un "agente revisor con una perspectiva diferente" en el bucle—diseñar esta verificación multicapa es uno de los trabajos que los humanos deberían mantener.
Autonomía de Diseño en Tres Etapas
Confiar todo de una vez provocará accidentes. Es más seguro separar el nivel de participación en capas:
- L1 (Manual): Los humanos escriben prompts y verifican cada uno. La forma tradicional.
- L2 (Bucle Semiautónomo): Seguir un archivo de estado y supervisar un conjunto específico de tareas hasta su finalización con
/loop. - L3 (Residente): Ejecutar continuamente mediante Routines o GitHub Actions sin intervención humana.
Es realista empezar con L2. Ejecuta una tarea hasta completarla con /loop y observa el comportamiento. Sube a L3 una vez que veas el rango de fiabilidad. Mis primeras veces, veía los registros en una pantalla lateral para ver "dónde tomó una decisión equivocada".
Trampas (Conócelas Primero)
Como solo he escrito sobre los aspectos positivos, aquí hay tres puntos donde podrías atascarte:
- Costos de tokens: Los bucles consumen más cuanto más se ejecutan. Esto es lo que Addy enfatizó; si pones el intervalo demasiado corto, puede costar una buena cantidad durante la noche. El modo a su propio ritmo es mejor que los intervalos fijos porque espera cuando debe, reduciendo el desperdicio.
- Operaciones irreversibles: El prompt de mantenimiento incorporado solo realiza acciones irreversibles como push o eliminación dentro del "rango ya permitido en la conversación". Al escribir tus propios prompts, es más seguro definir tú mismo los límites para operaciones destructivas.
- Desaparece en 7 días: Las tareas recurrentes de
/loopcaducan 7 días después de su creación. Si quieres ejecutarlo por más tiempo, pásate a Routines o tareas de escritorio.
Notas para Usuarios Intermedios
/loopy/goalson diferentes./loopse ejecuta por intervalo. Si quieres continuar cada turno hasta que se cumpla una condición, usa/goal. Si quieres que reaccione en el momento en que ocurra un evento, usa push a través de Channels.- Colocar un
loop.md(.claude/loop.mdo~/.claude/loop.md) te permite reemplazar el prompt predeterminado de un/loopvacío por el tuyo propio. Es útil para escribir tareas rutinarias como "arreglar si el CI de la rama release está en rojo". - Hasta 50 tareas programadas por sesión. Puedes ver la lista con
CronListy eliminar por ID conCronDelete.
Resumen
Antes, el tiempo que pasaba frente a la pantalla era el límite superior del progreso. Ahora, un bucle que lee un archivo de estado mientras duermo avanza una funcionalidad a la vez, y mi mañana comienza verificando ese progreso.
Antes de mejorar el contenido (precisión del prompt), diseña la forma en que se ejecuta (separación de bucles, gestión de estado y verificación). El apalancamiento se ha desplazado allí—este es el punto común en las historias de Boris, Addy y el arnés de Anthropic. Creo que no es una teoría difícil, sino una acumulación constante de diseños simples, como decidir cuándo parar antes de iniciar el bucle.
Información útil que no se puede compartir en X se está compartiendo en el LINE OpenChat. Si te interesa utilizar Claude Code/Codex o usar IA para operaciones en X, únete a nosotros.
