Claude Guía de Code Loop Engineering: 4 tipos de bucles y diseño seguro de la automatización ============================================================================================ ⁣El bucle del código INJX12⁣ es una estructura de control que hace que el agente repita los procesos de observación, acción y verificación hasta que se cumplan las condiciones de finalización. Se explican las diferencias entre los cuatro tipos de bucles, junto con métodos de diseño prácticos que incluyen la evidencia de verificación, la parada forzada, la idempedancia, el coste y el principio de privilegios mínimos. - ⁣El «Loop» de INJX12⁣ Code no es un bucle de código, sino una estructura de ejecución de agentes que repite el ciclo de observación, acción y verificación hasta que se cumple la condición de finalización. - El modo «por turnos» se encarga de los procedimientos de verificación; el modo «por objetivos», de la decisión de finalización; el modo «por tiempo», del momento de la reejecución; y el modo «proactivo» del inicio de la tarea y la orquestación, que se delegan al sistema. - Un buen bucle debe contar con condiciones de finalización medibles, pruebas de verificación externas, finalización forzada, idéntica repetibilidad y privilegios mínimos. - Dado que el modelo de evaluación `/goal` solo tiene en cuenta las pruebas que se desprenden de la conversación, es necesario informar claramente sobre el resultado de la prueba, el código de salida y el alcance de los cambios. - Las transformaciones deterministas deben procesarse mediante scripts, mientras que el flujo de trabajo dinámico y el uso de múltiples agentes solo deben aplicarse a tareas a gran escala que requieran un paralelismo real. ⁣El bucle de INJX12⁣ Code no es simplemente una función que permite ejecutar el modelo durante más tiempo. La clave reside en colocar un disparador (Trigger), un verificador (Verifier), una condición de éxito (Success condition), una parada forzada (Hard stop) y un límite de permisos (Permission boundary) alrededor de un agente de IA que actúa de forma probabilística, con el fin de convertir las tareas repetitivas en un sistema controlable. Este artículo resume de un solo vistazo las diferencias entre los bucles por turnos (Turn-based), basados en objetivos (Goal-based), basados en el tiempo (Time-based) y proactivos (Proactive Loop), así como los principios de diseño prácticos. 1. ¿Qué es el «Loop» en Claude Code? En este contexto, el «Loop» no se refiere a las sentencias for o while de los lenguajes de programación. El «bucle» que describe el equipo de Claude Code es una estructura de ejecución en la que el agente observa el estado actual, actúa, verifica el resultado y, a continuación, repite la tarea hasta que se cumplan las condiciones de finalización. Inicio de la tarea ↓ Análisis del estado y del código ↓ Elaboración del plan ↓ Modificación del código o ejecución de herramientas ↓ Pruebas y verificación ↓ ¿Se cumplen las condiciones de finalización? ├─ No: siguiente iteración └─ Sí: finalización e informe de resultados A la hora de identificar un bucle, resultan útiles las siguientes cuatro preguntas. ¿Qué inicia la tarea? ¿Qué finaliza la tarea? ¿Qué función de Claude Code controla la repetición? ¿Para qué tipo de tareas es adecuado? No es necesario convertir todas las tareas en bucles complejos. Para tareas en las que el resultado se comprueba de inmediato, como corregir un error tipográfico en un archivo o un simple cambio de nombre, es más eficaz utilizar un indicador de comando normal. Solo se debe optar por un bucle cuando realmente se requieran varias rondas de observación, modificación y verificación. 2. Comparación de los cuatro tipos de bucles Tipo Condición de inicio Condición de finalización Función principal Tareas adecuadas Responsabilidad del usuario Por turnos Indicación del usuario Cuando Claude considere que ha finalizado o necesite información adicional Conversación general, habilidades, herramientas de prueba y navegador Implementaciones y modificaciones breves y puntuales Procedimiento de verificación repetitivo Basado en objetivos El usuario especifica las condiciones de finalización Cuando el modelo de evaluación confirma que se cumplen las condiciones o el usuario lo interrumpe /goal, modo automático si es necesario Tareas cuyo estado de finalización es medible, como pruebas, compilaciones y migraciones Decisión de finalización Basado en el tiempo Tiempo, intervalo o calendario especificados El usuario lo cancela o finaliza una tarea externa /loop, /schedule Supervisión de PR, CI y despliegues; resúmenes periódicos; sondeo de estado Momento de la próxima ejecución Proactivo Calendario, API, eventos de GitHub, etc. Cumplimiento de los objetivos de tareas individuales, desactivación de rutinas Rutinas, /goal, habilidades, flujos de trabajo dinámicos, modo automático Clasificación de incidencias, gestión de errores, migraciones a gran escala y otras tareas continuas Detección de tareas, ejecución de indicaciones, orquestación La clave de esta clasificación no es «cuán inteligente es la IA», sino qué responsabilidad de control cede la persona al sistema. En el modo «Turn-based», la persona crea el siguiente prompt; en el modo «Goal-based», delega la decisión de si la tarea está completada; y en el modo «Time-based», delega el momento de la reejecución. En la etapa «Proactive», la responsabilidad de detectar la aparición de una tarea y ejecutar el prompt adecuado pasa al sistema. 3. Bucle por turnos: se cede el procedimiento de verificación El bucle por turnos es la forma básica en la que la mayoría de los desarrolladores utilizan el código Claude. Persona → Claude → Persona → Claude Cuando el usuario realiza una solicitud, Claude busca los archivos pertinentes, modifica el código, lo prueba y comunica los resultados. Aunque internamente puedan producirse varias iteraciones de observación, acción y verificación, la autoridad para iniciar la siguiente tarea sigue recayendo en el usuario. Modificar el código no es lo mismo que completar una funcionalidad Aunque Claude informe de que «ha completado la implementación y las pruebas», en el producto real pueden persistir los siguientes problemas: El estado no cambia al hacer clic en el botón. Se produce un error en la consola del navegador. El diseño para móviles se ve alterado. Faltan atributos de accesibilidad. Se superan las pruebas, pero el flujo real del navegador falla. Se han modificado archivos que no guardan relación con el cambio. Por lo tanto, el criterio de finalización no debe ser «se ha modificado el código», sino «se ha verificado el funcionamiento mediante pruebas externas». Reutilizar la verificación con SKILL.md Skill es un método que consiste en almacenar en SKILL.md las instrucciones y procedimientos que se utilizan repetidamente. Claude puede cargarlos automáticamente tras evaluar su relevancia, o bien se pueden ejecutar directamente mediante /skill-name. En lugar de incluir siempre los procedimientos operativos largos en CLAUDE.md, separarlos para que Skill se cargue solo cuando sea necesario permite utilizar el contexto de forma más eficiente. --- name: verify-ui-change description: Verifica los cambios en la interfaz de usuario en el entorno de ejecución real antes de dar por finalizados dichos cambios. --- # Verificación de cambios en la interfaz de usuario 1. Ejecuta el servidor de desarrollo. 2. Abre la pantalla modificada en el navegador. 3. Manipula los nuevos controles de forma real. 4. Comprueba si se produce el cambio de estado esperado. 5. Comprueba si hay nuevos errores y advertencias en la consola del navegador. 6. Comprueba la accesibilidad y los principales indicadores de rendimiento. 7. Si falla, corrige el error y vuelve a verificar desde el principio. 8. Informa de las pruebas realizadas, incluyendo los comandos ejecutados, los resultados y las capturas de pantalla. Una buena «Skill» no contiene recomendaciones abstractas, sino una lista de comprobación viable. «Comprobar que npm test devuelva el código de salida 0» es una regla mucho más sólida que «revisar con más detenimiento». Solidez de las pruebas de validación Prueba Fiabilidad Motivo Explicación del agente: «Parece que funciona correctamente» Baja No es un resultado de ejecución, sino una mera deducción Diferencias de código y revisión estática Media Se ven los cambios, pero no se comprueba el comportamiento en tiempo de ejecución Salida real de la prueba y código de salida Alta Existen resultados externos reproducibles Interacción con el navegador, capturas de pantalla, resultados de la consola y del rendimiento Muy alta Verifica directamente el recorrido del usuario y el estado en tiempo de ejecución El agente de revisión independiente y la integración continua (CI) llegan a la misma conclusión Muy alto Reduce el sesgo de autoconfirmación del agente de implementación Claude La documentación oficial de Code describe la habilidad «/run», que permite comprobar la aplicación en ejecución, y /verify, que verifica los cambios en el entorno de ejecución real. Si el método de ejecución del proyecto es complejo, es más seguro documentar en una Skill propia del equipo los comandos de inicio exactos, las variables de entorno y los procedimientos de preparación de datos. 4. Bucle basado en objetivos: delega la decisión de finalización En el bucle basado en objetivos, el usuario no tiene que decidir cada vez si «se debe realizar la tarea una vez más». El usuario define el estado de finalización y Claude continúa con varios turnos hasta que se cumplan dichas condiciones. El usuario especifica el objetivo ↓ Turno de trabajo de Claude ↓ Un modelo de evaluación independiente comprueba la condición de finalización ├─ No cumplida: se transmite el motivo al siguiente turno └─ Cumplida: finalización del objetivo /goal está documentado para su uso en Claude Code v2.1.139 o superior. Solo se puede activar un objetivo por sesión. Lo que ve realmente el modelo de evaluación Al finalizar cada turno, un modelo pequeño y rápido independiente analiza las condiciones de finalización y el contenido de la conversación para determinar si se ha «cumplido» o «no se ha cumplido». La configuración predeterminada es un modelo de evaluación de la familia Haiku. Una limitación importante es que el modelo de evaluación no lee los archivos directamente ni ejecuta pruebas por separado. Por lo tanto, el Claude que ha realizado la tarea debe dejar claramente constancia de las siguientes pruebas en la conversación: Los comandos ejecutados El número de pruebas y los resultados (superadas o fallidas) El código de salida El resultado de la compilación La lista de archivos modificados Las causas de los fallos restantes Resultados que confirmen que se han respetado las restricciones de alcance El modelo de evaluación no juzga «qué ocurrió realmente», sino «qué pruebas se han revelado en la conversación». Los cuatro elementos de un buen «Goal» Un buen «Goal» incluye los cuatro elementos siguientes: Condiciones de éxito medibles: superación de pruebas, éxito de la compilación, vaciado de la cola, consecución del umbral de puntuación Método de verificación: especificar con qué comando o herramienta se demostrará el éxito Restricciones del alcance de las modificaciones: directorios modificables, archivos prohibidos, efectos secundarios permitidos Condiciones de finalización forzada: número máximo de turnos, tiempo máximo, número de fallos consecutivos; interrupción en caso de error de permisos /goal: todas las pruebas y lints relacionadas con auth deben superarse, y git diff solo debe incluir src/auth y los archivos de prueba relacionados. En cada turno se informará del resultado de la ejecución y del código de salida. Si se alcanza un máximo de 12 turnos o 45 minutos, se interrumpirá el proceso y se resolverán los fallos restantes. La condición de finalización clave de /goal en sí misma es la determinación de éxito del modelo de evaluación o el comando /goal clear del usuario. Para imponer un límite de turnos o de tiempo, debe especificarse dentro de las condiciones de Goal. Condiciones adecuadas y inadecuadas Condiciones adecuadas Condiciones inadecuadas npm test finaliza con un código de salida 0 Perfeccionar el código Se superan las 48 pruebas relacionadas con la autenticación Se mejora la experiencia del usuario al máximo Todos los puntos de llamada a la API se cambian a la nueva interfaz y la compilación se realiza con éxito Se refactoriza con una estructura mejor La cola de incidencias pendientes está vacía y se registra el resultado de cada incidencia Se resuelven tantas incidencias como sea posible Los objetivos ambiguos pueden finalizar demasiado pronto o dar lugar a un ciclo interminable de mejoras. Comprobación del estado y suspensión /goal: comprueba las condiciones activas, el tiempo de ejecución, el número de turnos de evaluación, el consumo de tokens y el motivo de la última evaluación /goal clear: suspende el objetivo activo Configuración de un nuevo objetivo: sustituye al objetivo existente --resume o --continue: permite reanudar un objetivo inconcluso Aunque las condiciones se mantienen al reanudar, el número de turnos, el tiempo y el límite de tokens pueden reiniciarse, por lo que es recomendable gestionar las paradas forzosas junto con los indicadores de rendimiento. /goal y los permisos son independientes /goal solo inicia automáticamente el siguiente turno, pero no amplía los permisos de la herramienta. Si la escritura de archivos, los comandos de prueba o las operaciones de Git requieren autorización, es posible que se necesite dicha autorización incluso durante el Goal. Para la ejecución sin supervisión se puede utilizar el modo «Auto», pero este no es una función que «permita todas las herramientas incondicionalmente». El clasificador bloquea las operaciones que sean destructivas, difíciles de revertir o que tengan como objetivo elementos fuera de los límites de confianza, y las reglas explícitas ask y deny se aplican antes que el clasificador. 5. Bucle basado en el tiempo: supera el momento de reejecución Si el bucle basado en objetivos aborda «cuándo detenerse», el bucle basado en el tiempo aborda «cuándo volver a ejecutarse». Es adecuado para tareas en las que el estado de un sistema externo cambia con el paso del tiempo. Comprobar si hay nuevas revisiones en las PR Comprobar si la CI o la implementación han finalizado Comprobar el estado de las compilaciones prolongadas Resumen diario de mensajes de Slack Comprobar si hay nuevas entradas en la cola de incidencias /loop: ejecución repetida dentro de la sesión actual /loop 10m Comprueba las PR actuales e incorpora los nuevos comentarios; si hay alguna CI fallida, analiza la causa y corrígelo. Las principales formas descritas en este documento son las siguientes. Entrada Acción /loop 5m <prompt> Ejecuta el prompt a intervalos fijos especificados /loop <prompt> Claude selecciona el intervalo en cada repetición /loop Ejecuta el Prompt de mantenimiento integrado o el archivo loop.md del proyecto /loop 20m /review-pr 1234 Reejecuta la Skill permitida a intervalos especificados /loop depende de la sesión actual de Claude Code. El ordenador y la sesión deben estar en ejecución; si se inicia una nueva conversación, las tareas de la sesión se perderán. Las tareas pendientes se pueden recuperar con --resume o --continue, pero las tareas recurrentes caducan, por defecto, 7 días después de su creación. Tampoco se ejecutan de forma retroactiva todos los ciclos perdidos. Dado que el programador de la sesión puede estar sujeto a fluctuaciones (jitter), puede que no sea adecuado para requisitos operativos que exijan una «ejecución puntual a la hora exacta». /schedule: Rutina gestionada por Anthropic /schedule agrupa un Prompt, un Repository, un Connector y un Trigger para crear una rutina que se ejecuta en la infraestructura gestionada por Anthropic. Se puede ejecutar incluso si se cierra el portátil; en la documentación oficial se presenta como «Research Preview». Los triggers que admite una rutina son los siguientes: Programación recurrente Programación única en un momento futuro específico Llamadas a API autenticadas Eventos de pull request o lanzamiento en GitHub Se pueden vincular varios «Trigger» a una misma «Routine». Por ejemplo, se puede configurar una «Routine» de revisión de pull requests para que se ejecute todas las noches y, al mismo tiempo, responda al evento pull_request.opened. Comparación entre /loop y /schedule Categoría /loop Rutina /schedule Lugar de ejecución Ordenador y sesión actuales Nube gestionada por Anthropic Ejecución tras el apagado del ordenador Normalmente no es posible Sí Se requiere una sesión abierta Sí No Archivos locales sin confirmar Accesibles No accesibles; se clona el repositorio de nuevo en cada ejecución Intervalo mínimo 1 minuto según la documentación oficial 1 hora según la documentación oficial Persistencia Centrada en la sesión; las tareas recurrentes caducan a los 7 días Rutina almacenada en la cuenta Solicitud de permisos Hereda la política de la sesión actual Ejecución autónoma sin autorización interactiva Uso adecuado Supervisión de PR y despliegues breves Automatización de operaciones continuas Cuándo es mejor un evento que un sondeo Si se comprueban cada minuto las PR en las que rara vez se producen cambios, la mayoría de las ejecuciones finalizarán sin realizar ninguna acción. Si un sistema externo puede enviar eventos, la siguiente estructura resulta más eficiente. Fallo de CI o actualización de PR ↓ GitHub Trigger o API de Routine ↓ Ejecución de Claude solo cuando sea necesario El diseño basado en eventos reduce los retrasos y minimiza las llamadas innecesarias al modelo y el consumo de tokens. Si el sondeo es inevitable, es recomendable aumentar el intervalo para adaptarlo a la frecuencia real de los cambios y aplicar un «backoff» cuando no se produzcan cambios durante un periodo prolongado. Requisitos imprescindibles para las tareas basadas en el tiempo Idéntica: aunque se reciba el mismo evento varias veces, no deben producirse comentarios, PR ni implementaciones duplicados. Estado de procesamiento: deben registrarse el ID del último evento procesado, el SHA de la confirmación y el ID del comentario de revisión, entre otros. Estado de finalización: debe poder determinarse la finalización, por ejemplo, fusión o cierre de una solicitud de incorporación de cambios, cola vacía, éxito o reversión de una implementación. Ámbito de escritura: deben limitarse los efectos secundarios, como permitir comentarios, prohibir la fusión o permitir el push únicamente en la rama claude/*. Gestión de fallos: se necesitan reglas de reintento y escalación en caso de fallos en servicios externos, caducidad de la autenticación, límite de frecuencia o falta de permisos. 6. Proactive Loop: va más allá de la detección y la orquestación de tareas Proactive Loop no es un simple comando, sino una arquitectura de automatización continua que combina varias funciones. Desencadenante + Objetivo + Habilidades + Flujo de trabajo dinámico + Modo automático + Repositorio, conector, navegador y herramientas de CI Las nuevas tareas se detectan, procesan, verifican y se informan de los resultados sin que una persona tenga que introducir comandos en tiempo real. Ejemplo: gestión automática de comentarios sobre errores Recepción de incidencias de GitHub o comentarios de Slack ↓ Clasificación por duplicados, prioridad y reproducibilidad ↓ Creación de pruebas de reproducibilidad ↓ Búsqueda de posibles soluciones ↓ Implementación de la solución elegida ↓ Un agente de revisión independiente busca contraejemplos ↓ Verificación de pruebas, compilación y seguridad ↓ Borrador de PR e informe de resultados Las responsabilidades de cada componente son las siguientes. Componente Responsabilidad Trigger o /schedule Determinar el momento de iniciar una nueva tarea /goal Definir qué se considera completado en esta ejecución Skill Estandarización de los procedimientos de reproducción, implementación, verificación y presentación de informes Flujo de trabajo dinámico Ejecución en paralelo de múltiples subagentes y ramificación condicional Modo automático Ejecución de llamadas a herramientas permitidas sin espera de autorización Política de permisos Establecer el alcance de lo prohibido, lo autorizado y lo permitido automáticamente Flujo de trabajo dinámico y árbol de trabajo El flujo de trabajo dinámico es una estructura en la que el tiempo de ejecución ejecuta un script de orquestación en JavaScript escrito por Claude. En una llamada a un subagente normal, Claude selecciona el siguiente agente en cada turno, pero en el flujo de trabajo, los bucles, el procesamiento en paralelo, las ramificaciones y el almacenamiento de resultados intermedios se trasladan al script. Script de flujo de trabajo ├─ Agente A: Análisis de requisitos ├─ Agente B: Diseño de pruebas ├─ Agente C: Búsqueda de opciones de implementación ├─ Agente D: Revisión de seguridad └─ Juez: Comparación basada en pruebas Dado que los resultados intermedios se guardan en variables del script y no en el contexto de la conversación principal, es posible organizar tareas a gran escala de forma más reproducible. La documentación actual especifica un límite de tiempo de ejecución de un máximo de 16 agentes simultáneos y 1.000 agentes por ejecución, aunque estas restricciones pueden cambiar durante la fase de vista previa del producto. Si es necesario probar varias opciones de implementación al mismo tiempo, se puede separar el espacio de trabajo mediante un «Git Worktree». repo/ worktree-solution-a/ worktree-solution-b/ worktree-solution-c/ Si cada agente trabaja en una rama y un directorio independientes, se pueden reducir los problemas derivados de la sobrescritura simultánea de los mismos archivos. El agente evaluador debe comparar las opciones basándose en el cumplimiento de los requisitos, los resultados de las pruebas, el riesgo de regresión, el alcance de los cambios, la complejidad, el rendimiento, la seguridad y la coherencia con la arquitectura existente. No siempre es mejor contar con más agentes Si solo se aumenta el número de agentes en tareas que no admiten paralelismo, se incrementan los costes y los retrasos. Además, si varios agentes comparten la misma suposición errónea, los errores pueden propagarse. Los casos en los que un flujo de trabajo dinámico resulta adecuado son los siguientes: Migraciones en las que se aplica la misma transformación a cientos de archivos Auditorías de seguridad y calidad de todo el código fuente Comparación de planes desde múltiples perspectivas independientes Investigaciones en las que es necesario dividir el procesamiento de muchos elementos y realizar verificaciones cruzadas Tareas en las que resulta difícil incluir todos los resultados intermedios en el contexto de un solo agente Para la corrección de pequeños errores, la refactorización de un solo archivo o la incorporación de pruebas sencillas, es mejor utilizar un bucle por turnos (Turn-based Loop) normal o /goal. 7. Sistema para mantener la calidad del código en el bucle La calidad de los resultados del bucle depende en gran medida no solo del modelo en sí, sino también del sistema de verificación que lo rodea. 7.1 Ordenar el código base Claude sigue fielmente los patrones del código existente. Si hay API obsoletas, implementaciones duplicadas, estructuras de pruebas poco claras, módulos gigantescos o reglas de gestión de excepciones incoherentes, Loop puede replicar rápidamente esos problemas. Los requisitos básicos son los siguientes: Formateador y lint Límites claros entre directorios y módulos Pruebas unitarias, de integración y de extremo a extremo (E2E) fiables Distinción entre las API en uso y las API obsoletas Normas de desarrollo específicas para cada proyecto Entornos de compilación y desarrollo reproducibles 7.2 Crear una «Definición de «hecho»» por tipo de cambio Tipo de cambio Verificación mínima API Pruebas de contrato, compatibilidad con versiones anteriores, actualización de esquemas y ejemplos de documentación Frontend Manipulación real del navegador, errores de consola, accesibilidad, pantalla responsiva Base de datos Migración (adelantada o revertida), ámbito de bloqueo, plan de ejecución Dependencias Compilación, pruebas de regresión clave, verificación de licencias y seguridad Infraestructura Diferencias entre planes, privilegios mínimos, reversión, comprobación de exposición de información confidencial Es preferible fijar estos criterios en Skills, Hooks, scripts y reglas de CI, en lugar de repetirlos extensamente en el Prompt cada vez. 7.3 Proporcionar documentación actualizada y versiones precisas Un bucle puede repetir varias veces suposiciones erróneas. Debe facilitarse el acceso a la versión exacta utilizada en el proyecto, la documentación oficial, la documentación interna de arquitectura, las especificaciones de la API, la guía de migración y los ejemplos aprobados. 7.4 Separar el agente de implementación del agente de revisión El agente de implementación ya se ve influido por el diseño y los razonamientos ya seleccionados. El agente de revisión, en un nuevo contexto, puede plantear las siguientes preguntas de forma más independiente: ¿Se han suavizado las pruebas para que se superen? ¿Se han modificado archivos que quedan fuera del alcance? ¿Se han violado los límites de seguridad? ¿Se han omitido las pruebas de rutas de fallo y de valores límite? ¿Se ha producido alguna regresión en las funcionalidades existentes? Es más eficaz redactar la indicación de revisión (Review Prompt) de la siguiente manera: «Busca contraejemplos partiendo de la hipótesis de que la implementación es errónea y adjunta pruebas de reproducción para cada observación», en lugar de «Resume los aspectos positivos». 7.5 Vincular los fallos individuales a la mejora del sistema Si se repite el mismo error, no basta con corregir solo ese resultado concreto. Para evitar que ese tipo de fallo vuelva a producirse, hay que modificar uno de los siguientes aspectos: Añadir pruebas de regresión Reforzar los procedimientos de verificación de habilidades Añadir reglas a CLAUDE.md Añadir reglas de hook o lint Añadir reglas de denegación de permisos Reforzar las condiciones de finalización del objetivo Complementar la lista de comprobación de revisión Una buena ingeniería de bucles no consiste en corregir un único fallo, sino en crear un sistema en el que sea difícil que vuelva a producirse ese tipo de fallo. 8. Gestión de tokens y costes El coste de un bucle puede aumentar considerablemente en comparación con el de un único prompt. Coste total ≈ Coste del turno del agente principal + Coste de evaluación del objetivo + Coste de los subagentes + Coste de repetición del flujo de trabajo + Coste del contexto para leer los resultados de las herramientas + Frecuencia de ejecución basada en el tiempo Aunque la facturación exacta varía en función del plan, el modelo y el proveedor, el principio que determina la estructura de costes es el mismo. Principios prácticos para reducir costes No utilices Loop para tareas pequeñas. Las erratas, los cambios de nombre y los errores de tipo en un solo archivo se gestionan en un único turno. Establece condiciones de éxito y límites estrictos (hard stop) al mismo tiempo. Ten en cuenta el éxito, el número máximo de turnos, el tiempo máximo, los fallos consecutivos y los errores de permisos. Prueba los flujos de trabajo a gran escala en un ámbito reducido. Verifica los costes y la calidad con 5 archivos, un directorio o algunas incidencias antes de ampliar la prueba. Las tareas deterministas se procesan mediante scripts. Para la sustitución de AST, la conversión a JSON, el formateo y la generación de formularios fijos, los scripts probados resultan más económicos y reproducibles. Ajusta el ciclo de sondeo a la frecuencia real de los cambios. Utiliza disparadores de eventos siempre que sea posible. Se observa el uso durante el proceso. Se comprueba el uso de habilidades, subagentes, MCP, turnos y tokens en /usage, /goal y /workflows. Si se repite el mismo error, no se siguen realizando reintentos. Se establece un límite de fallos consecutivos y se escala a una persona. El modelo y el esfuerzo son palancas diferentes El modelo modifica la capacidad de inferencia básica y el alcance de los problemas que se pueden resolver. El esfuerzo modifica el número de archivos que se leen, el número de herramientas que se utilizan, el alcance de la verificación y hasta qué punto se llevan a cabo las tareas de varias etapas. Si Claude ha comprobado todos los archivos y pruebas necesarios, pero sigue tomando decisiones erróneas, es posible que se necesite un modelo más potente. Por el contrario, si no ha leído algún archivo importante, se ha saltado alguna prueba o ha interrumpido la refactorización a mitad de camino, puede que sea más adecuado aumentar el esfuerzo. 9. Permisos y límites de seguridad El diseño más peligroso en el «Proactive Loop» es otorgar amplios permisos al agente y establecer condiciones de éxito y de interrupción poco estrictas. El modo automático reduce las solicitudes de permisos generales, pero el clasificador puede bloquear las llamadas a herramientas que sean difíciles de revertir, destructivas o que tengan como objetivo elementos fuera de los límites de confianza. Además, los permisos explícitos permissions.ask y permissions.deny tienen prioridad sobre el modo automático. Ejemplo de jerarquía de permisos Nivel Ejemplos Aceptación automática Lectura de código, pruebas, lint, compilación, análisis, creación de ramas claude/*, creación de borradores de PR Aprobación humana Incorporación a la rama por defecto, despliegue en producción, aplicación de migraciones de base de datos, envío de mensajes a clientes externos Siempre prohibido Push forzado, publicación de secretos, eliminación de datos operativos, elusión de permisos, eliminación de registros de auditoría Es más seguro establecer reglas permanentes de ask y deny que decir una sola vez en una conversación «No hagas un push». Esto se debe a que las reglas de la conversación pueden debilitarse debido a la compresión del contexto o a cambios en la sesión. Cloud Routine clona un nuevo repositorio en cada ejecución y funciona con los permisos de GitHub y del conector asociados. Se deben minimizar los siguientes ámbitos: Repositorios y ramas accesibles Dominios de red permitidos Conectores que se van a utilizar Variables de entorno y secretos Permisos de escritura en sistemas externos Alcance de la creación, el push y la fusión de PR El estado «Finalización normal» en el historial de ejecuciones de la rutina puede significar que la sesión ha finalizado sin errores de infraestructura, pero no garantiza que se haya alcanzado el objetivo del trabajo. Es necesario revisar por separado el transcrito, las pruebas y el diff generado. 10. Plantilla de diseño de bucles para proyectos de desarrollo El siguiente código YAML no es sintaxis real del código Claude, sino una plantilla para la revisión del diseño. trigger: type: manual | interval | schedule | github_event | api_event scope: repositories: - target-repository allowed_paths: - src/** - tests/** prohibited_paths: - production/** - secrets/** task: objective: objetivo que se desea modificar o procesar input: nueva incidencia, evento, archivo o estado verification: commands: - unit-test - integration-test - lint - build runtime_checks: - browser-interaction - console-errors - accessibility evidence: - command-output - exit-code - test-summary - screenshots success: condition: Estado de finalización que puede evaluarse como verdadero o falso stop: max_turns: 12 max_duration_minutes: 45 max_consecutive_failures: 3 stop_on_permission_error: true escalate_on_external_outage: true efectos secundarios: clave_de_idempotencia: id_del_evento-o-sha_de_la_confirmación permitir_envío_de_rama: claude/* requerir_intervención_humana_para_la_fusión: true requerir_intervención_humana_para_la_implementación: true revisión: agente_independiente: true revisión_adversaria: true observabilidad: informar_sobre_el_progreso: true informar_sobre_el_uso_de_tokens: true informar_sobre_los_archivos_modificados: true informar_sobre_los_fallos_restantes: true Los elementos más importantes son los cinco siguientes, más que la propia frase del prompt. Trigger Verifier Condición de éxito Parada forzada Límite de permisos 11. ¿Qué bucle se debe elegir? Situación Método recomendado Tareas que concluyen con una única modificación y verificación Turn-based Tareas que requieren varios intentos, pero cuyo estado de finalización es claro /goal Tareas que requieren esperar brevemente el estado externo de CI, PR o implementación /loop Tareas que deben ejecutarse de forma repetida incluso si se cierra el portátil /schedule Routine Tareas que requieren una respuesta inmediata a eventos o alertas de GitHub Rutina activada por eventos Tareas que requieren el procesamiento en paralelo y la verificación cruzada de cientos de elementos Flujo de trabajo dinámico Conversiones en las que las reglas de entrada y salida son totalmente deterministas Script o tarea de CI El orden de selección no debe basarse en «la funcionalidad más potente», sino en «la estructura de control más sencilla para alcanzar el objetivo». 12. Orden de implementación seguro Elige una tarea que suponga un cuello de botella y que requiera comprobaciones repetitivas por parte de una persona. En primer lugar, crea un procedimiento de verificación mediante una Skill, un Script o un trabajo de CI. Estabiliza la calidad de la verificación en el modo por turnos. Si el estado de finalización es claro, añade /goal. Utiliza /loop solo cuando sea necesario esperar un estado externo. Si se requiere una ejecución prolongada, trasládalo a una rutina /schedule. Amplía a flujos de trabajo dinámicos y bucles proactivos solo después de haber verificado la idempedancia, los permisos y los costes. 13. Malentendidos frecuentes Malentendido Interpretación correcta Un «Loop» es una ejecución infinita Es una estructura de repetición limitada que cuenta con condiciones de éxito y una parada forzada El informe de finalización del agente es una verificación Se necesitan la salida de comandos externos, el código de salida y los resultados de tiempo de ejecución «/goal» concede automáticamente todos los permisos Solo inicia automáticamente el siguiente turno; la política de permisos es independiente /loop es un programador de ejecución a largo plazo Se centra en las sesiones y tiene una caducidad de 7 días, además de restricciones en el entorno de ejecución Cuantos más agentes haya, mejores serán los resultados La paralelización solo tiene valor cuando las funciones, los puntos de vista y la verificación son diferentes Todas las tareas repetitivas deben realizarlas los LLM Para las partes deterministas, los scripts son más económicos y ofrecen mayor reproducibilidad Conclusión La ingeniería de bucles (Loop Engineering) no es una tecnología para mantener la IA en ejecución durante mucho tiempo, sino el diseño de un sistema de control que permite que la IA detecte por sí misma sus errores, los corrija dentro de los límites de coste y se detenga ante situaciones de riesgo. Los LLM destacan en la exploración, la inferencia, la implementación, el análisis de excepciones y la comparación de alternativas. El sistema debe encargarse del momento de ejecución, el alcance de los cambios, los métodos de verificación, los criterios de finalización, los límites de coste y los límites de autorización. Cuanto más clara sea esta distribución de funciones, más se acercará la automatización del código Claude a un sistema de desarrollo y operaciones reproducible y auditable, más allá de una simple herramienta de generación de código. FAQ Q. ⁣¿En qué se diferencia el bucle de INJX12⁣ Code de los bucles «for» y «while» habituales? A. Los bucles normales repiten de forma determinista las instrucciones definidas en el código. Claude Code: «Loop» es una estructura de control de agentes en la que el agente observa el código y el estado externo, deduce la siguiente acción, ejecuta la herramienta, verifica el resultado y, a continuación, vuelve a realizar la tarea según las condiciones de finalización. Q. ¿Cuándo es más adecuado el bucle por turnos? A. Es ideal para tareas breves y puntuales en las que el usuario puede revisar los resultados al instante. No obstante, si los procedimientos de verificación son repetitivos —como en el caso de la interfaz de usuario, la API o la base de datos—, es recomendable crear dichos procedimientos en forma de «Skill» o «Script» para que Claude los verifique por sí mismo siguiendo los mismos criterios. Q. ¿El modelo de evaluación `/goal` comprueba directamente los archivos y los resultados de las pruebas? A. No. El modelo de evaluación no recurre a herramientas ni lee los archivos directamente, sino que evalúa las condiciones del objetivo y las pruebas que se desprenden de la conversación. La tarea Claude debe dejar constancia clara en los resultados de los comandos de prueba, los códigos de salida, los archivos modificados y las causas del fallo. Q. ¿Qué debe incluir una buena condición `/goal`? A. Se necesita un estado de finalización medible, un comando o una herramienta que lo acredite, los límites de lo que se puede modificar y lo que está prohibido, así como «puntos de parada» (hard stop) como el número máximo de turnos, el tiempo máximo o el número de fallos consecutivos. Es mejor que «las pruebas y el lint den un código de salida 0 y no haya diferencias fuera de la ruta especificada» que una «refactorización limpia». Q. ¿Hay un número máximo de turnos o un límite de tiempo en `/goal`? A. El «Goal» continúa hasta que el modelo de evaluación determine que se ha alcanzado el éxito o hasta que el usuario lo interrumpa con el comando `/goal clear`. Para limitar el presupuesto de ejecución, es necesario incluir directamente en las condiciones del «Goal» cláusulas relativas a los turnos o al tiempo, como «interrumpir tras un máximo de 12 turnos o 45 minutos». Q. ¿Al utilizar `/goal`, también se conceden automáticamente los permisos de la herramienta? A. No. Aunque `/goal` inicia automáticamente el siguiente turno, las políticas de permisos para la escritura en archivos, el shell, Git y los conectores externos se mantienen sin cambios. Si necesitas una ejecución sin supervisión, considera el modo automático, pero debes controlar por separado las tareas de riesgo mediante reglas `ask` y `deny`. Q. ¿Cuál es la principal diferencia entre `/loop` y `/schedule`? A. `/loop` es un método de sondeo a corto plazo que se ejecuta de forma repetida en la sesión actual de Claude Code y en el ordenador. `/schedule` permite guardar el Prompt, el Repository, el Connector y el Trigger como una rutina en la nube (Cloud Routine) para que se ejecuten en la infraestructura de gestión de Anthropic, por lo que no es necesario tener una sesión abierta ni el portátil encendido. Q. ¿Sigue ejecutándose `/loop` cuando se apaga el ordenador? A. Por lo general, no se ejecuta de forma continua. `/loop` es una operación de ámbito de sesión y Claude Code debe estar en ejecución. Para la automatización a largo plazo, se debe utilizar un programador sostenible, como Cloud Routine, una tarea programada de escritorio o GitHub Actions. Q. ¿Por qué es mejor el desencadenador de eventos que el sondeo por tiempo? A. Esto se debe a que, al no producirse cambios, no se generan llamadas innecesarias al modelo y se puede ejecutar inmediatamente después de que se produzca un cambio real. En el caso de sistemas que pueden generar eventos —como fallos en la integración continua (CI), actualizaciones de PR o alertas—, resulta más ventajoso en términos de coste y latencia conectarlos mediante GitHub Trigger o la API de Routine. Q. ¿Por qué se incluyen los procedimientos de verificación en `SKILL.md` y no en `CLAUDE.md`? A. El archivo `CLAUDE.md` es ideal para reglas breves que se aplican en todo el proyecto, mientras que las «Skills» son adecuadas para agrupar los procedimientos y archivos de apoyo necesarios solo para tareas específicas. Si se separan las largas listas de comprobación en «Skills», estas solo se cargarán en las tareas relevantes y se podrán volver a ejecutar directamente. Q. ¿En qué se diferencia el flujo de trabajo dinámico de una llamada normal a un subagente? A. En el método Subagent convencional, Claude selecciona al siguiente trabajador en cada turno y los resultados se acumulan en el contexto. El flujo de trabajo dinámico permite organizar migraciones, auditorías y verificaciones cruzadas a gran escala de forma más reproducible, ya que un script de JavaScript gestiona la ejecución en paralelo, las ramificaciones, las iteraciones y los resultados intermedios. Q. ¿El uso de varios agentes mejora siempre la calidad? A. No. Si las funciones y los puntos de vista se solapan, se pueden repetir los mismos errores y los costes no harán más que aumentar. Para que los agentes paralelos aporten valor, es necesario separar las responsabilidades —como en el caso de la implementación, el diseño de pruebas, la revisión de seguridad, el análisis de regresión y el Judge— y exigir pruebas independientes para cada conclusión. Q. ¿Cómo se evitan las tareas duplicadas en un bucle basado en el tiempo o proactivo? A. Se deben almacenar claves de idempotencia, como el ID del evento, el SHA del commit y el ID del comentario de revisión, así como el estado final del procesamiento. Se debe incluir en la fase de verificación una regla que impida volver a procesar mensajes a los que ya se ha respondido, PR que ya se han creado o commits que ya se han procesado. Q. ¿Qué tarea es la más adecuada para automatizar en el primer bucle? A. Es recomendable optar por tareas que, aunque requieran comprobaciones repetidas, presenten pocos efectos secundarios peligrosos y cuyo estado de finalización se pueda medir con claridad. Por ejemplo, resulta seguro empezar por resumir las causas de los fallos de CI en las PR, detectar discrepancias entre la documentación y el código, y realizar las verificaciones establecidas de pruebas y lint, para luego ampliar gradualmente los permisos de corrección y publicación. Sources - Ingeniería de bucles: Introducción a los bucles | Claude por Anthropic: https://claude.com/blog/getting-started-with-loops - Amplía Claude con habilidades - Documentación del código de Claude: https://code.claude.com/docs/en/skills - Mantener Claude trabajando para alcanzar un objetivo - Documentación del código de Claude: https://code.claude.com/docs/en/goal - Ejecutar comandos según una programación - Claude Code Docs: https://code.claude.com/docs/en/scheduled-tasks - Automatizar el trabajo con rutinas - Claude Documentación del código: https://code.claude.com/docs/en/routines - Coordina subagentes a gran escala con flujos de trabajo dinámicos - Claude Documentación de código: https://code.claude.com/docs/en/workflows - Cómo elegir un modelo Claude y un nivel de esfuerzo en el código Claude | Claude por Anthropic: https://claude.com/blog/claude-model-and-effort-level-in-claude-code - Configurar el modo automático - Claude Documentación de código: https://code.claude.com/docs/en/auto-mode-config Images - Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste: https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp - Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos: https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp --- Category: Tutorial Source: https://injoys.com/es/articles/claude-code-loop-engineering-guide License: cc_by Translation-Status: reviewed