gstack's Virtual Engineering Team: How 23 Roles Turn One Person Into a Team

Forum topic · ✨步子哥 · 2026-10-04

Summary

gstack is an open-source project by Garry Tan, President and CEO of Y Combinator, that implements a structured AI agent workflow for software engineering. Rather than being a simple skill pack, it defines an organizational structure of 23 specialized roles and 8 tools mapped to human job functions: CEO-level plan review, design, engineering management, coding, PR review, QA, security audit (via a /cso role), release management, and documentation. The entry point is /office-hours, which front-loads strategic validation before any code is written. The README reports 3 production services and 40+ shipped features in 60 days, claimed as 810x Garry Tan's own 2013 pace, measured in logical code changes rather than raw lines of code, with every change passing a review stage. Security is treated as a first-class role rather than an optional lint step, checking OWASP Top 10, dependency vulnerabilities, and leaked secrets. Installation takes roughly 31 seconds on a 4-vCPU Linux machine. The article argues gstack's real significance is not the speedup number but a shift from individual productivity to organizational design: one person running a balanced, multi-role virtual team where slash commands replace inter-role communication friction. gstack suits founder-CEOs still coding, first-time Claude Code users, and tech leads automating review, QA, and release workflows. MIT licensed, written in TypeScript.

gstack's "Virtual Engineering Team": How 23 Roles Turn One Person Into a Team

> Project: garrytan/gstack > Author: Garry Tan — President & CEO of Y Combinator > Language: TypeScript | License: MIT > Stars today: +121

---

1. Karpathy's Line

In March 2026, Andrej Karpathy said in a conversation:

> "I think I may not have hand-written a line of code since last December."

This sent shockwaves through the AI engineering community. But many people overlooked a precondition: Karpathy can do this not because he uses some magical model, but because he has a structured agent workflow — the model is just the engine; the workflow is the car.

Garry Tan's gstack is a complete implementation of this idea. Not "one prompt solves everything," but 23 expert roles + 8 tools that turn one person into a virtual engineering team.

---

2. Not a Skill Pack — an Org Chart

gstack is easily misread as "yet another Claude Code skill library." It is not.

addyosmani/agent-skills is a collection of general engineering skills — code review, doc generation, test writing. coreyhaines31/marketingskills is a marketing skill collection. These are skill libraries: you have a task, you go find the matching skill and execute it.

gstack is an organizational structure. Its 23 roles are divided not by "skill" but by function:

| Function | Role | Human Equivalent | |---|---|---| | Strategy | /plan-ceo-review | CEO: reviews whether a feature is worth building | | Design | /design | Designer: produces interaction proposals | | Eng management | /plan-eng-review | Eng manager: breaks down tasks, orders dependencies | | Coding | /build | Senior engineer: writes code | | Code review | /review | Staff engineer: reviews PRs | | QA | /qa | QA engineer: end-to-end testing | | Security | /cso | CSO: security audit | | Release | /release | Release manager: version management | | Docs | /docs | Documentation engineer: technical docs |

This is not a "toolbox" — it is a "virtual team." The difference: with a toolbox you actively reach in; with a team you give it a goal and it runs itself. gstack's design intent is the latter — you run /office-hours, describe what you're building, and roles intervene in sequence: the CEO first reviews whether it's worth doing, the designer drafts a proposal, the eng manager breaks down tasks, the engineer writes code, the reviewer checks PRs, QA tests, the release manager ships.

---

3. 810×: A Number That Needs Unpacking

Garry Tan's README gives a striking figure:

> "In the last 60 days: 3 production services, 40+ shipped features. 810× my 2013 pace."

810 times. This number needs unpacking.

First, the unit of measurement is "logical code changes," not raw LOC. This is a direct response to the criticism that "AI-generated code is just LOC padding." Logical code changes are meaningful, reviewable units of modification — a feature, a bugfix, a refactor. Not character counts.

Second, the denominator is Garry Tan in 2013, not an "average engineer." In 2013 he was already a YC partner, not a junior developer. His 2013 output was far above industry average. So 810× doesn't mean "AI is 810× faster than an average person" — it means "AI made an already-strong person 810× faster."

Third, 3 production services + 40 features in 60 days. This is the result, not the process. 3 production services imply the full path from design to deployment, including frontend, backend, database, and CI/CD. 40 features means about 0.67 features per day — a pace impossible for one person before AI.

The credibility of 810× depends on how strictly "logical code change" is defined. If every git commit counts, there's a lot of padding room. If it requires "passed review, merged to main, deployed to production," the number is far more meaningful. The mere existence of gstack's /review role hints at the latter — every change goes through review.

---

4. `/office-hours`: Front-Loading "Thinking It Through"

gstack's entry point is not /build — it's /office-hours.

This is counterintuitive. Most AI coding tools enter with "describe what you want, I'll give you code." gstack enters with "describe what you're working on, and the CEO first helps you judge whether it's worth doing."

/plan-ceo-review asks: What problem does this feature solve? Who are the users? What happens if you don't build it? How much time/money does it save or earn? Only after the CEO role approves does the design phase begin.

This front-loads "thinking it through" before "doing." In traditional teams this happens through meetings, documents, and reviews — costly and slow, so many small teams skip it and write code directly, ending up with features nobody uses. gstack automates this step, reducing the cost to "one conversation."

Garry Tan's experience as a YC CEO shows clearly here — one of YC's investment criteria is whether founders have "thought it through." gstack builds that judgment into the tool.

---

5. `/cso`: Security as a First-Class Citizen

gstack has a /cso role — Chief Security Officer. That's rare.

Most AI coding tools treat security as "optional lint rules" — run a SAST scan, flag vulnerabilities if any, pass otherwise. gstack elevates security to the role level: /cso proactively checks OWASP Top 10, dependency vulnerabilities, leaked secrets, and permission models during the code review stage.

The README notes that /cso requires a specific Bun version and native toolchain — meaning it doesn't just run lint but does real security analysis (possibly symbolic execution or taint analysis). That's much heavier than "adding a SAST tool in CI."

Why make security a role rather than a tool? Because security is a perspective, not a step. A tool is "run it and see if there are problems"; a role is "re-examine the entire design from a security angle." The former catches known vulnerabilities; the latter questions architectural choices. gstack chose the latter.

---

6. 30-Second Install: A Statement of Engineering Taste

gstack's ./setup completes in 31 seconds on a 4-vCPU Linux cloud machine, including binary builds and Chromium download.

This isn't a technical miracle — it's engineering taste. 31 seconds implies: minimized dependencies, optimized builds, parallel downloads. Many open-source projects' setups take 5-10 minutes and require manually installing a pile of system dependencies. gstack compresses the experience to the shortest possible "clone → setup → start using" path.

Garry Tan says in the README: "Stop there. You'll know if this is for you." — using a 30-second install threshold to let users judge for themselves, instead of writing a 5000-word "why you should use gstack." That's respect for the user's time, and confidence in product quality.

---

7. gstack's Real Barrier

gstack's barrier isn't installation — it's cognitive reframing.

Using gstack means accepting a premise: you are not writing code; you are managing a virtual team. You need to learn to "delegate" rather than "execute" — give /build a clear task description instead of writing it yourself; give /review enough context instead of expecting it to guess your intent; give /qa explicit acceptance criteria instead of letting it define "correct."

This is completely different from how traditional engineers work. The traditional muscle memory is "open editor → write code → run tests → commit." gstack demands "open terminal → run /office-hours → describe goal → wait for roles to engage → review output."

Garry Tan says gstack fits three types of people: 1. Founder/CEOs still writing code — who need to validate ideas fast 2. First-time Claude Code users — who need structured guidance rather than a blank prompt 3. Tech leads / staff engineers — who need to automate review, QA, and release workflows

For the first group, gstack is an "amplifier" — letting scarce engineering time cover more domains. For the second, a "scaffold" — avoiding getting lost in a blank prompt. For the third, an "automated pipeline" — handing repetitive review and release work to agents.

---

8. From "Personal Productivity" to "Organizational Design"

The most noteworthy thing about gstack is not the 810× number but its implicit claim: engineering organizations in the AI era may not need as many people.

A 23-role virtual team, if each role were a real person, would be a mid-sized engineering org (20-30 people). gstack lets one person run that team — though every "role" is the same LLM under different prompts, the checks and balances between roles are real: the CEO reviews whether it's worth doing, the eng manager breaks down tasks, the engineer writes code, the reviewer checks PRs, QA tests, the security officer audits.

This is not "AI replacing engineers" — it's "one person + AI covering more functions." What gets replaced is not people, but the friction cost of communication between functions. In traditional teams, CEO-to-engineer communication takes meetings, engineer-to-QA communication takes documents, QA-to-security communication takes emails. gstack compresses all of that into slash commands.

---

Project link: github.com/garrytan/gstack