The CEO of Y Combinator Ships 10,000 Lines of Code a Day. Here's Exactly How.

Andrej Karpathy — co-founder of OpenAI, one of the most respected engineers alive — said something on a podcast earlier this year that stopped me mid-scroll:

“I don’t think I’ve typed like a line of code probably since December.”

That was March 2026. Three months of not typing code, and he was still shipping.

When Garry Tan — President and CEO of Y Combinator, the organisation behind Airbnb, Coinbase, Stripe, Dropbox — heard that, he had the same reaction I did. How? He’d been wondering the same thing himself. Because he was experiencing something similar.

In the 60 days before he published his answer, Garry shipped 600,000+ lines of production code across 3 projects. 35% of that was tests. He was doing this part-time. While running YC full-time.

His answer is called gstack. It’s free, open source, MIT licensed, and it’s the most complete Claude Code setup I’ve come across. This post is my attempt to explain what it actually is and why it works — in plain language, not technical jargon.

---

The problem with most AI coding setups

Here’s what most people do with Claude Code: they open a terminal, type a question, read an answer, type another question. It’s useful. But it’s still just a smarter search engine.

The problem is that building software isn’t one thing. It’s a sequence of things that each depend on the previous one. You have an idea → you figure out if it’s the right idea → you design how to build it → you build it → someone reviews it for bugs → someone tests it works → someone ships it → someone checks it didn’t break anything in production.

If you’re a solo founder or a small team, you’re doing all of that yourself. Each step takes time. Each step is where mistakes slip through. And the steps aren’t connected — you lose context switching between them.

That’s what gstack solves.

---

What gstack actually is

gstack isn’t a single Claude skill. It’s 33 skills that work together as one system.

Each skill is a specialist. You type a slash command and Claude becomes that specialist — with the context from the previous step already loaded in. The system follows the same process that a real engineering sprint follows:

Think → Plan → Build → Review → Test → Ship → Reflect

Let me walk through what that actually looks like.

---

The sprint, step by step

Step 1: Office hours (/office-hours)

You describe what you want to build. Instead of just starting to code, /office-hours does what a good YC partner does — it asks you six hard questions that expose whether your idea is actually right.

It pushes back on your framing. It finds the assumptions you haven’t examined. It writes a design doc.

Here’s a real example of how it works:

You say: “I want to build a daily briefing app for my calendar.”

Claude says: “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.”

Then it extracts five capabilities you didn’t realise you were describing, challenges four premises, generates three implementation approaches with effort estimates, and recommends the narrowest version to ship first.

That design doc then flows into every skill that comes after it.

Step 2: Planning (/plan-ceo-review, /plan-eng-review, /plan-design-review)

Three different lenses review the plan before you write a line of code.

The CEO review thinks about scope — is this the right problem, is this the right solution. The engineering review locks in architecture: ASCII diagrams of data flow, edge cases, failure modes, a test matrix. The design review rates every design decision on a scale of 0–10, explains what a 10 looks like, and edits the plan until it gets there.

By the end of planning, you have a document that a team of senior people has reviewed. Except there’s no team. It’s just you.

Step 3: Build

Claude writes the code, guided by the architecture locked in the previous step. This part is what people usually think of when they think of AI coding — just writing the thing. But notice how different it is when the plan is already solid.

Step 4: Review (/review)

After the code is written, /review acts like a staff engineer doing a pull request review. It finds bugs that would pass automated tests but blow up in production. It auto-fixes the obvious ones. It flags race conditions, security gaps, completeness problems. It won’t let you ship sloppy code.

Step 5: Test (/qa)

/qa was the biggest unlock in the whole system. It opens a real browser — actual Chromium, actual clicks, actual navigation — and tests your app the way a user would. It finds bugs. Then it fixes them with atomic commits and generates regression tests so the same bug can never slip through again.

Garry went from running 6 parallel workstreams to 12 after this started working. Once Claude can actually see the thing it built and say “I SEE THE ISSUE” — then fix it, test the fix, and verify it’s gone — everything changes.

Step 6: Security (/cso)

Before shipping, /cso runs OWASP Top 10 and STRIDE threat modelling. For every finding it surfaces, it includes a concrete exploit scenario — not just “there’s a potential vulnerability” but “here’s exactly how someone would use this against you.” It has 17 false positive exclusions built in so it doesn’t waste your time with noise.

Step 7: Ship (/ship + /land-and-deploy)

/ship syncs main, runs your test suite, checks coverage, pushes the branch, opens the PR. /land-and-deploy merges it, waits for CI to pass, and verifies the production deploy actually worked. One command from “approved” to “verified in production.”

Step 8: Reflect (/retro)

At the end of the week, /retro gives you a breakdown — commits, test health, shipping streaks. It works across all your projects and AI tools. It’s the kind of visibility that most engineering managers never actually have.

---

Why this works when a blank prompt doesn’t

The key insight is that each skill feeds the next one.

/office-hours writes a design doc. /plan-ceo-review reads that doc. /plan-eng-review writes a test matrix. /qa picks up that test matrix. /review knows what the plan said the code was supposed to do.

Nothing falls through the cracks because every step knows what came before it.

That’s the thing that’s hard to see from the outside. It’s not the individual skills that make gstack powerful. It’s the connections between them.

---

Who built this and why it matters

Garry Tan has been building software for twenty years. Before running YC, he was one of the first engineers at Palantir, cofounded Posterous (acquired by Twitter), and built Bookface — YC’s internal social network.

In 2013, working flat-out, he had 772 GitHub contributions for the year. In 2026, by March, he already had 1,237 — and accelerating.

He open-sourced gstack because he thinks these tools should be available to everyone, not just people who figure them out through expensive trial and error. MIT license. No premium tier. No waitlist.

“I open sourced how I build software. You can fork it and make it yours.”

---

How to install it

gstack installs as a bundle, not individual skills. Open Claude Code and paste this:

Install gstack: run git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

Claude handles the rest. It works with Claude Code, Codex CLI, Gemini CLI, and Cursor. You need Git and Bun installed.

To give your whole team access, run the same command from inside your project — the skills get committed to .claude/ so every teammate gets them on git clone.

See the gstack stack on findskills.co for the full list of all 33 skills.

---

Why I’m writing about this

I built findskills.co because these tools were scattered across GitHub — useful to people who already knew the ecosystem, invisible to everyone else. gstack is exactly the kind of thing that gets missed. It’s not a viral tweet, it’s a 33-skill system with a 3,000-word setup guide that most people would never get through.

This is my attempt to make it findable. And readable. For everyone — not just engineers.

---

Source: garrytan/gstack on GitHub. Discovered via claude-code-best-practice by shanraisshan.