When most developers discover AI coding tools, they pick one and use it for everything. Chat with it, paste code in, copy code out. One tool, one workflow, every problem.
That works until you notice the cracks. The AI forgets what you told it ten messages ago. It generates code that doesn't match your project's patterns. You spend more time correcting it than you saved using it. And your token costs keep climbing.
I use Claude Code and Codex together on every .NET feature I build now. Claude plans. Codex builds. A single markdown file connects them.
This article will show exactly how it works.
The Problem With Using One Tool for Everything
If you've used Claude or Copilot for anything beyond a quick snippet, you've felt this:
The context problem. AI tools work best when they have rich context about your project.
But feeding that context costs tokens, takes time, and has to be repeated every session. The more complex your project, the worse this gets.
The consistency problem. Ask an AI to implement something without enough context and it generates code that doesn't match your conventions. Wrong patterns, wrong folder structure, wrong naming. You spend the time you saved fixing what was generated.
The cost problem. Using a powerful, context-aware model for every line of code is like hiring an architect to lay bricks. It's valuable, but not the most efficient use of the skillset.
The insight that changed my workflow: planning and implementation are different jobs. They need different things from an AI tool. Once I split them, everything got faster, cheaper, and more consistent.
The Two Roles — and Why Each Tool Fits
Claude Code — the planner
Claude Code runs in your terminal with full access to your codebase. Combined with a well-written CLAUDE.md file, it knows your project's architecture, naming conventions, existing services, and the rules Claude should follow.
You can learn more about setting up Claude and CLAUDE.md files here.
This makes Claude exceptional at reasoning. It can look at your actual code, understand what already exists, and produce a plan that fits your use case.
What Claude is doing in this workflow: thinking, planning, and writing the spec.It burns tokens once to understand the codebase deeply, then produces a clear, self-contained task document. That upfront investment pays off every time Codex uses the output.
Codex — the implementer
Codex is fast and focused. It excels at taking a clear, well-scoped specification and turning it into working code. It does not need to explore your entire codebase, just a good brief.
That's exactly what Claude provides.
What Codex is doing in this workflow: reading the task file Claude produced and implementing it. No context exploration, no pattern guessing, no wasted tokens on things it doesn't need to know.
Why this split works
| Claude Code | Codex | |
|---|---|---|
| Strength | Reasoning, planning, context | Implementation, speed |
| Needs | Full project context | A clear, focused spec |
| Cost | Higher per token — used once for planning | Lower per token — used for execution |
| Role in workflow | Architect | Builder |
The Workflow — Step by Step
Here is the exact workflow I follow, demonstrated by adding a real feature to SensorIngestApi — a device registration endpoint that did not exist before. This is not a staged demo. This is the actual feature being built.
Step 1 — Open Claude Code in the project repo
cd C:\Users\source\repos\SensorIngestApi
claude
Claude reads CLAUDE.md automatically. It already knows SensorIngestApi's
structure — the Controllers, Services, Interfaces, Data folders, the TimescaleDB setup, the SignalR hub, the channel pipeline, and the conventions the project follows. No manual context-pasting required.
Step 2 — Tell Claude what you want to build
Give Claude a plain description of the feature. You do not need to be precise. Claude's job in this step is to turn your rough idea into a precise spec.
I want to add a device registration endpoint to SensorIngestApi.
Devices should be stored in the database and we need to prevent duplicates.
Keep it consistent with how ReadingsController, StatsController,
and AlertsController work.
Claude reads the existing controllers, checks TelemetryDbContext, looks at the existing models, and asks any clarifying questions it needs before writing the spec. Because CLAUDE.md is loaded, it already knows the conventions,
IActionResult, ILogger<T>, CancellationToken, file-scoped namespaces without you having to repeat them.
Step 3 — Have Claude write task.md
Once Claude understands the feature, ask it to write the implementation brief:
Write a task.md file in the repo root that Codex can read to implement this.
Include all the context Codex will need — what to build, which files to touch,
and the conventions to follow.
Claude produces a structured markdown file and writes it directly to disk. It includes everything Codex needs and nothing it doesn't.
Step 4 — Open Codex in the same directory
Switch to Codex. Because it is running in the same directory, it can read the task.md file Claude just wrote.
Read task.md and implement everything described in it.
Codex reads the spec and implements. It follows the conventions Claude documented because they are written explicitly in the task file — not assumed from context it does not have.
Step 5 — Review with Claude
Once Codex has implemented, switch back to Claude Code for a quick review:
@code-reviewer review the files Codex just created against our CLAUDE.md conventions
Claude checks the output against your project standards and flags anything that slipped through.
After the review Claude gives a summary of what was good and what needs to be fixed,
You can then go through the process again: Claude Code drafts a fix plan -> Writes to task.md -> Codex implements fix.
What Goes in task.md — A Real Example
The quality of task.md determines the quality of Codex's output.
Claude writes it based on what it read from the codebase and CLAUDE.md, you do not write it manually.
# Task: Add Device Registration Endpoint
## Goal
Add a POST /devices endpoint that registers a device by DeviceId.
Registering the same device twice returns 409 Conflict.
Add a GET /devices endpoint to list all registered devices.
## Files to create
- SensorIngestApi/Models/Device.cs
- SensorIngestApi/Controllers/DevicesController.cs
## Files to modify
- SensorIngestApi/Data/TelemetryDbContext.cs (add DbSet<Device>)
## Conventions to follow
- IActionResult returns (not TypedResults — controller-based project)
- All DB calls async with CancellationToken forwarded
- ILogger<T> only — never Console.WriteLine
- null! on required EF Core string properties with a comment explaining why
- No new NuGet packages needed
The full task.md includes complete file contents, exact EF Core configuration, migration commands, and a "What NOT to do" section. I've linked it in the GitHub repo.
The Token Economics
This workflow is not just faster, it is meaningfully cheaper than using one tool for everything.
Without the split: You feed Claude (or any powerful model) the full codebase context on every implementation request. Every feature, every bug fix, every refactor, full context, full cost, every time.
With the split: Claude reads the full context once per planning session and produces or edits task.md. Codex receives a focused, self-contained spec with no wasted tokens on context it does not need. The expensive reasoning happens once. The cheap implementation happens as many times as needed.
What This Looks Like End to End
1. cd SensorIngestApi → claude
CLAUDE.md loads — project context ready
2. "I want to add a device registration endpoint.
Keep it consistent with ReadingsController."
3. "Write a task.md Codex can use to implement this."
Claude reads the codebase, writes task.md to disk
4. Switch to Codex — same directory
"Read task.md and implement everything in it."
Codex creates DevicesController, Device model,
updates TelemetryDbContext, flags migration needed
5. Back to Claude:
"@code-reviewer review the files Codex just created"
Claude checks against CLAUDE.md, returns verdict
6. Run migration, commit, done
Total prompts: 3 in Claude, 1 in Codex.
Total context feeding: once, at the start.
Result: a working DevicesController that looks like it was written by someone who knows the codebase.
Closing
The Claude + Codex split is not about which tool is better.
It is about using each tool for what it is actually good at.
Claude thinks. Codex builds. task.md is the contract between them.
Once you try this on a real feature it is hard to go back. The planning step forces clarity you would have skipped. The implementation step is faster because the spec is precise. The review step catches what slipped through. One habit that makes the whole thing safer is to commit after every step. When task.md is written, commit. When Codex finishes, commit. When the review is clean, commit. AI tools make mistakes and small frequent commits are your save points. Think of it like a video game, you would not play an hour without saving and then hand the controller to someone else!
Happy Coding!!!
Top comments (0)