Garry Tan là President & CEO của Y Combinator, một trong những tổ chức startup có ảnh hưởng nhất thế giới. Trong 60 ngày gần đây, ông viết được hơn 600,000 dòng code production (35% trong số đó là test, phần còn lại được merge vào các dự án thật), tức 10,000 đến 20,000 dòng mỗi ngày, trong khi vẫn làm đầy đủ vai trò CEO. Con số trong tuần gần nhất: 140,751 dòng thêm mới, 362 commits.
"That is not a typo. We are at the dawn of something real — one person shipping at a scale that used to require a team of twenty."
gstack là bộ công cụ ông dùng để đạt được điều đó, và ông đã mã nguồn mở toàn bộ.
§1Ý tưởng cốt lõi: một đội ngũ, không phải một trợ lý
Cách dùng Claude Code thông thường coi AI như một trợ lý thụ động chờ lệnh. Khác biệt lớn nhất của gstack là nó mô hình hóa AI thành một đội ngũ chuyên biệt, mỗi vai trò rõ ràng:
- CEO (
/plan-ceo-review): thách thức scope và giả định trước khi build - Eng Manager (
/plan-eng-review): khóa kiến trúc, data flow, test matrix - Designer (
/design-review,/design-consultation): phát hiện "AI slop" về mặt visual - Staff Engineer (
/review): code review cấp senior với auto-fix - QA Lead (
/qa): mở trình duyệt thật, click qua từng flow, tìm bug - Release Engineer (
/ship,/land-and-deploy): tạo PR, verify test coverage, deploy
Khi bạn có 10–15 phiên agent chạy song song, cấu trúc vai trò này là thứ ngăn mọi thứ khỏi trở thành hỗn loạn.
§2Triết lý đằng sau
Phần tôi thấy đáng đọc nhất trong repo là file ETHOS.md, bộ nguyên tắc được tự động inject vào mọi skill. Có hai nguyên tắc nổi bật.
Boil the Lake
Nguyên tắc đầu tiên: với AI, chi phí cận biên của sự hoàn chỉnh gần bằng không. Vì vậy, hãy luôn chọn giải pháp đầy đủ thay vì giải pháp "đủ dùng".
Nguyên tắc này dùng hình ảnh "lake vs ocean". Một cái hồ thì đun sôi được, như viết test 100%, implement đầy đủ edge case, xử lý hết error path. Một đại dương thì không, ví dụ viết lại toàn bộ hệ thống từ đầu. Nên cứ đun sôi hồ, đừng cố đun đại dương.
Có một bảng so sánh khá thú vị:
| Loại task | Đội người | AI-assisted | Tỉ lệ nén |
|---|---|---|---|
| Boilerplate / scaffolding | 2 ngày | 15 phút | ~100x |
| Viết test | 1 ngày | 15 phút | ~50x |
| Implement feature | 1 tuần | 30 phút | ~30x |
| Fix bug + regression test | 4 giờ | 15 phút | ~20x |
| Kiến trúc / thiết kế | 2 ngày | 4 giờ | ~5x |
| Research / khám phá | 1 ngày | 3 giờ | ~3x |
Nhìn bảng này thì quyết định "bỏ qua test vì tốn thời gian" không còn đứng được nữa. 10% cuối cùng mà các đội thường bỏ qua giờ chỉ tốn thêm vài phút.
Search Before Building
Nguyên tắc thứ hai: trước khi build bất cứ thứ gì, hãy tìm kiếm xem nó đã tồn tại chưa. Triết lý này chia nguồn kiến thức thành ba tầng:
- Tầng 1 (Tried and true): pattern chuẩn, cách tiếp cận đã được kiểm chứng. Rủi ro ở tầng này là bạn mặc định câu trả lời hiển nhiên luôn đúng.
- Tầng 2 (New and popular): best practice hiện tại, blog posts, xu hướng. Tìm kiếm, nhưng đọc có phê phán, vì đám đông có thể sai về những thứ mới cũng dễ như với thứ cũ.
- Tầng 3 (First principles): quan sát gốc rễ từ lý luận về bài toán cụ thể. Đây là loại kiến thức có giá trị nhất.
Mục tiêu của việc tìm kiếm là hiểu tại sao mọi người làm theo cách thông thường, rồi lý luận xem cách thông thường đó có thực sự đúng không, chứ không phải tìm code để copy.
§3Toàn bộ 25 skills
| Skill | Vai trò | |
|---|---|---|
/office-hours |
Reframe vấn đề trước khi code | ↗ |
/plan-ceo-review |
Thách thức scope và giả định | ↗ |
/plan-eng-review |
Khóa kiến trúc và data flow | ↗ |
/plan-design-review |
Review design trước khi implement | ↗ |
/design-consultation |
Xử lý câu hỏi visual một cách có hệ thống | ↗ |
/review |
Code review cấp staff engineer | ↗ |
/design-review |
Phát hiện và fix AI slop về visual | ↗ |
/investigate |
Debug có hệ thống | ↗ |
/qa |
Browser testing thật + bug fix | ↗ |
/qa-only |
Báo cáo bug, không sửa code | ↗ |
/benchmark |
Đo hiệu năng | ↗ |
/canary |
Kiểm tra sau khi deploy | ↗ |
/ship |
Tạo PR với verify test coverage | ↗ |
/land-and-deploy |
Merge PR qua production + health check | ↗ |
/document-release |
Cập nhật tài liệu sau release | ↗ |
/browse |
Headless Chromium với ~100ms latency | ↗ |
/codex |
Cross-model review qua OpenAI | ↗ |
/retro |
Thống kê hoạt động dev | ↗ |
/careful |
Guardrail cho thao tác nguy hiểm | ↗ |
/freeze |
Khóa file khỏi bị chỉnh sửa | ↗ |
/guard |
Bảo vệ branch khỏi force push | ↗ |
/unfreeze |
Gỡ lock từ /freeze |
↗ |
/setup-browser-cookies |
Thiết lập cookie cho browser testing | ↗ |
/setup-deploy |
Cấu hình deploy pipeline | ↗ |
/gstack-upgrade |
Cập nhật gstack lên phiên bản mới | ↗ |
§4Bắt đầu từ đâu?
25 skills là nhiều, nhưng thực tế bạn chỉ cần 5 cái đầu tiên để thấy được giá trị ngay:
/office-hours: dùng trước khi bắt đầu bất kỳ feature nào. Nó sẽ reframe lại vấn đề theo cách bạn chưa nghĩ tới./plan-ceo-review+/plan-eng-review: chạy lần lượt để có một bản kế hoạch được thách thức cả về product lẫn kỹ thuật./review: chạy sau khi AI viết code xong, bước này không nên bỏ qua./ship: tạo PR kèm verify test coverage, thay thế hoàn toàn việc tự tạo PR thủ công.
Phần còn lại (/qa, /investigate, /benchmark...) thêm vào khi bạn đã quen với flow cơ bản.
§5Suy nghĩ của tôi
gstack và Superpowers đang giải quyết cùng một bài toán theo hai góc nhìn khác nhau. Superpowers tập trung vào kỷ luật quy trình, buộc agent đi từng bước có thứ tự. gstack tập trung vào cấu trúc vai trò, mỗi skill là một chuyên gia với góc nhìn riêng. Bạn hoàn toàn có thể dùng cả hai trên cùng một project: Superpowers để giữ agent đi đúng quy trình, gstack để gọi đúng chuyên gia vào đúng thời điểm.
Cái tôi thích nhất ở gstack là triết lý này thay đổi cách ra quyết định trước khi bạn mở terminal. Khi bảng tỉ lệ nén cho thấy viết test chỉ tốn 15 phút thay vì một ngày, lý do để bỏ qua nó biến mất hoàn toàn.
Garry Tan gọi đây là "live experiment" và muốn chia sẻ với cả thế giới. Tôi nghĩ việc chia sẻ đó quan trọng hơn con số 600,000 dòng code. Ông công khai mọi thứ để chứng minh rằng một kỷ nguyên mới đang thực sự bắt đầu.