Let's be honest. Working with an AI coding assistant can sometimes feel like managing a super-intelligent intern who just drank three Red Bulls. They’re brilliant, incredibly fast, and can write amazing code… but they lack focus. They’ll jump from product planning to writing tests to shipping code without any real structure. It can be a little chaotic.
What if you could give that brilliant AI a clear job description? What if you could say, "Okay, for the next 10 minutes, you are only a product manager. Then, you'll be a senior engineer doing a code review. After that, you're on QA."
That’s the core idea behind a fascinating new open-source project from Garry Tan called gstack. It’s not a new AI model. Instead, it’s a toolkit—a set of rules and workflows—designed to make Anthropic's Claude Code more disciplined, reliable, and a whole lot easier to work with.
So, What's the Big Idea Here?
Think of it like a professional kitchen. You don't have one person trying to chop veggies, sear steaks, plate desserts, and wash dishes all at once. You have specialists. There's a prep cook, a line cook, a pastry chef—each with a clear role.
gstack brings that same philosophy to AI-assisted software development. It breaks down the messy process of building software into eight distinct "skills" or modes. These are basically slash commands that tell Claude what hat it should be wearing at any given moment.
The goal is to stop the AI from trying to do everything at once and instead have it operate with clear boundaries. This way, when you ask it to plan a feature, it thinks like a product manager. When you ask it to review code, it puts on its "skeptical senior dev" hat.
Let's Look at the "Job Descriptions"
The gstack repository comes with eight core commands that cover the entire software lifecycle. It’s like a playbook for your AI teammate.
Here’s a quick rundown of what they do:
- /plan-ceo-review: This is the high-level, "big picture" mode. You use this to get the AI to think like a product owner or CEO, focusing on the what and the why of a feature.
- /plan-eng-review: Now we're getting technical. This command tells the AI to put on its architect hat and think about data flow, potential failure points, and what tests will be needed.
- /review: This is your classic code review. The AI focuses squarely on production risk, code quality, and spotting potential bugs before they get merged.
- /ship: Time to get it out the door. This mode handles the practical stuff: preparing a branch, syncing with the main branch, running tests, and opening a pull request.
- /browse: This one is huge. It gives the AI agent access to a web browser to click around your app, log in, take screenshots, and see what’s actually happening. More on this in a second.
- /qa: This builds on the browser access. It’s a dedicated mode for systematically testing the parts of your app that were actually affected by the new code.
- /setup-browser-cookies: A handy utility for getting your local browser's cookies into the AI's headless session, so it can log into services just like you do.
- /retro: For looking back. This mode helps with engineering retrospectives to figure out what went well and what could be improved.
See the pattern? Each command gives the AI a very specific, narrow focus. It’s all about structure.
The Secret Sauce: A Browser That Actually Remembers Things
Okay, here’s where gstack gets really clever. The most important piece of this whole system isn't the fancy prompts or Markdown files. It’s the browser.
Most AI agents, when they need to use a browser, spin up a brand new one for every single action. It's slow, and even worse, the browser has amnesia. It forgets logins, cookies, and what tab it was on just seconds ago. A cold start for a browser can take 3-5 seconds, which adds up fast.
gstack throws that approach out the window. Instead, it runs a single, long-lived headless Chromium browser in the background. It’s like a little daemon that’s always on, waiting for instructions. The AI communicates with it over a local HTTP connection, which is lightning fast—we’re talking 100-200 milliseconds per call after the initial startup.
Because the browser stays alive, so does its state. Cookies, tabs, localStorage, and your login sessions all persist from one command to the next. This is a game-changer. It means the AI can log into your app once with /browse and then run a dozen QA tests with /qa without having to log in again every single time. And to keep things tidy, the browser server automatically shuts down after 30 minutes of inactivity.
Tying QA Directly to Your Code
This persistent browser is what makes the QA workflow so powerful. In many other systems, browser automation is a clunky, separate step. You might get a screenshot, but that's about it.
With gstack, browser access is a core part of the development loop. The /qa command is designed to be smart. It doesn't just randomly click around. It actually looks at the code you just wrote—the "diff" in your branch—to figure out which parts of the application were affected.
Imagine you changed 8 files that impact 3 different pages in your web app. The /qa command will identify those 3 affected routes and then automatically test those specific pages against your local running app. It’s a direct line from a code change to a real-world validation. This stops QA from being a detached, manual chore and makes it an intelligent, automated part of the process.
A Quick Peek Under the Hood
You might be curious about the tech choices here. The gstack team made some very specific decisions, and they’re pretty practical. The whole thing requires Claude Code, Git, and Bun (version 1.0 or higher).
Wait, Bun? Not Node.js?
Yep, and there are good reasons for it. The project's documentation lays out four key advantages of using Bun for this system:
- Compiled Binaries: Bun makes it easy to compile the browser tool into a single native binary, which simplifies the installation for users on macOS and Linux.
- Native SQLite Access: This is a big one. Chromium stores its cookies in an SQLite database. Bun can read this database directly without needing extra clunky packages.
- Native TypeScript: Bun runs TypeScript files out of the box, which just makes development smoother.
- Built-in HTTP Server: The browser daemon needs a web server, and Bun provides a super-fast one right out of the box with
Bun.serve().
These aren't cosmetic choices. They’re practical engineering decisions that make the whole system more efficient and easier to manage.
It's All About the Workflow
When you step back and look at gstack, you realize its true contribution isn't a revolutionary new AI. It's a revolutionary new structure.
The real value here is the operational discipline it imposes. By separating product thinking, engineering architecture, code review, shipping, and browser-based testing into explicit, distinct modes, gstack is trying to turn a brilliant but scattered AI coder into a reliable, professional member of the team.
It’s an opinionated take, for sure, but it feels like a significant step toward making AI an integrated, predictable, and genuinely helpful part of how we build software. And in a world of chaotic AI agents, a little bit of structure might be exactly what we need.
