gstack: How Garry Tan Ships 20,000 Lines of Code Daily (And You Can Too)

The Engineering Velocity Paradox

As someone who's spent nearly two decades building AI products, I've witnessed the perpetual tension between shipping fast and shipping right. We've all been there—pressure to deliver features quickly while maintaining code quality, security standards, and user experience. The traditional solution has been to throw more engineers at the problem, but what if there's a fundamentally different approach?

Enter gstack, Garry Tan's fascinating experiment in AI-powered engineering multiplication. The Y Combinator CEO claims to ship 10,000-20,000 lines of production code daily—part-time. That's not a typo. And now he's open-sourced the entire system.

What Is gstack Really?

gstack isn't just another AI coding tool. It's an orchestration layer that transforms your existing AI coding assistant (Claude, Codex, Gemini) into a complete virtual engineering organization. Think of it as Conway's Law in reverse—instead of your organization's structure dictating your software architecture, you're architecting an organization within your development environment.

The system provides 23 distinct specialist roles as slash commands, each with carefully crafted personas and responsibilities:

• `/office-hours` - Product thinking and strategy
• `/review` - Staff-level code review
• `/qa` - Real browser testing
• `/ship` - PR creation and deployment
• `/cso` - Security audit and compliance
• `/design-review` - UX/UI evaluation
• `/investigate` - Debugging and root cause analysis
• `/retro` - Weekly retrospectives

What strikes me most is the intentional workflow design. The sprint flow follows a natural progression: Think → Plan → Build → Review → Test → Ship → Reflect. Each skill feeds contextually into the next, creating a feedback loop that mirrors high-performing engineering teams.

The Philosophy Behind the Code

From a consciousness and systems thinking perspective, gstack represents something profound. It's an attempt to externalize and systematize the internal dialogue that experienced engineers have when building software. When I review code, I'm simultaneously thinking like a security officer, a performance engineer, and an end-user advocate. gstack makes these implicit roles explicit.

This reminds me of Daniel Kahneman's "Thinking, Fast and Slow"—we're essentially creating a "System 2" for software development, forcing deliberate, structured thinking at each stage rather than relying on intuitive, fast judgments.

Installation and Setup

The installation is refreshingly simple:

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

Requirements: - Claude Code (primary integration) - Git - Bun v1.0+

The system also works with Codex, Gemini CLI, and Cursor, though Claude Code appears to be the primary target.

Real-World Application at Scale

As someone who's led product and engineering teams at PayPal, I'm particularly intrigued by the `/office-hours` command. Product thinking is often the bottleneck in engineering organizations—not the coding itself, but the strategic decisions about what to build and why.

The `/cso` (Chief Security Officer) role is especially relevant in fintech. Having automated security reviews as part of your development flow, rather than as a separate gate, could dramatically improve both security posture and development velocity.

The Broader Implications

What Garry has built touches on a fundamental question I often explore: How do we augment human intelligence rather than replace it? gstack doesn't eliminate the need for human judgment—it structures and amplifies it.

This is particularly relevant as we see AI coding assistants becoming ubiquitous. The question isn't whether AI will help us code faster (it already does), but whether it can help us think more systematically about the entire software development lifecycle.

Getting Started: A Practical Approach

If you're considering trying gstack, I'd recommend starting with a small, non-critical project. Focus on understanding how the different roles interact:

1. Begin with `/office-hours` to clarify product requirements
2. Use `/review` to understand the code quality standards
3. Experiment with `/qa` for testing strategies
4. Try `/retro` to reflect on what you're learning

The goal isn't to use every command immediately, but to internalize the structured thinking each role represents.

The Future of Engineering Organizations

gstack raises profound questions about the future of software teams. If individual developers can achieve the output of entire teams, how do we think about collaboration, mentorship, and career growth? How do we maintain the creative serendipity that emerges from human interaction?

These aren't questions with easy answers, but they're questions worth exploring. As AI capabilities continue to expand exponentially, tools like gstack give us a glimpse into a future where the constraint on software development isn't engineering capacity, but product vision and strategic thinking.

Try It Yourself

I encourage you to experiment with gstack, not just as a productivity tool, but as a thinking framework. Pay attention to how it changes your development process, what roles you find most valuable, and where human judgment remains irreplaceable.

The code is MIT licensed and available on GitHub. In the spirit of open source and continuous learning, I'd love to hear about your experiences in the comments.

After all, the most interesting tools don't just help us work faster—they help us think differently about the work itself.