Vibe Coding Best Practices: Why I Use Multiple AI Personas

When your project is small, one AI session works fine. You talk to Claude, it writes code, you iterate. Simple.

Then the project grows. And you hit what people are now calling “context debt” — your single session is your architect, your coder, your strategist, and your QA tester all at once. It’s burning through tokens, losing track of what you discussed 20 minutes ago, and making decisions that don’t line up with what you agreed on three conversations back.

If you’re vibe coding and your context is overflowing, split your AI into multiple sessions with dedicated roles. I run an Architect on Opus for decisions and a Coder on Sonnet for implementation. After splitting, my token usage dropped from 1M to 250K per session. That’s the single biggest vibe coding best practice I can share.

Key Takeaways

• Split your AI into specialized personas (Architect, Coder, QA) instead of one session doing everything — token usage drops from 1M to 250K per session
• Subagents sound like the solution but they cut corners, waste tokens, and can’t be reused — separate terminals with a human relay work better
• Keep all context in markdown files in your repo, not in AI memory — it’s reliable, shareable, and provider-portable
• This runs on Claude Pro ($20/month, which includes Claude Code), not some enterprise setup

I was running 1M token context windows and it often wasn’t enough. That’s when I knew the one-session approach was done.

The vibe coding workflow: specialized roles

I run multiple AI sessions, each with a specific role. Each gets its own terminal, its own context, its own job description. Here’s the breakdown:

Architect (Opus) — the team lead. Makes technical decisions, writes detailed plans, reviews code after it’s written, writes QA test scenarios. Does not write a single line of production code.

Coder (Sonnet) — the junior dev. Takes the Architect’s plan and executes it. Pure implementation. Writes features and the tests for them.

QA Tester (Sonnet) — runs test scenarios through Playwright, connects directly to the database via MCP, checks that what the UI shows matches what’s actually in the data.

Think of it like a small team. The Architect is the senior who knows the system inside out. The Coder is a junior who’s incredibly fast but needs clear specs. And here’s the thing — with good specs, that junior becomes excellent.

After splitting things up, 250K tokens per session works fine. Down from 1M.

And by the way — this is all on Claude Pro (which includes Claude Code). $20/month. Not some enterprise setup.

• Architect (Opus) — Technical decisions, plans, code review, QA scenarios. Does NOT write production code.
• Coder (Sonnet) — Feature implementation, tests. Does NOT make architecture decisions.
• QA Tester (Sonnet) — Playwright tests, database verification, UI checks. Does NOT write feature code.

Should you use subagents or separate Claude Code sessions?

This is what most people assume. If you need multiple roles, let the AI spin up subagents and coordinate them for you.

I tried that. Here’s why I stopped.

You can’t see what’s happening. You can’t watch a subagent’s logs and the main session’s logs at the same time. Things happen that you miss entirely. This is the “glass box” problem that people on Hacker News keep raising — when multiple agents work without audit trails, you lose traceability fast.

They cut corners. Subagents are goal-oriented to a fault. Command fails? Skip it. File read fails? “I don’t need that file.” Rate limit hits? The subagent decides to do the review itself instead of retrying — superficially. Pipeline checks? git push --no-verify. They want the task marked complete, and they’ll take shortcuts to get there.

They burn through tokens. The Architect would spin up a subagent with something like “find out how billing works.” Simple task, right? That agent would blow through 80K tokens just to locate 2-3 files. I’ve seen this happen many times. It burned through my session limits so fast I’d have to stop working and wait for a reset.

No session reuse. Subagent finishes and it’s gone. If the Architect finds issues in the review, I’d need a fresh agent with zero context. With separate terminals, I send fixes back to the same Coder session. No context rebuild.

The billing module disaster

Here’s what actually pushed me over the edge.

A subagent gets a bug report. Fine — it investigates. Then it makes the wrong assumption about what’s causing it. Instead of stepping back, it writes a whole half-reimplementation to “fix” it. That fix causes a regression. And does the agent think “let me revert”?

No. It basically goes “well, too late now” and keeps digging. Deeper. Trying to reimplement the entire billing module to work around the regression it just created.

Assumptions and loops. That’s the pattern. Wrong assumption leads to a bad fix, bad fix causes a new problem, new problem triggers another wrong assumption. And the agent never stops to question the original assumption. It just keeps going.

That’s when I realized: bounded roles, limited permissions, limited scope — that’s the fix. Don’t give any one session the ability to go off the rails like that.

The relay pattern: fleet engineering without the tooling

There are tools popping up for running multiple AI sessions in parallel — people are calling it “fleet engineering.” Zaivern, Orca, Paseo. I don’t use any of them. Here’s what I do instead:

The Architect writes a plan, then produces a prompt for the Coder. I read the prompt, copy it to the Coder’s terminal. The Coder executes. I watch the logs while it works.

When it’s done, I send the result back to the Architect for review. The Architect checks the code, checks the tests, flags anything that needs fixing. If there are fixes, I send them back to the same Coder session.

I’m deliberately in the middle. That’s not a limitation — it’s the quality control layer.

Being the relay means I catch things: wrong assumptions before they snowball, steps the Coder skipped, checks it bypassed. If I wasn’t in the loop, I’d get another billing module disaster. No thanks.

Which model should each role use: Opus or Sonnet?

Multi-model rotation is becoming standard advice in vibe coding — several workflow guides in 2026 recommend it for cost optimization. But it’s not just about cost.

Opus for the Architect because it needs judgment. Architecture decisions, bug inspection, understanding trade-offs, reviewing code quality — that’s where the reasoning capability matters.

Sonnet for the Coder because it’s fast, produces clean code, and is cheaper per token. Could I use Opus for coding? Sure. But I’d burn through my limits too fast on work that doesn’t need that level of reasoning.

Strategic choice: save Opus capacity for where judgment matters.

What is context debt, and how do you fix it?

Context debt is the growing cost of working on an AI-assisted codebase when the AI doesn't remember your earlier decisions. Every new session starts from zero, so you re-explain the same things, changes get slower, and the code drifts away from what you agreed. The bigger the project gets, the more you pay.

My fix: every plan, every persona definition, every piece of documentation — it’s all markdown files in the repo. Not Claude’s memory. Not any provider’s memory.

Three reasons.

First, AI memory is unreliable. Many times you need something and it’s just not there. I got burned by that enough times to stop trusting it.

Second, files are shareable. They’re viewable, editable, pushable to git. If someone else works on the project, they have the same context I do. Memory is buried in a user folder somewhere — good luck collaborating with that.

Third — and this one matters more than people think — markdown files work with any model from any provider. If I switch from Claude to something else tomorrow, all my context is still there. No lock-in. The whole vibe coding workflow is designed to not depend on any one tool’s proprietary features. Separation of concerns applies to providers too.

What this actually looks like

I’m building a management system for a US accounting business. Client profiles, file management, secure vault for sensitive data, billing with subscriptions and one-off charges, team management with role-based access. The full stack.

Solo. No designer — I use Claude Design for that. No QA tester — Playwright MCP handles it. No second developer.

The plan is what makes it possible. A 5-page detailed plan means the Coder can execute with minimal back-and-forth. Not “build me a billing system” — every component, every edge case, every test, spelled out.

The Architect always requires: no commit unless all tests pass. Before a session the test suite might have 500 tests. After: 510. If the suite fails, the review doesn’t even start — nothing else to discuss until it’s green.

Before vs. After

• Token context: 1M and often not enough — now 250K per session, plenty of room
• Context retention: Lost mid-conversation — now each role retains focused context
• Quality control: Subagents cutting corners — now human relay catches problems early
• Model usage: One model for everything — now Opus for judgment, Sonnet for speed
• Context storage: AI memory (unreliable) — now markdown files in the repo (portable)

How long it took to get here

About a month or two. Not because it’s complicated — it was just novel. Nobody was doing it this way, so there was no guide to follow.

Some people call this “agentic engineering” now — the idea that AI coding needs structure, roles, and human oversight, not just “prompt and hope.” I just started treating it like a team instead of one thing doing everything. Give each role clear boundaries, clear expectations, and don’t let any one session try to be everything.

If you’re vibe coding and you’ve hit the wall where one session isn’t enough — where your context is overflowing and your sessions are getting messy — this is probably where you need to go. Not bigger context windows. Better separation.

I coach people 1-on-1 to set up vibe coding workflows like this. If that’s useful to you, book a call and we can talk about it.

What’s your current setup look like? Are you running into the same walls?