I Stopped Hiring a Team. I Hired a Process Instead.
Andrej Karpathy said something enough to bring him to limelight that stopped me mid-scroll.
“I don’t think I’ve typed like a line of code probably since December.”
Not “AI helps me code faster.” Not “I use Copilot for boilerplate.” He said he stopped typing code. Since December.
Most people read that as a flex. I read it as a systems problem. Because the obvious follow-up question isn’t “wow, how productive is he?” It’s: how does the software not turn into chaos?
When one person stops writing code and starts directing it, the bottleneck shifts completely. You’re no longer constrained by how fast you type. You’re constrained by how well you can think, plan, review, and ship. The process becomes the product. The workflow becomes the work.
gstack is Garry Tan’s answer to that problem. The Y Combinator CEO open-sourced his exact Claude Code setup: 23 slash-command tools, MIT licensed, that collectively turn a single developer into something that behaves more like a small engineering team.
It hit 99,500 GitHub stars. In weeks.
But here’s the thing: the stars are the least interesting part of the story.
What Everyone Misreads About This
The internet framed gstack as “Garry Tan’s productivity hack” or “YC CEO shares AI coding setup.” Both framings are technically accurate and almost completely wrong.
gstack isn’t about productivity in the way people mean when they say productivity. It’s not about doing the same thing faster. It’s about doing a structurally different thing, which happens to be much faster.
If you wish to save costs on your tokens without compromising the performance, checkout my open source repo here.
Most people using AI coding tools are doing something like this: they write a prompt, the AI writes some code, they review it, they iterate. It’s a faster version of the same loop they had before.
gstack does something different. It encodes the entire software development lifecycle into a sequence of roles:
/office-hours→/plan-ceo-review→/plan-eng-review→ build →/review→/qa→/ship
That’s not a faster developer. That’s a process, staffed by AI, with a human making decisions at the checkpoints.
The person who built gstack isn’t shipping code faster. He’s shipping outcomes faster, because the gap between “I have an idea” and “it’s in production, tested, documented, and reviewed” has collapsed.
The Diagram Nobody Drew
Here’s what’s actually happening under the hood:
The individual tools aren’t the insight. The sequence is.
Each stage feeds the next. /office-hours produces a design doc that /plan-ceo-review reads. /plan-eng-review produces a test plan that /qa picks up. /review catches bugs that /ship verifies are fixed. Nothing falls through the cracks because every step knows what the previous step decided.
This is the thing most AI coding setups are missing: not capability, but coordination. The failure mode of AI-assisted development at scale isn’t that the AI writes bad code. It’s that nobody told the AI what to think about before writing it.
The /office-hours Tool Is the One Most People Will Skip
And it’s the most important one.
Most developers, when they get excited about a feature idea, want to immediately start building. This is a deeply human instinct and a reliable source of wasted weeks.
/office-hours simulates a YC partner conversation before a line of code is written. Six forcing questions. It pushes back on your framing. It challenges premises. It generates implementation alternatives. And it writes a design doc that every downstream skill reads automatically.
The repo has an example that illustrates this perfectly:
You describe a “daily briefing app for my calendar.” The agent responds: “I’m going to push back on the framing. You said ‘daily briefing app.’ But what you actually described is a personal chief of staff AI.”
That reframe, happening before implementation, is worth more than any individual code-quality improvement downstream.
I’ve seen this failure mode in teams repeatedly: engineers build the literal feature that was described, when the actual user problem was three abstractions away. The feature ships. Nobody uses it. Six weeks lost. office-hours is a forcing function against that outcome.
The LOC Controversy (And Why Both Sides Are Missing the Point)
Garry Tan published his productivity numbers: roughly 810x his 2013 coding pace, measured in logical lines per day. The internet, predictably, split into two camps.
Camp A: “This is insane. One person can do what entire teams used to do.”
Camp B: “Lines of code is a garbage metric. AI inflates it. Meaningless.”
Both camps are arguing about the wrong thing.
The number doesn’t matter. What matters is that he shipped three production services, 40+ features, in 60 days, part-time, while running a global startup accelerator full-time. That’s the real stat. Lines of code is just his attempt to make the pace legible, not a claim about output quality.
And honestly? The LOC critics aren’t wrong that raw line counts inflate with AI. They are wrong that this makes the underlying productivity claim false. Normalized for inflation, more is shipping. The commit graph is visible.
The real question isn’t “is the metric right?” The real question is: what happens when this is table stakes? When every technical founder has a setup like this? When shipping three services in 60 days part-time is the floor, not the ceiling?
That question doesn’t have a comfortable answer yet.
The Three Things I’d Actually Use Immediately
I’ve been in this space long enough to recognize the difference between a feature list and a feature set. gstack has both. Here’s what I think is genuinely differentiated, not just a clever implementation of something obvious:
1. The /design-shotgun → /design-html pipeline
This is the first AI design workflow I’ve seen that isn’t either “describe a design in words and hope” or “use Figma and export.” The shotgun generates 4-6 visual variants using GPT Image, opens a comparison board, collects your feedback, and remembers what you liked across iterations. The taste memory is the part that compounds. After a few rounds, it starts biasing toward your aesthetic preferences. Then /design-html converts the winner into production-ready HTML with real dynamic layout, not the kind that looks fine at one viewport width and shatters at 1280px.
I’ve wasted more hours than I’d like to admit on AI-generated UIs that looked great in demos and fell apart in production. This pipeline actually addresses that.
2. GBrain, the memory layer
One of the quiet frustrations of AI coding tools is that every session starts from scratch. The agent doesn’t know your codebase’s quirks, your architectural decisions, the three things you tried that didn’t work. You re-explain everything, every time.
GBrain is persistent knowledge for your agent. Index a codebase once. The agent searches it instead of grep-ing blind. It remembers that you tried the event-sourcing approach and it caused race conditions. It knows your naming conventions. It compounds over time on your specific project.
This is closer to how a great staff engineer actually works. They know the system. They don’t ask you to explain the same architecture for the fifth time.
3. /pair-agent (the multi-agent coordination nobody is talking about)
This one is quietly fascinating. It lets agents from different AI vendors share the same browser, each in isolated tabs, with scoped tokens, rate limiting, and activity attribution. Claude Code and OpenClaw, coordinating through a shared browser, watching the same page, neither interfering with the other.
The enterprise AI infrastructure space has been talking about multi-agent coordination for two years. Most implementations are theoretical or toy examples. This is a production implementation you can run today.
My Honest Take
Here’s what I actually think, separate from the feature list:
gstack is impressive not because of what any individual tool does, but because of the philosophy baked into the sequencing. The insight is that most AI coding tools give you a faster horse. gstack gives you a different vehicle.
The reason I like this repository isn’t the star count. It’s that someone with Garry Tan’s vantage point, having watched thousands of startups build software over two decades, decided to encode his process rather than his preference. The /office-hours tool isn’t there because it’s technically clever. It’s there because he’s watched founders skip that step and pay for it.
That’s institutional knowledge turned into infrastructure. That’s the thing most devtools don’t have.
Is it perfect? No. The setup has real complexity. Running 10-15 parallel sprints via Conductor requires a specific machine setup and a specific kind of mind. The browser automation layer, while genuinely impressive, introduces surface area. And like any opinionated system, it works best if you agree with the opinions.
But the core idea, that software development is a process that can be staffed by AI roles rather than just a task that can be AI-assisted, is one that’s going to outlast any specific implementation.
The tools will change. The architecture will iterate. The star count will become a footnote.
The process insight will stick.
The Strangest Part
gstack shipped a file called slop-scan.config.json.
It’s a configuration file for detecting AI slop in your own AI-generated code.
An AI-powered workflow, with a tool to detect when AI output is... too AI-like.
I’m not sure whether that’s ironic or inevitable. Probably both.
That’s when software stops behaving like software. And starts behaving like something that’s learned to quality-check itself.
-Hardik
Support my work : buymeacoffee.com/HardikGoel
Repository: github.com/garrytan/gstack — MIT licensed, free, 99.5k stars. Worth 30 minutes even if you don’t use it, for the ETHOS.md alone.