Mở đầu: Tại sao Spec-Driven Development lại được chú ý vào lúc này?

Sự xuất hiện của các coding agent như Claude Code, GitHub Copilot..., đang thay đổi rất nhanh cách các team phát triển phần mềm làm việc. Trước đây, developer phải tự viết gần như toàn bộ code bằng tay. Còn hiện tại, chỉ cần mô tả yêu cầu bằng ngôn ngữ tự nhiên, AI đã có thể hỗ trợ viết code, tạo test và xử lý nhiều phần việc kỹ thuật. Điều từng được xem là “viễn tưởng” vài năm trước giờ đã trở thành công việc hằng ngày của rất nhiều team engineering.

Tuy nhiên, khi áp dụng AI coding trong thực tế, nhiều engineer lại gặp những vấn đề rất giống nhau:

• "Cái kế hoạch tôi vừa lập 3 tiếng trước là gì ấy nhỉ?" – thời gian dành cho việc scroll lại lịch sử chat ngày càng nhiều
• Giao việc cho AI xong thì phát hiện AI implement luôn cả những tính năng ngoài dự kiến (over-engineering)
• Khi cuộc hội thoại dài ra, các specification quan trọng bị chôn vùi trong context
• Khi đổi session, lại phải giải thích context cho AI từ đầu

Nói cách khác, AI giúp viết code nhanh hơn, nhưng lại khiến việc quản lý context và yêu cầu trở nên khó hơn.

Chính trong bối cảnh đó, Spec-Driven Development (SDD – Phát triển dựa trên đặc tả) bắt đầu được chú ý như một cách tiếp cận mới để vượt qua giới hạn của “Vibe Coding” – tức kiểu làm việc chủ yếu dựa trên việc chat liên tục với AI theo cảm hứng.

Bài viết này sẽ trình bày một cách hệ thống từ khái niệm cơ bản của SDD, phương pháp thực hành, so sánh các công cụ chính, cho đến cách ứng dụng "CafeKit" – công cụ OSS do Haposoft phát triển hướng đến các doanh nghiệp Nhật Bản.

 

1. Spec-Driven Development (SDD) là gì?

1.1 Định nghĩa

Spec-Driven Development (SDD) là phương pháp phát triển phần mềm trong đó tài liệu đặc tả (Specification) được xem là “nguồn thông tin đáng tin cậy duy nhất” của dự án. Toàn bộ quá trình implement, test hay review sẽ được thực hiện dựa trên đặc tả này, thay vì phụ thuộc vào lịch sử chat hoặc trí nhớ của từng thành viên trong team.

Trong cách làm truyền thống, developer thường viết code trước rồi mới document lại sau. Còn với SDD, quy trình được đảo ngược thành “spec-first” – tức là làm rõ yêu cầu trước, thống nhất chính xác hệ thống cần xây dựng như thế nào, rồi sau đó mới bắt đầu implement.

Điểm quan trọng nhất của SDD không nằm ở việc AI viết code thay con người, mà nằm ở việc con người và AI cùng làm việc dựa trên một specification chung.

1.2 Vị trí của SDD trong dòng chảy phát triển phần mềm

Thực tế, SDD không phải là một phát minh hoàn toàn mới. Đây là sự quay trở lại của những nguyên tắc nền tảng mà ngành software engineering đã sử dụng suốt nhiều thập kỷ: xác định yêu cầu, thiết kế, implement và test. Khác biệt nằm ở chỗ: trong kỷ nguyên AI, specification không chỉ để con người đọc nữa, mà còn là “ngôn ngữ giao tiếp” giữa con người và AI.

Trong Technology Radar Vol.32 (tháng 4/2025) của Thoughtworks, SDD đã được đưa vào trạng thái "Trial (Thử nghiệm)" và bắt đầu được chú ý nghiêm túc trên toàn ngành. Tại AWS re:Invent 2025, Amazon đã công bố "Kiro IDE" – môi trường phát triển tích hợp AI agent, hiện thực hóa tư tưởng SDD qua flow Requirements → Design → Tasks → Code Generation. Đây cũng chính là tư tưởng cốt lõi của SDD.

1.3 So sánh với Vibe Coding

 

2. Những hiệu quả cụ thể mà SDD mang lại – Báo cáo từ thực tế triển khai tại Haposoft

Spec-Driven Development vẫn còn là một emerging practice của giai đoạn 2025–2026, và hiện tại ngành phần mềm vẫn chưa có một bộ metric chung được thống nhất hoàn toàn. Tuy nhiên, tại Haposoft – nơi đã áp dụng workflow spec-first vào quá trình delivery cho các dự án offshore với khách hàng Nhật Bản – team đã ghi nhận được nhiều thay đổi đáng kể sau khi triển khai workflow SDD.

2.1 Giảm 30% effort trong giai đoạn estimate

Bối cảnh đo lường: So sánh effort khi PM/Tech Lead estimate cho các dự án mới trước và sau khi áp dụng spec-first workflow, trên các dự án Web/SaaS quy mô 3-12 tháng.

Lý do giảm được:

• Đặc tả được cấu trúc hóa rõ ràng ngay từ giai đoạn pre-sale, giúp việc breakdown WBS chính xác hơn và giảm phần "buffer cho điều không biết"
• Giảm số vòng làm rõ yêu cầu (clarification rounds) với khách hàng nhờ template đặc tả chuẩn
• Tái sử dụng được các spec module từ dự án trước (authentication, payment, notification...) thay vì estimate lại từ đầu

Ý nghĩa kinh doanh: Với một dự án trung bình estimate trong 2 tuần, việc giảm 30% effort tương đương tiết kiệm được khoảng 3 ngày công – đồng nghĩa với việc Sales team có thể response nhanh hơn 3 ngày tới khách hàng, một lợi thế cạnh tranh đáng kể trong thị trường Nhật Bản nơi tốc độ phản hồi rất được coi trọng.

2.2 Tăng 50% tốc độ SDLC delivery

Bối cảnh đo lường: So sánh thời gian từ "kickoff đến release production lần đầu" giữa các dự án sử dụng workflow cũ (code-first, document hóa sau) và các dự án mới áp dụng SDD với coding agent.

Lý do tăng được:

• Giảm rework do hiểu sai requirement: Vì đặc tả được người và AI thống nhất trước khi viết code, các trường hợp "implement xong rồi phát hiện hiểu sai" giảm đáng kể. Đây là nguồn lãng phí lớn nhất trong các dự án offshore Việt-Nhật do rào cản ngôn ngữ
• AI implement nhanh hơn khi có spec rõ: Coding agent có spec làm "kim chỉ nam" sẽ sinh code chính xác hơn ngay lần đầu, giảm số vòng prompt back-and-forth
• Test case được sinh ra từ acceptance criteria của spec, không cần viết test từ đầu sau khi code xong
• Tài liệu bàn giao được sinh tự động từ spec – đặc biệt quan trọng với khách hàng Nhật vốn yêu cầu tài liệu chỉn chu

Lưu ý về phạm vi áp dụng: Hiệu quả 50% được ghi nhận trên các dự án phát triển mới (greenfield) quy mô vừa và lớn. Với các dự án maintenance hoặc hotfix nhỏ, overhead của việc viết spec có thể vượt quá thời gian tiết kiệm được – đây là một lý do CafeKit có cơ chế cho phép skip phase đối với các thay đổi nhỏ.

2.3 Các hiệu quả định tính khác

Ngoài các con số cụ thể, team Haposoft còn ghi nhận nhiều lợi ích khó đo lường nhưng rất đáng giá trong vận hành:

Phân chia trách nhiệm rõ ràng giữa Người và AI: Đặc tả (What) do con người phê duyệt, còn implementation (How) thì giao cho AI. Cách phân chia vai trò này vừa kiểm soát được rủi ro AI "chạy lung tung", vừa tối đa hóa năng suất.

Tính liên tục vượt qua ranh giới session: Dù session Claude Code có bị ngắt, dù có đổi engineer phụ trách giữa chừng (vốn thường xuyên xảy ra ở các công ty offshore), chỉ cần còn file đặc tả là người mới có thể tiếp quản dự án trong thời gian ngắn.

Tài liệu tự động được tích lũy: Vì "đã làm gì, đến đâu, tại sao" đều được lưu lại dưới dạng file Markdown trong Git, gánh nặng khi bàn giao cho thành viên mới hoặc khi chính bản thân đọc lại sau vài tháng được giảm đáng kể. Điều này đặc biệt quan trọng với cấu trúc dự án mà PM Nhật và DEV Việt làm việc cùng nhau qua nhiều múi giờ.

 

---

3. Workflow điển hình của SDD

Cụ thể thì SDD đi qua những phase nào? Hãy cùng phân chia flow tiêu biểu thành 6 phase.

Phase 1: Định nghĩa yêu cầu (Requirements)

Đây là giai đoạn xác định business goal, vấn đề người dùng cần giải quyết, functional requirement và non-functional requirement. AI có thể hỗ trợ team chuyển các ý tưởng ban đầu thành user story hoặc acceptance criteria có cấu trúc rõ ràng hơn.

Phase 2: Thiết kế (Design)

Sau khi requirement được thống nhất, team bắt đầu thiết kế kiến trúc hệ thống, data model, API, luồng màn hình và các quyết định kỹ thuật liên quan.

Những quyết định này thường được lưu lại dưới dạng Design Doc hoặc ADR để sau này có thể truy vết được lý do tại sao team chọn hướng thiết kế đó.

Phase 3: Phân rã task (Task Breakdown)

Thiết kế sẽ tiếp tục được chia thành các task nhỏ có thể implement được.

Nhiều team áp dụng nguyên tắc “1 task = 1 commit” để giúp việc quản lý tiến độ và review trở nên dễ dàng hơn.

Phase 4: Implementation

Ở phase này, AI hoặc developer bắt đầu implement từng task.

Điểm quan trọng là AI luôn tham chiếu đến specification thay vì chỉ dựa vào lịch sử chat. Nhờ vậy, code được sinh ra có tính nhất quán cao hơn và ít bị “mất bức tranh tổng thể”.

Phase 5: Test

Acceptance criteria trong specification có thể được dùng để sinh test case và kiểm tra coverage.

Điều này giúp quá trình test bám sát business requirement hơn thay vì chỉ kiểm tra logic kỹ thuật đơn thuần.

Phase 6: Review

Cuối cùng, engineer sẽ review code dựa trên specification đã được thống nhất trước đó.

Việc có một “tiêu chuẩn đối chiếu” rõ ràng giúp review chất lượng code, security và maintainability trở nên minh bạch hơn.

4. Các lựa chọn công cụ SDD chính

Khi AI coding phát triển mạnh, ngày càng có nhiều công cụ hỗ trợ workflow Spec-Driven Development xuất hiện.

4.1 GitHub Spec Kit

Bộ công cụ SDD do GitHub cung cấp chính thức. Dựa trên tư tưởng "nếu có đặc tả rõ ràng thì AI có thể sinh code đúng", hỗ trợ tạo Design Doc, ADR và PRD.

4.2 Kiro IDE

IDE tích hợp AI dạng agent do AWS cung cấp. Hỗ trợ tích hợp từ việc làm rõ yêu cầu từ ngôn ngữ tự nhiên thành đặc tả, đến phân rã yêu cầu → thiết kế → implement → test → sinh code.

4.3 claude-code-spec-workflow

Công cụ CLI ra đời từ cộng đồng OSS. Implement flow SDD cho Claude Code, có thể khởi động workflow phát triển tính năng mới chỉ bằng một command.

4.4 cc-sdd / OpenSpec

Nhóm các công cụ nhẹ cung cấp flow spec → task → implement theo nhiều triết lý khác nhau. Có thể lựa chọn tùy theo quy mô và sở thích của dự án.

4.5 CafeKit (Sản phẩm của Haposoft, dành cho doanh nghiệp Nhật Bản)

Và đây, công cụ chúng tôi muốn giới thiệu chính là CafeKit – OSS do Haposoft chúng tôi phát triển.

5. CafeKit: Bộ công cụ SDD tối ưu cho phát triển doanh nghiệp

5.1 CafeKit là gì?

CafeKit (cafekit.haposoft.com) là bộ công cụ CLI mã nguồn mở, được thiết kế dành riêng cho Claude Code, implement workflow Spec-Driven Development 6 phase.

5.2 Workflow 6 phase của CafeKit

CafeKit sử dụng cùng thuật ngữ quen thuộc như trong môi trường phát triển phần mềm Nhật Bản, cung cấp các giai đoạn sau:

Định nghĩa yêu cầu → Thiết kế → Phân tích nhiệm vụ → Triển khai → Kiểm thử → Đánh giá

Mỗi giai đoạn tạo ra các tệp Markdown có cấu trúc được lưu trữ trực tiếp trong kho lưu trữ, có thể quản lý bằng Git. Vì các đặc tả được kiểm soát phiên bản cùng với mã nguồn, các nhóm có thể theo dõi các thay đổi một cách nhất quán hơn và duy trì lịch sử dự án rõ ràng hơn theo thời gian. Quy trình làm việc này cũng giúp việc cộng tác dễ dàng hơn giữa các kỹ sư, người đánh giá và các tác nhân mã hóa AI vì mọi người đều làm việc trong cùng một ngữ cảnh được ghi lại.

5.3 Vì sao nên áp dụng CafeKit?

Khi bắt đầu áp dụng quy trình làm việc SDD trong các dự án sản xuất, chúng tôi nhận thấy nhiều công cụ hiện có tập trung chủ yếu vào việc nhắc nhở nhưng lại hỗ trợ hạn chế trong việc duy trì cấu trúc dự án dài hạn.

CafeKit được thiết kế để giải quyết một số vấn đề thực tế mà chúng tôi gặp phải trong quá trình phát triển thực tế:

• Giữ cho đặc tả và triển khai được đồng bộ hóa trong suốt vòng đời dự án.
• Giúp dễ dàng duy trì bối cảnh dự án giữa các phiên làm việc với AI.
• Cải thiện sự hợp tác giữa nhiều kỹ sư làm việc với các tác nhân lập trình AI.
• Duy trì tài liệu có thể tái sử dụng thay vì hoàn toàn dựa vào lịch sử trò chuyện.

Mục tiêu không chỉ đơn giản là tạo ra mã nhanh hơn. Đó là tạo ra một quy trình làm việc mà cả con người và AI đều có thể làm việc dựa trên các đặc tả ổn định và có thể tái sử dụng.

5.4 Việc triển khai CafeKit chỉ mất vài phút

# Cài đặt (hình ảnh minh họa)

npm install -g @haposoft/cafekit

 

# Khởi tạo trong dự án

cafekit init

 

# Bắt đầu phase định nghĩa yêu cầu

cafekit spec new "Chức năng xác thực user"

 

Để biết chi tiết cách sử dụng và tài liệu, mời tham khảo trang web chính thức cafekit.haposoft.com.

6. Các bước thực hành triển khai SDD

"Tôi muốn áp dụng SDD vào công ty mình" – với những độc giả nghĩ như vậy, dưới đây là các bước triển khai thực tế.

Step 1: Bắt đầu từ dự án nhỏ

Tuyệt đối không nên áp dụng ngay vào dự án quy mô lớn. Hãy thử nghiệm từ phát triển các chức năng nhỏ mới hoặc công cụ nội bộ trước.

Step 2: Chuẩn bị template tài liệu đặc tả

Chuẩn bị template định nghĩa yêu cầu, template thiết kế tùy theo loại dự án. Cách nhanh nhất là customize dựa trên template của CafeKit.

Step 3: Tuân thủ triệt để nguyên tắc "1 Todo = 1 Commit = 1 Spec Update"

Bằng cách giữ task, commit, và cập nhật đặc tả tương ứng 1-1, có thể ngăn ngừa việc AI và con người hiểu lệch nhau.

Step 4: Chuyển văn hóa review sang giai đoạn đặc tả

Thay đổi quy trình vốn chủ yếu là "code review" thành 2 giai đoạn "review đặc tả → code review". Phát hiện sớm sẽ giúp giảm chi phí đáng kể.

Step 5: Cả team thống nhất công cụ

Nếu mỗi cá nhân dùng công cụ khác nhau thì format đặc tả sẽ trở nên lộn xộn. Hãy thống nhất công cụ (ví dụ: CafeKit) trong toàn team.

 

7. Những cạm bẫy khi triển khai SDD và cách đối phó

SDD không phải là chiếc đũa thần. Dưới đây là 3 cạm bẫy thường gặp khi triển khai.

Cạm bẫy 1: Viết đặc tả quá nhiều

Một trong những sai lầm phổ biến là biến SDD thành quy trình tài liệu quá nặng. Nếu team dành quá nhiều thời gian để hoàn thiện document, lợi ích về tốc độ từ AI sẽ bị giảm đáng kể.

Trong nhiều trường hợp, chỉ cần bắt đầu bằng những bullet point rõ ràng là đã đủ để AI hỗ trợ mở rộng specification.

Cạm bẫy 2: Đặc tả và code bị lệch nhau

Nếu requirement thay đổi nhưng specification không được update kịp thời, tài liệu sẽ nhanh chóng mất giá trị.

Đó là lý do workflow SDD luôn yêu cầu việc đồng bộ giữa spec và code.

Cạm bẫy 3: Quá tin tưởng vào AI

Dù workflow có tốt đến đâu, AI vẫn chưa thể thay thế hoàn toàn engineer.

Con người vẫn cần chịu trách nhiệm cuối cùng về chất lượng sản phẩm, security, edge case và các quyết định kỹ thuật quan trọng.

8. Tác động của SDD đến career

Trong kỷ nguyên AI, giá trị của việc “biết viết code” có thể sẽ dần giảm xuống.

Ngược lại, những kỹ năng trở nên quan trọng hơn sẽ là:

• Khả năng xác định đúng requirement
• Khả năng cấu trúc hóa vấn đề
• Khả năng truyền đạt rõ ràng cho AI

Nói cách khác, giá trị đang dần chuyển từ “người viết code” sang “người thiết kế giải pháp”.

Và SDD chính là một trong những kỹ năng giúp engineer chuẩn bị cho sự thay đổi đó.

Tổng kết

Bài viết đã trình bày các điểm sau về Spec-Driven Development (SDD):

• SDD/ Định nghĩa SDD: Phương pháp coi đặc tả là "nguồn thông tin đáng tin cậy duy nhất" và giao việc sinh code cho AI
• Hiệu quả thực tế tại Haposoft: Giảm 30% effort estimate, tăng 50% tốc độ SDLC delivery khi áp dụng spec-first workflow trên dự án greenfield quy mô vừa và lớn
• Workflow: 6 phase "Định nghĩa yêu cầu → Thiết kế → Phân rã task → Implement → Test → Review"
• Các công cụ chính: Spec Kit, Kiro IDE, claude-code-spec-workflow, và CafeKit cho doanh nghiệp Nhật Bản
• Các bước triển khai: Bắt đầu nhỏ, chuẩn bị template, thống nhất công cụ trong team

Từ thời đại AI "viết code" sang thời đại con người và AI "đối thoại bằng đặc tả". Spec-Driven Development chính là tư tưởng nằm ở trung tâm của sự thay đổi đó.

Nếu bạn muốn bắt đầu SDD trong phát triển enterprise tại Nhật Bản, hãy thử CafeKit (cafekit.haposoft.com). Hỗ trợ tiếng Nhật native, tương thích hoàn toàn với Claude Code, OSS miễn phí – có thể triển khai ngay từ hôm nay.

Liên hệ về CafeKit

Về việc hỗ trợ triển khai CafeKit, customize cho enterprise, đào tạo SDD..., xin liên hệ với Haposoft.

• Website chính thức: cafekit.haposoft.com
• Haposoft: Công ty offshore development có trụ sở chính tại Hà Nội (Việt Nam) và văn phòng tại Tokyo (Nihonbashi, Nhật Bản). Đạt chứng nhận AWS Select Tier Partner, ISO 9001:2015 và ISO 27001.

Hãy để sự phát triển trong kỷ nguyên AI được dẫn dắt bởi những đặc tả chắc chắn