I used to hand work to Codex the moment Git, a CLI, or code entered the conversation. I thought that would make execution faster.
What grew was not execution speed. It was the number of handoffs: frame the requirement in ChatGPT, inspect the repository in Codex, return to ChatGPT to change an assumption, then send it back to Codex. A round trip that brings back a new fact from the real environment is valuable. I was also moving questions that could still be decided without running anything.
TL;DR: I stopped routing work by whether it looked “technical.” While the next decision can be made safely from the current context, I let AI do the foundation work too: research, comparison, and structure. When the answer moves into the real repository, Git history, CLI, tests, or browser, I hand Codex an end-to-end execution unit using five fields.
The problem was my routing rule, not Codex
I have used Anthropic's Claude Code as more than code completion. It can read a codebase, edit files, and run commands. I gave it research, design, implementation, tests, and Git work as one long unit.
Claude Code Hooks were an important part of that workflow. A Hook is a user-defined command that runs at a particular lifecycle event in Claude Code. It can format after an edit, stop before a dangerous command, or start a verification step. In practical terms, Hooks let me turn repeated instructions into repeatable stopping points.
I still keep the operating idea I learned there: once I give an AI a well-defined unit of work, I want it to finish the investigation, decisions, execution, and verification.
When I started using the Codex app seriously, I tried to apply the same idea across ChatGPT and Codex. But I used a rough rule for where to cut the work:
If it becomes technical, move it to Codex.
That sounds natural, but “technical” is not an execution requirement. Defining a reader, comparing existing approaches, choosing constraints, and writing a done condition can all include technical language. None of those decisions necessarily needs the real repository yet.
I was confusing the topic of the work with the evidence the work required.
What a handoff actually carries
By handoff, I mean moving work from ChatGPT to Codex, or from one AI task to another. It is not just copying a prompt. It is transferring enough information for the next worker to continue the same decision.
That information is context. In AI systems, context is the information visible to the model when it decides its next response or action. Operationally, I treat context as a handoff packet: the goal, current state, decisions already made, fixed constraints, next action, and evidence that will prove success.
In my workflow, I rebuilt that packet for each move. If the decisions are still unstable, the next AI may research the same question again or act on a different assumption.
In an earlier Zenn article, I wrote about delivering important context reliably after a handoff without making the injected packet too large. That problem still matters. But there is a cheaper question to ask first:
Does this handoff need to happen yet?
Route by where the next answer lives
My current routing rule is:
If the next decision can be made safely from known goals and constraints, continue in the current surface. If getting the answer requires touching the real environment, hand it to Codex.
“Continue in the current surface” does not mean I write everything myself. I am moving foundation work to AI to test how much of my own load it can remove.
- Research and compare existing information
- Frame the reader's or user's problem
- Propose scope and non-scope
- Build an outline and first draft
- Propose done conditions and verification methods
The human keeps a different class of decisions: whose problem matters, what must not change, where the publication, deletion, spending, or other irreversible boundaries are, and what observed result should count as success.
This is not a compromise between dumping everything on AI and reviewing everything as a human. It is an operating design that gives the human and AI different kinds of ownership.
When the real environment holds the next answer, I move the work to Codex.
| Next question | Where the answer lives |
|---|---|
| Whose problem should this change solve? | Current requirements and human judgment |
| Does a similar implementation already exist? | The real repository and Git history |
| Does this command work in the current environment? | CLI output |
| Did the change break existing behavior? | Tests, lint, and build |
| Can a reader use the actual page? | The real browser surface |
The boundary is not between thinking and building. It is between deciding from available information and collecting evidence from the real artifact.
Use a five-field handoff
Once the boundary is clear, I do not need a long specification. This is the smallest packet I now try to fix before Codex starts:
goal: Who has what problem, and what changes for them?
constraints: Which decisions are fixed? What must not change? Where are the publish, delete, and spend gates?
execution: What is the current state? What remains to inspect or change in the real environment?
done_when: What observable state means the work is complete?
verify_with: Which command, screen, URL, test, or diff proves it?
This preserves implementation freedom while fixing the semantic boundaries.
For example, suppose the goal is “make a Zenn article reviewable.” Before I ask Codex to open a repository, AI can research candidate readers, check overlap with existing articles, propose the claim, build an outline, and define what the cover image needs to communicate.
The human decides whether the claim matches lived experience, what is safe to publish, and what “reviewable” means. Codex can then find the canonical files, place the article and image, run Zenn Preview, and check the table of contents, code blocks, links, image, and frontmatter on the real rendered page.
The five fields preserve technical choice while giving Codex enough meaning to act autonomously.
Ask for evidence, not routine decisions
After the handoff, I do not want Codex to ask me about every small reversible choice. I want it to own this loop:
Inspect -> Decide -> Change -> Test -> Repair -> Verify the real artifact
A return trip from Codex to the planning surface is valuable when execution produced a new fact:
- The API we expected does not exist
- A test disproved a requirement assumption
- The real UI is technically correct but hard to read
- An existing implementation makes new code unnecessary
Those handoffs are worth their cost because they carry evidence that was unavailable at the desk.
Reversible choices such as “should this variable be named A or B?” or “which of these equivalent libraries should we use?” usually are not worth a return trip. I am testing whether transferring ownership of the execution loop reduces the human load too.
What I cannot claim yet
I cannot say this boundary reduced my handoff count or completion time by a particular percentage. I have not measured that yet.
What I can claim today is improved explainability. When I stabilize decisions until the real environment is needed, it becomes easier to state what I am handing to Codex, why it is moving now, and what evidence will finish it.
To test the method, I plan to measure:
- Handoffs per unit of work
- Premises rebuilt after a handoff
- Clarification requests returned to the human
- Time from execution start to a verified artifact
I may change the boundary again in a few weeks. That would not make this a failure. It would mean the operating idea became a measurable hypothesis.
Try it on your next task
On your next AI-assisted task, stop before writing “technical work.” Fill the five fields, then ask one question:
Can the next decision be made safely without the real repository, CLI, test result, or browser?
If yes, let AI continue the foundation work in the current surface.
If no, move the work to the environment that has the answer and hand over execution and verification together.
The important idea I kept from Claude Code was to let AI own a long unit of work. What I changed for Codex was where that autonomous unit begins.
My current hypothesis is that handing off only the code leaves too much coordination with the human. So I am testing a broader split: move the foundation work to AI, keep the semantic boundaries human-owned, and move execution when the real environment has the answer.
What signal currently tells you to hand work to another agent?
This article was adapted from my Japanese Zenn article with AI assistance for English restructuring, copy editing, and cover art. The workflow described here is my own; factual claims were checked against the source article and official product documentation.
Top comments (1)
To answer the closing question: my handoff signal is whether I can verify the next claim from the transcript alone. The moment a claim needs fresh evidence, repo state, a command exit code, a rendered page, the work moves to the surface that can produce that evidence, which lands very close to your rule. "I was confusing the topic of the work with the evidence the work required" is the cleanest phrasing of that distinction I've seen. On your four planned metrics, I'd start with premises rebuilt after a handoff, because it is the only one of the four that catches silent context loss: handoff count and completion time can both improve while the packet quietly drops a constraint, and you only notice later as a wrong assumption acted on. Counting correction messages per handoff, the "no, we already decided X" kind, is a cheap proxy that needs nothing beyond grep over the session log.