El 99% de las personas usa mal /goal y los bucles.
El hype que escuchan es "bucles de larga duración que impulsan agentes autónomos": apúntalo a una tarea, aléjate, vuelve 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 harness + desarrollo guiado por especificaciones:
- Construye un harness para que el agente observe el problema
- Escribe una especificación ajustada con todos los casos de prueba
- Deja que Codex o Claude Code itere sin supervisión hasta cumplir cada uno.
Yo lanzo estos procesos constantemente durante la noche — de 2 a 5 horas por ejecución. En abril, uno resolvió un bug de compilación de Turbo en nuestro monorepo de Vercel y lo dejó todo en verde para la mañana. No se necesita /goal en absoluto.
Entonces, ¿para qué sirve realmente /goal?
Esto es lo que hizo una sola instrucción mientras yo no estaba:
- ~30 horas, 6,300 líneas de código, 92k páginas rastreadas, $40 gastados en APIs
- Clonar el bucle principal de otro producto — arquitectura completa reconstruida desde cero
- La salida de nuestra versión era ~50× mejor que la del producto de referencia con 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 función de pérdida (LFD): le escribes al agente un objetivo a optimizar, no una especificación a construir.
Esto es un ejemplo concreto del tuit de Peter, llevado a la práctica.
La especificación usada en el desarrollo guiado por especificaciones se convierte ahora en el punto de partida, ya no en la línea de meta.
Me llevó algo de experimentación lograr que funcionara. Pero aquí está el manual completo — aunque primero tenemos que empezar con lo mal que salió para que entiendas cómo diseñar estos /goal.
El agente hizo trampa 3 veces.
Todo empezó como siempre: con una especificación.
Simplemente apunté Codex al sitio web público del otro producto — "¿cómo podemos construir esto nosotros mismos?". En 30 minutos volvió con un diseño de sistema completo y casos de prueba: la especificación.
Pero esta vez, probé una instrucción diferente.
/goal implementa hasta que tu salida coincida exactamente con la suya
Y esto es 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 recall, cero generalidad — un motor de búsqueda que solo podía encontrar las 30 cosas que le había dado, jaja.
Solución → cegarlo. Evaluación oculta durante la ejecución, revelada solo al puntuar, con una lista de fallos por elemento.
Bucle 2 (20 minutos) - ciego, 30 elementos.
Cegué al agente del conjunto de evaluación, pero aprendió de los fallos — cada "no encontraste X" se convertía en una palabra clave en el siguiente ciclo. Tras unas cuantas iteraciones: usaba 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 añadir 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 los cientos, cada término un señuelo preciso para el siguiente fallo.
Tres rondas, tres trampas.
Ahí fue cuando hizo clic: el agente simplemente estaba optimizando.
La trampa no era un bug del agente. Era un bug en mi objetivo: le dije dónde ir y dejé todos los atajos abiertos.
Cada camino barato que no cierres es una dirección por la que el optimizador se lanzará. Y mi objetivo inicial se saltó todas las vallas.
Bucle 4 (30 horas) - ciego, 200 elementos, límites estrictos.
Así que empecé a bloquear direcciones. Limitar la lista de palabras clave, cegar la evaluación, ampliar la fecha — cada arreglo cerraba un camino barato más, hasta que la única dirección que quedaba para mover la cifra era mejorar genuinamente en la tarea.
Dejó de hacer trampa.
Y entonces se ejecutó. ~30 horas de cómputo, 92k páginas rastreadas, ~$40 en tokens, 6,300 líneas de código.
Resulta que el producto que estábamos tomando como referencia era el suelo, no el techo: terminamos generando ~50× los resultados con las mismas consultas.
(El viaje completo y los recibos aquí para los curiosos)
Desarrollo de función de pérdida (LFD): la anatomía de una buena función de pérdida
Cuando la mayoría de la gente intenta construir un producto, usa agentes para pasar de cero a lanzado en unas pocas horas.
Pero el truco está en lo que viene después: la cola larga. Los casos extremos que la especificación nunca imaginó solo salen a la luz en producción, un registro de error a la vez. Los arreglas 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 bug.
Yo he automatizado la parte barata de esto. Mi agente OpenClaw Zoe vigila el registro de errores cada día y lanza Codex sobre los nuevos errores a medida que llegan, creando PRs — tan ajustado como se puede conseguir ese bucle. (Configuración completa documentada aquí
La cola sigue llevando meses. Por eso construir un buen producto aún lleva tiempo, incluso con agentes haciendo el trabajo.
LFD acelera la cola. Si consigues ejemplos reales de salida esperada por adelantado —cómo se ve lo bueno, a escala— ejecutas el soak antes de lanzar: cientos de casos extremos golpean al agente en una sola ejecución de optimización, no en un goteo trimestral de informes de errores. Y la razón por la que esto es repentinamente factible es que, para más y más problemas, esos ejemplos están simplemente disponibles públicamente.
Desarrollo guiado por especificaciones:
Construye esto. Haz que pasen las pruebas.
Desarrollo de función de pérdida:
Construye esto. Haz que pasen las pruebas. Luego itera contra 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 hasta alcanzar el listón. 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–3, elige el 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
- Suficientemente grande para que la enumeración no sea rentable. 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 mirar.
2. Restricciones
Qué se le permite hacer al agente y qué no.
- El tiempo es la restricción que el agente siempre olvida. Los agentes no tienen sentido del tiempo. Insistirán durante 10 horas por una mejora del 2% porque la métrica se mueve nominalmente. Pero una solución del 80% en 2 horas es mejor que una del 100% completada en 30 días. Solución: establece un presupuesto de tiempo real.
- Dinero. Límites estrictos en cada llamada de pago: créditos de rastreo, 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 las cosas que quieres que toque.
- Metodología. ¿Se permite análisis LLM, o solo lógica determinista? ¿A qué fuentes de datos tiene acceso el agente? Escríbelo explícitamente.
3. Instrumentos (el harness)
Una restricción sin un instrumento es una vibra — el agente la violará alegremente porque no puede saber que la está violando. Para cada restricción anterior, incluye un comando CLI para que el agente pueda inspeccionarla.
- Medición del objetivo, en la resolución correcta. Elige el instrumento de objetivo con cuidado. Ejemplo real: un juez ingenuo que "pide a un LLM que puntúe 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 perfectos a nivel de píxel, 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 cada ejecución y cada paso. El agente debe saber cuánto tomó cada paso, el tiempo real transcurrido total. 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 scrape restantes, el gasto de este bucle, el gasto acumulado y el gasto proyectado antes del próximo lote de pago.
- Gasto en LLM. Darle una clave de API LLM para usar en el plano de datos puede simplificar mucha lógica. Pero el agente debería gastarlas responsablemente, sabiendo primero cuánto está gastando realmente.
- Uso de Codex. Este es un poco meta. El bucle debería ser consciente de sí mismo: ¿cuántos tokens estoy gastando en esta optimización? Útil para conocer el gradiente del paso de optimización actual.
El patrón es el viejo dicho: no puedes optimizar lo que no puedes ver.
Si eres nuevo en la ejecución de estos bucles, no lo lances y te vayas. Siéntate con el primer ciclo. Observa qué toca. Confirma que el harness que construiste se está usando correctamente. Luego vete a dormir. (Y trata de dormirte sin pensar en lo que te encontrarás al despertar)
4. Entropía forzada
Por qué importa la entropía forzada: cada bucle continúa desde el contexto completo de la ejecución anterior. El modelo no empieza de cero — está leyendo sus propias últimas cien decisiones y el gradiente que ha funcionado hasta ahora.
En un bucle /goal, alcanzar máximos locales es el estado por defecto. Sin un impulso explícito, el agente sigue subiendo la misma colina, y "la misma colina" es dondequiera que estuviera cuando dejó de mejorar.
Por ejemplo, si un pequeño ajuste mejora el resultado en un 0.1%, el agente seguirá girando ese mismo ajuste incluso si tiene otros 1000 ajustes 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 añadir uno.
- Forzar entropía en el estancamiento. Si el último ciclo no movió la métrica, el siguiente no puede ser "misma idea, más intensidad". El modelo tiene que dar un salto real no obvio — "piensa fuera de la caja" es un buen prompt — evita que el agente se limite a girar la misma perilla con más fuerza.
- Mantén un registro de iteración. 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 entre compactaciones.
El Meta-Meta-Prompt
Yo mismo escribía estos objetivos, pero rápidamente aprendí que ese es un trabajo para los agentes también.
Así que escribí una habilidad que produce este tipo de objetivos para una buena ejecución de desarrollo de función de pérdida.
Ahora es de código abierto aquí:
https://github.com/elvisun/loss-function-development
/lfd-design para generar el harness y el objetivo
Descenso de gradiente hasta el final: los dos bucles
Da un paso atrás y es descenso de gradiente hasta el final.
El bucle interno es el agente: escribe código, ejecuta pruebas, arregla. Horizonte corto, retroalimentación rápida, un objetivo — hacer que pasen las pruebas. Ese es el bucle interno de un desarrollador, y el desarrollo guiado por 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. Eso 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, movida del tiempo de entrenamiento al tiempo de prompt. Así es como la línea DeepSeek, Kimi, Minimax cerró la mayor parte de la brecha con GPT y Claude — entrenar 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 un ajuste de destilación a cualquier artefacto públicamente encontrable — nunca inspecciona los internos y no necesita hacerlo.
Apóyate en la palabra públicamente. Destilar la salida de alguien que está tras una TOS, un muro de inicio de sesión o de 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 aprender de ello. Esa parte no es nueva: es el movimiento más antiguo del 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 lo bueno, así que cualquiera puede destilarlo de vuelta en un fin de semana por $40.
Así que aquí hay un nuevo foso que se está volviendo cada vez más valioso: asimetría de información.
La empresa de código abierto canónica ya parpadeó. En abril de 2026, cal.com ($5M ARR) hizo privado su código de producción y se volvió 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](https://cal.com/) y enumera su superficie de ataque hasta que algo funcione
Ese 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 un pasivo. 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 posea 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 del competidor 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 puede tocar.
