ChatGPT and Opus Sitting in a Tree: A Two-AI Development Workflow

AI-assisted development workflows separate planning from implementation so that design decisions can be validated before code is generated.

This story is part of my evolving relationship with ChatGPT 5.2 and Opus 4.6. This process of using distinct design (ChatGPT) and implementation (Opus) allowed me to convert a 100% manual React project documentation platform to an almost completely automatic "discover and document" platform in just a few days.

A Teamwork Model Is Key

As I mentioned in my previous post, "Journey: Three Generations of Caching Architecture," I've been experimenting with ways AI can accelerate real engineering work. I am using these two as a "design team" and "coding team" respectively.

I "trained" ChatGPT to act as the design team and explicitly instructed it to never actually write code. Segregating the teams allows each side to focus on their part of the project. My job, as the "AI Whisperer", is to set the main course of the project as it builds out, and make sure both teams are in agreement before anything is actually written (more on this in a moment).

Interviewing the Client

The first thing I did before engaging GPT in the details of any planning was setting up the interview prompt. I am going to include this in full, because this defines the entire result that follows:

I have an existing manual software documentation system (for React/Node projects) that I would like to replace with sort of semi-automatic platform. I want you to act like an interviewer now, and build up a good picture of what we have, and how it currently works. Then my idea is to build something that can look at a commit, understand which files have changed, trace the effects of these changes, and keep some sort of versioning system. What we do now is we have divided files into components, routes, and functions. (I would like to expand to include hooks separately, as they are now co-mingled with components). We currently create an issue with an issue number (serial) and a title + description. Documentation includes linking files that were changed, documenting what changed, and incrementing the version number. We also try to include all interconnecting files (parents/children, routes, functions, hooks) that are linked. It would be really good to separate components automatically into regular components with display logic, custom hooks affecting App.js and children, context files, and Zustand store files. Let's start with that and you can interview me now.

GPT responds starting with this statement:

Perfect. I'm going to interview you in a way that (a) captures how your current system actually works, and (b) produces requirements we can turn into an automated "commit → impact graph → doc + version bump" pipeline.

What follows is several hours of back-and-forth where it discusses various items in a number list, and I respond with:

1.1: I don't agree with this, let's do that instead,
1.2: I am ok with that.

.. etc.

TIP: I use Apple Notepad to format and structure all of my answers so I was not limited by the constraints of a regular text-area input. This allows me to use number or bullet lists, fixed width text, etc.

TIP: GPT asked many specific architectural questions, which I had Opus answer because Cursor allows agentic access to the entire project, where GPT is limited to a single file at a time. This meant I could get a very good answer on how "X" is derived and pass it back to GPT.

Stay in Your Lane, LLM!

Eventually we arrived at a roadmap (let's call it the "master plan") where:

• The basic outline of the project was established.
• GPT had seen examples of all data involved, and how the current system was handling it.
• I had emphatically insisted that there will be no change in the existing UI.

We were basically in agreement, and not one line of code had been produced. And this is where the magic really started.

Plan the Plan, Man

I type this into the GPT window:

I am going to paste your plan above into Opus and report back what it says ok?

And I hand the plan specs for phase 1 (of an eventual 24 phases) to Opus 4.6 (via the Cursor.ai IDE). It comes back after awhile (and a few questions) with plan 1, rev 0, and (this is critical) I feed the entire plan back to GPT.

GPT has 10–20 points of disagreement with the plan specifications which I paste back into Cursor, and the plan is revised.

This goes on, sometimes for 30+ rounds, until GPT "signs off" on the plan.

And we switch Cursor to Agent mode and build out the plan.

You Can't Afford to Be Cheap

One thing I learned pretty fast was that dialing back the build cycle to use a cheaper model, in this case Claude Haiku, was a disastrous move. The code was badly broken with many bugs seeming to indicate a total lack of understanding the dependencies in the project.

I was spending so much time fixing the issues that, once I tried building in the most advanced (and expensive) model — Claude Opus 4.6 — the errors went nearly to zero, build was faster, and we started really moving along.

More expensive models with larger context windows end up being much less expensive, assuming you value your own time.

Takeaway Points

• Use separate models for fundamentally different aspects of the project. I find that ChatGPT is very good at abstract (almost philosophical) "reasoning". Claude Opus is excellent at coding. Cursor benefits dramatically from detailed "Cursor rules" (which were revised by ChatGPT during the initial interview).
• Be patient and make sure the two teams converge on the plan before you build out.
• Break large projects into very small and actionable phases. This lets you make sure one thing is working before you move on to the next one.

So says the "AI Whisperer"