- Spec-Driven Development (SDD) là cách tiếp cận kiểu waterfall được hồi sinh, trong đó phải viết tài liệu đồ sộ trước khi lập trình, nhằm tạo cấu trúc cho các công cụ hỗ trợ viết mã bằng AI, nhưng có nguy cơ làm suy giảm tính linh hoạt
- Cộng đồng mã nguồn mở đã phát triển các công cụ tự động tạo bản đặc tả, kế hoạch triển khai, danh sách công việc từ prompt và chỉ dẫn ban đầu; tiêu biểu có Spec-Kit, Kiro, Tessl, BMad Method
- Tuy nhiên khi sử dụng thực tế, nhiều giới hạn bộc lộ như thiếu nhận thức ngữ cảnh, tài liệu hóa quá mức, review mã kép, cảm giác an toàn giả tạo; với codebase lớn thì hiệu quả giảm mạnh
- Bài viết cho rằng SDD là nỗ lực nhằm thay thế lập trình viên nên đã lặp lại thất bại của mô hình waterfall, và đề xuất thay vào đó là cách phát triển lặp dựa trên ngôn ngữ tự nhiên
- Cách tiếp cận kết hợp nguyên tắc Agile và Lean Startup phù hợp hơn với phát triển hiện đại có sử dụng coding agent, và bước tiếp theo là phát triển các công cụ tương tác trực quan
Sự xuất hiện của Phát triển theo đặc tả (SDD)
- Spec-Driven Development (SDD) đưa vào quy trình viết tài liệu đặc tả trước khi lập trình để cung cấp một phương thức phát triển có cấu trúc cho các công cụ hỗ trợ viết mã bằng AI
- Dựa trên prompt và chỉ dẫn ban đầu, LLM tạo ra đặc tả sản phẩm, kế hoạch triển khai, danh sách công việc
- Mỗi tài liệu phụ thuộc vào bước trước đó, và người dùng chỉnh sửa để tinh luyện đặc tả
- Các tài liệu hoàn chỉnh sẽ được chuyển cho các coding agent như Claude Code, Cursor, Copilot để phục vụ việc viết mã
- Các công cụ tiêu biểu gồm Spec-Kit của GitHub, Kiro của AWS, Tessl, BMad Method (BMM)
- Bài phân tích so sánh liên quan được nhắc tới là Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl của Birgitta Böckeler
Vấn đề của tài liệu hóa bằng Markdown
- Đặc tả SDD phần lớn được cấu thành dưới dạng tệp Markdown; ví dụ một tính năng đơn giản được triển khai bằng GitHub Spec-Kit đã lên tới 8 tệp, 1.300 dòng
- Trường hợp thêm trường “referred by” cho Atomic CRM bằng Kiro cũng bị tách thành nhiều tài liệu
- Khi dùng thực tế, các nhược điểm sau lộ rõ
- Thiếu nhận thức ngữ cảnh (Context Blindness): bỏ sót hàm có sẵn hoặc ngữ cảnh mã hiện có nên vẫn cần chuyên gia xem lại
- Tài liệu Markdown quá mức (Markdown Madness): tài liệu dài khiến việc dò tìm lỗi đơn giản cũng tốn nhiều thời gian
- Quan liêu có hệ thống (Systematic Bureaucracy): lặp lại không cần thiết và chi tiết hóa quá mức gây kém hiệu quả
- Agile giả hiệu (Faux Agile): lạm dụng khái niệm “User Story” gây rối rắm
- Review mã kép (Double Code Review): phải xem xét cả mã trong đặc tả lẫn phần triển khai thực tế
- Cảm giác an toàn giả tạo (False Sense of Security): agent không thực sự tuân thủ đặc tả một cách hoàn toàn
- Lợi ích giảm dần (Diminishing Returns): hữu ích ở giai đoạn đầu dự án nhưng càng mở rộng quy mô thì càng chậm
- Vì đa số coding agent đã có sẵn plan mode và tính năng task list, lợi ích bổ sung của SDD là hạn chế, thậm chí còn có thể làm tăng chi phí phát triển
Sự trả đũa của quản lý dự án
- Giới hạn của SDD có thể đến từ việc công cụ chưa trưởng thành, nhưng về căn bản bắt nguồn từ cách đặt vấn đề sai
- Nó giả định mục tiêu là “làm thế nào để loại bỏ lập trình viên khỏi phát triển phần mềm”
- Cấu trúc này tìm cách thay thế lập trình viên bằng coding agent và kiểm soát chúng bằng kế hoạch cực kỳ chi tiết
- Điều này tương tự mô hình waterfall, nơi tài liệu hóa đồ sộ biến lập trình viên thành người chỉ làm nhiệm vụ chuyển dịch
- Nhưng phát triển phần mềm là một quá trình phi tất định (non-deterministic), nên không thể loại bỏ bất định chỉ bằng lập kế hoạch (trích dẫn bài viết No Silver Bullet)
- Ở giai đoạn yêu cầu, SDD cần chuyên môn của nhà phân tích nghiệp vụ; ở giai đoạn thiết kế, lại cần chuyên môn của lập trình viên, nên trên thực tế chỉ số ít người có thể dùng vì phải đảm nhiệm được cả hai vai trò
- Kết cục, cũng giống công cụ No Code, nó hứa hẹn “phát triển không cần lập trình viên” nhưng rồi cuối cùng vẫn cần lập trình viên
Phương án thay thế mới: phát triển lặp dựa trên ngôn ngữ tự nhiên
- Phương pháp Agile giải quyết bài toán phát triển phi tất định bằng cách chọn khả năng thích ứng thay vì khả năng dự đoán
- Việc chia yêu cầu phức tạp thành nhiều bài toán đơn giản là chìa khóa để tận dụng coding agent
- Bài viết đưa ra một quy trình lặp đơn giản áp dụng nguyên tắc Lean Startup
- Xác định giả định rủi ro nhất của sản phẩm
- Thiết kế thí nghiệm tối thiểu để kiểm chứng giả định đó
- Phát triển thí nghiệm và lặp lại theo kết quả
- Ví dụ, dùng Claude Code để phát triển công cụ điêu khắc 3D (sculpt-3D) trong khoảng 10 giờ
- Không có đặc tả, chỉ thêm dần tính năng bằng các chỉ dẫn ngắn
- Khi triển khai sai thì sửa ngay và lặp nhanh
- Cách làm này cho phép hội tụ nhanh ngay cả khi không có tài liệu kiểu waterfall, và sự kết hợp giữa Agile với coding agent giúp xây dựng sản phẩm theo thời gian thực
- Tuy vậy, do coding agent vẫn lấy văn bản làm trung tâm, chúng còn thiếu tương tác trực quan; về sau cần phát triển các công cụ tăng cường giao diện trực quan
Kết luận
- Phương pháp Agile vốn đã khiến tài liệu đặc tả trở nên không cần thiết, và SDD bị đánh giá là nỗ lực hồi sinh chúng
- SDD là cách tiếp cận nặng tính lý thuyết nhằm loại bỏ lập trình viên, nên đã bỏ lỡ cơ hội trao quyền cho thế hệ lập trình viên mới thông qua coding agent
- Bài viết ví coding agent như động cơ đốt trong: SDD chỉ trói nó vào đầu máy xe lửa, trong khi chúng ta cần mở rộng sang ô tô, máy bay và nhiều hình thức khác
- Cuối cùng, nếu xét đến môi trường thì cần sử dụng coding agent một cách tiết chế
1 bình luận
Ý kiến trên Hacker News
Với tư cách là một lập trình viên, cách mang lại mức tăng năng suất lớn nhất cho tôi là hình thành thói quen lên kế hoạch cho mọi việc từ trước
Mỗi khi nhận ticket, tôi chia nhỏ nó thành một danh sách TODO lớn để làm rõ trước thiết kế, phụ thuộc và đặc tả
Làm như vậy giúp tôi đi vào trạng thái flow thường xuyên hơn khi lập trình
Cách tiếp cận này cũng hiệu quả với các AI coding agent, vì nó là việc chuyển sẵn quá trình suy nghĩ ra bên ngoài
Tôi đã viết chi tiết hơn trong bài này
Thực ra việc chia nhỏ vấn đề và viết đặc tả là điều tốt
Chỉ có đặc tả bất biến mới gây ra vấn đề. Nếu vài tháng sau mới bắt đầu triển khai thì đặc tả sẽ bị đóng cứng
Còn Agile thì nhiều khi lại bị dùng như cái cớ để trì hoãn việc lập kế hoạch chiến lược. Kết quả là phải làm lại rất nhiều
Cuối cùng vẫn là vấn đề cân bằng, và tôi nghĩ “It depends” là một phương châm hay cho cả cuộc sống lẫn phát triển phần mềm
Nếu LLM quản lý đặc tả thì có vẻ sẽ có lợi thế là giảm gánh nặng bảo trì
Bài liên quan ở đây
Khi khó dự đoán, chúng tôi làm spike trước để khám phá code và thư viện
Chúng tôi tạo cả sơ đồ cấu trúc lý tưởng lẫn sơ đồ phản ánh các ràng buộc thực tế, để tránh bẫy kiến trúc về lâu dài
Sau vài tháng làm vibe coding, 6 tháng gần đây tôi đã chuyển sang spec-driven development
Tôi dành 2–3 giờ mỗi ngày để viết đặc tả, rồi trong ngày đó triển khai luôn tính năng đã được test
Viết đặc tả không khiến tôi kém linh hoạt hơn. Ngược lại, nó cho phép lặp nhanh theo chu kỳ 8 giờ
Đặc tả không phải prompt mà là tiêu chuẩn để đánh giá tính đúng đắn
Các bài test end-to-end được định nghĩa tốt giúp giảm mạnh lỗi của AI
Kết quả mỗi lần chạy đều khác nhau, và cuối cùng con người vẫn phải xem lại nên có thể rất kém hiệu quả
Gọi một công việc trong một ngày là ‘đặc tả’ thì dễ gây hiểu lầm. Cuối cùng chỉ là đổi tên cho quy trình cũ
Nhiều khi ngay cả biểu thức logic đơn giản cũng diễn giải sai, nên để nó hiểu đặc tả ngôn ngữ tự nhiên là rất rủi ro
Giao chúng cho agent xong là nó tự triển khai, còn tôi chỉ cần xem lại giữa chừng
Trong lúc AI làm việc thì tôi nghịch xe đua của mình, đúng là đôi bên cùng có lợi
Cuối cùng điều quan trọng chỉ là code có vượt qua được test hay không
Bài này có vẻ dành cho những người đã kết luận từ trước rằng “spec-based development không hợp với tôi”
Tôi xem đặc tả là điểm vào ngữ cảnh của LLM
Nếu cung cấp đầy đủ cấu trúc dự án, model, hàm, yêu cầu... thì LLM có thể hiểu ngữ cảnh và mở rộng tiếp được
Hơn nữa, nếu để LLM tự cập nhật đặc tả thì cũng có thể lặp theo kiểu Agile
Test đóng vai trò grounding trong thực tế cho LLM, giúp ngăn ảo giác
Test vừa là tài liệu vừa là tiêu chuẩn chất lượng, và cần quản lý LLM như một lập trình viên junior
Cho nhiều agent chạy song song rồi để chúng kiểm tra chéo nhau bằng lớp test có thể cho ra kết quả đáng kinh ngạc
Chỉ là nhờ LLM mà có thể lặp trên toàn bộ đặc tả với chi phí rẻ và tốc độ nhanh hơn, còn bản chất thì vẫn vậy
Đặc tả quá dài ngược lại còn cản trở tư duy khám phá
LLM không phải hệ thống tất định mà là hệ thống xác suất, nên giờ chúng ta phải debug đặc tả chứ không phải code
Lập trình viên giờ cần tiến hóa thành kiến trúc sư hệ thống nhận thức (cognitive systems architect)
Đặc tả ở mức cao và đặc tả cho từng thành phần chi tiết cùng tồn tại
Tôi đã thử làm công cụ CLI bằng Spec-Kit của GitHub, nhưng cần quá nhiều bước sửa, phân tích và viết lại
Nó gây bức bối vì thiếu phản hồi lặp đi lặp lại như waterfall
Cuối cùng thay vì nhìn đống code sai rồi tìm nguyên nhân, tôi thấy làm lại từ đầu còn hơn
Tôi thích coding cùng LLM, nhưng SDD cho cảm giác là một workflow nặng nề và kém hiệu quả
LLM thích ngữ cảnh, nên bạn phải liên tục chỉ dẫn rõ ràng theo cách lặp lại
Ví dụ khi làm app NextJS thì cần mô tả rõ đăng nhập, RBAC, triển khai ưu tiên test, v.v.
Bắt đầu từ đơn vị nhỏ rồi thêm tính năng dần dần là cách phù hợp hơn
Vấn đề của waterfall là lead time dài và chi phí lặp cao
Trong SDD thì hai điểm này được giải quyết nên tôi nghĩ không sao
Gọi một bản đặc tả mất vài giờ là waterfall thì hơi phóng đại
Nếu đi vào không gian lời giải phức tạp quá sớm thì việc giải quyết bài toán đơn giản sẽ trở nên khó khăn
Agile bắt đầu từ không gian nhỏ rồi mở rộng dần từng bước
Nếu đặc tả đủ chi tiết thì vòng lặp sẽ chậm lại, còn nếu không đủ thì LLM lại không hoạt động tốt
Cuối cùng nó vẫn giữ nguyên nghịch lý của waterfall mà quản lý ưa thích
LLM hoạt động tốt nhất khi được chỉ dẫn rõ ràng theo các đơn vị nhỏ
Họ sẽ viết đặc tả cho vài năm, chạy LLM mỗi 6 tháng, rồi khi thất bại thì đổ lỗi cho lập trình viên
Tôi là chính tác giả bài viết
Vẫn thấy thú vị khi cuộc tranh luận waterfall vs agile còn sôi nổi đến vậy
Đọc nền tảng của những người thấy SDD có giá trị cũng rất hay
Nhưng tôi vốn đã dùng chế độ Plan trước khi triển khai nên SDD không mang thêm nhiều giá trị
Hầu như chưa khi nào coding agent triển khai hoàn hảo chỉ trong một lần
Cuối cùng vẫn phải lặp lại nên ý nghĩa của Big Design Up Front bị mất đi
Tuy vậy, tôi tin coding agent đang mở ra một mô thức phát triển mới
Tôi nhớ đến video mình từng xem
Trong đó kỹ sư và lập trình viên nói về những điều họ có thể học từ nhau, và tầm quan trọng của việc lập kế hoạch trước là điểm rất ấn tượng
Người ta nói Agile đã giết chết tài liệu đặc tả, nhưng thật ra nó chỉ xé nhỏ chúng thành hàng nghìn ticket Jira
AI có thể ghi lại toàn bộ những quyết định và ngữ cảnh rời rạc này, rồi đặt câu hỏi khi chúng mâu thuẫn với các lựa chọn trong quá khứ
Nó có thể đưa ra phản hồi kiểu “Lý do Jim viết đoạn code này như vậy từ 5 năm trước còn còn phù hợp không?”
Bài này cho tôi cảm giác hơi kỳ lạ
Nhận đặc tả không hoàn chỉnh rồi giải quyết bằng thử sai thì với lập trình viên con người hay AI cũng như nhau
Nếu đã biết rõ thì đúng ra phải chỉ dẫn chi tiết
Có lẽ ý chính của bài là đang nói về “đặc tả tệ”
Tổng thể thì nó trông giống lập luận tự vệ của ngành công nghiệp Agile hơn
Tôi đã thử SDD bằng nhiều file đặc tả Markdown, và thứ thực sự hiệu quả là ** beads**
Nó giúp agent tập trung bằng cách đi theo cây công việc
Nó chia mỗi công việc theo TDD và không cho sang bước tiếp theo trước khi test vượt qua
Agent còn chỉ luôn các lệnh review nên việc code review rất dễ
Spec-Kit quá nặng nề nên beads thực tế hơn nhiều
Ngay cả dự án zmx làm hoàn toàn theo kiểu vibe-based, về sau tôi cũng viết lại toàn bộ dựa trên code tham chiếu từ agent