GSD Changed Everything. Here's How I Took It One Step Further

Or: Why I split my AI brain across two models and accidentally became a CEO

Photo by Getty Images on Unsplash

Let’s get one thing straight right out of the gate: the GSD movement is the best thing that happened to AI-assisted development this year. If you’ve been in any builder community recently, you’ve seen frameworks like GSD, Ralph Loop, BMAD, and Superpowers popping up everywhere. And for good reason. They solved the thing that was killing us all.

You know the thing. You sit down with Claude or ChatGPT, start a project, and for the first 30 minutes, you feel like a wizard. Code flows. Architecture emerges. You’re shipping features faster than you can drink your coffee.

Then, three hours later, the AI is “helpfully” refactoring your state management because something in your chat history from two hours ago confused it. Your global store now thinks “water intake” and “bicep curl max” are the same thing. You’re not engineering anymore. You’re babysitting.

GSD and similar frameworks tackled this problem head-on with a brilliant insight: stop dragging context through a single massive conversation. Instead, break work into atomic tasks, give each task a fresh context window, and let a lightweight orchestrator manage the flow. The orchestrator stays lean (around 15% context usage), while each executor gets a pristine 200K token workspace. Task 50 runs with the same quality as Task 1.

It works. It really works. Engineers at Amazon, Google, and Shopify are using it. It turned vibe coding from a gamble into something resembling a repeatable process.

So why am I writing this article?

Because after spending weeks using this pattern, I found a seam. A place where it can go further. And it starts with a question that none of these frameworks explicitly address:

What if the orchestrator and the executor shouldn’t be the same model?

The Blind Spot in Single-Model Orchestration

Here’s the thing about GSD and its siblings. They solved context rot beautifully. Fresh contexts, atomic commits, spec-driven planning. Chef’s kiss.

But there’s a subtlety hidden in the architecture: the orchestrator and the executors are typically the same model. Claude plans the work, Claude does the work, and Claude verifies the work. Different instances, sure. Clean contexts, absolutely. But the same “brain.”

Think about what that means in practice. When the planner creates a task spec, it does so with a particular understanding of code patterns, naming conventions, and architectural trade-offs. When the executor picks up that spec, it brings the exact same biases and blind spots.

It’s like having your CTO and your senior developer be the same person wearing different hats. Sure, they’ll be consistent. But will they catch their own assumptions? Will they challenge their own architectural instincts?

I started noticing this in my own work. The plans were solid. The execution was clean. But I kept finding myself in situations where both the plan and the code shared the same subtle misunderstanding of my project’s constraints. Nobody in the loop was offering a second opinion.

The Architect-Executor Pattern: Splitting the Brain

So I ran an experiment. Instead of letting a single model handle everything, I split the roles among different models. Not just different contexts. Different brains.

Photo by Beckett P on Unsplash

Role 1: The Architect (a different model than your executor)

The Architect lives in your codebase. It has a live view of your file tree, your dependencies, and your actual data shapes. But here’s the key rule: the Architect does not write code.

Instead, it thinks at the system level. You throw business problems at it, not coding tasks.

“We need to add a dynamic ‘Add Set’ button to the workout screen, but it needs to tie into the local Zustand store without breaking the existing mocks.”

The Architect reads your files, figures out the dependency chain, and writes a living blueprint. I use a literal implementation_plan.md and a devlog file that grow alongside the project. The Architect is the keeper of the state. It documents what’s been built, what broke, what technical debt exists, and what the next move should be.

Here’s what makes this different from GSD’s planning phase: the Architect adapts continuously. When it looks at your store and realizes that your mock data is an array rather than a dictionary, it adjusts the plan before any code is written. It’s not a one-shot spec. It’s a living conversation with your codebase.

Using a different model family for this role gives you genuine architectural diversity. Different training data, different reasoning patterns, different instincts about what “good code” looks like. That tension is a feature, not a bug.

Role 2: The Executor (your coding powerhouse)

This is where the GSD principle shines hardest, and I kept it: the Executor gets a clean context every single time.

Because the Architect maintains the high-level docs and project state in Markdown files, the Executor doesn’t need to remember yesterday’s conversation. It doesn’t need to remember anything.

The Architect produces a single, perfectly parameterized, atomic prompt. A clean instruction set with all the relevant context baked in. The Executor receives it in a brand new session, sees only the pure context needed for that specific feature, writes the code, commits to Git, and hands back a report.

Zero context degradation. Zero hallucinated dependencies from three hours ago. Zero “helpful” refactors you didn’t ask for.

Role 3: You. The Loop Closer.

You take the Executor’s report, pass it back to the Architect for type-checking and verification, and if it passes, you move on.

You’re no longer doing the prompt-tweak-paste-pray cycle. You’re not micromanaging syntax. You’re not re-reading a 200-message chat history every morning to remember where you left off.

You’ve become the CEO of your own codebase.

What This Gives You Beyond GSD

Let me be specific about where this extends what GSD already does well:

Architectural diversity. GSD uses one model family for everything. My pattern deliberately uses different models for thinking vs. doing. The Architect might catch an assumption that the Executor would blindly follow, and vice versa. It’s the AI equivalent of code review by someone who doesn’t share your mental model.

Model agnosticism. GSD is built around Claude Code (and recently OpenCode and Gemini CLI). My pattern is a methodology, not a framework. You can use whatever combination of models makes sense for your project. Gemini for architecture, Claude for execution. Or swap them. Or use local models for the Architect if you’re working with sensitive code.

Continuous adaptation vs. phase-based planning. GSD’s planning phase produces specs that executors follow. My Architect is a living entity that watches the codebase change and adjusts the plan between every execution cycle. If the Executor’s commit reveals something unexpected, the Architect sees it in the file tree and recalibrates.

Lightweight setup. GSD has commands, agents, workflows, and a .planning/ directory structure. That’s great for larger projects. But sometimes you just need a second brain watching your file tree while you ship features. The Architect-Executor pattern works with nothing more than two chat windows and a shared repo.

Built-in documentation as a side effect. Because the Architect maintains implementation_plan.md and a devlog, you get living project documentation for free. Not as a separate step or ceremony, but as a natural byproduct of how the system works.

When to Use What

Let me be honest about trade-offs, because this isn’t a silver bullet.

Use GSD (or similar frameworks) when: you’re a solo developer who wants a reliable, automated pipeline. You’re starting a greenfield project. You want atomic git commits and automated verification out of the box. You want something that “just works” with a few commands. GSD is genuinely excellent for this.

Use the Architect-Executor pattern when: you’re building something non-trivial where architectural decisions compound. You’ve noticed your AI making the same category of mistakes across planning and execution. You want a second opinion baked into your workflow. You’re comfortable with a more manual, methodology-driven approach. Or you simply want more visibility into what’s happening in your project without having to read chat history.

Combine them. Nothing stops you from using GSD for execution while running a separate Architect model that reviews the .planning/ directory and suggests adjustments. The patterns are complementary, not competing.

The Bigger Picture

Here’s what I think is actually happening in our industry right now. The initial wave of AI-assisted development was “just prompt it and see what happens.” That was exciting, but chaotic. The GSD wave brought structure: specs, clean contexts, atomic execution, verification loops. That was a massive leap forward.

The next wave, and I think we’re just at the beginning of it, is about heterogeneous AI systems. No single model does everything; different models play different roles, challenging each other and compensating for each other’s weaknesses. The same way a real engineering team works.

We don’t hire a team of five identical engineers and put them in separate rooms. We hire people with different backgrounds, different perspectives, and different instincts. Then we put them in the same room and let the creative friction produce something better than any one of them could build alone.

That’s what I’m chasing with the Architect-Executor pattern. Not a replacement for GSD. An evolution of the same core insight: structure makes AI reliable. I’m just adding one more layer of structure: the structure of diverse thinking.

Give it a try. Your codebase (and your mental health) will thank you.

Now, if you’ll excuse me, my Architect just told my Executor to replace the app icon with a picture of the Terminator, and I need to go verify that they haven’t accidentally triggered Skynet.

Keep building, friends. 🚀