The Orchestrator/Builder Pattern

Agentic coding is nothing new but it has come a long way since the first models were released just a short few years ago. My agentic tool of choice is Claude Code and now that we’ve had Claude Code for a full year I wanted to present the pattern I’ve settled into that seems to work really well for me.

One important note: I am using the Claude AI Max plan which I think is probably required for this setup to work. And as of this writing I am using the Opus 4.6 model. Previously I was using Opus 4.5.

Before I get into the details, this is not a post about whether we should be using AI coding agents, their impact on the environment, that AI is being forced upon us, or societal impacts of AI writ large. Those are all completely valid topics that are actively being discussed and debated but this post is not about those. With that out of the way, let’s dive in.

The Orchestrator/Builder Pattern

This pattern uses Two Claudes (tm):

The Orchestrator: use the Claude AI desktop app to plan, discuss, and ultimately orchestrate your project in Project mode. It doesn’t have access to my code folder but in Project mode you can save instructions, files, notes, and other context.

The Builder: use Claude Code in your IDE (in my case Cursor with Claude in a panel, not the CLI) to actually build and code your project. Has access to the code base and any coding-specific documents added to the repo.

I’ve been woking with this pattern for about two months now and it has been pretty amazing IMHO. In a sense, I am playing the two Claudes off each other but each has different strengths yet they know how to talk to each other…erm…or themselves…or something. And I know there has been pushback about anthropomorphism with AI agents so I am fully aware of that but for the sake of this article we will refer to them as separate entities so we know which is which.

In fact, in working with the Two Claudes, I have given them nicknames to them to make it easier to talk to each of them about the other:

OC: Orchestrating Claude (The Orchestrator) (and ‘Orchestrator is used here instead of Conductor so that we don’t have two ‘CCs’)

CC: Claude Code (The Builder)

Let’s go into each Claude in more detail:

The Orchestrator

The Orchestrator (‘OC’) is the agent that takes in your planning documents, requirements, scope, and goals to come up with a comprehensive plan for your project. The Orchestrator can break your project into more manageable chunks but more than that, sync with your project management tool (I use Linear) to create issues and decide on the best sequence.

The killer feature of this pattern is that The Orchestrator can create the prompts for The Builder. OC knows how to present the information based on the plan and its sequence in the language that optimizes The Builder to accomplish each task successfully. This alleviates all of the guesswork of trying to craft the prompts precisely while reducing the back-and-forth to a minimum.

It doesn’t stop there: once The Builder (‘CC’) codes a piece of the project, have it create a summary to feed back into The Orchestrator at each step. OC then will review the summary and create new interstitial prompts or questions to ask CC. In this way it is not just me reviewing and iterating with Claude Code itself, but checking each step and asking OC to spot anything I’ve missed or any implementation details that deviate from the plan. It catches things I definitely would have overlooked.

The Orchestrator has way more context than the Builder — in fact the entire training set for Claude along with your personal historical context and chat history. This allows it to plan much more effectively than by only using Claude Code. The Orchestrator is much more conversational by nature, whereas The Builder is much more technical. This dichotomy suits each Claude’s strength.

With this in mind, it is imperative to constantly play devil’s advocate against The Orchestrator’s plan. I not only ask OC questions, but ask it to ask me clarifying questions. This allows it to get much closer to your vision and help The Builder build what you imagine. I also ask OC if there is anything else I should be asking it and where it can help even more. This is another crucial piece of this pattern. As an example, when asking how could it be helping more, the OC replied that I should be asking it to play devil’s advocate to validate my ideas. Again, you are in control here and the OC can only do what you ask it to do. Sometimes you don’t think to ask it something so have it suggest things to ask.

The Builder

The Builder (‘CC’) is who actually writes the code. It takes the context and prompt input from OC to build each piece, then provides summaries for the OC to check and validate at each step. CC sometimes makes its own better architectural decisions that the OC had not thought of yet other times it misses the mark. By iterating on each step by feeding the summaries back into OC, we can ensure that CC is doing everything correctly. What’s more, the OC will then update the plan and sequence based on anything new coming from CC. As with the OC, I constantly ask CC if it has any clarifying questions or needs more context. Either I answer CC directly or feed its questions back into OC to clarify.

Let me also interject here that I am in control. I am not setting these agents on their own to build something. I — or in your case you — are the actual Maestro running the show. This is crucial. I check everything at each step and iterate and validate based on my assessments and Claude’s responses to questions. I find things that either the OC left out or that CC didn’t get right. My experience as a software engineer and designer is absolutely required and necessary here. To put another way: I am fully involved in the process at every step. Even just the mechanics of copying the prompts and context from OC to CC means that nothing can happen without my explicit approval.

The Workflow

If you haven’t tried using the O/B pattern yet and are still frustrated using Claude Code on its own, give this pattern a try. The iteration and validation is a really nice workflow and keeps you in the action at every step. I still get the dopamine hit from finishing each piece — the only difference is I am not actually typing in all the code by hand. I don’t think that is actually necessary to create good software.

All that said, without the experience I have built up over years working on software and the web, I don’t think this pattern would work; or at least work as well as it does. It is crucial to be skeptical of either Claude’s decisions and question them early and often. Moreover, I can — and do — jump in and edit some code when I need to.

Note that this pattern was not possible until the more recent models had advanced to where they are now. I’m not sure if this can be done with any other models yet with Claude AI in Project Mode and Claude Code in my IDE, it seems to be working well. And it’s only going to get better.

Simplified Steps:

1. Before starting a project, take the time to write out a detailed plan with requirements, goals, features, and questions. Write it yourself without AI.
2. Create a project in Claude AI (OC) in Project Mode
3. Upload the plan from Step 1 to Claude AI. Be sure to ask Claude to ask you any clarifying questions. Iterate on the plan with OC until both you and Claude feel like you are ready to go.
4. Instruct OC to create a detailed project plan broken into chunks with the context, prompts, and details Claude Code (CC) will need. Read over the plan carefully and iterate more if you need before starting the build. If you want/need connect your project management software to OC and create tasks/tickets.
5. Provide Claude Code (CC) with any context and the first prompt. Ask CC to ask you any clarifying questions. Either you can answer CC directly or feed these back into OC. Once CC is satisfied, start building.
6. Have CC create a summary after each task is finished. Check the code and the summary and validate/test. Feed the summary to OC for it to check. Ask OC if there is anything that doesn’t seem right or you need to validate further.
7. Based on what CC does, ask OC if anything needs adjusting or to reassess. Do this often.
8. Rinse and repeat. YMMV.

Challenges

This system is not perfect and things are still evolving in the agentic coding world but my hope is some of the current rough edges will be smoothed out over time making this a viable pattern for at least the next little while until a better pattern comes along. In the meantime I’ve still been running into some issues:

• Even with Opus 4.6 the conversation needs to be compacted pretty often. Sometimes Claude AI will get stuck and I have to start a new conversation. This is a bit frustrating and takes you out of the flow.

• Claude Code (CC) sometimes makes odd choices or doesn’t get the architectural decisions right so you have to be vigilant. Validate everything at each step.

How I Got Here

This pattern emerged somewhat organically out of a long process of working with AI coding tools over time and the progression may be relevant to others so I’ll provide some of that history here.

Beginnings

I really didn’t start working with any agentic coding until Cursor came out. I don’t even think I had the first version so let’s say this was about 2 years ago at the maximum. I’m not even sure what version of Cursor was my first but it would have been sometime in 2024 — before the first stable release for sure.

In any event, the first coding models in Cursor sucked. They couldn’t do much, and what they could do they did badly. I would jump into the Cursor sidebar using the early models and was very frustrated. The agents weren’t helping and were more likely to mess things up than not including adding serious bugs to your code. I was very weary of the available tooling and kind of gave up at that point. I would use an agent for tedious text processing tasks like adding commas to the end of strings or alphabetizing rows but not much else. They were not ready for prime time. Or anytime really.

Doing Things

That changed when Claude Sonnet 3.7 with Claude Code was released…in fact exactly a year ago at the time this post was published. That was the first model for me that showed promise and could actually…well…do things. From that point on I dabbled a little bit with other models but generally have stuck with Claude since then. It feels like a good chunk of developers have done the same.

Until recently, I was a co-founder at a company that is now shut down but through most of late 2024–2025 we were looking for ways to automate project management, tooling, and code tasks so we got a business plan for Claude and I started using the desktop and mobile apps. I wasn’t using those for coding yet but it got me familiar the strengths and weaknesses of non-code Claude and I started to see what those apps could do. The early versions were pretty limited: no Project mode, no Cowork, hardly any context.

As 2025 progressed, each iteration of Claude and the respective coding agents got better and better. Claude Sonnet 4.5 was a huge jump. The VS Code/Cursor extension had some major upgrades around that time: now you could add Claude as a panel in your editor; you weren’t limited to Cursor’s agentic sidebar (which I never liked) or the CLI/terminal. I could have a big Claude panel right next to my code files. They’ve updated the extension and worked out a lot of bugs but the general panel setup is the one I still use today for Claude Code.

A New Opus

It was November 2025 when Anthropic literally blew the doors open with Claude Opus 4.5. It was leaps and bounds ahead of any other model. The only thing I can compare it to is going from an Intel MacBook Pro to Apple Silicon. It just felt like magic and in some ways still does. Opus also came with Plan mode which I started to use immediately.

What I found late 2025 is that if I spent the time to write up detailed plans and provided them to Claude Code in Plan mode, it would invariably do a much better job. Blog posts and social media posts were saying to “talk to the agent like another developer” and “give it all the context another developer would need, along with the details” so I started doing this. And it increased the quality of the code Claude was spitting out immensely. No longer was I correcting the model at every step. I would check the code and the UI, iterate, and refine with greatly improved results. I wasn’t using Claude Code for everything (I still don’t) but I started to get a feel for what it could do and how it could make me more productive.

Opus 4.5 coincided with the Claude desktop app getting Project mode which made it much more than a chat app. Aside from Claude Code in your editor, the main Claude Code app could do work as well.

I dipped my toe into this new world by asking Claude questions related to code: Is X a good pattern? How does Y work? and so on. I would then take any learnings from Claude and my own research to inform my planning and context docs for Claude Code. This was the early steps of working with two Claudes.

From there I was working on a couple side projects and then had a eureka moment: What if there’s a better way? Wouldn’t Claude AI know how to talk to the coding agent and create the prompts better than I could? It couldn’t hurt to try.

Riddim Finder PoC

The first project where I really put this to the test was riddimfinder.com. This is a proof-of-concept site and to be perfectly honest it is not working as well as I hoped. Still, the experience of building it using the O/B pattern was invaluable.

The concept for Riddim Finder is to upload a reggae track and it would determine the riddim based on analysis of the audio. I used a relatively small training set for its internal model with pre-identified riddims so the model could then match unidentified tracks. The current (unfinished) state of the app gets some identifications right but unfortunately not enough to make it a viable production-ready app without a lot more work, a lot more training, and a lot more money.

As it happens, this is a much harder problem to solve than I thought. Current open source music fingerprinting can identify samples of an original track pretty easily. Identifying a separate track that uses the same bass and melody pattern but with completely different sounds is another matter altogether. This is something a human can do almost instantly (as long as they know the riddim) but a computer really struggles with. I may come back to finish Riddim Finder but for now it is incomplete at best. C’est la vie.

Nevertheless, using the O/B pattern for this project got me the PoC done in under two weeks where this would have taken 2 months on my own. I’m finding similar if not better gains with more recent projects. So far, so good.

Summary

Surely I can’t be the first person to utilize the Orchestrator/Builder pattern yet at the time of writing I had not seen another post about it so I thought it would be worth sharing — at the very least to give it a name. While there are still some rough spots, I’ve found the O/B pattern to be quite effective while keeping me — the developer/designer — in control.

Let me know if you give this workflow a try and how it’s working for you by posting a comment on Bluesky or Mastodon.

Also, for the record, this post was created without any AI whatsoever. All mistakes, typos, and the voice are my own.