For/Goal getest: Claude Code vs Codex bouwde mijn app in 32 min

For/Goal getest: Claude Code vs Codex bouwde mijn app in 32 min

Ik startte de timer op woensdag om 14:47 uur. Om 15:19 uur waren twee terminalvensters op mijn linkermonitor klaar met het opzetten van een werkende Next.js-applicatie: onboardingstroom, dashboard, landingspagina, auth-schermen, de hele vorm van een echt product. Tweeënzestig routekaarttaken. Beide apps. Tweeëndertig minuten elk. Ik was mijn koffie aan het bijvullen.

Dit is het deel waarin de demomensen op Twitter gewoonlijk een time-lapse van dertig seconden maken en er een einde aan maken. Ik wil je de daadwerkelijke naden laten zien. Omdat de for/goal-functie – de langlopende autonome lus die in Claude Code 2.1.139 is geland en wordt verzonden in Codex CLI 0.128.0 – alleen maar op magie lijkt. Daaronder staat een heel specifiek recept, en dat recept is het verschil tussen een agent die binnen een half uur een echte app verzendt en een agent die voor altijd blijft herhalen en dezelfde kapotte functie herschrijft totdat je het proces uit medelijden beëindigt.

Ik gebruik for/goal bijna elke dag sinds de functie is verdwenen. Twee parallelle projecten. Dezelfde productspecificatie. Dezelfde routekaart in zes fasen. Eén uitvoering in Claude Code, één in Codex. Beide klaar. Beiden produceerden iets dat ik kon git clone en demonstreerde het morgen aan een klant. Ze produceerden ook zeer verschillende apps vanuit dezelfde prompt, en de verschillen vertellen u precies welke agent u moet bereiken en wanneer.

Dit is de inzinking die ik graag had gehad voordat ik begon.

Wat For/Goal eigenlijk is - en waarom het niet zomaar een Slash-commando is

Laat ik eerst de marketingtaal uit de weg ruimen.

For/goal is een persistente objectieve modus. Je stelt één keer een doel, de agent werkt daar vele beurten doorheen – soms uren, soms een hele dag – en een tweede, kleiner model controleert na elke beurt of het doel ook daadwerkelijk wordt bereikt. Als de validator nee zegt, krijgt het hoofdmodel dat 'nee' plus een reden van één zin en blijft het werken. Als de validator ja zegt, eindigt de lus en geeft uw terminal de controle terug. Dat is de hele vorm ervan.

In Claude Code is de opdracht letterlijk /goal. Het werd geleverd in versie 2.1.139, uitgebracht begin mei 2026. De validator draait op welk model je ook hebt geconfigureerd als je kleine, snelle model (standaard Haiku) en de tokenkosten van de validator worden afzonderlijk van het hoofdbeurtbudget gefactureerd, wat van belang is als je zes uur lang een doel uitvoert.

In Codex CLI is het opdrachtoppervlak hetzelfde idee. Codex roept de lusprimitief for/goal aan, en de slash-opdrachten in versie 0.128.0 zijn /goal, /goal pause, /goal resume, /goal clear, plus een /side-thread voor het stellen van een snelle vraag zonder de hoofdrun te verstoren. Dezelfde architectuur: het hoofdmodel doet het werk, het kleine model beoordeelt de voltooiing.

Dit is, mechanisch gezien, een evolutie van het Ralph-looppatroon – de bash-oneliner die ingenieurs als Adam Tuttle en de snarktank repo de afgelopen twaalf maanden in een methodologie hebben omgezet. Ralph was een while true-wikkel rond uw codeeragent, met een verificatiecommando aan de andere kant van de lijn. For/goal neemt dat idee over en vouwt het in de agent zelf, met een echte supervisorarchitectuur en een statusbewuste stophook.

Dit is het deel dat me drie runs kostte om te internaliseren: dit is geen chat meer. Het is een werkproces met een checklist. Je praat er niet mee. U stelt de bestemming in en controleert of de bestemming bereikbaar is. De makelaar doet de rest.

Dat klinkt eenvoudig. Dat is het niet, en ik zal je laten zien waarom.

De opzet: één PRD, twee agenten, tweeënzestig taken

De testapp was een tool voor het beoordelen van inhoud, iets tussen een werkruimte in Notion-stijl en een wachtrij voor videoannotaties. Niets wereldschokkends. Ik heb ervoor gekozen omdat de reikwijdte groot genoeg was om interessant te zijn (er was verificatie, een werkruimteconcept, een beoordelingswachtrij, een onboarding-stroom en een instellingenpagina nodig), maar klein genoeg zodat ik elk bestand kon lezen dat de agent had gemaakt en je kon vertellen wat er werkelijk stond.

De specificatie was vijf bestanden in de projectroot voordat ik iets anders aanraakte:

• prd.md — het document met productvereisten. Ongeveer 1.400 woorden. Doelgroep, probleem, de drie kerntaken die de app moest uitvoeren, het datamodel in gewoon Engels en een lijst met items die buiten het bereik vallen, zodat de agent niet in functies terechtkomt die ik niet wilde. - productroadmap.mmd — een Zeemeermin-routekaart met zes fasen en tweeënzestig bladtaken. Fase 1 was het steigeren en de authenticatie, Fase 2 was het werkruimteconcept, Fase 3 was de beoordelingswachtrij, enzovoort tot en met Fase 6, dat het oppoetsen en onboarding was. - design.md — front-end richting. Kleurenpalet, typografiestapel, voorkeuren voor lay-outdichtheid ("dichte tabelweergaven over kaartrasters voor wachtrijpagina's") en een lijst met componenten die ik verwachtte te zien (gegevenstabellen, slide-over-panelen, opdrachtpalet). - claude.md — Claude Code's regelbestand op projectniveau.

Stack vastgemaakt aan Next.js 15 App Router, TypeScript strict, Tailwind v4, shadcn/ui, geen Redux, geen styled-componenten, serveracties voor mutaties. - agents.md — Het equivalente regelbestand van Codex met dezelfde beperkingen, geschreven in het voorkeursformaat van Codex.

Het doel dat ik elke agent gaf was woord voor woord identiek:

Bouw de volledige app zoals beschreven in prd.md en volg de taken in productroadmap.mmd totdat alle taken zijn voltooid en geverifieerd. Gebruik design.md voor front-end ontwerprichting. Nieuwe Next.js-app gebouwd. Uitvoeren met automatische goedkeuring ingeschakeld. Ga door totdat de validator bevestigt dat elke routekaarttaak is gecontroleerd en de app is opgebouwd en opgeschoond.

Die doelzin doet veel werk. Laat me uitpakken wat ervoor zorgt dat het een autonome run van dertig minuten overleeft, want ik heb drie eerdere pogingen met zwakkere fraseringen verbrand voordat ik hier aankwam.

De zinsnede "totdat alle taken zijn voltooid en geverifieerd" is de stopvoorwaarde. Het wijst de validator op iets concreets om te controleren – het routekaartbestand – in plaats van hem te vragen de kwaliteit te evalueren, iets wat kleine modellen vreselijk doen. "Fresh Next.js app build" is het bereikplafond. Het vertelt de agent "probeer niet te integreren met iets dat al in deze map bestaat, u bezit de hele boom." En "Uitvoeren met automatisch goedkeuren ingeschakeld" is de toestemmingsverlening. Zonder deze toestemming zal met name Claude Code elke veertig seconden stoppen om te vragen of het een pakket mag installeren.

Je zult zien wat er gebeurt als een van die clausules in een paar secties ontbreekt. Blijf rond voor het gedeelte over fouten in de tweede helft.

Hoe u een For/Goal-doel schrijft dat daadwerkelijk wordt voltooid

Dit is het deel dat ik wil vertragen, omdat het verschil tussen een doelreeks die wordt voltooid en een doelreeks die voor altijd blijft herhalen, bijna altijd de doelzin zelf is.

Een werkend for/goal-doel bestaat uit vier delen, in deze volgorde:

1. Wat te bereiken. Een meetbare eindtoestand. Niet 'maak het leuk'. Niet "de UX verbeteren." Iets waar de validator ja-of-nee op kan lezen en antwoorden zonder een oordeel te vellen. "Alle tweeënzestig routekaarttaken zijn in het bestand als voltooid gemarkeerd." "Productieopbouw gaat door." "Alle toneelschrijvers testen groen."

2. Wat te veranderen. Reikwijdte. Welke bestanden, welke mappen en welke oppervlakken de agent mag aanraken. Als je dit overslaat, zullen autonome agenten aangrenzende code herstructureren op weg naar het doel, en krijg je een diff van dertig pagina's met negen bestanden die je nooit had willen aanraken.

3. Wat te valideren. Het daadwerkelijke commando of signaal waar de validator naar moet zoeken. "pnpm build verlaat nul." "Het routekaartbestand bevat nul niet-aangevinkte items." Dit wordt na elke beurt aan het kleine, snelle model doorgegeven.

4. Wanneer moet u stoppen. De uitgangsvoorwaarde. Meestal hetzelfde als het validatiesignaal, maar soms wil je riem en bretels – "stop wanneer de validator bevestigt EN de integratietests minstens één keer zijn uitgevoerd."

Een doel dat groter is dan een enkele prompt, maar kleiner dan een open achterstand. Dat is de goede maat. "Refactor this function" is te klein - vraag er gewoon om. "Bouw een SaaS" is te groot: de agent heeft geen idee wat gedaan betekent en zal in een spiraal terechtkomen. "Bouw de app beschreven in prd.md totdat elke taak in productroadmap.mmd is gecontroleerd en de productiebuild is voltooid" is precies het formaat waarvoor /goal is ontworpen.

Kanttekening: ik heb dit getest op een weekendochtend, bijna volledig gevoed door espresso en koppigheid. De resultaten waren misschien anders op een maandag met een betere nachtrust. Maar ik betwijfel het. De discipline bij het schrijven van doelen is belangrijker dan het model waarop je het richt, en dat is de onverwachte les van de afgelopen twee maanden.

Voer er één uit: Claude Code op /goal

Ik raakte eerst /goal in Claude Code. De doelzin geplakt. Bekeken.

De eerste beurt was een planningsbeurt. Claude Code lees prd.md, lees productroadmap.mmd, lees design.md, lees claude.md, druk vervolgens een samenvatting van één alinea af van wat het ging doen en stelde één vraag: "Verschillende roadmaptaken verwijzen naar externe API-integraties - Stripe voor facturering, Opnieuw verzenden voor transactionele e-mail, Supabase voor auth en doorzettingsvermogen. Heb je hier inloggegevens voor, of moet ik bouwen met nepgegevens en stubbed-clients zodat de app offline werkt?'

Die ene vraag is het meest senior engineer-moment dat ik ooit een agent in het wild heb zien produceren. Het stelde vast dat de app eigenlijk niet kon worden voltooid zonder externe referenties, erkende dat ik die niet had verstrekt, en stelde een uitwijkmogelijkheid voor waardoor de app iets uitvoerbaars kon verzenden in plaats van vast te lopen. Ik zei dat het offline moest worden gebouwd met proefmodellen en een duidelijk gemarkeerde TODO-lijst met integratiepunten, en het bleef doorgaan.

Van daaruit duurde het negenentwintig minuten zonder nog een vraag.

Het patroon was elke keer hetzelfde: kies de volgende niet-gecontroleerde routekaarttaak, lees de relevante bestanden, schrijf of wijzig de code, voer een gerichte validatie uit (pnpm tsc --noEmit voor typewijzigingen, pnpm lint voor componentwijzigingen, pnpm build na belangrijke mijlpalen), vink de taak aan in het routekaartbestand en keer terug naar de validatie. De validator antwoordde na elke beurt "nee", behalve de laatste. Het 'nee' kwam terug met een reden van één regel - 'Fase 3, taak 4 nog steeds niet aangevinkt' of 'Build is twintig minuten geleden geslaagd, controleer of het nog steeds lukt na de nieuwe componenten' - en de volgende beurt begon met die reden als eerste invoer.

Op minuut negenentwintig zei de validator "ja". Claude Code stopte, vatte samen wat het had gebouwd en somde de TODO-integratiepunten op die het had verwijderd. Ik heb de repository gecontroleerd. Er waren tweeënzestig taken aangevinkt. Bouw geslaagd. Pluisjes schoon.

Toen las ik de daadwerkelijke app.

De landingspagina was rijk aan teksten. Echte kophiërarchie. Een testimonialsblok met drie geciteerde persona's die overeenkwamen met het publiek beschreven in de PRD. Een prijstabel met drie niveaus, elk verankerd aan een uit te voeren taak uit de specificatie. Het dashboard was veel tekst, maar duidelijk gestructureerd: zijbalk met de werkruimtewisselaar, een bovenste balk met de trigger voor het opdrachtpalet, een hoofdpaneel dat standaard op de beoordelingswachtrij stond. De beoordelingswachtrij zelf was een compacte tabel met sorteerbare kolommen, precies waar design.md om had gevraagd. Er was een onboarding-stroom met drie stappen en een schone microkopie.

De auteur werd bespot. Login doorgestuurd naar het dashboard na een nepvertraging. De sessie werd opgeslagen in een cookie met een TODO-opmerking die naar het Supabase-integratiepunt verwijst. De Stripe-afrekenknop opende een modaal waarin werd uitgelegd wat er zou gebeuren als de integratie was bedraad. Elke externe integratie was een duidelijk gemarkeerde naad, geen gebroken lijn.

Dit was de versie die ik naar een klant zou sturen om te laten zien hoe hun idee eruit ziet. Het zou het contact met een betalende gebruiker niet overleven – de auth alleen al is een beveiligingsincident dat nog moet gebeuren – maar het zou absoluut het contact met een demobijeenkomst op dinsdag overleven.

Totaal verstreken: 32 minuten, 14 seconden. Twee Haiku-validatorruns kostten me zevenenveertig cent. De tokenuitgaven van de hoofdagent waren volgens de kostencalculator $ 11,20 op Sonnet 4.6.

Voer twee uit: Codex CLI op /goal

Ik heb de map leeggemaakt, de spec-bestanden hersteld en op /goal in Codex gedrukt.

Codex heeft de env-vars-vraag niet gesteld. Het is net begonnen.

Dit is de eerste plaats waar de twee agenten uiteen gingen op een manier die er toe doet. Codex ging ervan uit dat het een licentie had om te bouwen met namaak overal waar externe referenties ontbraken. Dat is – uiteindelijk – wat ik het sowieso zou hebben opgedragen. Maar Claude Code's gedrag van pauzeren om te bevestigen is voor productiewerk de betere standaard. Codex's gedrag van alleen maar beslissen is het snellere pad als de specificaties ondubbelzinnig zijn, en dat is meestal het geval.

Het uitvoeringspatroon van Codex was vrijwel identiek aan dat van Claude Code op lusniveau (plannen, handelen, valideren, herhalen), maar de manier waarop het werk werd geordend was anders. Claude Code ging fase voor fase verder en voltooide fase 1 volledig voordat hij fase 2 aanraakte. Codex werkte meer roostervormig: het zette eerst het volledige app-skelet in de steigers (de lege routes en componentstubs van alle zes fasen), ging vervolgens terug en vulde ze in. Dit is iets dat ik heb opgemerkt tijdens meerdere Codex-runs en het is geen bug - zo is het planningsmodel in elkaar gezet. Codex geeft er de voorkeur aan om werk te ontbinden. Er wordt eerst het silhouet van het eindproduct opgebouwd en vervolgens gebeeldhouwd.

Minuut eenendertig, de validator zei ja. Ik heb de app gelezen.

Visueel was de Codex-app de mooiste. Schonere typografie (er werd Geist verkozen boven de Inter waar Claude Code standaard voor koos, wat overeenkomt met het front-end ontwerpgesprek dat ik in 2026 bij de meeste senior productontwerpers begin te zien). De landingspagina bevatte echte productafbeeldingen: Codex haalde tijdelijke afbeeldingen uit een schone Unsplash-verzameling in plaats van Image-componenten met kapotte src-attributen te verwijderen, zoals Claude Code dat ooit deed tijdens een eerdere test. Tabbladen waren schoner, pictogrammen waren afgerond en het kleuraccentsysteem trok consistent rode accenten uit het ontwerpbestand op elke pagina.

Functioneel deed Codex een aantal dingen die Claude Code niet deed. De beoordelingswachtrij had inline bewerking: u kon op een statuspil klikken en deze wijzigen zonder de pagina te verlaten. Het filtersysteem in de wachtrij had drie werkende filters plus een vervolgkeuzelijst met opgeslagen weergaven. De instellingenpagina had een tooltiplaag waarin elk veld werd uitgelegd. Er was een demowerkruimte die vooraf was gevuld met nep-inhoud, zodat de lege status van elke pagina iets liet zien in plaats van een tijdelijke aanduiding voor 'voeg je eerste item toe'.

De verliezen, omdat er altijd verliezen zijn: twee pictogrammen waren kapot — Codex verwijst naar lucide-react-pictogramnamen die niet bestaan ​​in de huidige versie, en ik moest ze met de hand omwisselen. De auth-fallback was slim maar kwetsbaar: de nepclient had 50% kans om de demogebruiker terug te sturen bij sessiecontrole, waarvan ik vrij zeker ben dat het een artefact was van hoe Codex het stub schreef en geen opzettelijk ontwerp. De tekst op de landingspagina was schaars in vergelijking met die van Claude Code. Codex plaatste visuele verfijning op de eerste plaats en liet de woorden de vrije loop.

Totaal verstreken: 32 minuten, 42 seconden. Ongeveer dezelfde tokenuitgaven. Ongeveer hetzelfde voltooiingspercentage voor taken.

Twee agenten. Zelfde specificatie. Dezelfde lusarchitectuur. Verschillende producten.

Naast elkaar: waar elke agent voor heeft geoptimaliseerd

Hier is de vergelijking die ik mij graag had willen geven voordat ik aan dit experiment begon.

1,20 hoofd + $0,47 validator | Ongeveer gelijkwaardig |

Als je op zoek bent naar de kop: Claude Code schreef een beter productverhaal, Codex schreef een betere productshell. De app van Claude Code zou beter converteren op een landingspagina; De app van Codex zou beter aanvoelen in een productdemo. Welke voor u van belang is, hangt volledig af van wat u verzendt.

Voor mijn eigen workflow ben ik begonnen met het zoeken naar Claude Code op for/goal, waarbij de uitvoer moet communiceren: landingspagina's, marketingpagina's, alles dat moet worden gelezen zoals iemand het heeft geschreven. Ik reik naar Codex op for/goal-runs waarbij de uitvoer zich moet gedragen: dashboards, tools, interne apps met veel interactieoppervlak. Die heuristiek heeft sindsdien ongeveer een dozijn runs aangehouden.

Wat dit betekent voor de manier waarop ik bouw

Laat me uitzoomen, omdat de implicatie hier groter is dan welke agent ik moet kiezen.

Ongeveer achttien maanden lang was het dominante patroon in de door AI ondersteunde ontwikkeling de call-and-response-lus. U vraagt, de agent doet één ding, u beoordeelt en u vraagt ​​opnieuw. Zelfs de beste workflows die ik heb gebouwd (en ik heb over de meeste ervan geschreven, inclusief de Claude Code en Codex twee-agent workflow en de Claudeex planningsloop – waren variaties op call-and-response met een tweede paar ogen toegevoegd.

For/goal doorbreekt dat patroon. De agent vraagt ​​geen toestemming. De agent heeft een bestemming, een budget en een validator, en jouw taak vóór de run is om de bestemming duidelijk genoeg op te schrijven zodat de validator kan herkennen wanneer deze is bereikt. Jouw taak tijdens de vlucht is om ergens anders te zijn. Jouw taak na de run is om de uitvoer te lezen en te beslissen wat goed is.

Dat is een andere spier. Het is dichter bij het schrijven van een opdracht voor een aannemer dan bij het koppelen van programmeren. De vaardigheid zit in de specificatie, niet in de aanwijzingen. Als uw PRD scherp is, uw routekaart gedetailleerd en uw ontwerpdocument concreet, maakt for/goal u snel op een manier die de vorige generatie codeeragenten niet kon. Als een van deze drie vaag is, zal for/goal een prachtig voltooide run produceren die het verkeerde product verzendt.

De reden dat dit ertoe doet: voor het eerst is het knelpunt in AI-ondersteund bouwen niet het model. Het is het voorbereidende werk. En voorbereidend werk is iets waar de meeste ingenieurs – waaronder ikzelf – te weinig in investeren omdat het niet voelt als bouwen. De verschuiving voor de /goal-krachten is dat voorbereidend werk het gebouw wordt. De code bevindt zich stroomafwaarts van de specificatie, en in de specificatie leeft nu het technische oordeel.

Ik had je zes maanden geleden verteld dat de toekomst van coderen orkestratie door meerdere agenten was: Claude Code praatte met Codex praatte met Gemini, met overdrachten, beoordelingslussen en consensusbeslissingen. Ik denk nog steeds dat dat erbij hoort. Maar for/goal deed me beseffen dat er een eenvoudiger toekomst parallel loopt: één goed gespecificeerde bestemming, één bekwame agent, één verifieerbare stopvoorwaarde. Geen orkestratie. Geen hand-offs. Gewoon een doel en een lus.

Die toekomst is minder interessant om denkstukken over te schrijven. Het is interessanter om het product te verzenden.

De fouten die ik heb gemaakt (en die jij zult maken)

Drie fouten uit mijn eerste tien for/goal-runs, voor het geval je het lesgeld wilt overslaan.

Fout één: ik gaf for/goal een vaag doel. "Bouw een projectmanagementtool" in plaats van "bouw de app die wordt beschreven in prd.md totdat alle routekaarttaken zijn gecontroleerd en de build is voltooid." De agent was twee uur bezig, produceerde zes verschillende versies van een instellingenpagina en stopte nooit omdat er geen concreet signaal was dat de validator moest controleren. De oplossing: wijs de validator altijd op een bestand of een opdracht, nooit op een gevoel.

Fout twee: ik vergat automatisch goedkeuren in te schakelen. Zonder dit zal vooral Claude Code pauzeren om toestemming te vragen voor elke pakketinstallatie, elk bestand dat wordt verwijderd, elk shell-commando buiten een kleine witte lijst. Voor een reeks van tweeënzestig taken betekent dit dat de agent ongeveer veertig keer stopt om vragen te stellen, wat het hele punt van langdurige autonomie ter discussie stelt. Schakel het expliciet in uw doelzin in ('uitvoeren met automatische goedkeuring ingeschakeld') of stel het in uw configuratie in voordat u begint.

Fout drie: ik liet de agent de specificatie tijdens de run uitvinden. Ik gaf het een brief van één pagina en zei: "zoek de rest uit." Het kwam er wel uit. De rest was niet wat ik wilde. For/goal is geen vervanging voor het nadenken over wat u bouwt. Het is een vervanging voor typen waar je al over hebt nagedacht. Dat zijn verschillende vaardigheden. De eerste woont nog steeds bij jou.

Er is een diepere versie van fout drie, waar niemand over schrijft: langlopende agenten zijn er heel goed in om elke specificatie er goed uit te laten zien tegen de tijd dat ze klaar zijn. Het eindproduct ziet er gepolijst uit, zal zijn eigen validator doorstaan, zal elke taak lijken te voltooien - en zal precies zo goed zijn als de specificaties waarmee u bent begonnen, niet beter. Als de specificatie dun was, is het gepolijste product een dun product met een schoon shirt. De agent zal het zwakke productdenken niet terugdringen. Dat is nog steeds jouw zaak.

Dit is het deel van for/goal waar je het meest aan moet wennen, vooral voor ingenieurs die hebben leren bouwen door te herhalen met een teamgenoot. De teamgenoot is nu de validator, en de validator leest een routekaartbestand, niet jouw routekaartdenken. Als de routekaart verkeerd is, zal de lus getrouw het verkeerde bouwen. Het werk dat vroeger tijdens de implementatie gebeurde, moet nu gebeuren voordat u op Enter drukt bij het doel. Die mentale verschuiving is de enige vaardigheid die het onderscheid maakt tussen de technici die features van twee weken in een middag klaar krijgen, en de technici die features van twee weken in acht uur frustrerende loops klaar krijgen.

Ik ben nog steeds aan het aanpassen. De discipline van het schrijven van een routekaart die een agent getrouw kan uitvoeren, verschilt wezenlijk van de discipline van het schrijven van een routekaart die jij kunt uitvoeren, omdat jij en de agent op verschillende manieren falen. Jij drijft. De agent niet. Je compenseert dubbelzinnigheid door op dit moment een oordeel te vellen. De agent compenseert dubbelzinnigheid door details te verzinnen, die vaak verkeerd zijn. Het stappenplan moet dus strakker zijn dan degene die je voor jezelf zou schrijven. Dat is de nieuwe vorm van het werk.

Wanneer moet u naar For/Goal reiken — en wanneer niet

Drie categorieën werk waar for/goal zijn brood mee verdient:

First-pass app-steiger op basis van een duidelijke specificatie. Precies het experiment in dit bericht. Je hebt een PRD, een routekaart, een ontwerpdocument. U wilt een beloopbare schaal waarvan de meeste oppervlakken op hun plaats zitten. For/goal is hier onverslaanbaar. Tweeëndertig minuten, wat een junior ingenieur het grootste deel van een week zou kosten.

Refactoren met een lange horizon met meetbare eindstatussen. "Migreer elke component in deze map van klasse- naar functiesyntaxis totdat pnpm tsc --noEmit passeert." "Converteer alle useEffect-gegevens die worden opgehaald naar serveracties totdat useEffect nergens in de codebase naar fetch verwijst." Alles met een meetbare stopvoorwaarde en een mechanisch pad. De Ralph-loop-mensen doen dit al een jaar; for/goal maakt het gewoon tot een eersteklas functie.

Bugfix-campagnes. "Los elke TypeScript-fout in de opslagplaats op zonder het runtime-gedrag te veranderen." De validator controleert het aantal fouten. De agent werkt het terug tot nul. Gaat naar huis.

Drie categorieën waarin for/goal de verkeerde tool is:

Alles waarvoor productbeoordeling halverwege de vlucht vereist is. "Verbeter de onboarding-stroom." Dat is geen bestemming, dat is een mening. De agent zal iets produceren. Het levert niet op wat je wilde, tenzij je eerst in de specificatie schreef wat je wilde. Vraag het gewoon.

Alles wat met productiesystemen te maken heeft. For/goal is voor omgevingen waar de slechtste uitkomst is "de agent heeft mijn middag verspild". Niet 'de agent heeft een database gewist'. Automatisch goedkeuren plus toegang tot productie is een categorie fouten die ik niemand van ons zou willen laten maken.

Alles waarbij de validator de kwaliteit moet evalueren. Kleine modellen kunnen niet antwoorden "is deze code goed?" betrouwbaar. Ze kunnen antwoorden: "Verlaat dit commando nul?" betrouwbaar. Ontwerp uw validatorvraag rond waar kleine modellen goed in zijn – ja/no beslissingen met concrete signalen – anders stopt uw ​​lus vroeg of stopt helemaal nooit.

Als je werk niet in deze drie "goede" categorieën past, wil je waarschijnlijk de reguliere Claude Code- of Codex-chatloop, niet voor/goal.. Het grootste deel van mijn echte werk leeft nog steeds in de normale chat. For/goal is het specialistische hulpmiddel dat ik twee of drie keer per week gebruik, niet de dagelijkse bestuurder.

Wat ik de volgende keer anders zou doen

Drie kleine dingen die ik zal veranderen in mijn volgende for/goal-experiment.

Ik zou naast prd.md een tests.md-bestand toevoegen en de agent vragen om integratietests voor de kritieke paden te schrijven als Fase 0, vóór elke UI. De tests worden dan het stopsignaal van de validator, dat veel sterker is dan 'alle routekaarttaken zijn aangevinkt'. Op dit moment vertrouwt de lus op de controle van de agent zelf of de routekaart compleet is; als de tests de waarheid waren, kon de agent niet tegen zichzelf liegen.

Ik zou het ontwerpdocument aanscherpen. Mijn design.md bestond uit ongeveer driehonderd woorden met voorkeuren. De volgende zal bestaan ​​uit zeshonderd woorden met specifieke componentpatronen die worden opgeroepen: exacte spatiëringtokens, exacte lettertypeschaal, exacte knophiërarchie. Ik wil de agent minder ruimte geven om ontwerpoordeel uit te vinden, omdat de momenten waarop Claude Code en Codex het scherpst uiteenliepen, de momenten waren waarop het ontwerpdocument zwijgde en ze elk een andere standaard kozen.

Ik zou hetzelfde doel bereiken in beide agents en een derde: Gemini 3 Pro via de nieuwe CLI, die ik tijdens deze run nog niet heb getest. Als twee agenten zoveel van elkaar verschillen op dezelfde specificatie, wil ik weten wat een derde mij geeft. Dat is een bericht voor volgende maand.

De mentaliteitsverandering, duidelijk uitgedrukt

Hier kom ik steeds op terug.

Zes maanden geleden betekende het bouwen van een app dat ik code moest schrijven met hulp van een agent. De agent was een versneller van het werk. Ik was de motor.

Tegenwoordig betekent het bouwen van een app met for/goal dat ik een specificatie schrijf met hulp van een agent, de specificatie vervolgens aan een andere agent overhandig en lees wat er terugkomt. De agent is de motor. Ik ben de architect.

Die zin is gemakkelijk te typen en moeilijk om te leven. De meeste dagen open ik nog steeds standaard de editor en schrijf ik het eerste onderdeel zelf, want dat is de zet die ik al tienduizend keer heb gedaan. De discipline om dat niet te doen – om een ​​extra uur in het specificatiebestand te blijven, om de validatorvraag te schrijven in plaats van de implementatie – is de nieuwe vaardigheid. De ingenieurs die het als eerste ontwikkelen, zijn degenen die vijf producten zullen verzenden in de tijd die nodig was om er één te verzenden.

De twee terminals op mijn linkermonitor om 15:19 uur die woensdagmiddag waren achteraf gezien niet het indrukwekkende deel. Het indrukwekkende deel waren de vier uur die ik de dag doorbracht voordat ik de PRD, de routekaart en het ontwerpdocument schreef. De agenten voerden in een half uur uit wat mij een week zou hebben gekost. Het denken dat het halfuur mogelijk maakte, nam nog steeds de dag in beslag.

Dat is de handel. Ik ben er vrij zeker van dat ik het wil.

Veelgestelde vragen

Wat is voor/goal in Claude Code en Codex?

For/goal is een persistente objectieve modus waarin de agent autonoom over vele beurten werkt totdat een klein validatormodel bevestigt dat aan een gedefinieerde voltooiingsvoorwaarde is voldaan. In Claude Code wordt het verzonden als /goal in versie 2.1.139; in Codex CLI leeft dezelfde primitief achter de /goal en gerelateerde slash-opdrachten in versie 0.128.0. Zie "Wat For/Goal eigenlijk is" hierboven voor de volledige werking.

Hoe lang kan een for/goal-run duren?

Voor/goal-runs worden begrensd door het budget dat u instelt (beurten, tokens of wandkloktijd) en niet door een hard plafond. Ik heb 32 minuten durende steigerruns gezien en nachtelijke refactorruns zijn allebei succesvol. Het praktische plafond is uw symbolische budget en uw bereidheid om de lus zonder toezicht door te laten gaan.

Is for/goal hetzelfde als de Ralph-lus?

For/goal is een evolutie van het Ralph-luspatroon. Ralph was een bash while true-wrapper rond een codeeragent met een externe verificatiestap; for/goal vouwt hetzelfde idee in de agent zelf met een ingebouwde supervisorarchitectuur en een statusbewuste stophook. Dezelfde vorm, schonere mechanica, betere validatorintegratie.

Heb ik een PRD nodig om te gebruiken voor/goal?

U hebt een duidelijke, op bestanden gebaseerde bestemming nodig. Een PRD plus een routekaart is de meest betrouwbare combinatie, maar u kunt /goal ook verwijzen naar een testsuite, een build-opdracht of een meetbare metriek. De regel is: de validator moet kunnen antwoorden "is het doel bereikt?" met een ja-of-nee-beslissing gebaseerd op een concreet signaal, niet op een kwaliteitsoordeel.

Wat is beter voor /goal — Claude Code of Codex?

Geen van beide is strikt genomen beter. In mijn tests produceert Claude Code meer communicatieve output: landingspagina's, marketingoppervlakken, pagina's met veel tekst die worden gelezen alsof iemand ze heeft geschreven. Codex produceert meer interactierijke uitvoer: dashboards, interne tools, oppervlakken met bewerkbare cellen en filters voelen direct verzorgder aan. Kies op basis van wat u verzendt.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io