El tweet que paralizó Twitter (X): "Ya no deberías estar enviando prompts. Deberías estar diseñando loops"
El 7 de junio de 2026, a las 12:28 AM, Peter Steinberger publicó dos oraciones en X.
No había diagrama. No había enlace a ningún repositorio. No había hilo explicativo con numeritos. Solo esto:
"Aquí va tu recordatorio mensual: ya no deberías estar enviando prompts a agentes de código. Deberías estar diseñando los loops que los envían por ti."
En 72 horas, el post superó los 6,5 millones de vistas. La comunidad de developers en X, Hacker News, Reddit y YouTube estuvo debatiendo esas dos oraciones durante una semana entera. Algunos las entendieron de inmediato. La mayoría no. Y la primera respuesta con más likes capturaba perfectamente el ambiente: "nadie sabe qué significa esto excepto él y Boris."
Lo que siguió fue el debate de programación más viral del año — y una de las redefiniciones más concretas del rol del developer en la era de la IA.
Quién es Peter Steinberger y por qué importa quién lo dice
Steinberger no es un influencer de tecnología. Es el creador de OpenClaw, el proyecto open-source de orquestación de agentes que se convirtió en el repositorio más estrellado de la historia de GitHub en el momento de su lanzamiento. Hoy forma parte del equipo de OpenAI.
Cuando alguien con ese historial publica algo provocador sobre cómo trabajar con agentes de IA, la comunidad lo toma en serio. Y lo que publicó no era una predicción ni una reflexión filosófica. Era una declaración técnica sobre cómo ya trabajan los mejores equipos del mundo.
Cuatro días antes del tweet, Boris Cherny — el creador de Claude Code y jefe del equipo en Anthropic — había dicho exactamente lo mismo en el escenario de un evento de WorkOS:
"Ahora ya no escribo prompts. Tengo loops corriendo. Ellos son los que le envían prompts a Claude y deciden qué hacer. Mi trabajo es escribir loops."
Dos declaraciones. De dos personas en el centro de los dos productos de coding agéntico más usados del mundo. Y casi nadie en la comunidad general había prestado atención a la de Cherny. El tweet de Steinberger fue el detonador que hizo que todo el mundo se sentara a escuchar.
¿Qué es exactamente un loop? (la pregunta que todos tenían miedo de hacer)
La confusión inicial fue real y comprensible. "Loop" es una palabra que en programación tiene décadas de historia — un bucle for, un while. No sonaba a revolución.
Pero en este contexto, un loop de agentes es algo diferente. La definición más clara llegó de Addy Osmani, ingeniería de Google Cloud, quien publicó un post extendido durante la misma semana y le dio nombre formal al concepto: Loop Engineering.
Su definición es precisa: un loop es el sistema que reemplaza al humano que estaba enviando prompts manualmente.
Más concretamente: un loop es un ciclo donde un agente de IA ejecuta una tarea, evalúa el resultado contra un criterio verificable — los tests pasan, el linter está limpio, la especificación se cumple — y reintenta automáticamente si el criterio falla. El loop corre hasta que la condición de éxito se cumple, o hasta que se agota un presupuesto de tokens o tiempo que tú definiste.
Tú defines la tarea, la verificación y la condición de salida. El agente maneja todo lo que hay en medio.
Eso es todo. La potencia está en el criterio verificable. Sin él, tienes un prompt de una sola vez. Con él, tienes un sistema.
La arquitectura de un loop: cinco componentes
Osmani, Steinberger y Cherny coincidieron durante esa semana en una estructura común para cualquier loop funcional. Tiene cinco piezas:
1. Descubrimiento — El loop encuentra el trabajo. Puede ser un issue abierto en GitHub, un test que falla en CI, un log de error, un webhook. No espera a que un humano lo active.
2. Descomposición de la tarea — El agente analiza el trabajo encontrado y lo divide en pasos ejecutables. Esta es la diferencia con un script tradicional: el agente decide cómo dividir la tarea, no el programador.
3. Capa de orquestación — El agente ejecuta los pasos, a veces delegando a sub-agentes especializados que corren en paralelo. Es aquí donde entra la potencia de arquitecturas multi-agente.
4. Verificación — El paso crítico. El loop evalúa el output contra algo externo y objetivo: compilación exitosa, tests en verde, diff dentro de un umbral de líneas, una llamada a la API devuelve 200. No "¿se ve bien esto?" sino algo que el sistema puede medir sin un humano.
5. Memoria persistente — El loop registra lo que aprendió para que la próxima iteración sea más eficiente. Aquí es donde conecta con el concepto de Dreaming de Anthropic — los loops que aprenden entre sesiones.
El comentario más útil en el hilo original de Steinberger vino de @mosyaseen, y resumió todo en una sola oración: "Diseñar el loop es la mitad del trabajo. La otra mitad es poner algo dentro del loop que pueda decir que no: un test, un type check, un error real."
Los loops ya existían. ¿Por qué el debate explotó ahora?
Esta es la pregunta que los escépticos hicieron de inmediato, y tenían razón en hacerla. La arquitectura ReAct — razonamiento más acción en ciclos — existe desde 2022. AutoGPT experimentó con loops en 2023. Los scripts bash de tipo "ralph loop" circulaban entre developers avanzados en 2025.
¿Qué cambió en junio de 2026?
Tres cosas, según el análisis posterior de AlphaSignal:
Primero, las ventanas de contexto. Un loop que carga un codebase completo en cada iteración era impráctica cuando el límite eran 32k o 128k tokens. Con ventanas de 1 millón de tokens, el proyecto entero cabe. El agente tiene contexto completo en cada reintento.
Segundo, el costo. Los loops son inherentemente más caros que un prompt único — corren múltiples veces y usan más tokens. La caída de precios de 2025-2026 hizo que la matemática funcionara para más casos de uso. Lo que antes era prohibitivo para un developer independiente ahora es viable.
Tercero, la infraestructura ya viene incluida. Hace un año, construir un loop significaba escribir bash personalizado y mantenerlo para siempre. Hoy, Claude Code tiene /goal, Codex tiene sus propios comandos de automatización, y Cursor está moviendo en la misma dirección. Lo que antes requería una rig personalizada ahora es un archivo de configuración.
Como lo formuló Boris Cherny en un evento de Meta's @Scale apenas una semana después del tweet viral: "Los loops son tan grandes como lo fue el salto del código fuente a los agentes. Los loops son el salto de los agentes a lo que viene después."
Casos reales: cómo se usan los loops en producción hoy
El debate no se quedó en lo teórico. Durante esa semana, varios practitioners compartieron sus implementaciones reales.
OpenClaw de Steinberger es el ejemplo más completo: un orquestador general siempre activo que usa un mecanismo de "latido" para llamar a un agente en ciclos fijos. Mantiene una base de datos de estado durable y sistemas de recuperación ante caídas. Mientras el equipo duerme, el agente evalúa el estado del repositorio, supervisa sub-loops secundarios y commitea cambios de código verificados.
AutoResearch de Andrej Karpathy aplica un loop con restricciones muy estrictas a una tarea singular y medible: experimentación en machine learning. El agente modifica un script de entrenamiento en PyTorch, ejecuta un run de entrenamiento de cinco minutos en una GPU dedicada, y lee la métrica de validation loss. Si el desempeño mejora, el loop commitea el código automáticamente. Si no, reintenta con otra variación.
Matt Van Horn describió cómo corre loops que abren pull requests en aproximadamente 30 repositorios open-source durante la noche, sin intervención manual. Publica la síntesis de lo aprendido como hilo en X cada mañana.
Un dato de contexto que Anthropic confirmó durante el evento Code with Claude de mayo: más del 80% del código que Anthropic integra a su propio codebase es escrito por Claude. No por prompts manuales — por loops.
Las críticas legítimas: cuándo un loop se convierte en un problema
El debate también produjo críticas sólidas que merecen espacio.
@SaidAitmbarek señaló el problema de la eficiencia de tokens: un loop que corre 20 iteraciones puede consumir el equivalente en costo de cientos de prompts manuales bien diseñados.
@jxnlco notó que el alcance de Steinberger en el tema amplifica el mensaje más allá de lo que los datos justifican — no todos los workflows se benefician de loops, y el entusiasmo puede llevar a implementaciones innecesarias.
TechTalks documentó el problema de los dead ends matemáticos: cuando Karpathy probó AutoResearch en tareas de optimización complejas, los agentes a veces entraban en ciclos donde ajustaban el learning rate en fracciones mínimas durante decenas de iteraciones sin progreso real, quemando tokens sin avanzar.
Y hay un problema de seguridad que Georgia Tech's Vibe Security Radar documentó: para mediados de 2026, más de 70 CVEs confirmados se rastreaban a herramientas de coding con IA, cubriendo command injection, server-side request forgery y cross-site scripting. Un loop que corre desatendido es también un vector de ataque que corre desatendido.
AlphaSignal lo resumió con cuatro condiciones necesarias para que un loop justifique su costo: la tarea se repite, la verificación está automatizada, el presupuesto de tokens puede absorber el desperdicio, y el agente ya tiene las herramientas que usaría un senior engineer. Si falta una de las cuatro, un prompt bien diseñado es más rápido y más barato.
Lo que esto significa para tu trabajo hoy
El desplazamiento que describe Steinberger no es del futuro. Ya está ocurriendo en los equipos más productivos del mundo. Pero como señaló la cobertura de Yahoo Tech, no es exclusivo de ingenieros de software.
La cita que más resonó en esa dirección vino de Lan Vo, directora de producto en Anthropic: "Este es el momento del manager. Estás diseñando un trabajo. Imagina que estás incorporando a un empleado. Ese empleado puede ser un asistente ejecutivo, un agente de soporte al cliente, o un ingeniero de software."
Y añadió algo que muchos no esperaban: "Si has usado una tarea programada en Claude Cowork, adivina qué, cariño. Ya escribiste un loop."
Para developers independientes y vibe coders — el perfil que más rápido puede capitalizar esto — la implicación práctica es clara:
El prompt que escribes manualmente cada mañana para revisar tus issues abiertos es un loop esperando a ser automatizado. El proceso de "le pido a Claude que escriba el componente, reviso, le pido que lo corrija, reviso, le pido los tests" es un loop manual que puede convertirse en un sistema con un criterio de salida definido. La diferencia entre una herramienta de IA que usas y un sistema de IA que trabaja para ti mientras duermes es, exactamente, esa.
El nuevo mapa de habilidades
Si el tweet de Steinberger tiene razón — y los datos de adopción sugieren que sí — el mapa de habilidades de un developer está cambiando de lugar en tiempo real.
Prompt engineering no desaparece. Se mueve hacia arriba en la cadena. Los prompts siguen existiendo dentro de los loops — solo que ahora los escribe el sistema, no el humano, y están optimizados para iterar, no para impresionar.
Lo que gana valor es diferente:
- Saber definir criterios de salida verificables y objetivos
- Diseñar sistemas que detecten cuándo un agente se atascó y necesita interrupción
- Entender el costo de cada iteración y construir loops con presupuesto
- Mantener supervisión humana en los puntos donde el agente no puede decir "no"
Y un meta-skill que nadie estaba enseñando hace dos años pero que hoy define a los developers más productivos del mundo: saber cuándo no usar un loop.
Para cerrar
Dos oraciones. 6,5 millones de vistas. Una semana de debate que produjo más claridad sobre el futuro del desarrollo de software que la mayoría de conferencias técnicas del año.
Lo que Steinberger hizo con ese tweet no fue revelar un secreto. Fue darle un nombre a algo que los mejores teams del mundo ya hacían, en el momento exacto en que las herramientas se democratizaron lo suficiente para que todos pudieran hacerlo también.
El prompt engineering no murió. Simplemente subió un nivel de abstracción. Y ahora el trabajo real es diseñar el sistema que envía los prompts.
Como dijo Cherny antes de que nadie prestara atención: "Mi trabajo es escribir loops."
Ahora es el tuyo también.
¿Ya estás usando loops en tus proyectos o todavía en modo prompt-por-prompt? Cuéntalo en comentarios. Y si quieres que publique una guía práctica para construir tu primer loop con Claude Code y Next.js, deja tu voto abajo.
Comentarios