Spec-driven development trong thực tế

1. Spec-driven development và các hãng làm tool đang hội tụ

Brian Casel mở đầu bằng nhận định rằng đang có một sự chuyển dịch lớn trong cách phát triển phần mềm theo hướng AI-first, và tên của nó là spec-driven development (theo video đăng ngày 24/09/2025). Theo anh, đây là cách những người build chuyên nghiệp rời bỏ sự khó đoán của vibe coding để chuyển sang một workflow thật sự ship được sản phẩm. Đó là một cách làm có phương pháp, đưa sản phẩm của bạn đi từ ý tưởng tới tay khách hàng một cách đều đặn.

Với Brian, một người làm chủ doanh nghiệp và làm product designer, đây là điều khiến anh hào hứng với thời điểm này (theo video đăng ngày 24/09/2025). Anh nói: chúng ta không chỉ thay đổi cách viết code, chúng ta đang thay đổi cách build sản phẩm.

Agent OS là hệ thống mã nguồn mở, miễn phí, do chính Brian làm ra để vận hành một quy trình spec-driven (theo video đăng ngày 24/09/2025). Anh giới thiệu nó cùng lúc với spec-driven development từ vài tháng trước khi đăng video này.

Theo Brian (video đăng ngày 24/09/2025), các hãng làm tool lớn giờ đây đang đi tới cùng một nhận thức: cách tiếp cận spec-driven là con đường đúng. Anh nói mình rất thích hướng đi này của cả ngành. Anh kể ra các ví dụ, tính tới lúc quay video: ngay trong tuần đó GitHub ra mắt dự án Spec Kit; Amazon gần đây ra mắt Kiro, một sản phẩm được xây quanh việc lập kế hoạch bằng spec; Cursor thêm một vài thứ để theo dõi task vào giao diện; còn Claude Code thì đã có planning mode từ trước.

Như vậy, theo anh (video đăng ngày 24/09/2025), cách tiếp cận spec-driven đang đi vào các tool phổ biến, và cả ngành nhìn chung đã đồng ý rằng spec là thứ thiết yếu. Nhưng tooling và quy trình đằng sau spec-driven development thì vẫn còn khá chưa ổn định. Anh nói thật lòng rằng như vậy là tốt, vì tất cả chúng ta vẫn đang tìm hiểu xem build trong kỷ nguyên AI-first nghĩa là gì.

2. Ba khía cạnh mà tooling đại trà còn thiếu

Chủ đề của video là xem xét spec-driven development trong thực tế. Brian cho rằng có ba khía cạnh then chốt mà tooling dành cho số đông vẫn còn thiếu (theo video đăng ngày 24/09/2025). Nếu không giải quyết chúng, theo anh, việc đưa AI vào các team sẽ tiếp tục là một cuộc leo dốc vất vả.

Anh tự giới thiệu là Brian Casel. Trong mấy tháng trước khi quay video, khi áp dụng spec-driven development vào các sản phẩm của chính mình và theo dõi tooling thay đổi, anh nhận ra ba vấn đề nền tảng mà phần lớn các tool chưa xử lý (theo video đăng ngày 24/09/2025). Đó là những điều anh cố giải quyết mỗi lần làm thêm một phiên bản Agent OS, và anh sẽ cho xem cách anh dùng Agent OS để làm cho spec của mình thật sự hữu ích.

3. Vấn đề thứ nhất: thiếu quy trình để thống nhất hướng đi

Vấn đề đầu tiên, theo Brian (video đăng ngày 24/09/2025), là thiếu một quy trình để thiết lập sự thống nhất (alignment). Phần lớn các tool chỉ mong bạn xuất hiện với một prompt rồi sinh ra spec, như thể chúng tự biết bạn muốn gì và tính năng đó phải khớp thế nào vào bức tranh lớn hơn của sản phẩm.

Nhưng chúng ta đâu có thức dậy là biết ngay phải build cái gì, anh nói. Ngay cả khi biết tính năng tiếp theo trên roadmap là gì, vẫn còn một giai đoạn quan trọng trước khi tạo spec (theo Brian, video đăng ngày 24/09/2025). Giai đoạn đó gồm việc chọn cách tiếp cận đúng, cân nhắc các tradeoff, các quyết định design, các edge case, và chiến lược sản phẩm của bạn. Lý do anh đưa ra: một tính năng có nhiều cách build khác nhau, và câu hỏi là cách nào tốt nhất cho sản phẩm và khách hàng của bạn.

Vì thế, theo Brian, phiên bản Agent OS mới tại thời điểm video (đăng ngày 24/09/2025) không vội viết spec. Thay vào đó, trước tiên nó cho agent cùng bạn làm phần ideation và lập kế hoạch chiến lược. Anh cho rằng phần context nền tảng này là then chốt nếu bạn muốn agent build đúng với tầm nhìn của bạn.

4. Demo: app Flashcards và lệnh new-spec

Để minh hoạ, Brian dùng một app đơn giản tên Flashcards mà anh đang làm, để kiểm tra bài tập về nhà của các con mình bằng câu hỏi (demo trong video đăng ngày 24/09/2025). Trong thư mục Agent OS của project có thư mục specs. Anh đã build xong tính năng đầu tiên, và spec hoàn chỉnh của tính năng đó nằm ngay trong thư mục này.

Giờ anh bắt đầu spec tiếp theo (demo trong video đăng ngày 24/09/2025). Claude Code đang mở, và anh chạy lệnh new spec. Vì project đã có sẵn product plan với roadmap và mission, Agent OS tham chiếu tới chúng và hỏi anh có muốn build luôn mục tiếp theo trên roadmap không.

Anh mở roadmap ra xem (demo trong video đăng ngày 24/09/2025): hai phần trước đã build xong, và giờ cần build giao diện question builder cho câu hỏi trắc nghiệm (multiple choice). Anh chọn đi tiếp với mục đó.

Từ đây, theo Brian (demo trong video đăng ngày 24/09/2025), Agent OS dùng sub-agent cho mọi bước trong quy trình, nếu bạn đang dùng Claude Code, vốn hỗ trợ sub-agent. Thư mục cho spec tiếp theo, tên question builder interface, đã được tạo và đang được khởi tạo.

5. Spec researcher và chín câu hỏi làm rõ

Tiếp theo, việc được chuyển sang sub-agent spec researcher (demo trong video đăng ngày 24/09/2025). Vai trò của nó là giúp Brian nghiên cứu, lập kế hoạch và làm rõ các chi tiết cho tính năng mới, trước cả khi bắt đầu viết spec. Nó đưa ra một danh sách câu hỏi làm rõ, lần này là chín câu.

Brian giải thích phần anh đã cài sẵn trong Agent OS (theo video đăng ngày 24/09/2025): anh hướng dẫn agent phân tích mission, product roadmap, standards của anh và ý tưởng ban đầu của tính năng, rồi từ đó nghĩ ra các câu hỏi làm rõ. Cụ thể, anh bảo nó đánh số các câu hỏi, để anh dễ trả lời theo kiểu: số một, trả lời; số hai, trả lời; số ba.

Điều thứ hai anh yêu cầu là agent vừa đặt câu hỏi vừa đưa ra một giả định hợp lý làm câu trả lời có khả năng đúng (theo video đăng ngày 24/09/2025). Nhờ vậy anh có thể trả lời rất nhanh, kiểu: số một, đúng; số hai, đúng; số ba, để anh chỉnh hướng một chút; số bốn, đúng. Theo anh, cách này làm cho việc lên kế hoạch, ideation và làm rõ dễ hơn một chút so với việc anh tự nghĩ ra các câu hỏi.

Thêm một mẹo nữa (theo Brian, video đăng ngày 24/09/2025): anh nhấn mạnh với agent tầm quan trọng của việc tham chiếu các thành phần design và kiến trúc đã có sẵn trong codebase khi nó soạn câu hỏi. Ở phía dưới danh sách có hẳn một mục hỏi anh, đúng nghĩa đen, rằng có tái sử dụng code hay component nào sẵn có trong codebase không. Anh cho rằng đây đều là những tài liệu planning rất quan trọng cần đưa vào quy trình.

Ở khung nhìn kéo xuống của danh sách (demo trong video đăng ngày 24/09/2025), các câu còn lại hỏi về rich text hay plain text, giữ cách sửa inline bằng Turbo Frames, validation tối thiểu hai đáp án, có xáo thứ tự đáp án không, lưu đáp án dạng JSON hay bảng answer_choices riêng, và có loại trừ gì khỏi tính năng này không; sau đó là mục "Existing Code Reuse" và mục "Visual Assets Request".

6. Trả lời câu hỏi và thả wireframe vào thư mục visuals

Brian trả lời xong chín câu (demo trong video đăng ngày 24/09/2025). Anh chỉ ra rằng việc này rất dễ: anh xác nhận giả định agent đưa ra và chỉnh hướng rất nhỏ ở vài chỗ. Anh quên ghi chú về phần tái sử dụng, nên thêm một dòng để agent dùng lại styling của giao diện câu hỏi đang có. Câu trả lời anh gõ vào terminal:

1. correct.
2. yes.
3. yup.
4. plain for now.
5. sure.
6. yes at least 2.
7. no, we'll add reordering later.
8. json field is fine.
9. no image support, no categories, no time limits.

yes, use our existing questions form as your reference for styling.

yes, adding a wireframe.

Còn một thứ cuối cùng mà Agent OS phiên bản lúc đó hỏi tới: thư mục visuals (theo video đăng ngày 24/09/2025). Phần này không bắt buộc, nhưng nếu bạn có mock-up hay wireframe nào, theo Brian, đây là lúc tốt để đưa chúng vào phần planning. Anh nói agent làm việc tốt hơn rất nhiều khi được bám theo một tham chiếu hình ảnh thật.

Brian có một wireframe rất đơn giản, vẽ thô, và anh thả nó vào thư mục visuals để nó nằm trong phần planning của spec này (demo trong video đăng ngày 24/09/2025). Theo anh, Agent OS lúc đó còn được cài sẵn khả năng nhận biết đây là một mock-up chi tiết hay chỉ là wireframe thô; trường hợp này nó sẽ biết đó là wireframe. Xong phần câu hỏi đầu tiên, anh gửi câu trả lời đi.

7. Vòng câu hỏi tiếp theo sau khi agent xem wireframe

Như Brian nói, vẫn chưa xong (demo trong video đăng ngày 24/09/2025). Agent vừa phân tích các câu trả lời cho vòng câu hỏi đầu, xem wireframe anh đưa, rồi đặt thêm vài câu hỏi làm rõ để chắc chắn hai bên hiểu như nhau. Nó để ý một chi tiết anh đưa vào wireframe và muốn xác nhận hướng đi. Nó còn chỉ ra rằng anh quên vẽ chi tiết để chọn đâu là đáp án mặc định.

Theo Brian (demo trong video đăng ngày 24/09/2025), một lần nữa agent diễn đạt câu hỏi sao cho anh trả lời thật nhanh, kiểu: bạn muốn làm cách này hay cách kia, và anh chỉ cần nói "option A". Câu trả lời anh gõ cho vòng này:

1. yes, build the ability to add/remove options.
2. yes, include ability to mark the default answer with a radio button.
3. inline

Đến đây phần việc của spec researcher hoàn tất (demo trong video đăng ngày 24/09/2025).

8. Thư mục planning và file requirements

Terminal báo spec đã được khởi tạo, requirements đã thu thập, tìm thấy một file visual, và gợi ý chạy /create-spec để sinh spec chi tiết và bảng chia task (demo trong video đăng ngày 24/09/2025).

Brian mở lại thư mục spec để xem đã có gì (demo trong video đăng ngày 24/09/2025). Spec thật vẫn chưa được tạo, nhưng đã có thư mục planning. Bên trong là visual, tức wireframe của anh, và một file initialization rất đơn giản, ghi lại hướng đi đầu tiên của anh. Sau đó là file requirements.

Theo Brian (demo trong video đăng ngày 24/09/2025), file requirements đóng vai trò tham chiếu và biên bản cho cuộc trao đổi vừa rồi: từng câu agent hỏi, câu trả lời của anh, các câu hỏi tiếp theo. Nó tham chiếu một ít code sẵn có, có ghi chú về visual assets mà agent đã phân tích rồi tự ghi lại những gì nó thấy, một số visual insight, và các functional requirement.

Brian có thể đọc qua và kiểm tra lại xem các chi tiết có đúng không (theo video đăng ngày 24/09/2025). Anh có thể kiểm tra mình đã trả lời đúng ý chưa, có muốn nghĩ lại chi tiết nào trong cách design tính năng không, hay agent có hiểu đúng điều anh nói không, vì phần lớn nội dung ở đây là ghi chú bằng lời của agent chứ không phải lời anh. Anh nói mình sẽ đi qua và kiểm tra lại những điểm này.

Theo anh (video đăng ngày 24/09/2025), đây là nguyên liệu thô: phần quyết định chiến lược và design mà anh và agent cùng nhau đưa ra. Giờ nó nằm trong context, và cũng được ghi lại thành tài liệu trong thư mục. Nhờ vậy anh có thể chuyển sang tạo spec thật với độ tự tin cao hơn nhiều rằng nội dung spec sẽ đúng như anh muốn.

9. Vấn đề thứ hai: thiếu context về standards của bạn

Brian nói đây là nơi tay nghề của người build nằm ở thời điểm này (theo video đăng ngày 24/09/2025). Tất nhiên chúng ta biết code sẽ ráp với nhau ra sao, nhưng agent có thể build phần lớn chỗ đó. Giá trị chúng ta mang lại nằm ở design, gu, kinh nghiệm và sự hiểu khách hàng cần gì. Và theo anh, những điều đó diễn ra ở giai đoạn planning này.

Trong lúc sub-agent spec writer đang viết spec (demo trong video đăng ngày 24/09/2025), anh chuyển sang vấn đề lớn thứ hai: thiếu context về standards của bạn. Theo anh, muốn viết spec để agent build đúng ngay từ lần đầu, chúng ta cần mức chi tiết về cách code phải được viết. Chỉ bảo agent "build một app React" hay "build một app Rails" là không đủ.

Có vô số biến số, theo Brian (video đăng ngày 24/09/2025): tech stack, code style, các thư viện đang dùng, các pattern đã thiết lập, các component và layout bạn đã làm ra. Spec cần chỉ dẫn agent tuân theo tất cả những định hướng này. Ta không thể cứ cho rằng một lượt quét codebase nhanh của agent sẽ bắt được hết, và cũng không thể dạy lại agent ở mỗi tính năng mới, vì như vậy là quay lại cảnh prompt vòng vòng.

Agent OS cho bạn định nghĩa coding standards, các lựa chọn design và các pattern chung của mình một lần (theo Brian, video đăng ngày 24/09/2025). Nhờ vậy, khi spec được viết và code được implement, agent đã có sẵn kiến thức đó bên trong.

10. Spec verifier và file spec.md một trang

Spec đã gần xong (demo trong video đăng ngày 24/09/2025). Spec writer làm xong phần việc và chuyển tiếp cho spec verifier, sub-agent kiểm tra lại công việc của spec writer, bảo đảm mọi thứ chính xác, không sót chi tiết nào. Bước này cũng hoàn tất, và terminal liệt kê mọi thứ nó đã làm.

Giờ đã có file spec.md chính thức (demo trong video đăng ngày 24/09/2025). Brian kể rằng anh từng có một phiên bản phức tạp hơn nhiều, nhưng anh cố ý cho agent rút gọn lại chỉ còn một trang. Trong đó có mục tiêu (goal), vài user story, một số functional requirement và non-functional requirement.

Tiếp theo là ghi chú về visual design, tham chiếu tới hình anh đã cung cấp (demo trong video đăng ngày 24/09/2025). Spec cũng chỉ ra các component tái sử dụng đã có trong codebase để agent tận dụng chúng thay vì build lại cùng một thứ hai lần. Có thêm ghi chú về cách tiếp cận kỹ thuật.

Phần kỹ thuật này được cố ý viết không quá chi tiết, theo Brian (video đăng ngày 24/09/2025), vì anh vẫn muốn để coding agent và các sub-agent chuyên trách cho từng hạng mục tự làm phần việc của chúng, thay vì dắt chúng đi sai hướng ngay từ đầu. Đây là spec ở mức high-level, nhưng có độ chính xác cao.

Như anh chỉ ra (demo trong video đăng ngày 24/09/2025), giờ có nhiều lớp cùng hoạt động: phần hỏi đáp ban đầu để làm rõ và cân nhắc chi tiết; sau đó agent tạo specification, có tính tới các standards anh đã cài trong Agent OS; rồi verifier agent vào xem lại tất cả; và giờ anh tự mình đọc lại bằng con mắt của người.

11. Task list chia theo nhóm và sub-agent được gợi ý

Ngoài spec còn có file tasks (demo trong video đăng ngày 24/09/2025). Đây là task list sẽ được thực hiện khi bước vào giai đoạn implementation. Nó được chia thành các task group, mỗi nhóm có một task cha chính và một số subtask.

Theo Brian (demo trong video đăng ngày 24/09/2025), điều đáng chú ý là Agent OS gợi ý sub-agent nào làm phần nào. Ví dụ phần cập nhật database sẽ giao cho sub-agent database engineer. Xuống tới tầng API thì giao cho API engineer. Các task được gom thành nhóm để từng sub-agent có thể xử lý tương đối tách biệt, và theo anh điều này sẽ rất hữu ích ở giai đoạn implementation. Phần làm UI thì giao cho sub-agent UI designer.

Theo Brian (video đăng ngày 24/09/2025), Agent OS 2.0 khi dùng với Claude Code sẽ được xây dựng rất nhiều xoay quanh ý tưởng điều phối nhiều sub-agent, mỗi sub-agent nhận từng task group riêng khi tới giai đoạn implementation.

Tất nhiên anh vẫn có thể review các task này, kể cả việc agent định giao task cho sub-agent nào, và có thể chỉnh, đổi ngay tại chỗ (theo video đăng ngày 24/09/2025). Ví dụ tính năng này có thể được build hơi khác so với tính năng trước, hoặc anh làm project này hơi khác so với một project khác. Theo anh, Agent OS cho anh sự linh hoạt để tạo ra các loại sub-agent khác nhau và đưa chúng vào quy trình theo những cách khác nhau tuỳ project.

12. Vấn đề thứ ba: tooling không được quá cứng nhắc

Điều đó dẫn tới yếu tố thứ ba, mà Brian cho là quan trọng nhất khi nói tới việc áp dụng các tool AI và spec-driven development vào thực tế (theo video đăng ngày 24/09/2025): tooling không được quá cứng nhắc trong việc định nghĩa quy trình phát triển của chúng ta.

Lý do anh đưa ra (video đăng ngày 24/09/2025): ai cũng build theo cách riêng. Team của bạn có thể làm theo hướng API first, còn của anh có thể ưu tiên UI first. Bạn có thể có 30 engineer trong một phòng ban, trong khi một người khác làm ở startup với ba co-founder. Team của một người có thể có nhiều giai đoạn testing, còn team của người kia ưu tiên đưa sản phẩm tới khách hàng thật nhanh.

Ngay trong một sản phẩm, theo Brian (video đăng ngày 24/09/2025), mỗi tính năng có thể được build hơi khác nhau. Tính năng này có thể đụng nhiều tới API và database, tính năng sau tập trung vào UI, tính năng sau nữa có thể chỉ liên quan tới app mobile. Mỗi spec cần những sub-agent khác nhau và một tổ hợp giai đoạn khác nhau trong quy trình phát triển.

Nếu tooling của bạn gây ma sát khi bạn hay team chuyển qua lại giữa các tính năng, các sản phẩm khác nhau, theo Brian (video đăng ngày 24/09/2025), điều đó có thể ngăn việc áp dụng spec-driven development một cách trọn vẹn. Khi đó bạn sẽ bỏ lỡ lợi ích và đòn bẩy mà phát triển AI-first mang lại.

Vì vậy, khi thiết kế phiên bản Agent OS mới tại thời điểm video, một trong các mục tiêu của Brian là làm nó thích ứng được theo mức mà quy trình phát triển của bạn đòi hỏi (theo video đăng ngày 24/09/2025). Nó dùng sub-agent và cơ chế điều phối mà bạn kiểm soát được khi chuyển từ spec này sang spec khác.