Dejé que Claude Programara por 4 Horas. Construyó Algo que Nadie Pidió.

10 min read

Abro la terminal. 4 horas. El dashboard está funcionando en el servidor privado, la capa de API sigue siendo pública. Más o menos lo que pedí. 😬

También en el diff: 2 componentes extraídos y movidos a un archivo que nadie le pidió que abriera, una actualización de versión de runtime que cambió silenciosamente el pipeline de build en la nube, y un commit pusheado a main antes de confirmar que el deployment era estable.

TLDR: En una conversación, la ambigüedad produce una pregunta de aclaración. En un bucle autónomo, produce horas de trabajo en la dirección equivocada. Este artículo cubre las 3 formas en que fallan los briefs de bucle y las líneas que previenen cada una antes de que desaparezcas.

Trabajador de oficina agobiado mirando salida infinita de terminal mientras un superhéroe con capa señala casualmente un botón de parar; langosta robótica surfeando por el escritorio.
Cuando tu asistente de IA decide reescribir toda tu base de código sin que se lo pidas.

Nada de eso es catastrófico. La sesión funcionó. Pero las 3 horas de debug que quemaron la mayor parte del compute vinieron de una restricción que faltaba en mi primer mensaje. La tarea: mover el dashboard de gestión de pedidos del hosting público a un servidor privado, solo interno. Lo que olvidé incluir: la capa de API tenía que seguir siendo públicamente accesible. Los partners externos la llaman. Moverla habría roto todo downstream.

Claude preguntó, yo respondí, se ajustó. Pero para entonces la arquitectura ya estaba diseñada en la dirección equivocada, y el conflicto de build con el integration handler que siguió tomó más de 200 llamadas de herramientas para desenredar. En el post-mortem, Claude nombró la causa raíz: "Si el primer mensaje hubiera dicho 'el dashboard va interno pero la capa de API se queda pública,' habría anticipado el conflicto de build. Esa divergencia no estaba en el brief."

~600k tokens. El brief fueron 6 mensajes enviados en 10 minutos mientras tenía otra cosa que publicar.

Por Qué los Bucles Fallan Diferente a los Prompts

Todos en la ola actual de hype de bucles están hablando de /goal, sub-agentes, flags de max-turns, costo de tokens. Nadie está hablando del brief.

En una conversación, la ambigüedad produce una pregunta de aclaración. Claude dice "¿quisiste decir X o Y?" y corriges en 10 segundos. En un bucle autónomo, esa misma ambigüedad produce horas de trabajo en la dirección equivocada. El modelo no se detiene cuando encuentra una restricción poco clara. Resuelve la ambigüedad por sí mismo y sigue adelante, que es precisamente la funcionalidad, hasta que se convierte en el bug.

Una prueba de LogRocket de Claude Code con Ralph hizo esto concreto. Brief: "Construye una herramienta CLI de estadísticas de GitHub. Hazla buena." El bucle corrió 5 minutos 41 segundos y entregó una herramienta funcional con obtención de perfiles de usuario, análisis de desglose de lenguajes y verificación de rate-limit. Nada de eso fue solicitado. La misma tarea con una condición de salida explícita y un cerco de alcance: ejecución limpia, sin expansión de alcance, alineada con los criterios definidos en cada punto. La única diferencia fue el brief.

Un desglose reciente en Medium de la mecánica de /goal nombró este patrón precisamente. Le das a Claude una tarea larga de refactoring, corre docenas de pasos, todo se ejecuta. Luego miras lo que construyó. Técnicamente correcto. Solo que no era lo que querías. "Se desvió." La desviación no viene del modelo. Viene del brief.

El error que seguía cometiendo era asumir que mis habilidades de prompting se transferían automáticamente a sesiones de bucle. La confianza de que lo hacen es la parte peligrosa, porque las 2 habilidades se sienten idénticas desde adentro. Es básicamente el "funciona en mi máquina" del tooling de agentes: cada sesión supervisada se entrega limpiamente, tienes el historial de commits para probarlo, y luego disparas un brief de bucle con la misma confianza y te alejas.

El prompting es sobre dar a Claude suficiente contexto para navegar los próximos intercambios mientras estás mirando, lo suficientemente cerca para corregir el curso cuando se dirige a algún lugar equivocado. El briefing de bucle es sobre dar a Claude suficientes restricciones para navegar 50 u 80 pasos sin que estés presente en absoluto, donde cada ambigüedad se resuelve por la mejor suposición del modelo en lugar de tu intención real, y esas suposiciones se componen a través de docenas de llamadas de herramientas en algo que puede verse completamente correcto en la superficie mientras es estructuralmente incorrecto para tus necesidades reales. La vaguedad que es tolerable en un prompt (el tipo que resuelves en 1 mensaje de seguimiento) es fatal en un brief de bucle donde no hay mensaje de seguimiento, y la sesión ya quemó 400k tokens para cuando miras lo que construyó.

3 Modos de Desviación, 3 Líneas Que Los Arreglan

TITLE "The Loop Brief Stack" + subtitle "3 components · 3 failure modes · before you hit Enter". Metaphor: engineering control panel blueprint with 3 clearly labeled switches, each with OFF and ON position. Style: engineer blueprint aesthetic, white technical lines on dark navy background, precise annotations, blueprint-style font. Palette: navy #0A1628, blueprint-white #E8F0FF, yellow #FFD600, red #FF4444, green #00C853, black #111111. Content: 3 switch panels labeled SCOPE FENCE (left), EXIT CONDITION (center), ESCALATION CRITERIA (right). OFF state shows red indicator and failure mode label (scope creep, drift, silent loop). ON state shows green indicator and fix label (locked scope, binary check, auto-escalate). Highlight: EXIT CONDITION panel center-positioned and slightly enlarged, yellow border glow. Legend: sticky note bottom-left corner "OFF = loop decides / ON = brief decides". Footer: copyright rentierdigital.xyz. NOT flat corporate vector, NOT minimalist tech startup aesthetic, NOT stock infographic.
El Stack de Brief de Bucle: Tres Componentes de Control Críticos

Hay 3 formas distintas en que fallan los briefs de bucle. Cada una mapea a un componente faltante.

Expansión de alcance: cerco de alcance faltante

Claude interpreta instrucciones cualitativas ("bueno", "limpio", "completo") como una invitación a expandir. No está alucinando, está optimizando. El problema es que su definición de "bueno" incluye decisiones que no autorizaste.

En mi sesión: 2 componentes refactorizados y reubicados durante la fase de debug, no porque estaba en el brief, sino porque la estructura de archivos estaba causando un error de exportación de build y arreglarlo era adyacente al problema real. El modelo resolvió un problema real. Uno que no le había pedido que mirara.

La solución es un cerco de alcance: una lista explícita de lo que no se toca, tan específica como lo que sí se toca.

Malo: "Refactoriza el módulo de auth."

Bueno: "Refactoriza el módulo de auth. No agregues nuevas funciones. No modifiques tests. No toques ningún archivo fuera de /src/auth."

La restricción negativa hace tanto trabajo como la positiva. Profundicé en construir una capa de enforcement CLI para agentes autónomos en un artículo anterior, y el patrón de verificación mapea directamente al control de alcance de bucle.

Desviación: condición de salida ausente

La ejecución corre limpia, más de 30 pasos, sin errores. Pero en algún lugar alrededor del paso 12 el bucle toma una bifurcación que no pretendías, y para cuando entrega, tienes una solución técnicamente correcta al problema equivocado. En mi sesión, la bifurcación de arquitectura (la capa de API se queda pública) se resolvió en conversación durante los primeros 15 minutos. Pero ninguna condición de salida codificó esa restricción explícitamente, así que no había verdad fundamental para que un verificador independiente verificara.

Causa raíz: sin condición de salida, o una demasiado vaga para atrapar la bifurcación equivocada.

La guía de bucle agéntico de MindStudio lo pone en 1 oración: "Escribe la condición de éxito antes de escribir el prompt. Si no puedes definirla en 1 oración, reduce el alcance de la tarea." Su regla complementaria: siempre pasa --max-turns en tareas autónomas como respaldo mecánico cuando la condición de salida no se alcanza limpiamente.

Malo: "Cuando se vea bien."

Bueno: "Cuando todos los 47 tests existentes pasen, el dashboard responda en el puerto 3013 en la red interna, y ningún archivo fuera de /src/dashboard haya sido modificado."

Obviamente, "cuando se vea bien" no puede ser verificado por nada que no seas tú. Un agente corriendo en paralelo no tiene acceso a tu juicio estético. La condición de salida tiene que ser binaria y verificable sin contexto.

Tal vez esté equivocado en esto, pero creo que la condición de salida es más difícil de escribir que el cerco de alcance. Te fuerza a comprometerte con lo que "terminado" realmente significa antes de haber empezado. En mi experiencia es la pieza que se omite primero, y la que más cuesta cuando falta.

Bucle silencioso: sin criterios de escalación

Cerco de alcance definido, condición de salida definida. Aún es posible quemar tu presupuesto silenciosamente cuando el bucle llega a un estado que no puede resolver y sigue intentando. Un builder en X después de 6 semanas de bucles de producción: "El poder es real pero también lo es el costo cuando un agente entra silenciosamente en un mal estado de bucle... hasta que llega tu factura de API."

En mi sesión esto se mostró como un proceso zombie sirviendo un build viejo, produciendo un tramo de corridas de test falso-negativas antes de que Claude correctamente reportara un bloqueador. El zombie no estaba respondiendo a pkill. Energía HAL 9000: reconocimiento calmado de cada consulta de diagnóstico, resistencia activa al shutdown. Excepto que era un socket Unix y no una IA homicida, lo que de alguna manera lo hizo más difícil de arreglar. Con una regla de escalación en el brief, se detiene y reporta en lugar de perseverar.

Malo: nada. Claude se las arregla.

Bueno: "Si el dashboard falla en cargar después de 3 intentos de deploy, detente inmediatamente. Reporta el último error y los últimos 3 archivos modificados. No intentes un 4to deploy."

Esa última línea importa. Sin ella, Claude intenta de nuevo, toca más archivos fuera del cerco de alcance para hacerlo, y regresas a un codebase que se ha desviado más de donde lo dejaste.

La Prueba del Otro Cuarto

Antes de lanzar cualquier bucle autónomo, 1 pregunta: ¿podría un agente que nunca ha leído mi código verificar que esta tarea está terminada?

Si no, la condición de salida es demasiado vaga.

Lance Martin del hilo de Anthropic sobre diseño de bucles hizo el principio explícito: el calificador tiene que ser independiente del ejecutor. Claude no puede calificar su propio trabajo. El sub-agente verificador recibe la condición de salida y devuelve un veredicto binario. Sin acceso a contexto, intención o historial de conversación. Solo la condición y el estado actual. Pasa o falla. Esto es alrededor de lo que está construido /goal: un calificador separado verificando si la condición de éxito definida se ha cumplido, sin leer tu intención en ella. La condición de salida es la única interfaz entre tu intención y el verificador. Si es ambigua, el verificador no puede ayudarte. (El equivalente RPG: pedirle al guerrero que evalúe su propia limpieza de mazmorra. Siempre dirá que sí.)

Vale la pena hacer una distinción del enfoque de contratos de prompt para sesiones supervisadas de Claude Code, donde un brief preciso estructura una sesión que estás mirando y puedes dirigir en tiempo real. Los briefs de bucle son para sesiones donde no estarás ahí para dirigir. El hábito del contrato viene primero. El brief de bucle lo extiende a sesiones autónomas con una restricción diferente: no se permite dirigir.

Desvío breve que no tiene nada que ver con nada de esto: he estado corriendo el mismo prompt de post-mortem con colaboradores humanos por unos meses, preguntándoles "¿qué en mi brief, si fuera diferente, habría cambiado tu ejecución?" Las respuestas son consistentemente más útiles que cualquier retro que haya corrido. Las personas no reportan naturalmente la falla de handoff. Describen lo que construyeron. Hacerlos nombrar la restricción faltante produce algo cercano a una auditoría real.

Brief Primero, Bucle Segundo

El costo de la sesión: ~600k tokens, una actualización de versión de runtime que cambió el entorno de build en la nube sin mi revisión, 2 componentes movidos en un codebase que no estaba planeando abrir, un commit en main antes de que el deployment fuera estable, y 3 horas de debug por una restricción que había dejado fuera del primer mensaje. Nada de eso es una falla del modelo. Todo era predecible desde el brief. El bucle corrió bien. El brief no, y esa brecha es lo que quemó las 3 horas.

Las 3 piezas que faltaban: un cerco de alcance listando lo que no se toca, una condición de salida verificable por un agente independiente, y una regla de escalación que detiene el bucle antes de que se queme a través de un mal estado. No en CLAUDE.md, que maneja comportamiento persistente a través de sesiones. En el brief mismo, antes de cada corrida autónoma.

Un builder en X después de quemar una sesión completa: "Muchos tokens... el resultado fue basura total. Tuve que empezar de nuevo." Eso es lo que cuesta un brief ausente a escala.

Si estás en la etapa donde los bucles corren pero no siempre aterrizan, Vibe Coding, For Real (Amazon Kindle, gratis en Kindle Unlimited) cubre la base: el método para ir de "corre" a "se entrega confiablemente."

Las 4 horas construyeron más o menos lo que pedí, más algunas cosas que no, y quemaron 3 horas de compute en una restricción que no estaba en el primer mensaje. En el post-mortem, Claude me dijo exactamente qué oración lo habría cambiado.

Tengo esa oración ahora. La escribiré primero la próxima vez.

Ve a escribir la condición de salida antes del prompt.

Fuentes

Este post puede contener enlaces de afiliados. Si los clicas, podría ganar una pequeña comisión (no te cuesta nada, y me ayuda a seguir enviando artículos de calidad todos los días para tu placer de lectura).