How to Delegate to Codex: 5 Habits for Working With an AI Coworker
Have you ever handed an AI coding agent a "please fix this" and then spent longer checking its work than it would have taken to do it yourself? When you don't say what "done" looks like, AI tends to return results that look plausible but are hard to verify.
The daglo team put this together from a coding agent session we attended at OpenAI Builder Bootcamp Seoul on October 27, 2026. Codex is OpenAI's coding agent: it reads and edits files, runs commands, and takes on development work for you. This post skips installation and focuses on the habit of delegating and verifying work the way you would with a coworker. For setup and AGENTS.md, see our Codex CLI setup guide. For how it differs from Claude Code, see Claude Code vs Codex.
The core of using Codex well: hand over goal, context, and "done when"
The key to delegating to Codex is to brief it like a new teammate: give the goal, the context it needs, the constraints to respect, and the criteria for done, all at once. If any of these is vague, you can't tell whether the result is right.
| Part | What to include | Example |
|---|---|---|
| Goal | What to change or build | Fix the bug where no error message appears after a failed login |
| Context | Relevant files, docs, error messages | Login screen file, steps to reproduce, error log |
| Constraints | Rules to follow and areas not to touch | Change the backend only; leave the UI design alone |
| Done when | Evidence that the job is finished | Related tests pass, and the error message shows when you repeat the steps |
A good prompt isn't a long prompt. It's one with less ambiguity: what to build and where to stop. Source: OpenAI, Codex best practices
Break work into reviewable pieces and agree on a plan first
Size each task so that a person can review the result and judge whether it worked. Big decisions such as priorities, architecture, and when to ship stay with people.
For larger tasks, ask for a plan before any code. The session described planning as the step where the model and the developer align on intent. Seeing the order of attack up front lets you fix a wasteful approach before it's built. The official commands support this flow:
- /plan: Turns on plan mode so Codex gathers context, asks questions, and drafts a plan.
- /goal: Sets the refined plan as a persistent goal. The docs suggest shaping it with /plan first.
- /side: Opens a temporary side chat during a long task so you can check direction without disrupting the main thread.
- /fork: When a new feature idea comes up mid-bugfix, copy the chat and explore it separately. Mixing topics in one chat tangles the context.
Make tests and review prove the work is done
Tests check how well the work meets the "done when" you set at the start. What matters isn't that tests ran but what the results actually verify.
If you have thousands of tests, don't pass the full output back to the model. A short summary of passes, failures, and causes leads to a better next fix. Before handing work to a human, use /review to check that the result matches the original request and follows AGENTS.md. An AI's first-pass review doesn't replace a person's final call, though. Look at the final diff yourself and ask:
- Does the change match the original goal?
- Did it add features nobody asked for?
- Were the constraints respected, and is there evidence the done criteria are met?
- Are remaining work and unresolved conditions written down?
Turn repeated work into skills and repeated mistakes into rules
If you keep giving the same explanation, it's time to turn that procedure into a skill. A skill is a packaged playbook of steps and reference material that the agent can call up when needed.
Instead of restating which tests, reviews, and outputs every pull request needs, you call the skill and Codex follows the same steps. The official guide recommends one job per skill. The session added that when the same problem keeps coming up, you should fold the fix into the skill's instructions and examples. That's how one person's know-how becomes the team's way of working.
Treat AGENTS.md the same way. Don't try to write it perfectly on day one; add a rule each time a mistake repeats.
Hand over the goals and done criteria your meeting agreed on
The goal and done criteria you give Codex usually come out of a planning meeting. Transcribing that meeting gives you accurate material for the brief, instead of rewriting it from memory.
- Transcribe and summarize: Record the meeting or upload the file to daglo, and you get a transcript that shows who's talking, plus a summary.
- Summarize straight into a brief: Save a "goal, context, constraints, done when" format in My Templates, and daglo remembers it and summarizes every recording in that format automatically. That summary becomes your first draft of the Codex brief.
- Ask what's missing: In Board Chat, ask "What did we agree on as done criteria, and what's still undecided?" The answer is grounded in the transcript, and you can check it against the original right away.
When several people weigh in, Speaker ID keeps track of who asked for what. It remembers the voices of the people in your meeting and fills in their real names instead of "Speaker 1" from the next recording on. daglo is the first in Korea to offer this to every user. Knowing who made a request also tells you who should review the result. Learn more about Speaker ID
#Codex #CodexTips #AICodingAgent #AGENTSmd #AIDelegation #OpenAI #DeveloperProductivity #daglo
Where talk becomes work.
Get started with 1,000 credits a month — no credit card required.