Series: Gstack (2/7)
Why AI Assistants Need 'Role Switching' — The Core Logic of Gstack
Here's a scenario you might recognize:
You ask Claude to "review this code." It responds with a thorough-looking breakdown — architecture suggestions, naming conventions, a few small bugs. You make the changes, commit, and two days later production breaks. You trace it for an hour and find a race condition — right there in the code it "reviewed."
Claude wasn't being stupid. You had it do a "paranoid senior engineer's" job using a "general assistant" brain.
Those are very different things.
The Cost of One-Conversation-Does-Everything
The way most people use Claude Code is to throw everything into the same context:
"Help me design the architecture for this feature."
"Okay, now help me write the implementation."
"Done, help me review it."
"Reviewed, help me open a PR."
Every step in the same conversation, AI responding in the same "mode" every step. Seems smooth on the surface, but in reality —
During architecture design, it didn't ask enough questions about whether the feature is worth building.
During code review, it looked at syntax and style, not production-level failure modes.
When opening the PR, it didn't confirm whether tests ran or the main branch was synced.
Every step was done. Every step was done at 70%.
Gstack's Core Idea: Cognitive Modes Can Be Switched
When Garry Tan designed Gstack, he started with a fundamental question:
"If I had a real dev team today, what is each role thinking about?"
The CEO is thinking: Is this feature worth building? What is the user's real problem? Is there a 10x better solution?
The Engineering Manager is thinking: Does this architecture have hidden failure modes? Where are the async boundaries? Is test coverage enough?
The senior engineer reviewing a PR is thinking: N+1 queries, race conditions, trust boundary violations — the problems that pass CI but blow up in production.
The Release Engineer is thinking: Is the branch synced with main? Did all tests pass? Is the PR description complete?
These roles operate on completely different "frequencies" — you can't summon all of them with one universal prompt. You'll get a diluted version of each.
What Gstack does is simple: package each of these cognitive modes into a skill, and switch between them explicitly with slash commands.
Nine Skills, Nine Cognitive Modes
Gstack currently offers nine core skills:
| Slash Command | Role | What It's Asking |
|---|---|---|
/plan-ceo-review |
Founder / CEO | Is this feature worth building? Is there a better solution? |
/plan-eng-review |
Engineering Manager | Architecture, data flow, edge cases, test coverage |
/review |
Paranoid Senior Engineer | Problems that pass CI but blow up in production |
/ship |
Release Engineer | Sync, test, push, PR — the full pipeline |
/browse |
QA Engineer (with eyes) | Click through your app with a real browser, verify with screenshots |
/qa |
QA Lead + bug fixer | Find issues, fix them, verify the fix, output a health score |
/qa-only |
QA Reporter | Report only, don't touch your code |
/setup-browser-cookies |
Session Manager | Import your real cookies into the headless session |
/retro |
Engineering Manager (retrospective) | Analyze commit history, shipping velocity, PR size |
Behind each skill is a carefully designed system prompt that puts AI in that cognitive mode — the questions it asks, the dimensions it checks, the format of its output — all calibrated for that role.
Why Not Just Use One Super-Prompt?
This is the most common question: "Can't I just tell Claude in the system prompt 'you are simultaneously a CEO, engineer, QA, and Release Engineer'?"
No, and the reason is specific: roles have cognitive conflicts that dilute each other when mixed.
CEO thinking is "think boldly, aim for the best solution"; paranoid engineer thinking is "assume everything will break, find the worst case." Run both modes simultaneously and you get a compromise — not bold enough, not paranoid enough — that helps neither task.
It's like asking the same person in the same meeting to both pitch to investors and do legal risk review — these tasks require fundamentally different mindsets, and separating them is what produces quality.
Gstack vs. Regular Prompting
A direct comparison:
The usual approach: "Help me review this code and find bugs."
→ Claude scans with general assistant mode, finds a few obvious issues, probably misses race conditions and N+1 queries.
Gstack /review:
→ AI switches to "paranoid senior engineer" mode, systematically checks: N+1 queries, race conditions, trust boundary violations, missing indexes, broken retry logic, stale reads — there's a checklist, it goes through each item, nothing gets skipped.
The difference isn't AI intelligence — it's the questions being asked. Good cognitive modes are the ability to ask the right questions.
What Gstack Can't Fix
Worth being clear about what Gstack doesn't solve:
- It won't decide what product to build — you still need to know what problem you're solving
- It doesn't replace programming ability — you still need to understand the advice it gives
- When running at full capacity it consumes a lot of tokens — each role has its own context initialization cost, complex tasks burn through quickly
Gstack is for people already writing production code with Claude Code who want more consistent quality — not for those just getting started with AI-assisted development.
Mental model built. Next step: get those nine skills actually running.
→ Gstack Installation and Quick Start: Nine Skills in 10 Minutes
Back to Series Overview
This is the first stop in the Gstack series, establishing the core concept of "why role switching matters." For the complete reading path and other post topics, return to Gstack Beginner Course.