Should you plan with one AI and build with another?

Imagine a developer on your right and a genius product manager on your left. I go to the product manager, ask what I should tell the developer, then copy and paste it over. It's almost silly, because it's the same AI. It works anyway.

"I use Claude Chat as my assistant, my genius product manager, and Claude Code as the actual developer."

Why split planning from building?

• Memory. In the chat it will lose stuff. You come back a day later and it says it doesn't have it. Pushing the plan into the coding tool means everything gets saved in files.
• Cost. The top model plans. A cheaper model implements. I've heard other builders land on the same split.

Why have a second AI check the plan?

Because the first one misses things. Every time. My habit is to have Claude write the plan, then hand it to ChatGPT. ChatGPT comes back with a list of what Claude missed. I give that list to Claude, and Claude agrees it missed all of it.

It works the other direction too. On one big build I had Codex write the plan in plan mode, had Claude redline the literal plan for how it would build every single piece, and only then let Codex run it completely on its own until it was done.

For large builds, I don't want to burn a ton of tokens building until we know the approach will work. A redline is cheap. Rebuilding is not.

How do I run the back and forth?

For anything foundational, I start by telling the AI not to act yet.

Don't do anything yet, let's brainstorm first.

Then I'll go back and forth for about 30 minutes straight. Tell me about this. How's that going to work? After that I paste Claude's answer into ChatGPT and ask two questions:

Do you think Claude did a good job here?
What do you think Claude screwed up on?

I keep passing it back and forth until the plan is right. A few rules I add on big builds:

• Review everything, not just the headline plan. I want every single supporting document reviewed in full, optimized and redlined.
• Start from what already works. When a team plan overlaps with documents I've already proven out, base it on mine where it makes sense, and change only what should change.

Can a cheaper tool do the building?

Yes, if a smart model stays in the reviewer seat. On one large build I had the top Claude model split the work into numbered packages, with a ready prompt for every step. I ran step one in a cheaper coding tool (Factory), pasted the output back to Claude, and only moved on once it confirmed the step was good enough. Then I pasted the next prompt in.

"Give me every single prompt for every step, or you're listing out all these different steps or packages that we can do. I'll do number one first."

The cheaper models were cheap enough that I didn't mind spending a little to use them for the coding steps.

When is a second model a must?

When a mistake would be expensive. Before a risky data recovery for a customer, restoring backed-up subscribers, I told the AI to give its plan to Claude Opus, get its feedback, and come back with what Claude said plus what it thought we should actually do. We could not risk messing it up.

The same job showed why proof matters. I expected about 100 missing subscribers. The AI said about 800. I didn't argue from my gut or accept its number. I asked it to audit and tell me exactly how many, and how it could know for sure.

What should the planner do that I usually don't?

1. Split my ideas into separate tracks. I get really excited about solving multiple problems at once. A smart AI should break that burst into separate builds automatically.
2. Ask me questions. I'd rather lean on the AI's view of the code than dictate how to do it.
3. Keep going around blockers. Build what can be built and set aside anything that needs my approval.

How does this work with a team?

The same handoff, one level up. When a teammate who also uses AI brings me something, the rule is: do the first two steps yourself, get it to basically done, then give me a prompt. Tell the AI you want to give me something I only have to copy and paste to solve the problem.

Keep one coding tool per project while you do this. GitHub is the source of truth, and Codex and Claude Code both just change it, but switching tools mid-project brings back the context problems you were trying to avoid.

The planning step is meta-prompting at a bigger scale: ask for the instructions before you ask for the work. The same second-opinion habit applies after the build, too: should an AI reviewer check work before you see it.