Garry Tan’s Claude Code Setup: Why gstack Is Spreading So Fast
Thu
AI SEO Specialist, Full Stack Developer
On March 17 and 18, 2026, Garry Tan’s open source Claude Code setup, gstack, basically did the modern dev internet speedrun.
TechCrunch wrote about it. GitHub stars jumped. Reddit got spicy. Hacker News did the thing where half the thread is “this is genius” and the other half is “this is cargo culting with extra steps”.
And that love hate split is the interesting part.
Because gstack is not some magical new model. It is not a secret jailbreak. It is not even a particularly complicated codebase.
It is a packaged workflow. An opinionated bundle of Claude Code “skills” that tries to make planning, review, QA, and shipping feel repeatable. Almost like you are installing a team’s operating system, not downloading a prompt.
That is why it is spreading. And also why it makes certain people roll their eyes.
Let’s unpack what it is, what people are reacting to, and what this says about where AI coding workflows are going next.
What gstack actually is (in plain English)
Here’s the repo if you want to browse it yourself: gstack on GitHub
At a high level, gstack is a set of Claude Code skills. Think of skills as reusable “mini playbooks” you can invoke while working in a codebase. Not just “write a function” prompts, but structured routines like:
- plan the change and list risks
- review a diff with a certain checklist
- test assumptions and edge cases
- do QA passes like a slightly annoying staff engineer
- prep the final output so it is actually shippable
In other words, it is scaffolding around the model.
And that scaffolding matters because most teams are not struggling with “can the model write code”. They are struggling with:
- it starts coding before it understands the problem
- it forgets constraints halfway through
- it outputs plausible changes that break one weird edge case
- it never really finishes, it just keeps going
- it is hard to review and trust the output
- everyone prompts differently, so results vary wildly
gstack tries to reduce that variance by making the model follow a consistent set of steps. You can argue about whether Garry’s steps are the best steps. But the direction is the point.
This is “prompting” moving from an individual sport to a team sport.
Why the internet is paying attention (it is not the code)
A lot of the hype is basically people realizing, again, that the biggest unlock is not the raw model. It is the workflow.
When someone ships a repo like gstack, they are implicitly saying:
“Stop improvising prompts every time. Install a process. Make the AI behave like your team behaves.”
That scratches a very real itch for operators and founders. Especially if you are:
- running a small team and you need output to be consistent
- shipping fast and tired of re explaining how you want things done
- onboarding new devs and noticing they struggle to use AI tools well
- trying to move from “AI helps sometimes” to “AI is a reliable production lever”
In that sense, gstack is less like a prompt collection and more like a lightweight “agent operating manual”.
Also, the author matters. Anything Garry touches gets attention. But the reason it stuck is that it captures a bigger shift: teams want reusable AI behavior.
Claude Code skills, and why they are a big deal
If you have not used Claude Code much, the “skills” concept is the key to understanding why this format is sticky.
Most people’s AI coding workflow still looks like this:
- paste a task into a chat
- get an answer
- copy into editor
- fix issues manually
- repeat
Skills push you toward something closer to:
- consistent entry points (how we start tasks)
- consistent intermediate artifacts (plans, checklists, test ideas)
- consistent exit criteria (what “done” means)
This is boring. Which is exactly why it is powerful.
Because boring is what lets a team scale.
When you package skills, you are basically turning fuzzy tacit knowledge into a callable function. Like. “Here is how we do code review here.” Now the model can do a first pass using your standard.
Even if it is not perfect, it produces a predictable review shape. And predictable shapes are easy to integrate into real workflows.
The deeper story: process packaging is beating model quality
This is the part a lot of people miss while debating whether gstack is “good” or “overhyped”.
Even if you swapped Claude out tomorrow for another frontier model, the value of gstack mostly remains, because it is not about Claude being uniquely smart.
It is about:
- sequencing tasks so the model stays on rails
- capturing “what good looks like” in a reusable form
- making outputs legible to humans (plans, diffs, checklists)
- reducing the cost of supervision
Model quality still matters, obviously. But we are in a phase where the marginal gains from process are often bigger than the marginal gains from switching models.
This is also why people inside companies are quietly building internal equivalents. They might not call it gstack, and it might live in a private repo or Notion, but it is the same instinct.
Standardize the way the AI works so your team stops getting random results.
Why people love it (the pro gstack argument)
The positive reaction tends to cluster around a few themes.
1. It turns “vibes based prompting” into something repeatable
A lot of builders are tired of the situation where one engineer gets amazing results with AI and another gets garbage, purely because of prompting style.
gstack says: here are the defaults. Here is the house style. Stop reinventing.
Even if you end up editing the skills heavily, the existence proof is valuable.
2. It creates a shared language for AI assisted work
Teams already have a shared language for shipping:
- spec
- plan
- PR
- review
- QA
- deploy
- postmortem
AI work often lacks this. People just say “I asked Claude to do it.”
A skill based approach creates a shared set of nouns and verbs. That is underrated. When you can say “run the review skill on this diff” you are no longer describing a mystical act. You are describing a routine.
3. It nudges the model toward safer behavior
A common failure mode is the model confidently making invasive changes. Skills that force planning, risk listing, and explicit test suggestions can reduce the blast radius.
Not eliminate. Reduce.
And reduction is enough to matter in production teams.
4. It feels like a shortcut to senior judgement
This is the spicy one.
Some folks love gstack because it feels like “install staff engineer brain”. Like you are borrowing an opinionated, checklist driven way of thinking about shipping.
That can help juniors. It can also help founders who are coding again after a break. Or operators who are technical but not deep in the stack.
This is also where some of the backlash comes from, because people worry it creates the illusion of senior judgement without the real understanding.
Which. Fair concern.
Why people dislike it (and why the criticism is not wrong)
The negative reaction also clusters into a few buckets. And honestly, they are mostly reasonable.
If you want the full temperature check, this TechCrunch piece captures the love and hate dynamic well: why Garry Tan’s Claude Code setup got so much love and hate
Here are the common critiques, translated into operator speak.
1. “This is just prompts in a trench coat”
Some people look at gstack and see glorified prompt templates. They are not entirely wrong.
If you treat it as “a bunch of text files telling a model what to do”, it can feel like over engineering.
But the counterpoint is: lots of valuable systems are “just” checklists. A pre flight checklist is just words. Still important.
The real question is whether the packaging makes it easier to actually use, consistently, in the middle of work.
2. It can encourage cargo cult process
If you copy someone else’s workflow without understanding why the steps exist, you can end up with bureaucracy that slows you down.
The risk is higher when the workflow is authored by a person with a different environment than yours. Different team size, different risk tolerance, different product constraints.
So yes, blindly adopting gstack is a little like pasting someone else’s incident response playbook into your org and calling it done.
3. Overconfidence amplification
Structured skills can increase trust, because the output looks more professional.
A model that produces a neat plan with bullet points can still be wrong. In fact, it can be wrong more convincingly.
This is a real risk with any operationalized AI output. The more “enterprise shaped” the output looks, the easier it is to rubber stamp.
If you adopt a setup like this, you need explicit countermeasures: review discipline, real tests, real observability, and the willingness to say no.
4. It can clash with how good engineers actually work
Some experienced engineers do not want to be forced into a template.
They might want to explore, spike, and iterate fast without writing a plan first. Or they might already have their own mental checklists.
To them, gstack can feel like process cosplay.
And to be clear, if you are already a strong engineer with a crisp workflow, you may not get much value from someone else’s scaffolding. You may even get negative value.
Who should copy this setup (and who shouldn’t)
Not everyone should adopt gstack. But a lot of teams should steal the underlying idea.
You probably should try it if you are:
- a founder shipping product fast with a small team
- a tech lead trying to standardize AI usage across devs
- a team that already uses Claude Code and wants more consistency
- an org where code review and QA are the bottlenecks
- onboarding new engineers and noticing uneven AI results
The biggest win case is: you want a default workflow you can tweak, rather than inventing from scratch.
You probably should not copy it as is if you are:
- working in a highly regulated environment with strict SDLC requirements
- building safety critical systems where “pretty good” plans are dangerous
- on a team with an established engineering playbook that already works
- an expert in a niche domain where generic checklists miss the real risks
Also, if you hate opinionated tooling on principle, you will hate this. Life is short.
What gstack reveals about how AI coding workflows are evolving
Zooming out, gstack is a signal that the market is moving from “tools that generate code” to “systems that generate reliable outcomes”.
A few trends are converging here.
1. Skills and playbooks are becoming the real IP
In 2023 and 2024, the “secret sauce” was model access and prompt tricks.
Now it is shifting toward:
- reusable skills
- team specific checklists
- domain constraints baked into workflows
- standardized artifacts that fit into existing pipelines
The model is the engine. Skills are the transmission.
If you are building in this space, the defensibility is not “we call GPT 5”. Everyone can call GPT 5. The defensibility is your workflow library and how well it fits real operator needs.
2. Repeatability is replacing novelty
Early AI coding was fun because it was surprising.
But production teams do not want surprises. They want predictable throughput. They want fewer regressions. They want the same shape of output every time so they can review quickly.
gstack is a bet on repeatability.
3. “Agent” is becoming a process, not a bot
There is a lot of noise around agents. People imagine a bot that just ships features.
In practice, what works is more boring. Agentic systems are basically:
- break work into steps
- enforce order
- preserve context
- produce artifacts
- require gates before proceeding
gstack is closer to that reality than most “autonomous dev” demos.
4. Teams are building AI operating systems
This is the biggest meta lesson.
A team that uses AI well usually has:
- a shared prompting style
- shared definitions of done
- agreed review standards
- a library of reusable instructions
- a place where those instructions live, versioned, improved, argued about
gstack is just one public example of that. It is spreading because lots of teams feel the pain of not having it.
Tactical lessons you can steal even if you never touch Claude Code
You do not need Claude Code. You do not need gstack. You do not need Garry’s opinions.
You can still take the underlying mechanics and apply them to whatever tool you use. Here are the practical takeaways.
1. Create 4 reusable skills for your team (start small)
If you only build four, build these:
- Planner: clarifies requirements, lists assumptions, proposes approach, calls out risks.
- Implementer: makes changes with minimal diff, references the plan, leaves notes for review.
- Reviewer: reviews for correctness, security, performance, style, and tests. Flags unknowns.
- QA Tester: proposes test cases, edge cases, and validation steps. Includes “how this could fail”.
Write them like checklists. Keep them short. You want something people actually run when busy.
2. Standardize the artifacts, not the exact wording
The point is not to make everyone use the same prompt.
The point is to make sure every AI assisted change produces the same key artifacts:
- a plan you can critique
- a list of assumptions
- a risk section
- test suggestions
- a clear summary of what changed
When outputs are shaped consistently, your review process gets faster and your trust increases.
3. Put gates in the workflow
Make it explicit when the model must stop and ask.
Example gates that work:
- “Do not edit code until the plan is approved.”
- “If you are uncertain about requirements, ask questions first.”
- “If tests fail, stop and propose fixes, do not keep changing random things.”
This prevents the model from going into “helpful autopilot” mode.
4. Treat skills like code: version them, review them, improve them
This is where most teams drop the ball.
They write a prompt, it works once, then it rots in a doc.
If skills matter, they should live somewhere version controlled. People should be able to PR improvements. You want a paper trail for why the workflow changed.
That is how you turn “prompting” into an operating system.
5. Measure outcomes, not vibes
If you adopt an AI workflow system, track a few simple metrics:
- review time per PR
- number of regressions
- test coverage changes
- cycle time from ticket to deploy
- how often AI output is reverted
If your workflow is not improving outcomes, it is just ceremony.
One last thing: document the workflow so it actually spreads internally
A big reason gstack is spreading is that it is packaged and documented enough that other people can pick it up.
Most internal AI workflows fail to spread because they live in someone’s head, or in a messy doc nobody trusts.
If you want these ideas to stick inside your org, you need clean documentation. Not fancy. Just clear. And kept current.
If you are already collecting workflow notes, checklists, and playbooks, you can turn that into polished internal docs, onboarding guides, and even public engineering content pretty fast with Junia AI. It is built for long form, search optimized writing, but honestly it is also great for operational documentation because it can take rough outlines and turn them into something readable and structured. Here’s the platform: Junia.ai
That is the real thread connecting all of this.
gstack is not famous because it is a repo. It is famous because it shows what happens when you package how you work, not just what you build.
And that is where AI dev workflows are heading. Less “ask the model for code”. More “install a process that makes the model useful, consistently, on a team, under deadlines”.