Codex /goal command: mijn eerlijke kijk op autonomous coding

Codex /goal command: mijn eerlijke kijk op autonomous coding

De eerste keer dat ik Codex een /goal gaf en wegliep van mijn bureau, kwam ik veertig minuten later terug en ontdekte dat dezelfde functie elf keer was herschreven. Elf. Elke versie een beetje anders. Geen van hen is objectief beter dan de vorige. De agent was aan het loopen - niet in de productieve Ralph-loop-zin, maar in de zin van "Ik heb geen idee wanneer ik moet stoppen". Mijn doel was "de weergave sneller maken." Dat was de hele prompt. Dat was het hele probleem.

Ik had een langlopende autonome agent een vaag doelwit gegeven en reageerde toen verbaasd toen hij afdwaalde.

Het commando Codex /goal verscheen eind april in versie 0.128.0 en verandert de vorm van wat een codering agent zou moeten doen. De meeste slash-commando's zijn reactief: je vraagt, het antwoordt, je vraagt ​​het opnieuw. /goal is het tegenovergestelde. U stelt één keer een doel en Codex blijft plannen, handelingen, testen, evalueren en herhalen herhalen, totdat het doel aantoonbaar is bereikt of u zegt dat het moet stoppen. Het komt het dichtst in de buurt van "vuur en vergeet". autonomous coding die ik heb gebruikt, voelt niet helemaal losgeslagen.

Maar 'voelt zich niet helemaal losgeslagen' doet veel werk in die zin. Omdat het verschil tussen een /goal-run die een prestatiewinst van 25% oplevert en een run die elf versies van dezelfde kapotte functie produceert, niet het model is. Het is ook niet de prompt. Het is iets subtielers – en als je het eenmaal ziet, kun je het niet meer ongedaan maken.

Ik heb de afgelopen twee weken binnen dit commando geleefd. Dit is wat ik heb geleerd, wat ik fout heb gedaan, en het raamwerk dat ik nu gebruik om te beslissen of een werkstuk thuishoort in een /goal-run of in een normaal pull-verzoek.

Wat de Codex /goal-opdracht eigenlijk is

Laat ik eerst de marketingtaal van dit ding verwijderen, omdat de OpenAI changelog – zoals altijd – extreem beknopt is over wat er is verzonden.

De opdracht Codex /goal is een persistente objectieve modus voor de Codex CLI. Je geeft het een doel. Het geeft de controle niet terug na één reactie. Het brengt uw repo in kaart, plant, bewerkt bestanden, voert tests uit, evalueert het resultaat aan de hand van uw stopcriteria en verklaart het doel voltooid of start een nieuwe iteratie. De agent blijft bij veel gereedschapsoproepen aan de draad vastzitten. Het overleeft contextlimieten vanwege de manier waarop Codex de status comprimeert en hergebruikt. Het registreert de voortgang. Het respecteert de goedkeuringsregels.

Dit is geen chat. Het is een werkproces met een checklist.

Het werd geleverd als een experimentele functie, wat OpenAI-taal is voor "dit is echt, maar we plaatsen het nog niet op de startpagina." U schakelt het handmatig in uw configuratiebestand in, voert Codex uit in uw terminal en een kleine reeks nieuwe slash-opdrachten verschijnt in de TUI.

Hier is het daadwerkelijke opdrachtoppervlak vanaf Codex CLI 0.128.0:

• /goal <objective> — stel een langlopend doel in en start de lus
• /goal pause — voltooi de huidige stap en pauzeer vervolgens
• /goal resume — hervat een gepauzeerd doel
• /goal clear — wis het actieve doel volledig
• /goal (geen argumenten) — toon voortgang, tokengebruik en verstreken tijd
• /side <prompt> — open een zijthread om een vraag te stellen zonder het hoofddoel te verstoren; terugschakelen met de escape-toets

De opdracht /side is het onderdeel waar niemand over praat, en het is stiekem de beste functie in de bundel. Daarover later meer.

Voordat ik inga op het gebruik van dit alles: er is één ding in de bronvideo die ik heb bekeken dat niet klopt, en je bespaart jezelf een frustrerende middag als je het nu weet.

Het enige configuratiedetail dat iedereen fout heeft

De walkthrough die ik oorspronkelijk volgde, vertelde me dat ik doelen moest inschakelen in config.yml. Ik heb twintig minuten verward doorgebracht met de vraag waarom er niets gebeurde voordat ik de daadwerkelijke Codex-documentatie controleerde.

Codex CLI gebruikt geen YAML. Er wordt gebruik gemaakt van TOML.

Het bestand is ~/.codex/config.toml en de vlag bevindt zich onder een [features]-tabel. Het minimale enable-blok ziet er als volgt uit:

[features]
goals = true

U kunt dit ook doen vanaf de opdrachtregel: codex features enable goals schrijft dezelfde waarde naar hetzelfde bestand. Hoe dan ook, sla het bestand op, start Codex opnieuw op en de opdrachten /goal en /side verschijnen in het slash-opdrachtpalet. Als dat niet het geval is, hebt u het verkeerde bestand bewerkt of gebruikt u een Codex-versie ouder dan 0.128.0. Voer codex --version uit om te bevestigen.

Zodra features.goals = true globaal is ingesteld, werkt de functie in zowel de Codex CLI als de Codex-app. U hoeft het slechts één keer in te schakelen, in de CLI, en het verspreidt zich.

Klein detail. Groot verschil tussen "dit werkt" en "ik verspil een uur."

Laten we, nu dat uit de weg is, eens praten over wat er werkelijk toe doet – en dat is wanneer je dit commando in de eerste plaats zou moeten gebruiken, omdat het antwoord luidt: ‘veel minder vaak dan je zou denken’.

De twee soorten codeerwerk – en waarom /goal verkeerd is voor een van hen

Hier is het mentale model dat me een week van misbruik kostte om op te landen.

Bijna elk stukje codeerwerk dat ik doe valt in een van de twee categorieën. De categorieën zien er van buitenaf hetzelfde uit. Een senior ingenieur kan ze meestal binnen ongeveer dertig seconden uit elkaar houden. Een coderende agent – en eerlijk gezegd, veel junior-ingenieurs – kunnen ze helemaal niet uit elkaar houden. En /goal is slechts het juiste hulpmiddel voor één van hen.

Categorie één: duidelijk omschreven werk. Je kent de input. Je kent de opbrengst. Je weet ongeveer hoe het verschil eruit ziet voordat je begint. "Integreer de Notion API zodat we klantoverzichten kunnen synchroniseren met de database van een project." "Voeg een Stripe webhook-handler toe die logt in onze bestaande gebeurtenistabel." "Migreer het gebruikersmodel van op e-mail gebaseerde naar op UUID gebaseerde primaire sleutels." Deze taken hebben een vorm. Er is een eindig aantal bestanden dat moet worden gewijzigd, er is een duidelijke definitie van klaar, en het pad is grotendeels mechanisch als je er tien minuten over hebt nagedacht.

Voor dit soort werk is /goal overdreven, grenzend aan schadelijk. Je wilt geen zelfevaluatielus. U wilt een schone PR. U wilt dat de agent precies doet wat u vraagt, de controle teruggeeft en u de mogelijkheid geeft om te beoordelen. De standaard Codex-workflow – één prompt, één antwoord, normale beoordeling – gaat hier uitstekend mee om. Ik schrijf over hoe ik die lus uitvoer in mijn [uitsplitsing van de Codex en Claude Code twee-agent workflow] (https://www.mejba.me/blog/claude-code-codex-two-agent-workflow), en 90% van mijn echte werk bevindt zich daar nog steeds.

Categorie twee: verkennend werk. Dit is waar het doel bekend is, maar het pad niet. "Verminder de P95-latentie op deze API met 20%." "Verminder onze geheugenvoetafdruk op de werkpool." "Zoek en corrigeer de lay-outverschuiving waardoor onze Lighthouse-score op mobiel instort." U kunt het gewenste resultaat beschrijven met een statistiek. Je kunt het verschil echter niet vooraf beschrijven. De oplossing kan een configuratiewijziging zijn, een queryoptimalisatie, een coderefactor, een algoritmewissel – of een combinatie van alle vier die achter elkaar worden ontdekt na het uitvoeren van profilers.

Dit is waarvoor /goal is gebouwd. De redeneringslus – plannen, handelen, testen, evalueren, herhalen – heeft precies de juiste vorm voor verkenning. Je stelt een controleerbaar doel en laat de agent malen. Het probeert iets. De tests vertellen of de verandering de metriek heeft verplaatst. Zo ja, dan probeert het verder te gaan. Als dat niet het geval is, trekt hij zich terug en probeert hij een andere hoek.

Het verhaal van 25% FPS-verbetering dat je zult zien rondgaan in Codex-demo's? Dat is categorie twee. Iemand gaf Codex een renderprestatieprobleem met een duidelijk meetbaar doel en liet het urenlang draaien. Ze wisten niet welke optimalisatie zou landen voordat ze begonnen. De agent heeft ontdekt wat hij moet proberen en wat hij moet behouden.

Het diepere inzicht hier, dat ik op de harde manier heb moeten leren: de meeste ingenieurs blijven standaard categorie één denken, zelfs als ze aan categorie twee problemen werken. Ze proberen de oplossing te specificeren voordat ze de zoekruimte hebben begrepen. /goal dwingt je om dat om te draaien: je moet je verbinden aan de bestemming zonder je aan de route te binden. Dat is ongemakkelijk. Het is ook waar de hefboomwerking zit.

Maar het werkt alleen als je bestemming reëel is. Dat brengt ons bij de discipline die elke doelloop maakt of breekt.

Verifieerbaarheid van doelen is het hele spel

Kijk wat er gebeurt als je Codex een vaag doel geeft.

Ik heb /goal make the search faster geprobeerd in een klein Laravel-zijproject. Codex begon met het uitvoeren van de bestaande zoekopdracht, waarbij een basislijn (goed) werd verkregen. Vervolgens werd een index toegevoegd voor de meest bevraagde kolom (goed). Vervolgens werd opnieuw een benchmark uitgevoerd en werd een verbetering van 14% (goed) gevonden. Daarna bleef het doorgaan. Het heeft caching van queryresultaten toegevoegd. Vervolgens werd de zoekcontroller gerefactored. Vervolgens werd een Redis-laag toegevoegd. Vervolgens stelde het een full-text zoekmigratie voor naar Meilisearch. Op geen enkel moment hield het op, omdat ik het op geen enkel moment had verteld wat ‘snel genoeg’ betekende.

Codex injecteert aan het begin van elke iteratie een systeeminstructie die in essentie zegt: "Behandel onzekerheid als niet bereikt." Het is een vangrail tegen valse claims van voltooiing. Maar het snijdt aan twee kanten. Als uw doel echt niet verifieerbaar is – als er geen meetwaarde, geen checklist, geen test is die een goede uitslag kan opleveren – dan zal de agent het doel voortdurend als niet bereikt beschouwen. Het blijft herhalen totdat je geen tokens, geduld of geld meer hebt.

De oplossing is eenvoudig te beschrijven en verrassend moeilijk uit te voeren. Elke /goal die u instelt, moet twee dingen bevatten:

1. Een concreet doel. Ofwel een statistiek ("P95 onder 250 ms"), een geslaagde test ("alle e2e-tests in tests/checkout/ groen"), of een verifieerbare checklist ("dashboardzijbalk toont de Filament-beheerderslink, geautomatiseerde tests zijn geslaagd, geen nieuwe consolefouten in het buildlogboek").
2. Een definitie van gedaan die de agent zichzelf kan controleren. Nee "totdat het er goed uitziet." Geen "totdat de prestaties acceptabel zijn." De agent moet een commando kunnen uitvoeren, een resultaat kunnen observeren en op basis van die observatie kunnen beslissen.

Vergelijk deze twee aanwijzingen. Dezelfde bedoeling. Heel ander gedrag:

• Slecht: /goal speed up the dashboard
• Goed: /goal Reduce dashboard initial paint from current 2.4s baseline to under 1.0s on the staging environment. Success criteria: Lighthouse performance score above 90 on /dashboard, all existing e2e tests in tests/dashboard/ continue to pass, no new TypeScript errors in the build.

De eerste is een wens. De tweede is een contract. Codex kan contracten vervullen. Het kan geen wensen vervullen – en erger nog, het zal doen alsof het het probeert.

Als ik niet zeker weet hoe ik het contract moet schrijven, doe ik iets wat de OpenAI Codex-documentatie expliciet aanbeveelt en dat ik nu weiger over te slaan: ik brainstorm eerst over het doel met Codex, in de normale chatmodus, voordat ik /goal uitvoer. Ik beschrijf het probleem. Ik vraag Codex welke verifieerbare succescriteria het zou voorstellen. Ik maak er ruzie mee. Ik scherp de criteria aan. Dan, en alleen dan, open ik een schone thread en voer ik /goal uit met het verfijnde contract. Die brainstormstap is misschien tien minuten werk en het heeft me uren aan verspilde tokenuitgaven bespaard.

Wat Codex feitelijk doet zodra het doel begint

Laat me door de lus lopen, omdat de mechanica ertoe doet.

Wanneer u /goal <objective> typt, doet Codex iets dat er onopvallend uitziet, maar feitelijk de basis vormt van alles wat volgt: het brengt de repository in kaart. Het leest bestandsstructuren, sleutelconfiguraties en pakketmanifesten. Het schetst een model van wat uw project is en hoe het is aangesloten. Dit is niet gratis (het kost tokens), maar het is het verschil tussen een agent die plausibel ogende code schrijft en een die code schrijft die daadwerkelijk bij uw codebase past. In mijn stuk over context engineering onderzoek ik waarom dit soort contextladen vooraf belangrijk is, en /goal is een van de duidelijkste uitdrukkingen van dat principe in elk huidig ​​AI-hulpmiddel.

Dan is het van plan. Codex schetst een reeks stappen waarvan hij denkt dat deze naar het doel zullen leiden. Het kiest de eerste stap. Het voert het uit. Het "draaien" kan van alles zijn: bestanden bewerken, shell-opdrachten uitvoeren, tests uitvoeren, een API gebruiken, logboeken lezen. Dan evalueert het. Heeft de stap de metriek verplaatst? Heeft het de tests doorstaan? Voldeed het aan een checklistitem?

Zo ja, dan kiest het de volgende stap. Zo nee, dan probeert het een variant of trekt zich terug en probeert een andere hoek. De lus gaat verder.

Je kunt dit in realtime zien gebeuren en het is echt hypnotiserend. Er zit een ritme in. Lezen, schrijven, testen, observeren, beslissen. De agent wacht niet op u. Het werkt gewoon.

Terwijl het werkt, kunt u opdrachten geven. /goal pause voltooit de huidige stap en stopt de lus netjes - geen half toegepaste bewerkingen, geen verweesde tooloproepen. /goal resume gaat verder waar het gebleven was. /goal zonder argumenten toont u een voortgangsoverzicht, tokenuitgaven en verstreken tijd zonder iets te onderbreken.

En dan is er /side.

/side <prompt> opent een kortstondige zijlijn die het hoofddoel niet verstoort. De hoofdlus blijft lopen. U kunt Codex een vraag stellen: "wacht, wat is ook alweer het verschil tussen een debounced en een gesmoorde scroll-handler?" – en krijg een antwoord in een aparte context, en ontsnap dan terug naar de rode draad om het doel te blijven zien lopen. Dit klinkt klein. Dat is het niet. Vóór /side verbrak elke onderbreking de stroom van agent. Met /side kunt u beslissingen controleren, niet-gerelateerde informatie opzoeken of zelfs een klein verhelderend experiment starten, allemaal zonder de context van het hoofddoel te vergiftigen.

Deze enkele functie zorgde ervoor dat ik /goal begon te vertrouwen voor langere runs. Het vermogen om te vragen zonder te onderbreken verandert de relatie van 'Ik moet me volledig inzetten en hopen' in 'Ik kan toezicht houden zonder te saboteren'.

Het verdichtingsprobleem dat niemand ziet aankomen

Hier worden de zaken technisch en ontstaat het verschil tussen een productieve /goal-run en een gedoemde run.

Langlopende agents verzamelt context. Elke tooloproep, elk gelezen bestand, elk testresultaat: het stapelt zich allemaal op in de gespreksgeschiedenis. Uiteindelijk kom je in het contextvenster van het model terecht, en er moet iets gebeuren. Codex handelt dit af met de prompt compaction. Het vat eerdere wijzigingen samen in een strakkere opdracht en gaat van daaruit verder.

Verdichting klinkt eenvoudig. Dat is niet zo.

Goede compaction behoudt wat belangrijk is: het doel, de huidige staat van het werk, de dingen die werkten, de dingen die faalden en waarom, de beperkingen, de voorkeuren van de gebruiker. Na een goede compaction gaat de agent verder waar hij was gebleven en voelt het werk continu aan. Slechte compaction verwijdert de zwaarbevochten context: de specifieke reden waarom een ​​eerdere aanpak mislukte, de configuratiekeuze die een benchmark geldig maakte, de afweging die de gebruiker expliciet koos. Na een slechte compaction probeert de agent opnieuw mislukte benaderingen, stelt opnieuw vaste vragen en drijft langzaam af van de oorspronkelijke bedoeling.

Ik heb dit zien gebeuren bij een echt project. Codex voerde een /goal uit om een ​​databasequerypijplijn te optimaliseren. Rond de derde compaction verloor het het feit dat ik expliciet had afgemeld voor denormalisatie. Het suggereerde opnieuw denormalisatie. Ik ving het op omdat ik keek, maar als ik AFK was geweest, zou de agent een uur hebben besteed aan het volgen van een pad dat ik al had afgesloten.

Er is goed onderzoek vanuit de gemeenschap over hoe Codex compaction eigenlijk onder de motorkap werkt - Simon Zhou's onderzoek en de bredere compaction onderzoeksoverzicht zijn beide de moeite waard als je de details van de machinekamer wilt weten. De korte versie: compaction-kwaliteit is een functie van hoe het agent-harnas samenvat, wat het behoudt en wat het weggooit. Codex is hier redelijk goed in, maar niet perfect, en langere doelen benadrukken dit meer.

De praktische implicatie voor /goal-gebruikers is klein maar belangrijk: schrijf uw doeldefinitie in het soort taal dat compaction overleeft. Gebruik specifieke nummers. Gebruik benoemde bestanden en functies. Vermeld de beperkingen expliciet met 'niet doen' in plaats van 'liever niet'. Alles wat u één keer zegt en ervan uitgaat dat de agent het zich zal herinneren, loopt gevaar. Alles wat u in de doeldefinitie zelf invoegt, wordt bij elke iteratiegrens opnieuw geïnjecteerd, wat betekent dat het elke compaction overleeft.

Ik schrijf mijn doeldefinities nu alsof ik een contract schrijf dat aan het begin van elke bijeenkomst hardop moet worden voorgelezen, want dat is feitelijk wat er gebeurt.

Milieu is belangrijker dan modelkeuze

Dit is het deel van /goal dat mij het meest verraste.

Ik ging ervan uit dat het verschil tussen een geweldige run en een middelmatige run zou neerkomen op welk model ik koos. Dat gebeurde niet. De grootste variabele in de /goal-kwaliteit is, met een ruime marge, de omgeving waarin de agent zal werken.

Een /goal-run is slechts zo goed als de signalen die beschikbaar zijn voor de agent. Als het doel is "de P95-latentie met 20% te verminderen" en de agent geen manier heeft om de P95-latentie te meten, is het doel in de praktijk niet te verifiëren, hoe netjes je het ook hebt geschreven. De agent raadt het. Het zal optimaliseren wat het kan zien, hopen dat dit correleert met wat het niet kan zien, en veranderingen produceren die de werkelijke metriek wel of niet kunnen veranderen.

Rijke omgevingen produceren geweldige /goal-runs. Rijk betekent:

• Echte logboeken. Applicatielogboeken, gestructureerd en opvraagbaar, idealiter vanuit een testomgeving die het productiegedrag weerspiegelt.
• Een staging- of testcluster. Gedistribueerd als het doel iets netwerkgerelateerds betreft. De agent moet een verandering kunnen doorvoeren, implementeren en observeren.
• Kosten- en prestatiestatistieken. Live, opvraagbaar, met duidelijke basislijnen. Als de agent de huidige nummers niet kan ophalen, kan hij niet beslissen of het klaar is.
• Vlamgrafieken en profilers. Voor prestatiewerk is dit niet bespreekbaar. De agent zal geen warm pad vinden door alleen de broncode te lezen.
• Volledige toegang tot de codebase met toestemming om wijzigingen aan te brengen, tests uit te voeren en de git-status te inspecteren. Een /goal-run die voor elke opdracht toestemming moet vragen, zal zijn tijd verspillen aan goedkeuringsprompts in plaats van aan voortgang.

Voor risicovolle of resource-intensieve doelen (alles wat urenlang de CPU zal belasten, een database zal hameren of een lange benchmarksuite zal draaien) voer ik ze niet uit op mijn lokale computer. Ik start een cloud-VPS, kloon de repo daar, voer Codex uit vanuit een SSH-sessie en laat het werken. Het gaat niet alleen om de kosten van grondstoffen. Het gaat erom dat mijn laptopventilator zes uur lang niet schreeuwt terwijl een benchmarkloop draait. Het gaat erom de omgeving te isoleren, zodat "de agent iets kapot heeft gemaakt" binnen de perken blijft.

Als u de uitvoering van cloud-based agent hebt uitgesteld, is dit het gebruiksscenario dat uiteindelijk de juiste instelling ervan rechtvaardigt. Ik behandel het bredere patroon in [mijn langlopende agent-harnasbeschrijving] (https://www.mejba.me/blog/anthropic-long-running-agent-harness), en /goal past net zo netjes in dat patroon als alles wat ik heb gezien.

De scrappy branch trap – en de PRD-lus die dit oplost

Dit is het meest contra-intuïtieve wat ik heb geleerd over /goal-runs, en het is de les waarvan ik wou dat iemand mij die had gegeven voordat ik begon.

De uitvoer van een succesvolle /goal-run is bijna nooit code die u zou moeten verzenden.

Die zin zal verkeerd klinken als je hem niet hebt geleefd. Laat het me uitleggen.

Een /goal-run is per definitie verkennend. De agent zoekt naar een oplossing die hij niet op voorhand kent. Het pad dat daarvoor nodig is, omvat doodlopende wegen, debug-afdrukinstructies, hardgecodeerde waarden die worden gebruikt voor het testen, opmerkingen zoals // TODO: revisit this hack en snelkoppelingen die lokaal werkten maar de codebeoordeling niet zullen overleven. De agent is niet lui. Het doet precies hoe verkennend werk eruit ziet als een mens het doet: iets werkend krijgen, de aanpak valideren en vervolgens opruimen. Behalve dat /goal meestal geen tijd, tokens of geduld meer heeft vóór de opruimfase.

Wat je uiteindelijk krijgt is wat ik nu een ‘scrappy branch’ noem. Het werkt. Het verplaatst de metriek. Het voldoet aan de doeldefinitie. Vaak is het ook een absolute puinhoop.

De eerste paar keer dat ik /goal uitvoerde, probeerde ik deze branch's rechtstreeks samen te voegen. Altijd een vergissing. Twee weken later vond ik debug-afdrukken in de productiecode. Ik zou een hack vinden die afhankelijk was van een specifiek bestand dat alleen in de werkmap van agent bestond. Ik zou benaderingen vinden die het onmiddellijke doel oplosten, maar subtiele technische schulden introduceerden.

De oplossing is een workflow, geen configuratievlag. Zodra een /goal-run met succes is voltooid, beschouw ik het resultaat als een proof of concept en niet als een resultaat. Ik heb het diff aandachtig doorgelezen. Ik haal er het inzicht uit – de daadwerkelijke techniek die het probleem heeft opgelost. Vervolgens schrijf ik een korte PRD waarin ik beschrijf wat ik heb geleerd: de aanpak, de afwegingen, de beperkingen, de onderdelen die hebben gewerkt en de onderdelen die moeten worden opgeschoond.

Dan gooi ik de rommelige branch weg.

Ik open een nieuwe thread, geef Codex de PRD als een schone specificatie en voer een normale taak uit (categorie één werk, volgens mijn eerdere definitie) om hetzelfde inzicht te implementeren tegen een schone codebase. Het resultaat is dramatisch beter. Geen foutopsporingsafdrukken. Geen hacks. Geen opgehoopt littekenweefsel uit de exploratiefase. Gewoon een zuivere implementatie van een aanpak waarvan inmiddels is bewezen dat hij werkt.

Dit tweefasige patroon – verkenning via /goal en vervolgens implementatie via de normale workflow – is het AI-coderingspatroon met de hoogste hefboomwerking dat ik dit jaar heb gevonden. Het weerspiegelt hoe goede menselijke ingenieurs daadwerkelijk aan moeilijke problemen werken. Jij onderzoekt. Jij leert. Je gooit de piek weg. Jij bouwt het echte werk.

Een paar ingenieurs in de Ralph-loop-gemeenschap hebben op vergelijkbare wijze over PRD-aangedreven autonomous coding geschreven, en de convergentie is geen toeval. Het patroon werkt omdat het twee soorten cognitie scheidt die de agent niet tegelijkertijd zou moeten doen: uitzoeken wat je moet bouwen, en het goed bouwen.

Mijn beslissingskader voor /goal versus normale workflow

Na twee weken testen is dit de beslissingsboom die ik nu gebruik voordat ik naar /goal ga:

Vraag 1: Kunt u het verschil beschrijven voordat u begint?

• Zo ja → standaardworkflow. Schrijf een gerichte prompt, krijg een gericht antwoord, bekijk de PR. /goal voegt hier niets toe.
• Zo nee → ga verder met vraag 2.

Vraag 2: Kunt u het doel omschrijven als een verifieerbaar, meetbaar resultaat?

• Zo ja → /goal ligt op tafel. Doorgaan.
• Zo nee → je bent er niet klaar voor. Brainstorm over het doel in de normale modus totdat u een schoon contract kunt schrijven.

Vraag 3: Heeft de agent toegang tot de signalen die hij nodig heeft om te verifiëren?

• Zo ja → /goal is het juiste hulpmiddel. Voer het uit.
• Zo nee → repareer eerst de omgeving. Voeg statistieken toe. Voeg een faseringscluster toe. Voeg echte logboeken toe. Evalueer dan opnieuw.

Vraag 4: Nadat de run is voltooid: behandelt u de output als een resultaat of als een piek?

• Behandel het als een piek. Altijd. Distilleer het inzicht in een PRD. Voer een schone implementatiepas uit volgens de verfijnde specificaties. Stuur dat.

Dat is het. Dat is het raamwerk. Het heeft me echt geld aan tokens en echte uren aan opruimwerk bespaard, en het is de lens waardoor ik nu elke /goal-demo op Twitter lees.

Als iemand je vertelt dat /goal de verzonden code rechtstreeks naar de hoofdpagina voert, zou ik heel beleefd vragen hoe hun bugpercentage er over twee weken uitziet. Omdat ik daar ben geweest. De eerste run is bedwelmend. Het opruimen is waar de les leeft.

Waar ik denk dat dit de volgende stap is

/goal is experimenteel. Het gaat snel evolueren. Een paar dingen waar ik naar kijk:

De grens tussen /goal-verkenning en gestructureerde taakuitvoering zal vervagen. Het PRD-looppatroon dat ik hierboven heb beschreven, zal waarschijnlijk in de tool zelf worden ingebakken (destilleren, refactoren, implementeren) in plaats van te leven als een handmatige workflow erbovenop. Zodra dat gebeurt, wordt de kloof tussen "Ik had een idee" en "Ik heb een schone PR" dramatisch kleiner.

Het milieuprobleem zal worden opgelost met betere standaardinstellingen. Op dit moment is het een hele klus om een ​​/goal te krijgen die voldoende signalen bevat om zijn eigen werk te verifiëren. De meeste projecten hebben dit niet. De volgende golf agent-tools wordt geleverd met beheerde staging-omgevingen, ingebouwde observatiemogelijkheden en doelsjablonen voor algemene optimalisatiedoelen. We zijn er nog niet. Dat zullen we binnenkort zijn.

De kwaliteitsverschillen tussen de AI-codeertools compaction zullen een belangrijke selectiefactor worden. Op dit moment kiezen de meeste ingenieurs een codering agent op basis van het model. Over een jaar gaan ze een keuze maken op basis van hoe het harnas de context beheert tijdens urenlange autonome runs. Codex, Claude Code, Anthropic's beheerde agents - het model is niet de gracht. Het harnas is.

Als je deze ruimte wilt blijven volgen, schrijf ik elke week over nieuwe AI-coderingstools, en de [Codex / Claude Code-dekking is waar de meeste praktische lessen terechtkomen] (https://www.mejba.me/blog/codex-vs-claude-code-subscription).

Veelgestelde vragen

Hoe schakel ik de opdracht Codex /goal in?

Voeg [features] gevolgd door goals = true toe aan uw ~/.codex/config.toml-bestand, sla het op en start de Codex CLI opnieuw. U kunt ook codex features enable goals uitvoeren, waardoor automatisch dezelfde waarde wordt geschreven. Controleer dit door codex --version uit te voeren en te bevestigen dat u 0.128.0 of hoger gebruikt. /goal en /side verschijnen in het slash-opdrachtpalet zodra ze zijn ingeschakeld.

Is het veilig om de opdracht Codex /goal zonder toezicht uit te voeren?

Het is veiliger dan het uitvoeren van een willekeurige Ralph-lus, maar ik zou het niet volledig onbeheerd laten draaien op productie-aangrenzende code. Gebruik een cloud-VPS of een geïsoleerde omgeving, stel een tokenbudget in en bekijk de resulterende branch zorgvuldig. Behandel de output als een piek, niet als een resultaat – zie het rommelige branch-gedeelte hierboven.

Wanneer moet ik /goal gebruiken versus een normale Codex-prompt?

Gebruik /goal alleen voor verkennend werk waarbij u de bestemming kent, maar niet de route: prestatie-optimalisaties, vertragingsreducties, onderzoek naar de bug. Gebruik normale aanwijzingen voor elke taak waarbij u het verschil kunt beschrijven voordat u begint. Het meeste echte codeerwerk valt in de tweede categorie.

Wat is het verschil tussen /goal en /side in Codex CLI?

/goal stelt een blijvend doel en start een langlopende autonome lus. /side opent een tijdelijk nevengesprek dat een actief doel niet verstoort. U kunt vragen stellen, informatie opzoeken of kleine experimenten uitvoeren terwijl het hoofddoel blijft lopen. Schakel terug naar de hoofdthread met de escape-toets.

Waarom eindigt mijn /goal-run nooit?

Bijna altijd omdat het doel niet verifieerbaar is. Codex injecteert 'behandel onzekerheid als niet bereikt' in elke iteratie, zodat een vaag doel als 'het sneller maken' voor onbepaalde tijd blijft herhalen. Herschrijf het doel als een concreet contract – specifieke metriek, benoemde tests, expliciete checklist – en de lus eindigt correct wanneer aan de criteria is voldaan.

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