Claude Guía de Code Loop Engineering: 4 tipos de bucles y diseño seguro de la automatización

⁣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.

1. ¿Qué inicia la tarea?
2. ¿Qué finaliza la tarea?
3. ¿Qué función de Claude Code controla la repetición?
4. ¿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

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

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:

1. Condiciones de éxito medibles: superación de pruebas, éxito de la compilación, vaciado de la cola, consecución del umbral de puntuación
2. Método de verificación: especificar con qué comando o herramienta se demostrará el éxito
3. Restricciones del alcance de las modificaciones: directorios modificables, archivos prohibidos, efectos secundarios permitidos
4. 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

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.

/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

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

1. Idéntica: aunque se reciba el mismo evento varias veces, no deben producirse comentarios, PR ni implementaciones duplicados.
2. 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.
3. 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.
4. Ámbito de escritura: deben limitarse los efectos secundarios, como permitir comentarios, prohibir la fusión o permitir el push únicamente en la rama claude/*.
5. 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.

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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. Ajusta el ciclo de sondeo a la frecuencia real de los cambios. Utiliza disparadores de eventos siempre que sea posible.
6. Se observa el uso durante el proceso. Se comprueba el uso de habilidades, subagentes, MCP, turnos y tokens en /usage, /goal y /workflows.
7. 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

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?

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

1. Elige una tarea que suponga un cuello de botella y que requiera comprobaciones repetitivas por parte de una persona.
2. En primer lugar, crea un procedimiento de verificación mediante una Skill, un Script o un trabajo de CI.
3. Estabiliza la calidad de la verificación en el modo por turnos.
4. Si el estado de finalización es claro, añade /goal.
5. Utiliza /loop solo cuando sea necesario esperar un estado externo.
6. Si se requiere una ejecución prolongada, trasládalo a una rutina /schedule.
7. 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

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.