Triết lý Development-Driven Specs thay cho Spec-Driven Development

Phát triển và đặc tả song song: cách Bill Cox xây dựng coding agent

Bill Cox giới thiệu Ensemble, một coding agent (tác nhân lập trình) được xây dựng từ cuốn sách The Art of Building AI Coding Agents — một cuốn sách giảng dạy dạng thực thi của chính ông. Ấn bản 3 là ấn bản hiện hành: ứng dụng viết bằng C# 14 / .NET 10, được phát triển ngay bên trong Ensemble với Cadence.

Điểm cốt lõi của dự án là triết lý Development-Driven Specifications (đặc tả dẫn dắt bởi phát triển), đối lập với Spec-Driven Development (phát triển dẫn dắt bởi đặc tả) phổ biến hiện nay.

Xây mã và đặc tả cùng lúc

Theo Bill, mục tiêu không phải là viết một kế hoạch chi tiết từ đầu rồi giao cho AI, cũng không phải "vibe-code" một hệ thống rồi viết tài liệu cho mã nguồn sau đó. Mục tiêu là trở thành chuyên gia thông qua việc pair-programming (lập trình cặp) với AI, rồi lưu giữ chuyên môn đó ở dạng một tác nhân khác có thể thực thi được.

Quy trình cụ thể của Bill gồm các bước:

• Thảo luận thiết kế, sau đó chỉ phác thảo phần TL;DR và bài tập của chương tiếp theo.
• Pair-programming phần triển khai: điều hướng AI theo thời gian thực, thử ý tưởng, sửa lỗi, ghi lại những điểm chưa rõ và lý do của từng quyết định quan trọng.
• Khi phần triển khai vượt qua bộ chấm điểm bài tập, dùng ghi chú đó để viết phần thân chương: quá trình xây dựng, bài học, đánh đổi và lý do — chứ không phải một tour tham quan mã nguồn đã hoàn thiện.
• Giao chương và bộ chấm điểm cho một tác nhân "học viên" hoàn toàn mới, để kiểm tra liệu nội dung giảng dạy có đủ để tái dựng phần triển khai hay không. Những gì lần thử đó bộc lộ sẽ được đưa ngược trở lại chương.

Kết quả là một executable specification (đặc tả thực thi được): một "codebook" truyền tải phán đoán cần thiết để xây dựng hệ thống, chứ không chỉ là danh sách tính năng mong muốn. Chính Ensemble V2 đã thực thi cuốn sách này để xây dựng V3; sau đó Bill và Cadence làm việc bên trong V3 để cải thiện cả tác nhân lẫn nội dung giảng dạy. Mỗi chương vẫn giữ nguyên những giới hạn kiểm chứng đã được ghi lại.

Chuyên môn của con người là tài sản thực sự

Điểm mạnh của cách làm này là chuyên môn của con người lớn dần trong quá trình phát triển, thay vì phụ thuộc vào lần kiểm tra cuối cùng đối với mã sinh ra mà mình không quen thuộc. Mã chỉ là sản phẩm đầu ra; tài sản tái sử dụng được chính là kiến thức cần thiết để xây dựng lại nó.

Đừng chỉ ghi lại cần xây cái gì. Hãy dạy cách xây và vì sao phải xây theo cách đó. Bạn không thể học hết những điều đó ngay từ đầu.

Cách xây và chạy

Dự án yêu cầu một .NET 10 SDK có sẵn (chỉ riêng runtime thì không thể build ứng dụng). Không có gì trong kho mã tự cài SDK, đọc thông tin xác thực khi build, tự khởi động server hay thay thế ứng dụng đã cài.

Trước tiên cần kiểm tra shell có tìm thấy SDK hay không:

dotnet --list-sdks           # nên có SDK phiên bản 10.x

Nếu không tìm thấy dotnet, hoặc make báo lỗi dotnet: No such file or directory, thì quá trình build chưa tới bước biên dịch: file thực thi SDK không có trong PATH. Có thể thêm thư mục SDK vào PATH hoặc truyền đường dẫn đầy đủ cho Make qua biến DOTNET.

Khi dotnet đã có trong PATH, các lệnh chính gồm:

• make — build GUI C# và tạo launcher ./ensemble
• make cli — build client dòng lệnh C#
• ./ensemble --help — khởi chạy tường minh và xem các tùy chọn trước khi dùng
• make test — chạy bộ kiểm thử hồi quy C# và các test Go ở thư mục gốc

Go vẫn được giữ ở thư mục gốc cho các bộ chấm điểm tái sử dụng, nhà cung cấp giả lập cục bộ và công cụ xuất bản — không còn là runtime đang hoạt động.

Chấm điểm và xuất bản sách

Mỗi chương có lệnh thực thi và phạm vi được ghi tài liệu riêng. Lưu ý rằng mã C# không được đưa cho bộ chấm điểm dành cho mã nguồn Go. Ví dụ, chương 5 ghi lại lộ trình grade-edition3 -ch 5 -executable-only với 65 điểm trong phạm vi.

Để build sách: make book lắp ghép bản thảo hiện tại, make ebook tạo EPUB, make print tạo PDF cho in và đọc. Các lệnh này dùng công cụ xuất bản có sẵn cục bộ, không bao giờ tự cài đặt. Ấn bản 1 và 2 được lưu trữ đóng băng trong các thư mục edition-1/ và edition-2/, không bị viết lại theo bố cục hiện tại.

Ngoài ra còn có Puffin book, nơi làm việc cho Gateway, Connections, Agenda, Puffin và các công việc liên quan tới Watchtower/bảo mật. Ghi chú ở đây cũng theo Development-Driven Specs; các đề cương vẫn là tạm thời, chưa phải tính năng hoàn chỉnh.

Góc nhìn

Với các kỹ sư và nhóm phát triển Việt Nam đang đưa AI vào quy trình làm việc, cách tiếp cận này đáng để cân nhắc. Rất nhiều nhóm hiện đang dùng mô hình ngược: viết đặc tả kỹ rồi để AI sinh mã, hoặc để AI viết mã trước rồi mới bổ sung tài liệu. Cả hai đều dễ khiến con người đánh mất hiểu biết về hệ thống mà mình đang vận hành — đặc biệt khi mã do AI sinh ngày càng nhiều.

Điều đáng học ở đây là việc ghi chép lý do đằng sau các quyết định, và kiểm tra lại tài liệu bằng cách để một tác nhân khác tái dựng từ đó. Với những nhóm phải bàn giao hệ thống hoặc onboarding người mới liên tục, một "đặc tả thực thi được" như vậy hữu ích hơn nhiều so với tài liệu mô tả bề mặt tính năng. Tuy nhiên, cách làm này đòi hỏi người kỹ sư thực sự tham gia điều hướng AI trong suốt quá trình, chứ không thể chỉ đặt hàng một kế hoạch rồi chờ kết quả.