Claude Code and Codex used together to ship .NET features faster
Developer Olabamiji Oyetubo describes a two-AI workflow where Claude Code acts as architect — planning and writing specs — while Codex acts as builder, implementing from those specs to cut cost, improve consistency, and reduce context drift.
Score breakdown
In a Dev.to post, Olabamiji Oyetubo argues that planning and implementation are fundamentally different jobs that benefit from different AI tools. His workflow uses Claude Code — loaded with a `CLAUDE.md` project context file — to reason about the codebase and produce a self-contained `task.md` spec file. Codex then reads that spec and implements the code without needing to explore the full codebase. The split reduces token costs, improves pattern consistency, and avoids the context-drift problems that plague single-tool workflows. A final Claude Code review pass checks Codex's output against `CLAUDE.md` conventions, and any fixes loop back through the same plan-then-build cycle.
- 01Author Olabamiji Oyetubo uses Claude Code as a planning 'architect' and Codex as an implementation 'builder' for every .NET feature he builds.
- 02A `CLAUDE.md` file gives Claude Code full knowledge of the project's architecture, naming conventions, and rules without repeated prompting.
- 03Claude produces a self-contained `task.md` spec file on disk that Codex reads to implement the feature — no codebase exploration required from Codex.
Writing on Dev.to, Olabamiji Oyetubo presents a structured two-AI workflow for building .NET features that splits cognitive labor between Claude Code and Codex. The core insight is that planning and implementation require different things from an AI: planning needs deep project context and reasoning ability, while implementation needs a clear, focused specification. Using one powerful model for both wastes tokens and introduces inconsistency; using a weaker model for planning produces specs that don't match real project conventions.
The workflow begins with Claude Code running in the terminal alongside a `CLAUDE.md` file that encodes the project's architecture, naming conventions, existing services, and rules.
The workflow begins with Claude Code running in the terminal alongside a `CLAUDE.md` file that encodes the project's architecture, naming conventions, existing services, and rules. The developer gives Claude a rough natural-language description of the desired feature — in the article's example, a device registration endpoint for `SensorIngestApi` — and Claude reads existing controllers like `ReadingsController`, `StatsController`, and `AlertsController`, inspects `TelemetryDbContext`, and asks clarifying questions before writing a structured `task.md` file to disk. This spec includes every convention Codex needs — `IActionResult`, `ILogger`, `CancellationToken`, file-scoped namespaces — written explicitly rather than inferred.
Codex then reads `task.md` from the same directory and implements the feature without touching the broader codebase. Because conventions are spelled out in the spec, Codex doesn't need to guess patterns or explore files it doesn't need, keeping its token usage lean. After implementation, the developer switches back to Claude Code and invokes a `@code-reviewer` command to validate Codex's output against `CLAUDE.md` standards. Any issues found feed back into the loop: Claude drafts a fix plan, updates `task.md`, and Codex implements the correction — maintaining the clean architect-builder division throughout.
Key facts
- 01Author Olabamiji Oyetubo uses Claude Code as a planning 'architect' and Codex as an implementation 'builder' for every .NET feature he builds.
- 02A `CLAUDE.md` file gives Claude Code full knowledge of the project's architecture, naming conventions, and rules without repeated prompting.
- 03Claude produces a self-contained `task.md` spec file on disk that Codex reads to implement the feature — no codebase exploration required from Codex.
- 04The workflow is demonstrated on a real feature: a device registration endpoint with duplicate prevention added to `SensorIngestApi`.