I separate thinking from editing: ChatGPT for design/review, coding agents for execution

I’ve gradually moved toward a workflow where I don’t ask one coding agent to own the entire loop.

I keep the filesystem-heavy execution with Codex, Claude Code, or OpenCode: editing files, running tests, fixing errors, and executing a concrete implementation.

For architecture, design, planning, and independent review, I often prefer a high-reasoning ChatGPT conversation.

The obvious problem is: ChatGPT doesn’t live in your repo. How do you give it enough context to reason about a complex codebase without dumping the whole repository into the chat?

That’s why I built a small local-first tool called AI Badger.

Instead of stuffing everything into context, it gives ChatGPT a focused package with repository topology, Git state, task/session context, relevant source, and other metadata.

The important part is that the workflow is two-phase:

- Initial context: ChatGPT gets enough topology and task context to understand the problem.

- Targeted follow-up: If it needs more, it can ask for a specific file, class, symbol, prefix, or nearby code, and I pull that context locally.

So on a large repo, the goal isn’t to make ChatGPT read everything. It’s to let it narrow into the relevant parts interactively.

Once the design is settled, I ask for a compact implementation handoff with concrete file/function changes and minimal filler.

Then the coding agent gets a much narrower job:

repo context → ChatGPT reasoning → compact plan → coding agent execution

If the session already started inside Codex/Claude Code/OpenCode, I also have a handoff Agent Skill that carries over the useful session state: current goal, decisions, constraints, completed work, and verification. Badger combines that with repository context locally so the conversation can continue in ChatGPT without reconstructing everything manually.

After implementation, I can send the changes back through the same flow for an independent review.

I also tested this in one small OpenCode dogfooding run. Giving the execution agent a compact Badger-assisted handoff instead of the raw feature request resulted in:

- 32% fewer active agent tokens

- 55% lower runtime

- 86% fewer reasoning tokens during execution

It’s one run, not a benchmark, but the direction matches what I’ve been seeing in normal use: the less discovery the editing agent has to repeat, the more focused the execution becomes.

The mental model I’ve ended up with: separate thinking from editing.

Give the reasoning model enough real repo context to make good decisions, then let the filesystem-aware coding agent execute a compact, concrete plan.

Curious if anyone else is splitting their workflow between web reasoning chats and CLI/IDE coding agents this way.

AI Badger + experiment details: https://github.com/PVRLabs/aibadger