Từ "Vibe Coding" đến phát triển dựa trên đặc tả: Hành trình 4.5 giờ xây dựng ứng dụng Fitness với AI Agent

Trong kỷ nguyên AI hiện nay, các kỹ sư chuyên nghiệp đang dần chuyển dịch từ khái niệm "vibe coding" (lập trình theo cảm hứng) sang một phương pháp chặt chẽ hơn: Phát triển dựa trên đặc tả (Spec-Driven Development). Thậm chí, Andrej Karpathy - người đã đặt ra thuật ngữ "vibe coding" - cũng thừa nhận rằng kỷ nguyên này đang kết thúc để nhường chỗ cho Kỹ thuật tác nhân (Agentic Engineering), nơi con người đóng vai trò giám sát các tác nhân AI làm việc dựa trên các đặc tả chi tiết.

Agentic Engineering Workflow

Vậy làm thế nào để áp dụng quy trình này vào thực tế? Trong bài viết này, chúng tôi sẽ cùng trải qua hành trình xây dựng một ứng dụng web theo dõifitness từ ý tưởng đến thành phẩm trong vòng 4,5 giờ.

Vibe Coding vs. Spec-Driven Development

Đa số chúng ta đều đã từng thử "vibe coding": viết một yêu cầu ngắn gọn cho AI (ví dụ: "Thêm biểu đồ DAU vào ứng dụng của tôi"), chờ mã nguồn được tạo ra, chạy thử và xem kết quả. Nếu không vừa ý, ta lại yêu cầu AI chỉnh sửa. Quá trình này lặp đi lặp lại.

Phương pháp này hoạt động tốt cho các dự án nhỏ, nhưng gặp nhiều rắc rối khi mở rộng quy mô. Nhược điểm lớn nhất là thiếu các tiêu chuẩn thực hành tốt (best practices) và quy ước chung, dẫn đến mã nguồn lộn xộn. Hơn nữa, các tác nhân AI thường không lưu vết lý do đằng sau các quyết định mã hóa, gây ra tình trạng "hỏng" không rõ nguyên căn sau các bản cập nhật.

Spec-Driven Development (SDD) giải quyết vấn đề này bằng cách áp dụng tư duy kỹ thuật truyền thống. Thay vì nhảy thẳng vào viết mã, chúng ta bắt đầu bằng việc tư duy sâu sắc: đưa ra quyết định kiến trúc, định nghĩa yêu cầu và ghi chép chúng vào một đặc tả (specification) có cấu trúc, lưu trữ trực tiếp trong kho chứa mã nguồn (repository). Điều này tách biệt rõ ràng giữa đặc tả (cái ta xây dựng và tại sao) và việc triển khai (mã nguồn thực tế).

Quy trình SDD

Một quy trình SDD tiêu chuẩn thường bao gồm các giai đoạn sau:

1. Định nghĩa Hiến pháp (Constitution): Đây là bộ tài liệu thỏa thuận về các quyết định cốt lõi của dự án, bao gồm:
   • Mission (Sứ mệnh): Tại sao chúng ta xây dựng dự án này và mục tiêu chính là gì?
   • Tech Stack (Ngôn ngữ/Công nghệ): Các quyết định kỹ thuật, quy trình triển khai.
   • Roadmap (Lộ trình): Các giai đoạn dự án, tính năng kế hoạch.
2. Phát triển tính năng: Hiểu yêu cầu -> Viết đặc tả chi tiết -> Triển khai thay đổi -> Kiểm thử.
3. Quy hoạch lại (Replanning): Dừng lại để xem lại Hiến pháp và các quyết định trước đó, đảm bảo chúng vẫn phù hợp với mục tiêu dự án.

Thực tế: Xây dựng ứng dụng Trainlytics

Để kiểm chứng quy trình SDD, tôi quyết định xây dựng Trainlytics - một ứng dụng web cá nhân để theo dõi chạy bộ và tập tạ nhằm chuẩn bị cho giải marathon sắp tới. Mục tiêu là tạo ra một công cụ linh hoạt hơn các ứng dụngfitness hiện có.

Công cụ tôi sử dụng là Visual Studio Code kết hợp với plugin Claude Code. SDD có lợi thế lớn là không phụ thuộc vào loại LLM hay IDE cụ thể nào.

Bước 1: Tạo Constitution

Thay vì viết tay, tôi sử dụng LLM để tổng hợp bộ tài liệu "Constitution" dựa trên tầm nhìn sản phẩm ban đầu. Sau một vài câu hỏi làm rõ, tác nhân AI đã tạo ra các tệp mission.md, tech-stack.md và roadmap.md.

Spec Documents Structure

Tuy nhiên, trước khi để AI viết mã, tôi dành thời gian xem xét và tinh chỉnh các tài liệu này. Ví dụ, tôi nhận ra cần thêm tính năng xác thực (authentication) để có thể đăng nhập từ cả máy tính và điện thoại. Việc chỉnh sửa đặc tả lúc này giúp tiết kiệm hàng giờ sửa mã sau này.

Bước 2: Giai đoạn tính năng đầu tiên (MVP)

Theo lộ trình, chúng tôi bắt đầu với tính năng cốt lõi: Ghi nhật ký hoạt động. Quy trình là Plan (Lập kế hoạch) -> Implement (Triển khai) -> Validate (Kiểm chứng).

Tôi yêu cầu tác nhân AI tạo ra các tệp đặc tả cho tính năng này (plan.md, requirements.md, validation.md). Sau khi xem xét, tôi để AI triển khai từng nhóm nhiệm vụ một cách tuần tự.

App Interface

Khi mã nguồn sẵn sàng, tôi chạy ứng dụng cục bộ và kiểm tra thủ công. Sau vài lần lặp lại với agent để sửa lỗi nhỏ, ứng dụng đã hoạt động trơn tru, cho phép ghi nhận cả buổi chạy bộ và tập tạ.

Bước 3: Replanning (Quy hoạch lại)

Với một ứng dụng đã chạy được, nhiều người sẽ tiếp tục xây thêm tính năng ngay lập tức. Tuy nhiên, trong SDD, đây là lúc quan trọng nhất để dừng lại và suy nghĩ. Tôi nhận thấy mình cần các mẫu bài tập (templates) để tiết kiệm thời gian nhập liệu hơn là các tính năng phức tạp khác.

Tôi yêu cầu AI cập nhật roadmap.md và điều chỉnh ưu tiên:

1. Mẫu buổi tập Strength (Strength session templates).
2. Cải tiến giao diện UI.
3. Phân tích cơ bản (Basic analytics).

Tự động hóa và Spec Kit

Quy trình trên hoàn toàn có thể tự động hóa. Một công cụ nổi tiếng hỗ trợ SDD là Spec Kit của GitHub. Nó giúp tích hợp quy trình này trực tiếp vào môi trường làm việc với các lệnh slash command.

Spec Kit tập trung vào các vấn đề cao cấp như chất lượng mã, tiêu chuẩn kiểm thử và tính nhất quán của UX. Sau khi cài đặt, tôi đã chạy qua hai giai đoạn phát triển với Spec Kit và quy trình hoạt động rất mượt mà.

Kết luận

Tổng cộng, tôi đã mất khoảng 4,5 giờ để xây dựng một sản phẩm hoàn chỉnh từ đầu đến cuối. Kết quả thật sự đáng khích lệ. Quy trình SDD không chỉ giúp tôi viết code nhanh hơn nhờ AI mà còn đảm bảo chất lượng và tính nhất quán của dự án.

Review Process

Nếu bạn chỉ cần sửa đổi nhỏ hoặc chạy phân tích nhanh, việc viết đặc tả chi tiết có thể là quá mức cần thiết. Nhưng đối với các dự án lớn hơn, đặc biệt là khi làm việc nhóm, Spec-Driven Development chắc chắn là phương pháp tôi sẽ ưu tiên sử dụng.

Vai trò của kỹ sư đang thay đổi: từ người viết mã trực tiếp sang người tập trung vào quyết định kiến trúc, xem xét (review) và thiết kế hệ thống. Chúng ta đang dần bước đến một thế giới mà Tiếng Anh (hoặc ngôn ngữ tự nhiên) trở thành giao diện lập trình chính.