This is the skill that matters most. Codex is only as good as the brief you give it. The good news: you already know how to do this — it's the same as clearly delegating to a smart colleague. We'll give you a simple four-part recipe and a habit that quietly doubles your results.
Dit is de belangrijkste vaardigheid. Codex is zo goed als de briefing die je geeft. Het goede nieuws: je kunt dit al — het is hetzelfde als helder delegeren aan een slimme collega. We geven je een eenvoudig recept in vier delen en een gewoonte die je resultaten stilletjes verdubbelt.
Each conversation with Codex is called a thread — exactly like a chat in ChatGPT. You type in the box at the bottom (the Composer), Codex responds and acts, and the back-and-forth builds up in the thread. You can run several threads at once for different tasks, and switch between them.
Start a new thread for each distinct task. Keeping "tidy my reports" and "build a calculator" in separate threads keeps Codex focused and keeps your history readable.
Elk gesprek met Codex heet een thread — precies als een chat in ChatGPT. Je typt in het vak onderaan (de Composer), Codex antwoordt en handelt, en het heen-en-weer bouwt zich op in de thread. Je kunt meerdere threads tegelijk draaien voor verschillende taken en ertussen wisselen.
Start een nieuwe thread voor elke aparte taak. "Mijn rapporten opschonen" en "een rekenmachine bouwen" in aparte threads houdt Codex gefocust en je geschiedenis leesbaar.
OpenAI's own guidance for good results is to put four things in your request. Remember them as Goal, Context, Constraints, Done:
What you want, in one clear sentence. "Turn these notes into a one-page summary."
Which files or folders to use. Point Codex at them with an @ mention, e.g. "@notes.txt".
Your rules and preferences. "Keep it formal, in Dutch, no longer than 300 words."
How you'll know it worked. "Done when the summary is saved as summary.docx and you've told me the three key points."
You won't always need all four, but the "Done when" part is the secret ingredient most people skip. Telling Codex how to check its own work dramatically improves quality — it can verify before handing back.
OpenAI's eigen advies voor goede resultaten is om vier dingen in je verzoek te zetten. Onthoud ze als Doel, Context, Beperkingen, Klaar:
Wat je wilt, in één heldere zin. "Maak van deze notities een samenvatting van één pagina."
Welke bestanden of mappen te gebruiken. Wijs Codex erop met een @-vermelding, bijv. "@notities.txt".
Je regels en voorkeuren. "Houd het formeel, in het Nederlands, maximaal 300 woorden."
Hoe je weet dat het werkte. "Klaar wanneer de samenvatting is opgeslagen als samenvatting.docx en je me de drie kernpunten hebt gegeven."
Je hebt niet altijd alle vier nodig, maar het "Klaar wanneer"-deel is het geheime ingrediënt dat de meesten overslaan. Codex vertellen hoe het zijn eigen werk kan controleren, verbetert de kwaliteit enorm — het kan verifiëren voordat het teruggeeft.
For anything bigger than a one-liner, ask Codex to plan before it acts. Codex has a Plan mode (you can type /plan) where it gathers context and asks you clarifying questions before changing anything. This is the "explain before doing" behavior, and it's gold for non-coders: you catch misunderstandings while they're still free to fix.
A reliable opener: "Before you change anything, tell me your plan and ask me any questions." Read the plan, correct it, then say "go ahead."
For longer efforts there's also Goal mode (/goal), where you set a persistent objective and completion criteria and let Codex work toward it across several steps.
Voor alles wat groter is dan een eenregelig verzoek: vraag Codex om te plannen voordat het handelt. Codex heeft een Plan-modus (typ /plan) waarin het context verzamelt en je verhelderende vragen stelt voordat het iets wijzigt. Dit is het "uitleggen voor het doen"-gedrag, en goud voor niet-programmeurs: je vangt misverstanden af terwijl ze nog gratis te herstellen zijn.
Een betrouwbare opener: "Voordat je iets wijzigt, geef je plan en stel me eventuele vragen." Lees het plan, corrigeer het, zeg dan "ga je gang."
Voor langere klussen is er ook Goal-modus (/goal), waar je een blijvend doel en criteria voor "klaar" instelt en Codex er in meerdere stappen naartoe laat werken.
| ❌ Vague | ✅ Clear |
|---|---|
| "Sort out my data." | "Take @sales.csv, remove duplicate rows, and save a clean copy as sales-clean.csv. Done when you tell me how many duplicates you removed." |
| "Make a summary." | "Summarize @meeting.txt into 5 bullet points and a list of action items with owners. Keep it in Dutch." |
| "Build me a tool." | "Build a simple one-page web tool that converts euros to dollars. Plan it first, then build. Done when I can open it in a browser and type an amount." |
Notice the pattern: name the file, state the goal, add a constraint, define "done." The clear versions aren't longer because they're fancy — they're longer because they're specific.
| ❌ Vaag | ✅ Helder |
|---|---|
| "Regel mijn data." | "Neem @verkoop.csv, verwijder dubbele regels, en sla een schone kopie op als verkoop-schoon.csv. Klaar wanneer je me vertelt hoeveel duplicaten je verwijderde." |
| "Maak een samenvatting." | "Vat @vergadering.txt samen in 5 bullets en een lijst met actiepunten met eigenaren. Houd het in het Nederlands." |
| "Bouw een tool voor me." | "Bouw een eenvoudige webpagina die euro's naar dollars omrekent. Plan het eerst, bouw daarna. Klaar wanneer ik het in een browser kan openen en een bedrag kan typen." |
Zie het patroon: noem het bestand, geef het doel, voeg een beperking toe, definieer "klaar." De heldere versies zijn niet langer omdat ze chic zijn — ze zijn langer omdat ze specifiek zijn.
When Codex proposes changes, it shows them to you as a diff (a before/after view) before they're final. You don't have to understand every line — you're checking "is this roughly what I asked for?" If not, just say so in plain language: "The tone is too casual, make it formal," or "You changed the wrong file, I meant the one in the reports folder." Codex adjusts and tries again.
Working with Codex is a conversation, not a vending machine. Small course-corrections are normal and expected. We'll explore the review panel properly in Module 03.
Als Codex wijzigingen voorstelt, toont het ze als een diff (een voor/na-weergave) voordat ze definitief zijn. Je hoeft niet elke regel te begrijpen — je controleert "is dit ongeveer wat ik vroeg?" Zo niet, zeg het gewoon in gewone taal: "De toon is te casual, maak het formeel," of "Je wijzigde het verkeerde bestand, ik bedoelde dat in de map rapporten." Codex past aan en probeert opnieuw.
Werken met Codex is een gesprek, geen snoepautomaat. Kleine bijsturingen zijn normaal en verwacht. We verkennen het beoordeelpaneel goed in Module 03.
Brief Codex like a colleague: Goal, Context (@mention files), Constraints, Done-when. For anything non-trivial, ask for a plan first. Then review the diff and steer in plain language. Specific in, great out.
Brief Codex als een collega: Doel, Context (@-vermeld bestanden), Beperkingen, Klaar-wanneer. Voor alles wat niet triviaal is, vraag eerst om een plan. Beoordeel dan de diff en stuur bij in gewone taal. Specifiek erin, goed eruit.