For/Goal probado: Claude Code vs Codex crearon mi app en 32 min

For/Goal probado: Claude Code vs Codex crearon mi app en 32 min

Empecé el cronómetro a las 2:47 p. m. de un miércoles. A las 3:19 p. m., dos ventanas de terminal en mi monitor izquierdo habían terminado de armar una aplicación Next.js en funcionamiento: flujo de incorporación, panel de control, página de inicio, pantallas de autenticación, la forma completa de un producto real. Sesenta y dos tareas de la hoja de ruta. Ambas aplicaciones. Treinta y dos minutos cada uno. Había estado rellenando mi café.

Esta es la parte en la que la gente de la demostración en Twitter suele recortar un lapso de tiempo de treinta segundos y dar por terminado el día. Quiero mostrarles las costuras reales. Porque la función for/goal, el bucle autónomo de larga duración que aterrizó en Claude Code 2.1.139 y se envía en Codex CLI 0.128.0, solo parece magia. Debajo hay una receta muy específica, y esa receta es la diferencia entre un agente que envía una aplicación real en media hora y un agente que hace un bucle para siempre, reescribiendo la misma función rota hasta que matas el proceso por lástima.

He estado ejecutando for/goal casi todos los días desde que se eliminó la función. Dos proyectos paralelos. Misma especificación del producto. Misma hoja de ruta de seis fases. Una ejecución en Claude Code, otra en Codex. Ambos terminaron. Ambos produjeron algo que pude hacer git clone y hacer una demostración a un cliente mañana. También produjeron aplicaciones muy diferentes a partir del mismo mensaje, y las diferencias le indican exactamente a qué agente recurrir y cuándo.

Este es el desglose que desearía tener antes de comenzar.

Qué es realmente For/Goal y por qué no es simplemente otro comando de barra diagonal

Primero déjame dejar de lado el lenguaje de marketing.

For/goal es un modo objetivo persistente. Usted establece un objetivo una vez, el agente trabaja en él durante muchos turnos (a veces horas, a veces un día completo) y un segundo modelo más pequeño verifica después de cada turno si el objetivo realmente se ha cumplido. Si el validador dice que no, el modelo principal obtiene ese "no" más un motivo de una frase y sigue funcionando. Si el validador dice que sí, el ciclo finaliza y su terminal le devuelve el control. Esa es toda la forma.

En Claude Code, el comando es literalmente /goal. Se envió en la versión 2.1.139, lanzada a principios de mayo de 2026. El validador se ejecuta en cualquier modelo que haya configurado como su modelo pequeño y rápido (Haiku de forma predeterminada) y el costo del token del validador se factura por separado del presupuesto del turno principal, lo cual es importante cuando se ejecuta un objetivo durante seis horas.

En Codex CLI, la superficie de comando tiene la misma idea. Codex llama a la primitiva de bucle for/goal, y los comandos de barra diagonal en la versión 0.128.0 son /goal, /goal pause, /goal resume, /goal clear, además de un hilo /side para hacer una pregunta rápida sin perturbar la ejecución principal. Misma arquitectura: el modelo principal hace el trabajo, el modelo pequeño juzga la finalización.

Esta es, mecánicamente, una evolución del patrón de bucle de Ralph: la frase ingeniosa que ingenieros como Adam Tuttle y el repositorio de snarktank convirtieron en una metodología durante los últimos doce meses. Ralph era un contenedor while true alrededor de su agente de codificación, con un comando de verificación en el otro extremo de la tubería. For/goal toma esa idea y la integra en el propio agente, con una arquitectura de supervisor real y un gancho de parada consciente del estado.

Aquí está la parte que me llevó tres carreras internalizar: esto ya no es una charla. Es un proceso de trabajo con una lista de verificación. No le hablas. Usted establece el destino y verifica que sea accesible. El agente hace el resto.

Lo cual suena simple. No lo es y te mostraré por qué.

El montaje: un PRD, dos agentes, sesenta y dos tareas

La aplicación de prueba era una herramienta de revisión de contenido, algo entre un espacio de trabajo estilo Notion y una cola de anotaciones de vídeo. Nada que haga temblar al mundo. Lo elegí porque el alcance era lo suficientemente grande como para ser interesante (necesitaba autenticación, un concepto de espacio de trabajo, una cola de revisión, un flujo de incorporación y una página de configuración) pero lo suficientemente pequeño como para poder leer cada archivo que el agente produjo y decirle qué había realmente allí.

La especificación era cinco archivos en la raíz del proyecto antes de tocar algo más:

• prd.md: el documento de requisitos del producto. Alrededor de 1.400 palabras. Audiencia, problema, las tres tareas principales que la aplicación necesitaba realizar, el modelo de datos en inglés sencillo y una lista de elementos fuera de alcance para que el agente no se desviara hacia funciones que yo no quería. - productroadmap.mmd: una hoja de ruta de Mermaid con seis fases y tareas de sesenta y dos hojas. La Fase 1 fue el andamiaje y la autenticación, la Fase 2 fue el concepto del espacio de trabajo, la Fase 3 fue la cola de revisión, y así hasta la Fase 6, que fue el pulido y la incorporación. - design.md — dirección frontal. Paleta de colores, pila de tipografía, preferencias de densidad de diseño ("vistas de tablas densas sobre cuadrículas de tarjetas para páginas de cola") y una lista de componentes que esperaba ver (tablas de datos, paneles deslizables, paleta de comandos). - claude.md: archivo de reglas a nivel de proyecto de Claude Code.

Pila anclada a Next.js 15 App Router, TypeScript estricto, Tailwind v4, shadcn/ui, sin Redux, sin componentes con estilo, acciones de servidor para mutaciones. - agents.md: archivo de reglas equivalente a Codex con las mismas restricciones, escrito en el formato preferido de Codex.

El objetivo que le di a cada agente era idéntico, palabra por palabra:

Cree la aplicación completa descrita en prd.md siguiendo las tareas en productroadmap.mmd hasta que todas las tareas estén completas y verificadas. Utilice design.md para la dirección del diseño frontal. Nueva compilación de la aplicación Next.js. Ejecutar con la aprobación automática habilitada. Continúe hasta que el validador confirme que todas las tareas de la hoja de ruta están marcadas y que la aplicación se compila y se limpia.

Esa frase de gol está funcionando mucho. Permítanme explicar qué lo hace sobrevivir a una ejecución autónoma de treinta minutos, porque quemé tres intentos anteriores con frases más débiles antes de llegar aquí.

La frase "hasta que se completen y verifiquen todas las tareas" es la condición de parada. Señala al validador algo concreto que debe verificar (el archivo de hoja de ruta) en lugar de pedirle que evalúe la calidad, que es un trabajo que los modelos pequeños hacen terriblemente. La "compilación nueva de la aplicación Next.js" es el límite de alcance. Le dice al agente "no intente integrarse con nada que ya exista en este directorio, usted es dueño de todo el árbol". Y "Ejecutar con aprobación automática habilitada" es la concesión de permiso; sin él, Claude Code en particular se detendrá cada cuarenta segundos para preguntar si puede instalar un paquete.

Verás lo que sucede cuando falta una de esas cláusulas en algunas secciones. Quédese para la sección de errores de la segunda mitad.

Cómo escribir un objetivo For/Goal que realmente termine

Esta es la parte en la que quiero reducir el ritmo, porque la diferencia entre una carrera de gol que se completa y una carrera de gol que se repite para siempre es casi siempre la frase de gol en sí.

Un objetivo for/goal que funciona tiene cuatro partes, en este orden:

1. Qué lograr. Un estado final mensurable. No "hazlo agradable". No "mejorar el UX". Algo que el validador pueda leer y responder sí o no sin tomar una decisión. "Las sesenta y dos tareas de la hoja de ruta están marcadas como completadas en el archivo". "Pases de construcción de producción". "Todos los exámenes de Dramaturgo son verdes".

2. Qué cambiar. Alcance. Qué archivos, qué directorios, qué superficies el agente puede tocar. Si omite esto, los agentes autónomos refactorizarán el código adyacente en su camino hacia el objetivo y obtendrá una diferencia de treinta páginas que incluye nueve archivos que nunca quiso tocar.

3. Qué validar. El comando o señal real que el validador debe buscar. "pnpm build sale de cero". "El archivo de hoja de ruta no tiene elementos sin marcar". Esto es lo que se envía al modelo pequeño y rápido después de cada turno.

4. Cuándo parar. La condición de salida. Por lo general, es lo mismo que la señal de validación, pero a veces desea cinturón y tirantes: "deténgase cuando el validador confirme Y las pruebas de integración se hayan ejecutado al menos una vez".

Un objetivo más grande que un solo mensaje pero más pequeño que un trabajo pendiente abierto. Ese es el punto ideal del tamaño. "Refactorizar esta función" es demasiado pequeño; simplemente indíquelo. "Construir un SaaS" es demasiado grande: el agente no tiene idea de lo que significa "hecho" y se disparará. "Compile la aplicación descrita en prd.md hasta que se verifiquen todas las tareas en productroadmap.mmd y se pase la compilación de producción" es exactamente el tamaño para el que se diseñó /goal.

Nota al margen: probé esto una mañana de fin de semana impulsado casi exclusivamente por el espresso y la terquedad. Los resultados podrían haber sido diferentes un lunes con mejor sueño. Pero lo dudo. La disciplina para redactar objetivos importa más que el modelo al que apuntas, que es la lección inesperada de los últimos dos meses.

Ejecute uno: Claude Code en /goal

Primero presioné /goal en Claude Code. Pegó la frase de gol. Observó.

El primer turno fue un turno de planificación. Claude Code leyó prd.md, leyó productroadmap.mmd, leyó design.md, leyó claude.md, luego imprimió un resumen de un párrafo de lo que estaba a punto de hacer y formuló una pregunta: "Varias tareas de la hoja de ruta hacen referencia a integraciones externas de API: Stripe para facturación, Reenvío para correo electrónico transaccional, Supabase para autenticación y persistencia ¿Tiene credenciales para estos, o debería compilar con datos simulados y clientes descartados para que la aplicación se ejecute sin conexión?

Esa única pregunta es el momento más importante para un ingeniero que he visto producir a un agente en la naturaleza. Identificó que la aplicación en realidad no se podía completar sin credenciales externas, reconoció que no había proporcionado ninguna y propuso una alternativa que le permitiría enviar algo ejecutable en lugar de detenerse. Le dije que construyera fuera de línea con simulacros y una lista TODO claramente marcada de puntos de integración, y continuó.

A partir de ahí continuó durante veintinueve minutos sin más preguntas.

El patrón fue el mismo en todos los turnos: elegir la siguiente tarea de la hoja de ruta no marcada, leer los archivos relevantes, escribir o modificar el código, ejecutar una validación enfocada (pnpm tsc --noEmit para cambios de tipo, pnpm lint para cambios de componentes, pnpm build después de hitos importantes), marcar la tarea en el archivo de la hoja de ruta y regresar al validador. El validador respondió "no" después de cada turno excepto el último. El "no" regresó con un motivo de una sola línea: "Fase 3, tarea 4 aún sin marcar" o "La última compilación pasó hace veinte minutos, verifique que todavía pasa después de los nuevos componentes", y el siguiente turno comenzó con ese motivo como primera entrada.

En el minuto veintinueve, el validador dijo "sí". Claude Code se detuvo, resumió lo que construyó y enumeró los puntos de integración TODO que había eliminado. Revisé el repositorio. Sesenta y dos tareas cumplieron. Construcción aprobada. Limpiar pelusas.

Luego leí la aplicación real.

La página de destino estaba repleta de textos. Jerarquía de encabezados real. Un bloque de testimonios con tres personajes citados que coincidían con la audiencia descrita en el PRD. Una tabla de precios con tres niveles, cada uno de ellos vinculado a un trabajo por realizar de la especificación. El panel tenía mucho texto pero estaba claramente estructurado: barra lateral con el selector de espacio de trabajo, una barra superior con el disparador de la paleta de comandos, un panel principal que por defecto era la cola de revisión. La cola de revisión en sí era una tabla densa con columnas ordenables, exactamente lo que había pedido design.md. Hubo un flujo de incorporación con tres pasos y una microcopia limpia.

Se burlaron de la autenticación. El inicio de sesión se redirige al panel después de un retraso falso. La sesión se almacenó en una cookie con un comentario TODO que apunta al punto de integración de Supabase. El botón de pago de Stripe abrió un modal que explicaba lo que sucedería cuando se conectara la integración. Cada integración externa era una costura claramente marcada, no una llamada rota.

Esta era la versión que le enviaría a un cliente para mostrarle cómo es su idea. No sobreviviría al contacto con un usuario que paga (la autenticación por sí sola es un incidente de seguridad a punto de ocurrir), pero sí sobreviviría absolutamente al contacto con una reunión de demostración del martes.

Total transcurrido: 32 minutos, 14 segundos. Dos ejecuciones del validador Haiku me costaron cuarenta y siete centavos. El gasto en tokens del agente principal fue, según la calculadora de costos, de $11,20 en Sonnet 4.6.

Ejecute dos: Codex CLI en /goal

Borré el directorio, restauré los archivos de especificaciones, presioné /goal en Codex.

Codex no hizo la pregunta sobre env-vars. Acaba de empezar.

Este es el primer lugar en el que los dos agentes divergieron de una manera importante. Codex asumió que tenía licencia para construir con simulacros en cualquier lugar donde faltaran credenciales externas. Que es, al final, lo que le habría dicho que hiciera de todos modos. Pero el comportamiento de Claude Code de hacer una pausa para confirmar es, para el trabajo de producción, el mejor valor predeterminado. El comportamiento de Codex de simplemente decidir es el camino más rápido cuando la especificación no es ambigua, y así es la mayor parte del tiempo.

El patrón de ejecución de Codex era casi idéntico al de Claude Code en el nivel de bucle (planificar, actuar, validar, repetir), pero la forma en que secuenciaba el trabajo era diferente. Claude Code fue fase por fase, terminando la Fase 1 por completo antes de tocar la Fase 2. Codex funcionó de forma más reticular: primero creó un andamiaje de todo el esqueleto de la aplicación (las seis fases de rutas vacías y apéndices de componentes), luego regresó y los rellenó. Esto es algo que he notado en múltiples ejecuciones de Codex y no es un error, es cómo se realiza la planificación. El modelo en Codex prefiere descomponer el trabajo. Primero construye la silueta del producto terminado y luego esculpe.

Minuto treinta y uno, el validador dijo que sí. Leí la aplicación.

Visualmente, la aplicación Codex era la más bonita. Tipografía más limpia (eligió Geist en lugar de Inter que Claude Code utilizó por defecto, que coincide con la conversación de diseño front-end que estoy empezando a ver entre la mayoría de los diseñadores de productos senior en 2026). La página de destino tenía imágenes reales del producto: Codex extrajo imágenes de marcador de posición de una colección Unsplash limpia en lugar de eliminar componentes Image con atributos src rotos como lo hizo Claude Code una vez durante una prueba anterior. Las pestañas estaban más limpias, los íconos eran redondeados y el sistema de acento de color extrajo acentos rojos del archivo de diseño de manera consistente en cada página.

Funcionalmente, Codex hizo algunas cosas que Claude Code no hizo. La cola de revisión tenía edición en línea: podía hacer clic en una pastilla de estado y cambiarla sin salir de la página. El sistema de filtrado de la cola tenía tres filtros funcionales más un menú desplegable de vista guardada. La página de configuración tenía una capa de información sobre herramientas que explicaba cada campo. Había un espacio de trabajo de demostración precargado con contenido falso, por lo que el estado vacío de cada página mostraba algo en lugar de un marcador de posición "agrega tu primer elemento".

Las pérdidas, porque siempre hay pérdidas: dos íconos estaban rotos: Codex hacía referencia a nombres de íconos lucide-react que no existen en la versión actual, y tuve que cambiarlos a mano. El respaldo de autenticación fue inteligente pero frágil: el cliente simulado tenía un 50% de posibilidades de devolver al usuario de demostración en la verificación de sesión, lo cual estoy bastante seguro fue un artefacto de cómo Codex escribió el código auxiliar y no un diseño deliberado. La copia de la página de destino era escasa en comparación con la de Claude Code: Codex puso el pulido visual en primer lugar y dejó que las palabras fluyeran.

Total transcurrido: 32 minutos, 42 segundos. Aproximadamente el mismo gasto simbólico. Aproximadamente la misma tasa de finalización de tareas.

Dos agentes. Misma especificación. Misma arquitectura de bucle. Diferentes productos.

El lado a lado: para qué optimizó cada agente

Aquí está la comparación que me hubiera gustado que me dieran antes de comenzar este experimento.

1.20 principal + $0.47 validador | Aproximadamente equivalente |

Si está buscando el titular: Claude Code escribió una mejor historia de producto, Codex escribió una mejor presentación del producto. La aplicación de Claude Code generaría mejores conversiones en una página de destino; La aplicación de Codex se sentiría mejor en una demostración del producto. Cuál es importante para usted depende completamente de lo que envíe.

Para mi propio flujo de trabajo, comencé a buscar Claude Code en for/goal donde el resultado tiene que comunicarse: páginas de destino, páginas de marketing, cualquier cosa que deba leerse como lo escribió una persona. Busco Codex en ejecuciones for/goal donde la salida tiene que comportarse: paneles, herramientas, aplicaciones internas con mucha superficie de interacción. Esa heurística se ha mantenido en aproximadamente una docena de ejecuciones desde entonces.

Qué significa esto para mi forma de construir

Permítanme alejarme, porque la implicación aquí es mayor que qué agente elegir.

Durante aproximadamente dieciocho meses, el patrón dominante en el desarrollo asistido por AI ha sido el ciclo de llamada y respuesta. Usted pregunta, el agente hace una cosa, usted revisa, vuelve a preguntar. Incluso los mejores flujos de trabajo que he creado, y he escrito sobre la mayoría de ellos, incluido el flujo de trabajo de dos agentes Claude Code y Codex y el bucle de planificación Claudeex, fueron variaciones de llamada y respuesta con un segundo par de ojos agregados.

For/goal rompe ese patrón. El agente no pide permiso. El agente tiene un destino, un presupuesto y un validador, y su trabajo antes de la ejecución es escribir el destino con suficiente claridad para que el validador pueda reconocer cuándo se ha alcanzado. Tu trabajo durante la carrera es estar en otra parte. Su trabajo después de la ejecución es leer el resultado y decidir qué es bueno.

Ese es un músculo diferente. Está más cerca de escribir un informe para un contratista que de programar en pareja. La habilidad está en la especificación, no en la indicación. Si su PRD es nítido, su hoja de ruta es granular y su documento de diseño es concreto, for/goal lo hace rápido de una manera que la generación anterior de agentes de codificación no pudo. Si alguno de esos tres es vago, for/goal producirá una ejecución bellamente completada que enviará el producto incorrecto.

La razón por la que esto es importante: por primera vez, el cuello de botella en la construcción asistida por AI no es el modelo. Es el trabajo de preparación. Y el trabajo de preparación es algo en lo que la mayoría de los ingenieros (incluido yo mismo) invierten poco porque no tienen ganas de construir. El cambio para las fuerzas /goal es que el trabajo de preparación se convierte en el edificio. El código está detrás de la especificación, y la especificación es donde ahora reside el juicio de ingeniería.

Hace seis meses les habría dicho que el futuro de la codificación era la orquestación de múltiples agentes: Claude Code hablando con Codex hablando con Gemini, con transferencias, ciclos de revisión y decisiones de consenso. Sigo pensando que eso es parte de esto. Pero for/goal me hizo darme cuenta de que hay un futuro más simple que se ejecuta en paralelo: un destino bien especificado, un agente capaz, una condición de parada verificable. Sin orquestación. Sin traspasos. Sólo un gol y un bucle.

Es menos interesante escribir artículos de reflexión sobre ese futuro. Es más interesante enviar el producto.

Los errores que cometí (y tú cometerás)

Tres errores de mis primeras diez ejecuciones de /goal, en caso de que desee saltarse la matrícula.

Error uno: le di a for/goal un objetivo vago. "Crear una herramienta de gestión de proyectos" en lugar de "compilar la aplicación descrita en prd.md hasta que se verifiquen todas las tareas de la hoja de ruta y se apruebe la compilación". El agente funcionó durante dos horas, produjo seis versiones diferentes de una página de configuración y nunca se detuvo porque no había ninguna señal concreta que el validador pudiera verificar. La solución: siempre apunte el validador a un archivo o comando, nunca a un sentimiento.

Error dos: Olvidé habilitar la aprobación automática. Sin ella, Claude Code en particular se detendrá para solicitar permiso para cada instalación de paquete, cada eliminación de archivo y cada comando de shell fuera de una pequeña lista blanca. Para una ejecución de sesenta y dos tareas, esto significa que el agente se detiene unas cuarenta veces para preguntar, lo que hace que el objetivo de la autonomía a largo plazo sea discutible. Habilítelo explícitamente en su oración de objetivo - "ejecutar con aprobación automática habilitada" - o configúrelo en su configuración antes de comenzar.

Error tres: dejé que el agente inventara la especificación dentro de la ejecución. Le di un resumen de una página y dije "descubre el resto". Lo descubrió. El resto no era lo que quería. For/goal no sustituye a pensar detenidamente lo que estás construyendo. Es un sustituto de escribir lo que ya has pensado. Esas son habilidades diferentes. El primero todavía vive contigo.

Hay una versión más profunda del error tres, sobre el que nadie escribe: los agentes de larga duración son muy buenos para hacer que cualquier especificación parezca correcta cuando finaliza. El producto final se verá pulido, pasará su propio validador, parecerá que completa cada tarea y será exactamente tan bueno como la especificación con la que comenzó, ni mejor. Si la especificación era delgada, el producto pulido es un producto delgado que lleva una camisa limpia. El agente no va a rechazar el pensamiento débil sobre el producto. Eso todavía depende de ti.

Esta es la parte de for/goal a la que es más necesario acostumbrarse, especialmente para los ingenieros que aprendieron a construir iterando con un compañero de equipo. El compañero de equipo ahora es el validador, y el validador está leyendo un archivo de hoja de ruta, no su pensamiento sobre la hoja de ruta. Si la hoja de ruta es incorrecta, el bucle construirá fielmente lo incorrecto. El trabajo que solía realizarse durante la implementación ahora debe realizarse antes de presionar Intro en el objetivo. Ese cambio mental es la única habilidad que separa a los ingenieros que realizan funciones de dos semanas en una tarde de los ingenieros que realizan funciones de dos semanas en ocho horas de ciclos frustrantes.

Todavía me estoy adaptando. La disciplina de escribir una hoja de ruta que un agente pueda ejecutar fielmente es realmente diferente de la disciplina de escribir una hoja de ruta que usted pueda ejecutar, porque usted y el agente fallan de diferentes maneras. Te vas a la deriva. El agente no. Compensas la ambigüedad ejerciendo tu juicio en el momento. El agente compensa la ambigüedad inventando detalles, a menudo erróneos. Por lo tanto, la hoja de ruta tiene que ser más estricta que la que usted mismo escribiría. Ésa es la nueva forma de la obra.

Cuándo buscar For/Goal y cuándo no

Tres categorías de trabajo en las que for/goal se gana el sustento:

Andamiaje de aplicación de primer paso a partir de una especificación clara. Exactamente el experimento de esta publicación. Tienes un PRD, una hoja de ruta, un documento de diseño. Quiere un caparazón ejecutable con la mayoría de las superficies en su lugar. For/goal es imbatible aquí. Treinta y dos minutos para lo que a un ingeniero novato le llevaría casi una semana.

Refactorizaciones de horizonte largo con estados finales medibles. "Migrar cada componente en este directorio de la sintaxis de clase a función hasta que pase pnpm tsc --noEmit". "Convierta todos los datos useEffect obtenidos en acciones del servidor hasta que ningún useEffect haga referencia a fetch en ninguna parte del código base". Cualquier cosa que tenga una condición de parada medible y una trayectoria mecánica. La gente de Ralph-loop ha estado haciendo esto durante un año; for/goal simplemente lo convierte en una característica de primera clase.

Campañas de corrección de errores. "Resuelva todos los errores TypeScript en el repositorio sin cambiar el comportamiento del tiempo de ejecución". El validador verifica el recuento de errores. El agente lo reduce a cero. Se va a casa.

Tres categorías en las que for/goal es la herramienta incorrecta:

Cualquier cosa que requiera valoración del producto en pleno vuelo. "Mejorar el flujo de incorporación". Eso no es un destino, es una opinión. El agente producirá algo. No producirá lo que desea a menos que primero haya escrito lo que desea en la especificación. Sólo indíquelo.

Cualquier cosa que tenga que ver con sistemas de producción. For/goal es para entornos donde el peor resultado es "el agente desperdició mi tarde". No "el agente borró una base de datos". La aprobación automática más el acceso a producción es una categoría de error que no me gustaría que ninguno de nosotros cometiera.

Cualquier cosa en la que el validador tenga que evaluar la calidad. Los modelos pequeños no pueden responder "¿este código es bueno?" seguramente. Pueden responder "¿este comando sale de cero?" seguramente. Diseñe su pregunta de validación en torno a en qué son buenos los modelos pequeños (sí, decisiones /no con señales concretas) o su ciclo se detendrá antes de tiempo o nunca se detendrá en absoluto.

Si su trabajo no encaja en esas tres categorías "buenas", probablemente desee el bucle de chat normal Claude Code o Codex, no for/goal.. La mayor parte de mi trabajo real todavía se encuentra en el chat normal. For/goal es la herramienta especializada a la que recurro dos o tres veces por semana, no el controlador diario.

Lo que ejecutaría diferente la próxima vez

Tres pequeñas cosas que cambiaré en mi próximo experimento for/goal.

Agregaría un archivo tests.md junto con prd.md y le pediría al agente que escriba pruebas de integración para las rutas críticas como Fase 0, antes de cualquier UI. Luego, las pruebas se convierten en la señal de parada del validador, que es mucho más fuerte que "todas las tareas de la hoja de ruta cumplidas". En este momento, el bucle confía en la verificación del propio agente de que la hoja de ruta esté completa; Si las pruebas fueran ciertas, el agente no podría mentirse a sí mismo.

Ajustaría el documento de diseño. Mi design.md tenía alrededor de trescientas palabras de preferencias. El próximo será de seiscientas palabras con patrones de componentes específicos llamados: tokens de espaciado exacto, escala de fuente exacta, jerarquía de botones exacta. Quiero darle al agente menos espacio para inventar juicios de diseño, porque los momentos en los que Claude Code y Codex divergieron más marcadamente fueron los momentos en los que el documento de diseño guardó silencio y cada uno eligió un valor predeterminado diferente.

Ejecutaría el mismo objetivo en ambos agentes y un tercero: Gemini 3 Pro a través de su nuevo CLI, que aún no he probado con esta duración de ejecución. Si dos agentes divergen tanto en la misma especificación, quiero saber qué me ofrece un tercero. Esa es una publicación para el próximo mes.

El cambio de mentalidad, expresado claramente

Esto es a lo que sigo volviendo.

Hace seis meses, crear una aplicación significaba escribir código con la ayuda de un agente. El agente fue un acelerador de la obra. Yo era el motor.

Hoy en día, con for/goal, crear una aplicación significa escribir una especificación con la ayuda de un agente, luego entregarla a un agente diferente y leer lo que regresa. El agente es el motor. Soy el arquitecto.

Esa frase es fácil de escribir y difícil de vivir. La mayoría de los días sigo abriendo el editor y escribiendo el primer componente yo mismo, porque ese es el movimiento que he hecho diez mil veces. La disciplina de no hacer eso (permanecer en el archivo de especificaciones durante una hora extra, escribir la pregunta del validador en lugar de la implementación) es la nueva habilidad. Los ingenieros que lo desarrollen primero son los que enviarán cinco productos en el tiempo que antes se tardaba en enviar uno.

Los dos terminales en mi monitor izquierdo a las 3:19 p. m. de ese miércoles por la tarde no fueron, en retrospectiva, la parte impresionante. Lo impresionante fueron las cuatro horas que dediqué el día anterior a escribir el PRD, la hoja de ruta y el documento de diseño. Los agentes ejecutaron en media hora lo que a mí me habría llevado una semana. El pensamiento que hizo posible la media hora todavía tomó el día.

Ese es el negocio. Estoy bastante seguro de que lo quiero.

Preguntas frecuentes

¿Qué es para /goal en Claude Code y Codex?

For/goal es un modo objetivo persistente en el que el agente trabaja de forma autónoma durante muchos turnos hasta que un pequeño modelo de validación confirma que se cumple una condición de finalización definida. En Claude Code, se envía como /goal en la versión 2.1.139; en Codex CLI, la misma primitiva se encuentra detrás de /goal y los comandos de barra diagonal relacionados en la versión 0.128.0. Consulte "Qué es realmente For/Goal" más arriba para conocer la mecánica completa.

¿Cuánto tiempo puede durar una ejecución de for/goal?

Las ejecuciones de For/goal están limitadas por el presupuesto que establezca (turnos, fichas o tiempo de reloj de pared) en lugar de por un límite máximo. He visto ejecuciones de andamiaje de 32 minutos y ejecuciones de refactorización nocturnas exitosas. El límite práctico es su presupuesto simbólico y su voluntad de dejar que el ciclo continúe sin supervisión.

¿For/goal es lo mismo que el bucle Ralph?

For/goal es una evolución del patrón de bucle Ralph. Ralph era un contenedor bash while true alrededor de un agente de codificación con un paso de verificación externo; for/goal incorpora la misma idea al propio agente con una arquitectura de supervisor incorporada y un gancho de parada con reconocimiento de estado. Misma forma, mecánica más limpia, mejor integración del validador.

¿Necesito un PRD para usarlo con /goal?

Necesita un destino claro basado en archivos. Un PRD más una hoja de ruta es la combinación más confiable, pero también puede señalar con /goal un conjunto de pruebas, un comando de compilación o una métrica medible. La regla es: el validador debe poder responder "¿se alcanzó el objetivo?" con una decisión de sí o no basada en una señal concreta, no en un juicio de calidad.

¿Cuál es mejor para for/goal: Claude Code o Codex?

Ninguno de los dos es estrictamente mejor. En mis pruebas, Claude Code produce resultados más comunicativos: páginas de destino, superficies de marketing, páginas con muchos textos que se leen como si las hubiera escrito una persona. Codex produce resultados más ricos en interacción: los paneles, las herramientas internas, las superficies con celdas editables y los filtros se sienten más pulidos desde el primer momento. Elige según lo que estás enviando.

Trabajemos juntos

¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
• Cartera: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y marca): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io