99% de las personas están usando /goal y los bucles de forma incorrecta.
El hype que escuchan es "bucles de larga duración que impulsan un agente autónomo": apúntalo a una tarea, aléjate, regresa y encuentra código funcionando.
Pero los mejores ingenieros de agentes han estado haciendo eso sin /goal durante 6 meses (desde que salieron GPT-5.2 y Opus 4.5). Se llama ingeniería de arnés + desarrollo basado en especificaciones:
- Construye un arnés para que el agente observe el problema
- Escribe una especificación ajustada con todos los casos de prueba
- Deja que Codex o Claude Code iterren sin supervisión hasta que cumplan cada uno.
Yo inicio estos procesos durante la noche constantemente — de 2 a 5 horas por ejecución. En abril, uno resolvió un bug del caché de compilación de Turbo en nuestro monorepo de Vercel y para la mañana ya estaba todo en verde. No se necesita /goal en absoluto.
Entonces, ¿para qué sirve realmente /goal?
Esto es lo que hizo un solo prompt mientras yo no estaba:
- ~30 horas, 6,300 líneas de código, 92 mil páginas rastreadas, $40 gastados en APIs
- Clonó el bucle principal de otro producto — la arquitectura completa reconstruida desde cero
- La salida de nuestra versión fue ~50 veces mejor que la del producto de referencia en las mismas consultas. (Esta es una nueva capa de datos que impulsará newsjack.sh — las habilidades de inteligencia de noticias de código abierto en las que he estado trabajando)
El secreto es el desarrollo de funciones de pérdida (LFD): le escribes al agente un objetivo a optimizar, no una especificación a construir.
Este es un ejemplo concreto del tuit de Peter, puesto en práctica.
La especificación utilizada en el desarrollo basado en especificaciones ahora se convierte en el punto de partida, ya no en la línea de meta.
Me tomó algo de experimentación lograr que esto funcionara. Pero aquí está el manual completo — aunque primero debemos empezar por lo mal que salió todo para que entiendas cómo diseñar estos /goal.
El agente hizo trampa 3 veces.
Todo comenzó con lo que siempre hago: una especificación.
Simplemente apunté a Codex al sitio web público del otro producto: "¿cómo podemos construir esto nosotros mismos?". En 30 minutos, regresó con un diseño completo del sistema y casos de prueba: la especificación.
Pero esta vez, probé un prompt diferente.
"/goal implementa hasta que tu salida coincida exactamente con la de ellos"
Y esto fue lo que pasó:
Bucle 1 (5 minutos)
El agente tomó el conjunto de evaluación, generó datos semilla que lo reflejaban y declaró victoria en cinco minutos.
"100%" de recuperación, cero generalidad — un motor de búsqueda que solo podía encontrar las 30 cosas que le había dado, jaja.
Solución → cegarlo. La evaluación oculta durante la ejecución, revelada solo al puntuar, con una lista de elementos fallados por cada uno.
Bucle 2 (20 minutos) - ciego, 30 elementos.
Cegué al agente del conjunto de evaluación, pero aprendió por fallos — cada "no encontraste X" se convertía en una palabra clave en el siguiente ciclo. Tras unos pocos ciclos: usó exactamente 30 palabras clave, una por elemento, y "ganó" de nuevo.
Solución → ampliar el conjunto de evaluación. Cientos de elementos para puntuar, demasiados para enumerar.
Bucle 3 (30 minutos) - ciego, 200 elementos.
Después de agregar 200 elementos al nuevo conjunto de evaluación, el agente volvió a hacer trampa.
Curiosamente, el agente enumeró de todas formas. La lista de palabras clave se infló hasta llegar a cientos, cada término un señuelo preciso para el siguiente fallo.
Tres rondas, tres trampas.
Fue entonces cuando lo entendí: el agente simplemente estaba optimizando.
La trampa no era un error en el agente. Era un error en mi objetivo: le dije a dónde ir y dejé todos los atajos abiertos.
Cada camino fácil que no bloqueas es una dirección que el optimizador tomará a toda velocidad. Y mi objetivo inicial se saltó todas las barreras.
Bucle 4 (30 horas) - ciego, 200 elementos, límites estrictos.
Así que comencé a bloquear direcciones. Limitar la lista de palabras clave, cegar la evaluación, ampliar la fecha — cada corrección cerró un camino fácil más, hasta que la única dirección que quedaba y movía el número era mejorar genuinamente en la tarea.
Dejó de hacer trampa.
Y entonces funcionó. ~30 horas de cómputo, 92 mil páginas rastreadas, ~$40 en tokens, 6,300 líneas de código.
Resulta que el producto que estábamos usando como referencia era el piso, no el techo: terminamos generando ~50 veces más resultados en las mismas consultas.
(El viaje completo y las pruebas aquí para los curiosos)
Desarrollo de funciones de pérdida (LFD): la anatomía de una buena función de pérdida
Cuando la mayoría de las personas intenta construir un producto, usan agentes para pasar de cero a lanzado en unas pocas horas.
Pero el problema es lo que viene después: la cola larga. Los casos extremos que la especificación nunca imaginó aparecen solo en producción, un registro de error a la vez. Los corriges uno por uno. Los casos que no atrapas en los registros los reportan los usuarios, que es la forma más cara de encontrar un error.
He automatizado la parte barata de esto. Mi agente OpenClaw, Zoe, monitorea el registro de errores todos los días y genera instancias de Codex para los nuevos errores a medida que aparecen y crea PRs — es lo más ajustado que puede ser ese bucle. (La configuración completa está documentada aquí
La cola larga aún lleva meses. Por eso construir un buen producto todavía toma tiempo, incluso con agentes haciendo el trabajo.
LFD acelera la cola larga. Si puedes obtener ejemplos reales de salida esperada desde el principio — cómo se ve el éxito, a escala — ejecutas la prueba de resistencia antes de lanzar: cientos de casos extremos golpean al agente en una sola ejecución de optimización, no en un goteo trimestral de reportes de errores. Y la razón por la que esto es repentinamente factible es que, para más y más problemas, esos ejemplos simplemente están disponibles públicamente.
Desarrollo basado en especificaciones:
Construye esto. Haz que las pruebas pasen.
Desarrollo de funciones de pérdida:
Construye esto. Haz que las pruebas pasen. Luego itera con estos 1,000 casos de evaluación.
Un conjunto de pruebas es finito — termina en el momento en que está en verde. Una evaluación de 1,000 casos al 95% es un objetivo hacia el que desciendes; no hay salida antes de alcanzar el estándar. Eso importa porque el agente toma cientos de decisiones que nunca verás, y cada una se resuelve contra algo. Si no escribiste el objetivo, el agente elige uno — y como mostraron las rondas 1 a 3, elige lo que sea más barato de satisfacer.
La función de pérdida es más grande que la evaluación. Tiene 4 cosas: el objetivo, las restricciones, los instrumentos y la entropía forzada. Cuatro piezas.
1. Objetivo
- Lo suficientemente grande como para que la enumeración no valga la pena. Una evaluación de 28 ítems se memorizó en una ronda. Cuantos más, mejor.
- Ciega al agente de la clave de respuestas. Los datos de evaluación existen solo para la puntuación posterior. Si el agente puede ver las respuestas durante la ejecución, encontrará la manera de mirarlas.
2. Restricciones
Lo que el agente puede hacer y lo que no.
- El tiempo es la restricción que el agente siempre olvida. Los agentes no tienen sentido del tiempo. Trabajarán durante 10 horas por una ganancia del 2% porque la métrica nominalmente se mueve. Pero una solución del 80% en 2 horas supera a una del 100% completada en 30 días. Solución: establece un presupuesto de tiempo real.
- Dinero. Límites estrictos en cada llamada paga: créditos de rastreador, gasto en LLM, techo total en dólares en una clave desechable.
- Superficie. Todos los proveedores, modelos permitidos, límites de concurrencia. Aísla al agente solo a lo que quieres que toque.
- Metodología. ¿Se permite el análisis con LLM, o solo lógica determinista? ¿Qué fuentes de datos tiene acceso el agente? Especifícalo.
3. Instrumentos (el arnés)
Una restricción sin un instrumento es una vibra — el agente la violará alegremente porque no puede darse cuenta de que la está violando. Para cada restricción anterior, implementa un comando CLI para que el agente pueda inspeccionarla.
- Medición del objetivo, en la resolución correcta. Elige cuidadosamente el instrumento del objetivo. Ejemplo real: un juez ingenuo que "pide a un LLM que califique dos capturas de pantalla" aprueba clones de UI con errores de espaciado de 12px, porque los LLM no pueden ver realmente las imágenes, las convierten en embeddings y luego comparan los embeddings. Así que si quieres clones de UI con píxeles perfectos, dale a tu agente una herramienta de diferencia de píxeles. Luego /goal hasta que la diferencia de píxeles sea 0.
- Contabilidad del tiempo. Marca la hora de cada ejecución y cada paso. El agente debe saber cuánto tiempo tomó cada paso, el tiempo total transcurrido. El tiempo es un instrumento de primera clase, no una nota al pie.
- Presupuesto del proveedor. "¿Cuánto estamos gastando en rastreadores ahora mismo?" debería ser un comando, no una suposición. Rastrea los créditos de raspado restantes, el consumo de este bucle, el consumo acumulado y el consumo proyectado antes del próximo lote pago.
- Gasto en LLM. Darle al agente una clave de API de LLM para usar en el plano de datos puede simplificar mucha lógica. Pero el agente debe gastarlos de manera responsable, sabiendo primero cuánto está gastando realmente.
- Uso de Codex. Este es un poco meta. El bucle debe ser consciente de sí mismo: ¿cuántos tokens estoy gastando en esta optimización? Es útil para conocer el gradiente del paso de optimización actual.
El patrón es el mismo viejo dicho: no puedes optimizar lo que no puedes ver.
Si eres nuevo en la ejecución de estos bucles, no lo inicies y te alejes. Siéntate con el primer ciclo. Observa lo que toca. Confirma que el arnés que construiste se está usando correctamente. Luego vete a dormir. (E intenta quedarte dormido sin pensar en lo que encontrarás al despertar)
4. Entropía forzada
Por qué la entropía forzada importa: cada bucle continúa desde el contexto completo de la ejecución anterior. El modelo no está empezando de nuevo — está leyendo sus propias últimas cien decisiones y el gradiente que funcionó hasta ahora.
En un bucle /goal, alcanzar máximos locales es el estado predeterminado. Sin un impulso explícito, el agente sigue caminando por la misma colina, y "la misma colina" es donde sea que estuviera cuando dejó de mejorar.
Por ejemplo, si una pequeña perilla mejora el resultado en un 0.1%, el agente seguirá girando esa única perilla aunque tenga otras 1000 perillas para probar.
La entropía debe forzarse explícitamente en la ejecución, porque el modelo no la tomará por sí solo:
- Reflexión de sobreajuste en cada ciclo. ¿Estoy construyendo una solución más general, o memorizando la evaluación? Si está memorizando, el siguiente cambio debe eliminar un artefacto con forma de evaluación (limitar una lista, cegar una característica, ampliar la evaluación, rechazar una semilla), no agregar uno.
- Fuerza la entropía al estancarse. Si el último ciclo no movió la métrica, el siguiente no puede ser "la misma idea, pero más fuerte". El modelo tiene que dar un salto real no obvio — "piensa fuera de la caja" es un buen prompt — evita que el agente simplemente gire la misma perilla con más fuerza.
- Mantén un registro de iteraciones. Haz que el agente registre la hipótesis, el modo de fallo esperado, el diagnóstico de cada paso, para que pueda mirar atrás y reflexionar a través de las compactaciones.
El Meta-Meta-Prompt
Estaba escribiendo estos objetivos yo mismo, pero rápidamente aprendí que también es trabajo para los agentes.
Así que escribí una habilidad que produce este tipo de objetivos para una buena ejecución de desarrollo de funciones de pérdida.
Ahora es de código abierto aquí:
https://github.com/elvisun/loss-function-development
/lfd-design para generar el arnés y el objetivo
Descenso de gradiente hasta el fondo: los dos bucles
Da un paso atrás y es descenso de gradiente hasta el fondo.
El bucle interno es el agente: escribe código, ejecuta pruebas, corrige. Horizonte corto, retroalimentación rápida, un objetivo — hacer que las pruebas pasen. Ese es el bucle interno de un desarrollador, y el desarrollo basado en especificaciones es cómo lo ejecutas. Los agentes de codificación ya lo automatizaron.
El bucle externo es /goal: impulsa todo el sistema hacia una métrica de resultado a través de muchos ciclos — lanza, mide, cambia de rumbo, desciende. Horizonte largo, retroalimentación escasa. Ese es tradicionalmente el bucle de un equipo de producto, los meses de lanzar-medir-iterar comprimidos en una sola ejecución.
Ambos bucles están automatizados ahora. Lo que queda de tu parte es definir la función de pérdida — qué exactamente debería optimizar /goal y de qué manera.
Estás destilando un producto — o cualquier cosa que deje un artefacto público
Otra perspectiva: esto es esencialmente destilación, trasladada del tiempo de entrenamiento al tiempo de prompt. Es cómo la línea DeepSeek, Kimi, Minimax cerró la mayor parte de la brecha con GPT y Claude — entrena tu modelo con las salidas de otro hasta que las tuyas las reproduzcan.
Pero en lugar de destilar un modelo, ahora puedes usar /goal y LFD para ejecutar una destilación que se ajuste a cualquier artefacto disponible públicamente — nunca inspecciona los internos y no necesita hacerlo.
Apóyate en la palabra públicamente. Destilar la salida de alguien que está detrás de una puerta de Términos de Servicio, un inicio de sesión o un pago no es juego limpio. Pero lo que se publica abiertamente — las salidas que una empresa envía para ganar clientes — siempre ha sido justo para aprender de ello. Esa parte no es nueva: es la jugada más antigua en el software. Lo nuevo es que ahora es barato y se puede hacer en horas en lugar de meses.
Da un paso atrás, y aquí está el cambio más grande. El costo de la ejecución colapsa a ~$0 dondequiera que haya simetría de información — cuando las salidas son públicas, todos pueden ver cómo se ve el éxito, así que cualquiera puede destilarlo de vuelta durante un fin de semana por $40.
Así que aquí hay un nuevo foso que se está volviendo cada vez más valioso: la asimetría de información.
La empresa canónica de código abierto ya parpadeó. En abril de 2026, cal.com ($5M ARR) hizo que su código de producción fuera privado y se volvió de código cerrado. La razón que dieron se lee literalmente como el resumen de este ensayo: en una era de amenazas de seguridad impulsadas por IA, no puedes dejar tu código fuente donde un agente pueda leerlo.
"/goal lee el código fuente de cal.com y enumera su superficie de ataque hasta que algo funcione"
Eso es un ataque demasiado peligroso y demasiado fácil de ejecutar.
La empresa cuya identidad completa era "código abierto" decidió, en 2026, que la apertura se había convertido en una responsabilidad. Eso debería decírtelo todo.
Durante toda la historia del software, "lo construimos nosotros" fue el foso.
Esa era se está cerrando.
La próxima pertenece a quien sea dueño de lo que el artefacto nunca contuvo: el conjunto de evaluación contra el que nadie más puede puntuar. La lista de casos extremos con los que tus usuarios realmente tropiezan. La verdad fundamental que mides en privado. Quien tenga el objetivo que el agente de la competencia no puede ver es el único cuyo bucle sigue descendiendo.
El producto es un fin de semana ahora.
Ve a construir la evaluación que un fin de semana no pueda tocar.
