Spec-Kit — 90k stars, bao nhiêu dùng được thật?

GitHub open-source Spec-Kit cho spec-driven development với AI agent. Mổ xẻ xem đâu là phần đáng thử, đâu chỉ là đóng gói lại thứ builder đã biết.

Chuyện gì đang diễn ra

Bạn đã bao giờ giao việc cho AI coding agent, nhận code chạy ngon, rồi hai ngày sau phát hiện nó lệch hoàn toàn so với yêu cầu ban đầu chưa? GitHub nghĩ vấn đề không nằm ở agent — mà ở cách mình giao việc cho nó. Từ đó họ open-source Spec-Kit, một toolkit áp dụng Spec-Driven Development (SDD — quy trình lấy specification làm trung tâm) cho AI coding workflow.

Ý tưởng: thay vì prompt kiểu tự do, bạn viết một PRD (Product Requirements Document — tài liệu yêu cầu sản phẩm) có cấu trúc rõ ràng, rồi dùng nó làm grounding document (tài liệu neo — nguồn sự thật duy nhất để agent tham chiếu). Agent đọc spec, sinh code, rồi tự validate output dựa trên acceptance criteria trong spec đó.

Repo hiện đạt hơn 90 nghìn stars trên GitHub. Con số ấn tượng — nhưng ấn tượng có nghĩa là dùng được thật không? Mình mổ xẻ.

Bên trong Spec-Kit có gì

Bóc ra thì Spec-Kit gồm bốn lớp:

Template PRD có cấu trúc — thay vì chat tự do với agent, bạn điền mục tiêu, user story, constraints, và acceptance criteria vào một template chuẩn. Agent đọc file này thay vì đoán ý từ cuộc hội thoại.

Grounding flow — spec không chỉ là tài liệu nằm im. Nó trở thành context chính mà agent tham chiếu xuyên suốt quá trình sinh code. Giống như bản OKR cả team cùng nhìn vào — không ai phải đoán "lead muốn gì".

Validation loop (vòng đối chiếu) — agent sinh code xong sẽ quay lại kiểm tra với spec. Không phải compile được là xong, mà phải khớp với yêu cầu đã viết ra.

Stack-agnostic — spec mô tả "cái gì" và "tại sao", không chỉ định framework hay ngôn ngữ. Agent tự chọn cách triển khai.

Nói thẳng ra: đây là structured prompting kết hợp context management, được đóng gói thành một workflow có tên chính thức và repo riêng.

Phần đáng giữ lại

Discipline quan trọng hơn tool

Giá trị lớn nhất của Spec-Kit không nằm trong code — mà ở thói quen nó buộc team phải có. Nếu bạn đã theo dõi blog, mình từng bàn ở bài về vibe coding trôi vào production rằng thiếu neo là nguyên nhân chính khiến agent output trật ray. Spec-Kit chính là một loại neo.

Ví dụ cụ thể: giả sử team bạn 4 người đang build API cho app nội bộ. Dev A prompt Copilot theo cách của A, dev B prompt kiểu khác. Kết quả: hai module cùng chức năng nhưng convention khác nhau, naming lệch, error handling mỗi nơi một kiểu. Một bản spec chung trước khi bắt tay code sẽ giảm tình trạng này — giống brief giao việc cho đồng nghiệp mới: càng rõ từ đầu, càng ít phải sửa sau.

Validation loop giảm lỗi "đúng mà sai"

Cái bẫy kinh điển khi dùng AI coding agent: code chạy, test pass, nhưng business logic lệch yêu cầu. Mình từng thấy một team để agent generate cả module authentication — code sạch, nhưng flow quên mất bước verify email vì prompt không nhắc tới. Agent không sai — nó làm đúng thứ được hỏi, chỉ là thứ được hỏi không đủ. Validation loop trong Spec-Kit ép agent quay lại đối chiếu acceptance criteria, giảm đúng loại lỗi "nhìn đúng nhưng thiếu".

Open-source, MIT, fork được

Bạn fork repo, chỉnh template theo convention team mình, tích hợp vào workflow hiện tại. Không mua thêm gì, không lock-in.

Phần nên lướt qua

Stars không phải adoption signal

90 nghìn stars nghe hoành tráng, nhưng stars trên GitHub là vanity metric (chỉ số ảo). Nhiều repo viral vì marketing tốt chứ không phải vì production adoption. Đừng để con số ấy thành lý do duy nhất bạn đưa Spec-Kit vào pipeline.

SDD không phải paradigm mới

Nếu team bạn đã viết RFC hoặc design doc trước khi code — bạn đang làm SDD rồi, chỉ không gọi tên vậy. Hiểu lầm mình thấy lan nhiều trên Twitter: người ta chia sẻ Spec-Kit như thể đây là cách tiếp cận hoàn toàn mới. Thật ra nó là đóng gói lại thực hành đã tồn tại, có thêm lớp template tối ưu cho agent.

"Stack-agnostic" có mặt trái

Không chỉ định tech stack trong spec nghĩa là agent tự quyết implementation. Với team có convention rõ thì ổn. Nhưng nếu codebase đang chạy Express mà agent chọn Fastify vì "tối ưu hơn" — bạn có thêm việc refactor thay vì bớt. Ai từng nhận pull request từ đồng nghiệp mới tự ý đổi framework sẽ hiểu cảm giác này.

Spec hay dở vẫn tùy người viết

Spec-Kit giải quyết format, không giải quyết nội dung. Spec mơ hồ thì agent vẫn hiểu sai — giống brief onboard cho nhân viên mới: template đẹp nhưng viết "làm tính năng cho nó xịn" thì kết quả vẫn lung tung như thường.

Đánh giá nhanh trong một buổi chiều

1. Clone repo Spec-Kit, mở đọc template PRD mẫu — chú ý phần acceptance criteria
2. Chọn một tính năng nhỏ team đang cần build (đừng thử với cả module lớn lần đầu)
3. Viết spec theo template — tập trung acceptance criteria thật cụ thể, đo được
4. Feed spec vào agent đang dùng — Copilot, Claude Code, hay Gemini CLI đều được
5. So sánh output với cách prompt thông thường: code có sát yêu cầu hơn không?

Câu hỏi đúng không phải "Spec-Kit có tốt không" — mà là "team mình có đủ discipline viết spec tốt không". Tool khuếch đại thói quen. Nếu thói quen chưa có, thêm tool cũng chỉ thêm một bước mà chẳng ai buồn làm.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng