El Jefe de Claude Code Dejó de Hacer Prompts. Eso No Es un Consejo. Es una Cronología.

Ya no deberías estar haciendo prompts a agentes de código. Deberías estar diseñando bucles que hagan los prompts por ti.

Eso me partió de risa cuando lo vi. Peter Steinberger soltó esas 12 palabras en X el 7 de junio, y 6.5 millones de personas las leyeron en 24 horas. Y 5 días antes, Boris Cherny, el jefe de Claude Code, había dicho exactamente lo mismo en el escenario de un evento de WorkOS. Casi palabra por palabra.

Me dio risa porque llevaba meses haciendo esto sin tener un nombre para ello.

Yo Lo Llamaba "Modo Resuélvelo Tú"

El flujo de trabajo era simple, tal vez vergonzosamente simple. Establecía un objetivo en /goal, dejaba un CLAUDE.md con las reglas del proyecto, le daba a Claude Code el contexto del repo, y me iba. Volvía 20 minutos después, a veces 2 horas. O había una funcionalidad que funcionaba o había un desastre que necesitaba arreglo. Ambos resultados hacían avanzar el proyecto.

No hacía esto por ninguna convicción de principios. Simplemente pasó cuando dejé de mirar el stream de salida y empecé a tratar a Claude Code como un dev junior al que podía delegar. Establecer el objetivo, darle el contexto, e irme.

Sin etiqueta para nada de esto.

Luego Steinberger posteó, y la mitad de mi feed asentía mientras la otra mitad discutía si esto era realmente nuevo o solo prompting con pasos extra. Y el clip de Cherny de 5 días antes empezó a circular. "Ya no le hago prompts a Claude. Tengo bucles corriendo que le hacen prompts a Claude y averiguan qué hacer. Mi trabajo es escribir bucles."

Reconocimiento, no descubrimiento. Ya estaba haciendo una versión de esto. Solo que ahora tenía nombre.

Ese nombramiento importa más de lo que parece a primera vista. Sin un término para una práctica, no puedes comparar notas sobre ella, no puedes mejorar deliberadamente el patrón, y no puedes saber si lo estás haciendo bien o mal. "Modo resuélvelo tú" funcionaba bien como abreviación personal. "Ingeniería de bucles" es algo alrededor de lo cual puedes construir una metodología. El concepto no cambió entre el 2 y el 7 de junio. Lo que cambió es que ahora todos en la misma conversación usan la misma palabra, y las personas que aún no lo hacían ahora saben lo que se están perdiendo.

¿En Qué Peldaño Estás?

Lo que Cherny describió en WorkOS Acquired Unplugged el 2 de junio se desglosa en 3 etapas de evolución en cómo los desarrolladores trabajan con un agente de código.

Peldaño 1: usas Claude como autocompletado. Más inteligente que Copilot, pero sigues escribiendo código, revisando cada línea, sosteniendo la herramienta. El agente asiste. Tú diriges cada paso.

Peldaño 2: estás haciendo prompts a 5 o 10 Claudes en paralelo. Delegando tareas, revisando salidas, enrutando entre ellos manualmente. Sigues en el bucle, solo que eres un controlador de tráfico más ocupado en lugar de un conductor. Mucha gente que piensa que es "avanzada con IA" está aquí y asume que está en el peldaño 3.

Peldaño 3: no estás en el bucle para nada. Construiste el sistema que ejecuta el bucle por ti. Claude no está esperando tu próximo mensaje. Está ejecutando contra condiciones, puertas de verificación, y lógica de reintentos que definiste una vez y que ahora corre sin ti. Tu trabajo cambió de "escribir el prompt" a "diseñar qué pasa cuando el agente falla, tiene éxito, o se topa con algo que no anticipaste."

La diferencia entre el peldaño 2 y el 3 no es sobre habilidad en prompting. Es arquitectónica. No llegas al peldaño 3 haciendo mejores prompts. Llegas ahí dejando de hacer prompts y codificando la lógica en algo que corre por sí solo. Piénsalo como el problema de tower defense: deja de defender cada posición manualmente y empieza a colocar estructuras que se mantengan sin ti. El prompting es combate directo. La ingeniería de bucles es construir tus torretas antes de dejar la base.

La Brecha Ahora Es Legible

El post del 7 de junio no fue un reporte de tendencias. Fue una medición.

Cuando los mejores practicantes en un campo anuncian públicamente un cambio en su propia práctica, la brecha entre las personas que ya lo hacen y todos los demás pasa de invisible a visible. Eso fue lo que pasó. La práctica había estado corriendo por meses. Lo que cambió es que el marcador se volvió público.

El proyecto AutoResearch de Karpathy es la prueba concreta más clara registrada. Está ejecutando 50 experimentos de ML durante la noche en una sola GPU. El agente modifica el código de entrenamiento, lo ejecuta, lee los resultados, itera, sin decisiones humanas en el bucle. Acuñó "Era Loopy de IA" exactamente para esto, en un episodio del podcast No Priors que alcanzó 875K vistas contra un promedio del canal de alrededor de 8,500. Eso es un outlier de 100x en un pod de IA de nivel investigación. El apetito por entender esto ya no es teórico.

El número de Cherny es más directo: 100% de su código personal durante los 30 días antes de diciembre 2025 fue escrito por rutinas que había configurado, no por él haciendo prompts a Claude directamente. Y reportes de la industria de junio 2026 ponen a Claude Code cerca del 4% de todos los commits públicos en GitHub. 4% de todo el grafo público de GitHub es una huella masiva, y no está pasando a través de sesiones manuales de prompting una por una. Esos son bucles corriendo. A este punto, ejecutar prompts individuales para enviar código de producción es el "funciona en mi máquina" del desarrollo agéntico.

La razón por la que el timing importa más que el concepto es la lógica de composición, y esta es la parte que la mayoría de los hilos explicativos se saltan completamente. Un desarrollador que hace prompts manualmente mejora en prompting, con iteraciones más rápidas y resultados más dirigidos con el tiempo. Es mejora lineal en una curva de esfuerzo lineal, y es genuinamente valioso. Un desarrollador que codifica lógica de bucles está operando en un modelo estructuralmente diferente. Cada bucle que diseñan corre sin ellos. Cada mejora a ese bucle se aplica a cada ejecución futura automáticamente. Una trayectoria mejora el trabajo que ya hacen. La otra construye un sistema que maneja esa categoría mientras diseñan el siguiente bucle. Estas 2 trayectorias se ven casi idénticas al inicio. No puedes distinguirlas en la semana 1. El diferencial se vuelve visible a lo largo de semanas, se compone en la dirección de la persona que construyó el bucle, y no es recuperable haciendo prompts más rápido. Eso es exactamente lo que el momento del 7 de junio hizo legible: el marcador se volvió público, y ahora puedes más o menos saber en qué trayectoria estás solo mirando tu salida del último mes.

El Bucle Que No Nombraste

Algo que noté cuando el post de Steinberger empezó a circular: muchos desarrolladores asintiendo en reconocimiento no tenían idea de que ya estaban en el peldaño 3 para algunas tareas.

/goal ya es un bucle cerrado. Defines una condición de parada. Claude itera hasta que se cumple o se topa con un error duro. No estás tomando decisiones entre iteraciones. La funcionalidad se envió en Claude Code v2.1.139 en mayo 2026, y los desarrolladores que lo descubrieron temprano, que establecían el objetivo, se iban, y volvían a resultados técnicamente ya estaban haciendo ingeniería de bucles. Yo estaba ejecutando esto antes de que /goal existiera, solo usando sesiones largas con contexto detallado y esperando que Claude se mantuviera en la tarea. Solo que no lo había nombrado.

Las 3 cosas que separan "usé /goal y me fui" de un bucle de producción real: un archivo de habilidades que codifica las reglas de calidad, un paso de verificación que revisa la salida contra esas reglas, y un agente de revisión que ve el resultado fresco antes de que algo se envíe. Podrías ya tener 1 de ellos sin saber que los otros 2 existen. Muchos desarrolladores tienen un CLAUDE.md. No muchos lo han conectado a una capa de verificación. Y aún menos han agregado el agente de revisión, que es donde el bucle atrapa las cosas que el agente de construcción racionalizó como aceptables.

La anatomía completa, como Anthropic demuestra en su video de verificación: un SKILL.md que codifica los no-negociables de tu proyecto, un paso de verificación del navegador que revisa la salida renderizada contra esas reglas, y un segundo agente que revisa antes de que algo se fusione. El CLAUDE.md que ya escribiste es la base, /goal corre contra él, y el agente de revisión controla la salida antes de que se envíe. Conecta esos 3 y tienes un bucle que corre sin ti en la habitación.

Para cualquiera que ya haya hecho el movimiento de vibe coding a codificar lógica de proyecto en prompts, el bucle es la siguiente capa de la misma arquitectura. El instinto de hacer explícitas las reglas implícitas del proyecto y dejar de evaluar la salida a ojo después del hecho. El bucle solo ejecuta esa lógica en modo autónomo.

Nota al margen que apenas conecta pero la pongo aquí de todos modos. Cuando aprendí a programar en los 90s, teníamos un Bull DPS 7000 compartido en la escuela. Mainframe viejo. 1 slot de compilación a la vez, primero en llegar, primero en ser servido. Lo que descubrí fue escribir un script de shell tonto que sondeaba la cola del compilador cada 15 segundos y reenviaba mi trabajo al instante que se abría un slot. Mi código siempre se compilaba. Mis compañeros estaban refrescando manualmente. Les admití esto mucho después. Perdón chicos. No tan perdón, honestamente.

El instinto de codificar el reintento en lugar de hacerlo tú mismo a mano tiene 30 años. El branding es nuevo.

Tu Primer Bucle No Necesita Una Flota

El peldaño 3 no requiere 100 agentes y una capa de orquestación. Esa es la versión que Karpathy ejecuta para experimentos de ML nocturnos. Tu primer bucle es más simple, y probablemente puedes empezarlo hoy.

El bucle de producción mínimo:

/goal "Implementar la funcionalidad de filtrado de productos de la especificación. Terminado cuando la suite de pruebas pase y no haya errores de TypeScript."

Eso ya es peldaño 3 para esa tarea. Claude corre hasta que la condición se cumple o se topa con un error que no puede resolver. No estás en el medio. La clave es la palabra "cuando" en el objetivo, porque la condición de parada tiene que ser algo que el agente pueda verificar automáticamente, no algo que tengas que mirar y juzgar después.

Un bucle sin una capa de verificación es solo adivinanza automatizada. La mejora que lo hace usable en producción:

Paso 2. Agrega un SKILL.md con los no-negociables de tu proyecto: tus reglas reales, para tu proyecto real, escritas de la manera que briefearías a un nuevo dev el día 1. Las convenciones que enforces, los casos edge que siempre regresan, las cosas que atraparías en code review 3 días después si nadie las escribiera. Mientras más específica la regla, más se comporta el bucle como alguien que realmente leyó tus docs antes de empezar.

Paso 3. Agrega un paso de verificación del navegador. Claude en Chrome o el Chrome DevTools MCP revisa la salida renderizada contra tus criterios de calidad: layout shifts, Core Web Vitals, regresiones visuales. Cosas que no aparecen en suites de pruebas pero sí aparecen en producción. La demo de Anthropic muestra un layout shift atrapado automáticamente, fuera del alcance de la tarea original, porque Core Web Vitals ya estaban en el SKILL.md. Eso es el bucle haciendo trabajo que no pediste explícitamente, porque codificaste cómo se ve "bueno" por adelantado.

Paso 4. Agrega un agente /code-review como segunda pasada. Este agente ve la salida fresca, sin la historia de cómo se construyó. Atrapa las decisiones racionalizadas que el agente de construcción se pasó por alto, lo cual hará, porque el agente de construcción ha estado mirando el mismo contexto durante toda la ejecución.

Empieza con los pasos 1 y 2 si quieres ejecutar algo hoy. Agrega 3 y 4 cuando el bucle base esté estable.

Creo que el paso que tropieza a la mayoría de la gente, y tal vez esté equivocado en esto pero coincide con cada falla de bucle que he visto, es la condición de parada. Específicamente: establecer una que no puede ser verificada automáticamente. "Hacer que la UI se sienta pulida" no es una condición de parada. Es una oración. "No layout shift arriba de 0.1 CLS" es una condición de parada. Punto de guardado antes de la puerta del jefe, no después. Establece la puerta antes de que el bucle empiece, o estarás corriendo toda la mazmorra otra vez. La puerta tiene que ser diseñada antes de empezar, no revisada cuando esté hecho.

Un bucle sin una puerta de verificación no ahorra tiempo. Automatiza estar equivocado.

Antes de que cualquiera de esto funcione consistentemente, el andamio debajo tiene que ser sólido. Spec vaga, sin cobertura de pruebas, dependencias que heredaste pero no entiendes realmente (el bucle correrá contra esas con confianza y enviará basura). El Blueprint de 8 pasos en Vibe Coding, For Real fue construido exactamente para esto: ir de demo roto a app desplegada antes de entregar la iteración a un sistema autónomo. El bucle necesita algo real contra lo cual correr.

Y cuando estés listo para extender el bucle a sistemas externos (disparar un deploy, ejecutar un service check, llamar una API), construir esa capa con CLIs en lugar de conectores MCP cambia qué tan debuggeable y confiable termina siendo esa extensión en producción.

Cuando El Marcador Se Volvió Público

No sabía que "modo resuélvelo tú" tenía nombre. No sabía que me ponía en el peldaño 3 para algunas tareas. No sabía que la era Bull DPS 7000 y la era Boris Cherny estaban ejecutando el mismo instinto con 30 años de diferencia.

Lo que el momento del 7 de junio realmente fue: no el inicio de la ingeniería de bucles para las personas que ya lo hacían. El momento en que la brecha entre practicantes y todos los demás se volvió visible para ambos lados. Cherny había estado ejecutando 100% de su código a través de rutinas desde diciembre 2025. Karpathy había estado lanzando experimentos nocturnos por meses. La brecha ya estaba ahí. El post de Steinberger solo volteó el marcador público.

Las personas que ya lo hacían no aprendieron nada nuevo el 7 de junio. Las personas que no lo hacían ahora saben que el reloj está corriendo.

La tasa de composición es real y no espera. Cada bucle que diseñas corre sin ti. Cada mejora al bucle se aplica a cada ejecución futura. Esa es una trayectoria estructuralmente diferente de volverse más rápido en prompting, y la brecha entre las 2 se vuelve medible más rápido de lo que la mayoría de la gente espera.

¿En qué peldaño estás ahora mismo, y es en el que quieres quedarte?

---

Fuentes

• Peter Steinberger (@steipete), X, 7 de junio, 2026
• Addy Osmani, "Loop Engineering," addyosmani.com, 7 de junio, 2026
• Andrej Karpathy, Skill Issue: Code Agents, AutoResearch, and the Loopy Era of AI, podcast No Priors
• explainx.ai, "Loop Engineering: The Claude Code Guide," junio 2026
• datasciencedojo.com, "Agentic Loops: From ReAct to Loop Engineering," junio 2026
• Anthropic, How to get Claude Code to verify its own work, YouTube

Este post puede contener enlaces de afiliados. Si los clickeas, 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).