Spec-Driven Development là gì? Spec là tài sản

Spec-Driven Development là cách phát triển phần mềm lấy bản đặc tả làm nguồn sự thật trước khi viết code, để AI sinh code, kiểm thử và tài liệu theo đúng yêu cầu đã duyệt. Khi kết quả sai, đội dự án sửa spec rồi sinh lại phần cần thiết, thay vì vá tiếp lên một nền code không ai còn giải thích nổi. Ca AWS Kiro rút một tính năng từ 40 giờ công xuống dưới 8 giờ cho thấy giá trị của việc khóa spec sớm. Tụi em áp SDD cho mọi dự án tại MONA, vì trong 14.000+ dự án đã làm, thứ giết dự án nhiều nhất là đề bài mù mờ. Đề bài đi trước.

Spec-Driven Development nghĩa là chốt đề bài trước, code tính sau

Trong Spec-Driven Development, spec ghi phần mềm làm gì, ai dùng, dữ liệu đi đâu, điều kiện đạt và cách xử lý lỗi. Code đứng sau tài liệu đó. Thứ tự này quan trọng từ năm 2025, khi AI đủ nhanh để biến một yêu cầu mơ hồ thành nhiều code sai. Nhanh sai vẫn là sai.

AWS Kiro ghi nhận một tính năng từ 40 giờ công xuống dưới 8 giờ khi viết spec trước. Con số ấy không áp thành mức nhanh hơn 5 lần cho mọi dự án; nó chỉ ra thời gian thường mất ở vòng hiểu sai rồi làm lại. Tụi em dùng SDD để giảm đoán ý, không lấy tốc độ gõ code làm thành tích.

GitHub công bố Spec Kit, còn Microsoft gọi SDD là kỹ thuật AI-Native. MONA đặt SDD trong mô hình phát triển phần mềm AI-Native gồm 4 trụ, nơi người ra đề, kiểm soát và chịu trách nhiệm. AI làm phần tay chân. Ranh giới rất rõ.

Một bản spec đủ chặt trông như thế nào

Spec là gì? Đó là bản mô tả hành vi mong muốn của phần mềm bằng ngôn ngữ mà người làm nghiệp vụ lẫn người làm kỹ thuật đều kiểm tra được. Một spec tốt không cần phô thuật ngữ, nhưng phải trả lời đủ 4 lớp dưới đây trước khi đội dự án cho AI chạy. Thiếu 1 lớp, phần thiếu đó sẽ biến thành chỗ máy tự đoán. Mỗi lớp phải kiểm được.

Ở dự án phần mềm theo yêu cầu, 4 lớp là căn cứ chốt phạm vi và chi phí. Khi yêu cầu đổi, hai bên sửa đúng dòng, nhìn ảnh hưởng rồi quyết. Sau gần 10 năm và hơn 14.000 dự án, tụi em thấy tranh cãi thường bắt đầu ở các chữ “nhanh”, “dễ dùng”, “tự động”. Spec buộc chúng có nghĩa đo được.

Spec phải rõ. Nếu anh chị chưa mô tả được điều kiện nghiệm thu, đội kỹ thuật chưa nên cho AI sinh code, dù bản mẫu đầu tiên xuất hiện chỉ sau vài giờ.

Từ spec ra code chạy được: đúng 6 bước

Một luồng SDD đi qua 6 bước: lấy yêu cầu, làm rõ, viết spec, người duyệt, sinh code cùng kiểm thử, đối chiếu kết quả. Bước thứ 4 là cửa quyết định. Khi logic nghiệp vụ chưa được ký, bước thứ 5 chưa chạy; tốc độ AI không được dùng để ép chấp nhận đề bài còn hở.

1. Mục tiêu: vấn đề, người dùng.
2. Làm rõ: AI hỏi, người chốt.
3. Viết spec: luồng, ngoại lệ, điều kiện đạt.
4. Duyệt: nghiệp vụ và kỹ thuật khóa đề.
5. Sinh: code, kiểm thử, tài liệu.
6. Nghiệm thu: chấm theo spec.

Điểm kỹ thuật nằm ở 3 thứ: spec, code, bộ kiểm thử. Code đổi mà kiểm thử không đổi theo spec sẽ tạo ba bản sự thật lệch nhau; spec đổi thì cả hai phải cập nhật trong cùng vòng. Ca 40 giờ công xuống dưới 8 giờ chỉ xảy ra khi ba đầu ra bám cùng đặc tả. Tụi em áp logic ấy cho website tích hợp AI và LMS, nơi vai trò cùng ngoại lệ khó nhìn trên giao diện.

Code theo sau. Đây là phần khác biệt giữa SDD và vibe coding: một bên khóa đề rồi mới sinh, bên kia hợp với bản thử nhanh nơi người làm chấp nhận dò đường bằng kết quả.

3 lỗi làm SDD chậm hơn cả cách cũ

SDD không tự cứu một đội viết yêu cầu kém. Lỗi thứ 1 là biến spec thành bản mô tả giao diện, chỉ ghi nút nằm đâu mà bỏ trống quy tắc nghiệp vụ; lỗi thứ 2 là nhét mọi quyết định vào một tài liệu dài rồi không ai chịu trách nhiệm duyệt; lỗi thứ 3 là sửa code trực tiếp nhưng quên cập nhật spec. Sau vài vòng, bản đặc tả và sản phẩm nói hai chuyện khác nhau.

Một spec dài 14 trang chưa chắc chặt hơn bản 4 trang; độ dài không phải thước đo. Thước đo là mỗi yêu cầu quan trọng có điều kiện đạt, có người duyệt và có kiểm thử đi kèm. Khi ba lỗi trên xuất hiện, tụi em dừng luồng ngay, vì để AI chạy tiếp chỉ làm khối lượng cần gỡ lớn thêm. Đừng vá tiếp.

Với website đã vận hành, lỗi còn dễ lộ ở giai đoạn bảo trì: người sửa một tính năng rồi làm hỏng luồng cũ. Dịch vụ quản trị website cần giữ tài liệu cùng bộ kiểm thử sau mỗi lần đổi, đặc biệt ở hệ thống hoạt động 24/7. SDD có giá trị sau ngày bàn giao nhiều hơn trong màn trình diễn sinh code ban đầu.

MONA đang chạy SDD như thế nào

Chiều 19/08/2026, tụi em làm bản whitepaper 14 trang bằng chính cách đang mô tả. Người viết khóa spec cho từng trang, AI dựng bản trình bày, người duyệt bắt 3 lỗi bố cục rồi sửa trước khi phát hành trong 1 buổi chiều. Câu chuyện nhỏ đó cho thấy SDD không bị giới hạn trong code; mọi đầu ra do AI tạo đều cần một bản mô tả cái đúng trông ra sao.

Ở dự án phần mềm, vai trò được giữ theo cùng nguyên tắc. Người hiểu nghiệp vụ ra đề, dev senior soát kiến trúc và code, AI gánh phần lặp, còn anh chị duyệt phạm vi cùng điều kiện nghiệm thu trước khi triển khai. Tụi em không giao code máy chưa có người đọc lên máy chủ, kể cả bản nháp xuất hiện sau vài giờ. Người chịu trách nhiệm vẫn là người.

Cách làm này đi qua nhiều loại sản phẩm, từ website doanh nghiệp, website cho doanh nghiệp tại TP.HCM đến chatbot trực 24/7. Con chatbot Gấu Cười trên mona.media và tổng đài 1900 636 648 cũng đi theo đề bài chốt trước, AI code phần lặp, dev senior duyệt rồi mới lên máy chủ; anh chị muốn xem nhánh sản phẩm có thể đọc về chatbot AI. Tụi em giữ cửa.

Bản whitepaper AI-Native SDLC 14 trang ghi lại đầy đủ sơ đồ, được phát hành đúng ngày 19/08/2026 để anh chị mang vào buổi làm việc với đội kỹ thuật.

SDD đứng ở đâu trong mô hình 4 trụ

MONA vận hành 4 trụ theo một thứ tự dễ hiểu: Kanban quản dòng công việc, SDD giữ nguồn sự thật, AI-DLC đưa AI vào từng khâu, còn Agentic SDLC dành cho MVP hoặc dự án nhỏ. SDD áp cho mọi dự án vì cả 3 trụ còn lại đều cần biết kết quả đúng là gì. Tụi em coi spec như đường ray; AI chạy nhanh nhưng không được rời đường ray đó.

Trong bản phân tích mô hình phát triển phần mềm, một dự án đầy đủ đi qua 6 bước và nằm trên 1 bảng công việc chung. SDD hiện diện từ bước làm rõ đến nghiệm thu, còn AI-DLC nối dữ liệu giữa kế hoạch, code, kiểm thử và vận hành. Nếu anh chị đang chuẩn bị chuyển đổi AI cho doanh nghiệp, spec còn giúp tách quyết định của người khỏi việc máy được phép làm. Quyền phải ghi rõ.

Với bộ AI agent, ranh giới càng cần viết rõ: agent nào đọc dữ liệu gì, được gọi công cụ nào, dừng ở điều kiện nào và ai duyệt hành động nhạy cảm. Hệ thống hoạt động 24 giờ mỗi ngày, 7 ngày mỗi tuần càng không được có 1 quyền cấp thừa, vì lỗi lớn hơn một màn hình sai màu. Tụi em luôn viết quyền và cửa dừng vào spec trước khi cho agent chạy.

Giữ đúng thứ tự. SDD không thay Kanban hay AI-DLC; nó cung cấp đề bài để hai trụ đó chạy mà người chịu trách nhiệm vẫn kiểm tra được.

Ai nên làm SDD, ai chưa cần

SDD hợp với dự án có nhiều vai trò, nhiều ngoại lệ, cần bảo trì dài và có điều kiện nghiệm thu rõ. Phần mềm theo yêu cầu, website doanh nghiệp, LMS hoặc AI agent đều thuộc nhóm này, vì một quyết định sai thường lan qua hơn 1 luồng dữ liệu. Anh chị cũng nên dùng khi đội làm việc gồm cả người nghiệp vụ lẫn kỹ thuật, bởi spec là mặt giấy chung để hai bên cùng ký vào một nghĩa.

Ai đừng dùng? Một bản thử bỏ đi sau 1 buổi, trang giới thiệu chỉ để kiểm tra phản ứng hoặc đoạn mã dùng đúng 1 lần không cần quy trình nặng. Trong những ca đó, viết spec dài hơn thời gian dùng sản phẩm là lãng phí; tụi em sẽ chọn bản mô tả ngắn, khóa vài điều kiện quan trọng rồi thử nhanh. Đừng thần thánh hóa SDD.

Ranh giới đổi hẳn khi hệ thống chạm tiền, dữ liệu riêng tư hoặc hoạt động 24/7. Tại đó, bỏ spec để tiết kiệm vài giờ là quyết định tệ, còn giao toàn quyền cho AI agent viết riêng tự sửa rồi tự đưa lên máy chủ là việc tụi em không làm. 85% khách tiếp tục đồng hành với MONA sau dự án đầu phản ánh phần nào giá trị của kỷ luật sau bàn giao, không chỉ tốc độ làm bản đầu.

Câu hỏi thường gặp về Spec-Driven Development

Bốn câu dưới đây đi thẳng vào cách dùng SDD, từ 40 giờ công xuống dưới 8 giờ ở ca AWS Kiro đến kinh nghiệm gần 10 năm của MONA với hơn 14.000 dự án. Bốn câu, trả lời thẳng.

SDD là gì?

SDD là viết tắt của Spec-Driven Development, cách làm lấy spec đã duyệt làm nguồn cho code, kiểm thử và tài liệu. Một luồng chuẩn có 6 bước từ lấy yêu cầu đến nghiệm thu, trong đó người giữ quyền duyệt trước khi AI thực thi. Người chấm giữ quyền.

Spec là gì trong phát triển phần mềm?

Spec là bản đặc tả hành vi, quyền, dữ liệu, ngoại lệ và điều kiện đạt của sản phẩm. Một bản cần bao phủ đủ 4 lớp gồm người dùng, luồng chính, ngoại lệ và nghiệm thu; số trang không quan trọng bằng khả năng kiểm tra.

SDD có làm dự án nhanh hơn không?

Có, khi thời gian cũ bị mất vào hiểu sai và làm lại. Ca AWS Kiro được nêu trong brief rút một tính năng từ 40 giờ công xuống dưới 8 giờ sau khi viết spec trước, nhưng đội dự án vẫn phải trả đúng thời gian cho việc hiểu nghiệp vụ. Nhanh vì bớt làm lại.

SDD có thay dev senior không?

Không. Dev senior giữ kiến trúc, rà code và chịu trách nhiệm trước khi sản phẩm lên máy chủ; AI chỉ gánh phần lặp. Từ 2016 và hơn 14.000 dự án, tụi em càng chắc rằng trách nhiệm kỹ thuật không giao cho máy.

Chốt spec trước khi trả tiền cho code

Spec-Driven Development đáng dùng khi anh chị muốn nhìn thấy phạm vi, giá và điều kiện nghiệm thu trước dòng code đầu tiên. Phép tính 40 giờ xuống dưới 8 giờ chỉ có giá trị khi phần tiết kiệm đến từ giảm làm lại, còn chất lượng vẫn được người chịu trách nhiệm kiểm soát. Tụi em dùng SDD để khóa đúng chỗ đó. Chốt spec trước đã.

Nếu đề bài đang nằm trong vài tin nhắn, một file mô tả rời và 2 cách hiểu khác nhau giữa kinh doanh với kỹ thuật, hãy dừng trước khi cho AI sinh thêm code. Gọi 1900 636 648 hoặc gửi yêu cầu qua khung chat, tụi em sẽ cùng anh chị chuyển phần mơ hồ thành spec sơ bộ, chỉ ra điều kiện nghiệm thu và phạm vi cần chốt. Sau đó anh chị mới quyết có làm tiếp với MONA hay không.