Spec-driven development — IDE nặng hay layer nhẹ?

Khi 9 công cụ SDD cùng xuất hiện, câu hỏi thật sự không phải tool nào tốt nhất — mà team bạn cần enforcement hay suggestion.

Cuộc tranh luận không ai nói thẳng

Bao nhiêu lần bạn ship feature trong hai ngày nhờ AI coding agent, rồi sprint sau cả team ngồi refactor vì "code chạy đúng nhưng giải sai bài toán"? Nếu câu trả lời là "nhiều hơn một lần" — bạn không đơn độc.

Spec-driven development (SDD) — phát triển theo đặc tả — đang nổi lên như một cách giải. Thay vì viết code trước rồi chỉnh sau, SDD yêu cầu khóa spec trước, biến code thành output sinh ra từ spec đó. Năm 2026 đã có ít nhất 9 công cụ xoay quanh workflow này, nhưng cuộc tranh cãi thật sự nằm ở chỗ: nên dùng IDE toàn phần tích hợp sẵn SDD, hay gắn một layer spec nhẹ lên bộ công cụ hiện tại?

Đây không phải chuyện tool nào "tốt hơn". Đây là chuyện team bạn đang đứng ở đâu.

Biến số thứ nhất — kỷ luật spec hiện tại của team

Nếu team bạn đã có thói quen viết spec rõ ràng — dù chỉ là Google Doc mô tả user story, acceptance criteria (tiêu chí chấp nhận), edge case (trường hợp biên) — thì gắn thêm một spec layer nhẹ như GitHub Spec Kit lên workflow hiện tại là đủ. Spec Kit hoạt động như một bộ template và convention, không ép bạn đổi IDE hay thay toàn bộ pipeline. Bạn vẫn code trong VS Code hay Cursor, chỉ thêm lớp spec ở đầu.

Nhưng nếu team bạn thuộc nhóm "spec là cái Jira ticket ba dòng rồi code luôn" — dạng này khá phổ biến ở các team startup Việt Nam 3–5 người — thì một IDE toàn phần như Kiro đáng xem xét hơn. Kiro ép bạn đi qua ba phase: Requirements → Design → Tasks, mỗi phase sinh ra một artifact cụ thể (requirements.md, design.md, tasks.md). Nó dùng EARS notation — một cú pháp viết user story có cấu trúc — để sinh acceptance criteria tự động, bao gồm cả edge case mà developer thường bỏ qua khi viết tay.

Hiểu nôm na: nếu team đã có kỷ luật, bạn cần công cụ hỗ trợ. Nếu team chưa có kỷ luật, bạn cần công cụ ép kỷ luật.

Ví dụ cụ thể: Giả sử team 4 người đang xây internal tool cho bộ phận vận hành. Trước đây, PM viết brief trên Notion, dev đọc xong nhảy vào code ngay với Cursor. Kết quả: feature "tìm kiếm đơn hàng" chạy tốt trên UI nhưng thiếu filter theo ngày, thiếu xử lý khi không có kết quả — những scenario mà brief không đề cập. Nếu dùng Kiro, phase Requirements sẽ buộc liệt kê từng scenario, kể cả "khi user search mà không có kết quả thì hiển thị gì". Nếu dùng Spec Kit, dev tự thêm file spec vào repo theo template — nhưng phải tự giữ kỷ luật viết đủ.

Biến số thứ hai — spec hướng dẫn người hay điều khiển máy?

Đây là điểm mà nhiều team đang nhầm. Không phải SDD tool nào cũng hoạt động giống nhau.

Nhóm một: spec dùng để hướng dẫn con người. GitHub Spec Kit thuộc nhóm này — spec là tài liệu sống, con người đọc và code theo. AI có thể suggest, nhưng quyết định cuối vẫn là dev.

Nhóm hai: spec dùng để điều khiển agent. Kiro thuộc nhóm này — spec sinh xong, agent hooks (tự động hóa chạy theo sự kiện file) sẽ tự cập nhật test, tự refresh README, tự chạy security scan mỗi khi file thay đổi. Con người viết spec, máy sinh code và giữ code đồng bộ với spec.

Sự khác biệt này quan trọng hơn bạn nghĩ. Nếu team muốn agent tự sinh code từ spec, bạn cần tool nhóm hai — và phải chấp nhận rằng agent hooks sẽ can thiệp vào workflow hiện tại. Nếu team chỉ cần spec để giảm miscommunication giữa PM và dev, nhóm một đủ dùng và ít xáo trộn hơn.

Ví dụ thực tế: Một team backend 6 người đang maintain hệ thống microservices cho fintech. Compliance yêu cầu con người kiểm tra từng dòng code — agent tự sinh code ở đây là rủi ro chứ không phải lợi thế. Với họ, SDD layer nhẹ giúp spec rõ hơn là đủ. Ngược lại, team 2 người đang prototype nhanh cho startup thì agent-driven SDD giúp ship nhanh hơn rõ rệt, vì spec thay thế luôn việc review thủ công ở giai đoạn đầu.

Khi nào chọn A, khi nào chọn B?

Thay vì liệt kê feature, mình đúc thành hai câu hỏi bạn tự trả lời:

Câu 1: Team bạn sẵn sàng đổi IDE không? Kiro xây trên Code OSS (nền tảng mã nguồn mở đằng sau VS Code), nên giao diện quen. Nhưng "quen giao diện" khác xa "quen workflow". Agent hooks, auto-routing giữa nhiều model (Claude Sonnet, Qwen, DeepSeek...), phase bắt buộc trước khi code — tất cả thay đổi cách bạn bắt đầu một task. Việc chuyển IDE giống một đợt áp thấp — không nguy hiểm, nhưng sẽ có vài ngày trời xám trước khi mọi thứ ổn định lại.

Câu 2: Bạn cần enforcement hay suggestion? Nếu vấn đề là "team không viết spec", bạn cần enforcement — tool phải chặn luồng khi thiếu spec. Kiro làm việc này. Nếu vấn đề là "team viết spec nhưng spec không đủ chi tiết", bạn cần suggestion — tool gợi ý bổ sung edge case mà không chặn luồng. Spec Kit và các framework nhẹ phù hợp hơn.

| Tiêu chí | IDE toàn phần (Kiro) | Layer nhẹ (Spec Kit, BMAD…) |
|---|---|---|
| Kỷ luật spec hiện tại thấp | ✅ Ép quy trình | ⚠️ Phụ thuộc ý thức team |
| Team đã có IDE stack riêng | ⚠️ Phải migrate | ✅ Gắn thêm, không thay |
| Cần agent tự sinh code | ✅ Agent hooks tích hợp | ❌ Không có sẵn |
| Compliance yêu cầu human review | ⚠️ Agent có thể chạy trước khi người kịp xem | ✅ Con người vẫn kiểm soát |
| Team dưới 3 người, cần tốc độ | ✅ Agent bù thiếu headcount | ✅ Nhẹ, nhanh setup |

Kết — đừng chọn tool, hãy chọn mức kỷ luật

Mình thấy nhiều team Việt Nam đang hào hứng với SDD vì lý do sai: "tool này sẽ tự viết spec cho mình". Không tool nào viết spec thay bạn — tool chỉ ép bạn viết, hoặc gợi ý bạn viết tốt hơn.

Trước khi chọn giữa IDE nặng hay layer nhẹ, trả lời một câu: team bạn có thật sự sẵn sàng dừng lại 30 phút đầu sprint để viết spec, thay vì nhảy vào code ngay? Nếu "có" — layer nhẹ đủ rồi, khỏi đổi IDE. Nếu "chắc là không ai chịu" — thì mới cần tool ép kỷ luật từ bên ngoài.

Sương tan thì đường mới rõ. Spec rõ thì code mới đúng bài toán.

---

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