Deja de Escribir Prompts Manualmente. Cómo Convertir Agentes de IA en una Línea de Ensamblaje Autónoma
El responsable del desarrollo de Claude Code en Anthropic, Boris Cherni, alguna vez admitió que ya no escribe prompts manualmente. En su lugar, ejecuta bucles automáticos que forman tareas para Claude, lo lanzan y verifican el resultado por sí mismos. Escribir un prompt una vez no es un problema. Pero si alimentas las mismas instrucciones a un asistente de IA todos los días—ya sea verificando CI o clasificando errores—estás haciendo trabajo rutinario.
El desarrollador Kobus Greyling publicó un proyecto llamado loop-engineering en GitHub, que propone cambiar el enfoque. Deja de ser un operador de chat y conviértete en un diseñador de sistemas autónomos. El proyecto ha acumulado más de 10,000 estrellas, y hay algo genuino aquí para reflexionar.
De Sesiones Puntuales a Bucles Cerrados
El problema principal con las interacciones típicas con agentes de codificación como Claude Code, Grok o Cursor radica en el contexto. Abres un diálogo, explicas la estructura del proyecto, das una tarea y esperas el resultado. La sesión se cierra—el contexto se pierde. Al día siguiente, todo comienza de nuevo.
El concepto de Loop Engineering propone cerrar el proceso en un bucle infinito. El agente se ejecuta según una programación, lee el estado del repositorio desde un archivo especial, realiza trabajo en una rama aislada, ejecuta pruebas y actualiza estados.
flowchart LR
A[Schedule / Automation] --> B[Triage Skill]
B --> C[Read + Write STATE / Memory]
C --> D[Isolated Worktree]
D --> E[Implementer Sub-agent]
E --> F[Verifier Sub-agent]
F --> G[MCP / Git / Tickets]
No necesitas escribir frameworks complejos en Python para esto. La arquitectura del bucle se construye a partir de varios elementos comprensibles:
- Ejecución programada vía cron, GitHub Actions o systemd.
- Estado del proyecto en un archivo Markdown regular
STATE.mdque reside en la raíz del repositorio y persiste ante cualquier reinicio del agente. - Ramas de trabajo Git aisladas para que los cambios del agente no rompan la copia de trabajo actual.
- Separación de agentes en ejecutor y verificador (Maker / Checker). Uno escribe código, el segundo ejecuta pruebas y verifica linters.
Qué Hay Dentro del Repositorio
El proyecto consiste en un conjunto de utilidades CLI publicadas en npm y un catálogo de escenarios listos para usar. Todas las herramientas están combinadas bajo un paquete único, así que no es necesario clonar nada.
Puedes desplegar una plantilla a un proyecto existente con un comando:
npx @cobusgreyling/loop init . --pattern daily-triage --tool grok
Después de la inicialización, la herramienta crea archivos de habilidades, estructura de almacenamiento de estado y genera el índice de preparación del proyecto—el Loop Ready score.
Para verificar la salud del sistema resultante, usa el doctor:
npx @cobusgreyling/loop doctor .
Este comando encuentra problemas de configuración y genera tres pasos principales para mejorar. Por ejemplo, sugerirá agregar límites de presupuesto de tokens o configurar rutas prohibidas para edición.
El conjunto de herramientas también incluye utilidades loop-cost para estimar costos de tokens, loop-sync para encontrar discrepancias entre la descripción del bucle y el archivo de estado, y loop-worktree para crear ramas separadas de manera segura para cada intento de corrección.
Siete Plantillas Listas para Usar
El repositorio contiene plantillas para tareas comunes de desarrollo.
Cada patrón se describe con un desglose de costos de tokens y un modo de implementación recomendado:
- Triage Diario. Una vez al día, escanea el repositorio, recopila issues y actualiza
STATE.md. - PR Babysitter. Monitorea pull requests abiertos, verifica estados de pruebas y deja sugerencias para los autores.
- CI Sweeper. Intercepta builds de CI fallidos e intenta corregir pruebas fallidas en una rama separada.
- Dependency Sweeper. Actualiza bibliotecas dependientes y verifica que el proyecto compile.
- Changelog Drafter. Recopila un borrador de changelog antes de un nuevo release.
- Post-Merge Cleanup. Elimina ramas obsoletas y archivos temporales después de un merge.
- Issue Triage. Revisa nuevos envíos al tracker y sugiere labels o respuestas iniciales.
El autor recomienda implementar bucles de manera incremental. Primero, ejecuta el agente en modo solo lectura (L1), donde solo genera reportes. Cuando estés seguro de la precisión de sus conclusiones, puedes pasar al modo de confirmación (L2), y solo entonces delegar rutinas menores a autonomía completa (L3).
El Lado Oscuro de la Autonomía
Kobus Greyling desglosa honestamente los riesgos de los agentes autónomos. Si lanzas un bucle con sub-agentes sin restricciones, tu factura de API de LLM será sorprendentemente desagradable. Las solicitudes repetidas en un bucle infinito pueden quemar cientos de dólares en un par de horas.
El segundo riesgo se llama deuda de comprensión. Si el agente escribe parches por sí mismo, ejecuta pruebas por sí mismo y fusiona código en main por sí mismo, el equipo pierde rápidamente el control sobre la arquitectura. El proyecto se convierte en una caja negra.
Además, toda la verificación sigue siendo tu responsabilidad. Al agente le falta sentido común e intentará cerrar una prueba por cualquier medio necesario, incluso si eso significa eliminar la prueba en sí.
Quién Debería Probarlo
El repositorio será útil para equipos que ya usan activamente herramientas de IA desde línea de comandos como Claude Code o Grok y buscan una forma de integrarlas sistemáticamente en CI/CD.
Comienza pequeño. Instala loop init, elige un escenario daily-triage y deja que el agente pase una semana solo escribiendo reportes diarios en STATE.md. Esta es una forma segura de entender qué tan bien se adapta el concepto a tu proyecto sin arriesgar la estabilidad de tu codebase.
Proyectos relacionados