Mục lục
“Vibe Coding” và Những Thách Thức Đầu Tiên của Lập Trình Hỗ Trợ AI
Sự Trỗi Dậy của “Vibe Coding”
Kể từ khi thuật ngữ “Vibe Coding” xuất hiện vào đầu năm 2025 – được đặt ra bởi Andrej Karpathy vào ngày 2 tháng 2 – các nhà phát triển đã có thể tạo ra các ứng dụng hoàn chỉnh thông qua các công cụ lập trình hỗ trợ bởi trí tuệ nhân tạo (AI). Con số này thực sự đáng kinh ngạc: 25% các startup thuộc khóa Winter 2025 của Y Combinator có cơ sở mã nguồn được tạo ra tới 95% bởi AI. Ban đầu, đã có một sự bùng nổ trong việc tạo ứng dụng chỉ bằng cách gõ các prompt cơ bản vào cửa sổ chat. Mặc dù kết quả trông rất ấn tượng – dù thường khá chung chung và được xây dựng trên cùng các thư viện UI – các nhà phát triển dần cảm thấy thất vọng theo thời gian.
Khi Lời Hứa Gặp Thực Tế: Vấn Đề Chất Lượng Mã Nguồn
Các mô hình ngôn ngữ lớn (LLM) vượt trội trong việc tạo nội dung mới, nhưng chúng thường gặp phải hạn chế về chất lượng mã nguồn, lựa chọn kiến trúc, các mẫu API và tiêu chuẩn bảo mật. Điều này không phải vì LLM thiếu khả năng so với các nhà phát triển chuyên nghiệp, mà là do các nhà phát triển gặp khó khăn trong việc định nghĩa chính xác những gì họ muốn trong các prompt của mình, cách LLM nên đạt được mục tiêu, và cách kết quả nên được xác thực. Hóa ra, mặc dù các nhà phát triển rất hiệu quả trong việc viết mã, họ thường thất bại trong việc diễn đạt chính xác những gì họ muốn bằng văn bản thuần túy. Đây là một vấn đề cốt lõi mà các phương pháp phát triển mới cần giải quyết.
Từ TDD Đến User Stories: Bài Học Cho Kỷ Nguyên AI
Test Driven Development (TDD) – Một Góc Nhìn Cá Nhân
Khi bắt đầu học phát triển phần mềm vào năm 2012, tôi đã làm quen với Test Driven Development (TDD), nơi các nhà phát triển định nghĩa các bài kiểm tra với kết quả mong đợi trước khi viết mã thực tế. Tôi chưa bao giờ hoàn toàn áp dụng kỹ thuật này trong công việc phát triển của mình, mặc dù tôi hiểu giá trị của nó. Tôi thấy nó không thực tế cho công việc hàng ngày, bởi vì đối với tôi, viết phần mềm là một quá trình sáng tạo, phát triển theo thời gian. Mặc dù tôi cân nhắc kiến trúc và các mẫu thiết kế trước khi bắt đầu, tôi thường bắt đầu viết mã và tái cấu trúc sau khi đã triển khai tính năng được yêu cầu. Viết các bài kiểm tra trước chắc chắn sẽ giúp tạo ra mã nguồn có cấu trúc tốt hơn ngay từ đầu, nhưng nó cũng làm chậm quá trình sáng tạo.
Tầm Quan Trọng của Đặc Tả Người Dùng Chi Tiết
Tuy nhiên, tôi từng làm việc cho một công ty phát triển một sản phẩm phức tạp, nơi tôi học được tầm quan trọng của việc định nghĩa các user story một cách chính xác, bao gồm cả personas và các tiêu chí chấp nhận. Tôi thường thấy rằng các user story không phản ánh đầy đủ những gì chủ sản phẩm muốn tôi triển khai, dẫn đến nhiều vòng lặp viết mã, phản hồi từ QA và điều chỉnh. Những bài học từ quá khứ này, cùng với những thách thức hiện tại với các công cụ lập trình hỗ trợ AI, đã mở ra một mô hình đầy hứa hẹn. Mô hình này kết hợp các khái niệm của TDD và các user story được định nghĩa rõ ràng, đồng thời vẫn cho phép sự sáng tạo trong lập trình – với các công cụ AI đảm nhận phần việc nặng nhọc.
Spec Driven Development (SDD): Định Hình Tương Lai Lập Trình
SDD Là Gì và Tại Sao Nó Lại Quan Trọng?
Khi chúng ta xem xét ý nghĩa thực sự của “Vibe Coding”, chúng ta nhận ra nó cho phép chúng ta quên đi sự tồn tại của mã nguồn. Ý tưởng chính rất đơn giản: thay vì định nghĩa mục tiêu bằng mã, chúng ta diễn đạt chúng bằng ngôn ngữ tự nhiên, thuần túy. Nhờ LLM, ngay cả những người không có kiến thức kỹ thuật sâu cũng có thể biến ý tưởng của họ thành hiện thực. Tuy nhiên, phương pháp này thường chỉ hoạt động hiệu quả cho các bản prototype. Mã nguồn sẵn sàng cho sản xuất không chỉ cần trông đẹp mắt – nó cần phải không có lỗi, có kiến trúc vững chắc, an toàn và đầy đủ chức năng. Để đạt được điều này, các nhà phát triển phải định nghĩa các hướng dẫn tùy chỉnh với các quy tắc khác nhau, thêm máy chủ MCP (Multi-Context Protocol) và viết các prompt chính xác cung cấp “rào chắn” rõ ràng cho LLM. Đáng tiếc, các nhà phát triển thường đánh giá thấp nỗ lực cần thiết cho việc thiết lập và prompt engineering này.
Đây chính là lúc Spec Driven Development (SDD) phát huy tác dụng. Thay vì viết mã trước rồi mới tài liệu hóa sau, SDD bắt đầu bằng việc định nghĩa một đặc tả. Đặc tả này đóng vai trò như một hợp đồng về cách mã nguồn của bạn phải hoạt động và trở thành nguồn sự thật mà các công cụ và tác nhân AI của bạn sử dụng để tạo, kiểm tra và xác thực mã. Kết quả là giảm thiểu phỏng đoán, ít bất ngờ hơn và mã nguồn chất lượng cao hơn.
Lợi Ích Vượt Trội của SDD
- Nâng cao chất lượng mã nguồn: Bằng cách định nghĩa rõ ràng yêu cầu trước, SDD giúp AI tạo ra mã nguồn chính xác, ít lỗi hơn.
- Cải thiện kiến trúc: Đặc tả chi tiết giúp AI xây dựng kiến trúc vững chắc, dễ bảo trì.
- Tăng cường bảo mật: Các tiêu chuẩn bảo mật được tích hợp ngay từ đầu trong đặc tả.
- Giảm thiểu lỗi và phỏng đoán: Quy trình rõ ràng giúp loại bỏ sự mơ hồ trong quá trình phát triển.
- Tăng tính nhất quán: Mã nguồn được tạo ra theo một khuôn khổ thống nhất.
- Tăng tốc độ phát triển: AI xử lý các tác vụ lặp lại, giải phóng nhà phát triển tập trung vào việc xác minh và tinh chỉnh.
Bốn Giai Đoạn Vàng của Spec Driven Development
SDD chia quá trình phát triển thành bốn giai đoạn riêng biệt, mỗi giai đoạn có các mục tiêu và kết quả cụ thể. Trong suốt các giai đoạn này, chúng ta dựa vào công cụ lập trình AI đã chọn để được hỗ trợ. Trách nhiệm của chúng ta là diễn đạt mục tiêu bằng ngôn ngữ tự nhiên. Mã nguồn cuối cùng được tạo ra chỉ là sản phẩm của những đặc tả rõ ràng này.
1. Đặc Tả (Specify): Định Hình “Cái Gì”
Trong giai đoạn này, bạn cung cấp một mô tả cấp cao về những gì bạn đang xây dựng và lý do tại sao, sau đó tác nhân lập trình (coding agent) sẽ tạo ra một đặc tả chi tiết. Đây không phải là về các ngăn xếp công nghệ hay thiết kế ứng dụng – đó là về hành trình người dùng, trải nghiệm và tiêu chí thành công. Bạn sẽ định nghĩa ai sẽ sử dụng sản phẩm của bạn, vấn đề nó giải quyết cho họ là gì, cách họ sẽ tương tác với nó và kết quả nào là quan trọng nhất. Hãy coi đây là việc lập bản đồ trải nghiệm người dùng mong muốn trong khi để tác nhân lập trình xây dựng chi tiết. Đặc tả này trở thành một tài liệu sống, phát triển khi bạn có được những hiểu biết sâu sắc hơn về người dùng và nhu cầu của họ.
2. Lập Kế Hoạch (Plan): Phác Thảo “Làm Thế Nào”
Giai đoạn này là lúc bạn bắt đầu đi sâu vào kỹ thuật. Bạn sẽ cung cấp cho tác nhân lập trình ngăn xếp công nghệ, kiến trúc và các ràng buộc mong muốn của bạn, và nó sẽ tạo ra một kế hoạch kỹ thuật toàn diện. Nếu công ty của bạn có các công nghệ được chuẩn hóa, hãy chỉ định chúng ở đây. Nêu chi tiết bất kỳ tích hợp nào với các hệ thống cũ, yêu cầu tuân thủ hoặc mục tiêu hiệu suất bạn cần đạt được. Bạn cũng có thể yêu cầu nhiều biến thể kế hoạch để so sánh các phương pháp khác nhau. Bằng cách cung cấp tài liệu nội bộ của bạn cho tác nhân lập trình, nó có thể trực tiếp tích hợp các mẫu kiến trúc và tiêu chuẩn của bạn vào kế hoạch. Hãy coi đây là việc đặt ra các quy tắc trước khi trò chơi bắt đầu – tác nhân lập trình cần hiểu các thông số trước khi nó có thể bắt đầu hoạt động hiệu quả.
3. Phân Công Nhiệm Vụ (Tasks): Chia Nhỏ Công Việc
Tác nhân lập trình biến đặc tả và kế hoạch thành các công việc có thể thực hiện được bằng cách tạo ra các phân đoạn nhỏ, có thể xem xét được, mỗi phân đoạn giải quyết một thành phần cụ thể. Mỗi nhiệm vụ phải có thể thực hiện và kiểm tra độc lập – cách tiếp cận này cho phép tác nhân lập trình xác thực công việc của mình và duy trì sự tập trung, tương tự như quy trình phát triển dựa trên kiểm thử. Thay vì các chỉ thị rộng lớn như “xây dựng xác thực”, bạn nhận được các nhiệm vụ chính xác như “tạo một endpoint đăng ký người dùng xác thực định dạng email”.
4. Thực Thi (Implement): Biến Kế Hoạch Thành Mã Nguồn
Tác nhân lập trình thực hiện các nhiệm vụ tuần tự hoặc song song tùy theo thích hợp. Sự khác biệt chính ở đây là thay vì xem xét các khối mã khổng lồ, bạn – nhà phát triển – đánh giá các thay đổi tập trung, cụ thể, giải quyết các vấn đề riêng biệt. Tác nhân lập trình có hướng dẫn rõ ràng: đặc tả định nghĩa cái gì cần xây dựng, kế hoạch phác thảo cách xây dựng, và nhiệm vụ chỉ rõ chính xác công việc cần làm.
Vai Trò Không Thể Thiếu Của Nhà Phát Triển
Điều quan trọng là vai trò của bạn không chỉ dừng lại ở việc chỉ đạo – bạn phải xác minh. Ở mỗi giai đoạn, hãy suy nghĩ và tinh chỉnh. Liệu đặc tả có thực sự nắm bắt được sản phẩm bạn định xây dựng? Liệu kế hoạch có giải quyết được các ràng buộc trong thế giới thực? Liệu AI có bỏ sót bất kỳ trường hợp ngoại lệ hoặc thiếu sót nào không? Quá trình này bao gồm các điểm kiểm tra có chủ đích, nơi bạn đánh giá những gì đã được tạo ra, xác định các khoảng trống và điều chỉnh hướng đi trước khi tiếp tục. Trong khi AI tạo ra các hiện vật, bạn đảm bảo tính chính xác và phù hợp của chúng.
GitHub Spec Kit: Công Cụ Hỗ Trợ Đắc Lực Cho SDD
Giới Thiệu GitHub Spec Kit
Vì việc tuân theo SDD đòi hỏi việc định nghĩa một lượng lớn văn bản mô tả – bao gồm các đặc tả, chi tiết ngăn xếp công nghệ, các trường hợp kiểm thử, v.v. – GitHub đã phát hành một CLI mã nguồn mở có tên là Spec Kit để đơn giản hóa việc tạo các tệp cần thiết. Được phát hành vào ngày 2 tháng 9 năm 2025, Spec Kit hiện đang ở phiên bản 0.0.30+ và tiếp tục phát triển nhanh chóng với các bản cập nhật thường xuyên và đóng góp từ cộng đồng.
Hướng Dẫn Cài Đặt Spec Kit
Spec Kit có thể được cài đặt theo hai cách khác nhau. Phương pháp đầu tiên sử dụng `uvx`, một trình quản lý gói Python hoạt động giống như `npm` với `npx`. Tôi khuyên bạn nên cài đặt `uvx` thông qua Homebrew.
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
Lệnh này tạo một thư mục mới với tên đã định nghĩa. Sau đó, bạn sẽ xác nhận trợ lý lập trình AI nào bạn muốn sử dụng. Hiện tại, bạn không thể chuyển đổi giữa các công cụ đã chọn sau khi khởi tạo.
Nếu bạn muốn tạo các tệp trong một dự án hiện có, bạn có thể truyền cờ `–here`.
Phương pháp cài đặt thay thế: Bạn có thể tải xuống các gói mẫu dành riêng cho nền tảng mà không cần sử dụng CLI. Chúng có sẵn trên trang phát hành trong cả biến thể POSIX shell (sh) và PowerShell (ps).
Ảnh: Giao diện khởi tạo dự án với Spec Kit
Cấu Trúc Dự Án Với Spec Kit
Dựa trên công cụ bạn đã chọn, Spec Kit tạo ra các tệp khác nhau trong các thư mục cụ thể. Hiểu cấu trúc này là rất quan trọng để triển khai hiệu quả.
Ảnh: Tổng quan về các tệp được tạo bởi Spec Kit
Prompt Files
Thư mục `prompt` chứa các prompt có thể tái sử dụng, có thể được thực thi thông qua GitHub Copilot. Các prompt này bao gồm các hướng dẫn mà GitHub Copilot nên tuân theo. Chúng ta sẽ sử dụng các prompt này để tạo đặc tả ban đầu, kế hoạch triển khai kỹ thuật và cuối cùng là các nhiệm vụ chúng ta có thể thực hiện từng bước. Cách tiếp cận này đơn giản hóa việc tuân thủ các hướng dẫn của Spec Driven Development, vì nhóm GitHub đã định nghĩa chính xác những gì tác nhân AI phải làm, đảm bảo nó tuân thủ các rào chắn đã thiết lập.
Memory Directory
Thư mục `memory/` chứa `constitution.md`, định nghĩa các nguyên tắc của bạn như kiến trúc ưu tiên, các mẫu lộ diện API, cách tiếp cận TDD, thư viện, công nghệ và tiêu chuẩn viết mã. Bạn nên điền chi tiết tệp này trước khi chạy bất kỳ prompt nào. Công cụ lập trình AI của bạn có thể giúp ích trong quá trình này. Tôi khuyên bạn nên sử dụng `context7 MCP` hoặc một máy chủ tài liệu `MCP` khác để truy xuất các hướng dẫn về phong cách mới nhất cho framework của bạn. Để có kết quả tốt nhất, hãy sử dụng các LLM tiên tiến nhất hiện có, chẳng hạn như Sonnet 4 hoặc GPT-4.
Fill out the project constitution for a modern Angular web application. Ensure it follows Domain-Driven Design, uses TypeScript with Angular Material and SCSS, is built with TDD principles, adheres to Clean Code practices, and complies with the latest Angular Style Guides. #context7 #angular-cli #file:constitution.md
Scripts Directory
Thư mục `scripts/` chứa các tập lệnh shell được tác nhân lập trình thực thi để giúp nó hiểu các đặc tả, tạo nhánh và tạo các tệp cần thiết khác. Bạn không nên sửa đổi các tệp này theo cách thủ công, vì chúng là một phần không thể thiếu của quy trình tự động hóa SDD.
Templates Directory
Thư mục `templates/` chứa các mẫu markdown cho các tệp mà tác nhân lập trình sẽ tạo ra sau này. Chúng đảm bảo định dạng nhất quán trên tất cả các đặc tả, kế hoạch và nhiệm vụ được tạo ra. Bạn nên tránh sửa đổi các tệp này theo cách thủ công.
Tích Hợp Công Cụ AI
Các công cụ AI khác nhau sử dụng các tệp hướng dẫn khác nhau:
- GitHub Copilot:
.github/copilot-instructions.md - Cursor:
.cursorrulesfiles - Claude:
CLAUDE.md - Gemini:
GEMINI.md
Cải tiến trong v0.0.30+: Hệ thống mẫu hiện bao gồm các biến thể dành riêng cho nền tảng (POSIX shell và PowerShell) để tương thích đa nền tảng, cùng với xác thực toàn diện để đảm bảo các tệp hướng dẫn được cấu hình đúng cách.
SDD Trên Thực Tế: Ví Dụ Với GitHub Spec Kit
Tạo Đặc Tả Đầu Tiên (Specify)
Sau khi định nghĩa bản “hiến pháp” (`constitution`), đã đến lúc tạo đặc tả đầu tiên của bạn. Bước khởi đầu này rất quan trọng để định nghĩa mục tiêu của ứng dụng. Hãy càng cụ thể càng tốt. Bạn cũng có thể sử dụng AI yêu thích của mình để nâng cao mô tả. Tập trung vào trải nghiệm người dùng hơn là các chi tiết kỹ thuật.
Để sử dụng chức năng `specify`, hãy thực thi lệnh thông qua công cụ AI bạn đã chọn. Trong trường hợp của GitHub Copilot, điều này liên quan đến việc sử dụng lệnh `/specify`:
/specify NG Pokedex is an application designed for Pokémon fans who want a simple and engaging way to discover and explore their favorite creatures. The app focuses on making the search and discovery process intuitive: users can quickly look up a Pokémon by name or browse by type, such as Fire or Water. Each Pokémon entry presents the essentials—its name, image, and key stats—so users can immediately recognize and compare them.
When users want to dive deeper, they can click on a Pokémon to open a detail view that provides richer information in a focused and easy-to-read format. To personalize the experience, users can mark their favorite Pokémon and curate their own collection, which can be updated at any time by toggling a star icon.
The experience is designed to be seamless across devices—desktop, tablet, and mobile—so users can enjoy discovering and managing their Pokémon wherever they are. Success for this application means that users feel empowered to explore the Pokémon world effortlessly, stay engaged through personalization features like favorites, and return to the app because it makes their interactions simple, fun, and rewarding.
Chạy prompt này sẽ tạo tệp đặc tả đầu tiên của bạn và một nhánh mới. Với mỗi đặc tả, tác nhân sẽ tạo một nhánh riêng để làm việc – trong ví dụ của tôi, `001-ng-pokedex-is`. Quá trình này có thể mất vài phút, vì tác nhân lập trình gọi nhiều script, tạo tệp và tạo user stories, yêu cầu cũng như các thực thể chính. Tác nhân đảm bảo nó tuân thủ tất cả các hướng dẫn được định nghĩa bởi Spec Kit CLI.
Mở tệp `spec.md` đã tạo và cuộn qua nó. Ở cuối tệp, tác nhân xác thực các yêu cầu sau:
### Content Quality
- [x] No implementation details (languages, frameworks, APIs)
- [x] Focused on user value and business needs
- [x] Written for non-technical stakeholders
- [x] All mandatory sections completed
### Requirement Completeness
- [x] No [NEEDS CLARIFICATION] markers remain
- [x] Requirements are testable and unambiguous
- [x] Success criteria are measurable
- [x] Scope is clearly bounded
- [x] Dependencies and assumptions identified
Nếu bất kỳ hộp kiểm nào vẫn chưa được chọn, bạn nên chạy lại lệnh `specify` với thông tin chi tiết hơn hoặc tự hoàn thành tài liệu. Điều quan trọng là phải xác thực rằng các story và yêu cầu được định nghĩa phù hợp với tầm nhìn của bạn cho ứng dụng hoặc tính năng. Ví dụ, các trường hợp ngoại lệ (edge cases) cần được định nghĩa thủ công vì tác nhân không tự động chỉ định chúng.
### Edge Cases
- What happens when no Pokémon match a search query? The system MUST display a user-friendly message indicating no results were found and suggest alternative actions (e.g., broadening the search criteria).
- How does the system handle when a user tries to access detailed information for a Pokémon that doesn't exist? The system MUST display a 404 error page with a friendly message and a link back to the main page.
- What occurs when the user has no favorited Pokémon yet? The system MUST display a message indicating that the favorites list is empty and suggest Pokémon to explore.
Xây Dựng Kế Hoạch Kỹ Thuật (Plan)
Sau khi hoàn thiện đặc tả phi kỹ thuật, đã đến lúc tạo kế hoạch kỹ thuật để triển khai. Theo kinh nghiệm của tôi, bạn có thể tối ưu hóa quy trình này bằng cách thiết lập cấu trúc ứng dụng mặc định ngay từ đầu thay vì dựa vào tác nhân lập trình để làm điều đó. Tôi đề xuất sử dụng `context7 MCP` một lần nữa để đảm bảo bạn tuân thủ các hướng dẫn thiết lập dự án mới nhất. Trong trường hợp của tôi, tôi cũng sẽ kết hợp máy chủ `Angular CLI MCP` để tạo dự án Angular. Hãy chuẩn bị tinh thần rằng prompt này có thể mất vài phút để hoàn thành.
/plan The application will be developed using Angular 20 together with Angular Material, following the guidelines of Material Design v3. There is no backend; instead, all Pokémon data will be retrieved directly from the PokeAPI V2. The list of favorites will be stored in the browser’s local storage, which means the data is tied to the user’s device and will be reloaded whenever the page is refreshed. Testing will be carried out with Jasmine and Karma, both of which are included in the standard Angular CLI setup. No other third-party libraries will be introduced, apart from those provided by the Angular CLI project and Angular Material itself. This approach ensures a lean and maintainable project that strictly follows Angular’s official ecosystem. The architecture will be guided by Angular best practices and style guides, while performance, responsiveness, and accessibility according to Material Design v3 are considered essential requirements. This plan defines the technical foundation and the constraints within which the coding agent will generate the specification, ensuring a consistent and future-proof implementation. #context7 #angular-cli
Ở giai đoạn này, tác nhân tạo ra một số tệp, bao gồm tài liệu `plan.md`. Tài liệu này phác thảo cách tác nhân nên tìm kiếm thông tin cần thiết để tạo nhiệm vụ, và bao gồm kết quả nghiên cứu, hướng dẫn tuân thủ các nguyên tắc của bạn và định nghĩa mô hình thực thể. Hãy xem xét cẩn thận các tệp này để đảm bảo tác nhân sẽ tuân thủ kiến trúc, tiêu chuẩn framework và yêu cầu đặc tả của bạn. Đặc biệt chú ý đến tệp `quickstart.md`, vì nó chứa hướng dẫn khởi tạo các tệp dự án. Xác minh rằng các phiên bản `npm` khớp với các phiên bản mới nhất của framework và công cụ bạn ưu tiên.
Ảnh: Kế hoạch kỹ thuật được tạo ra bởi Spec Kit
Định Nghĩa Nhiệm Vụ Thực Thi (Tasks)
Đây là bước đặc tả cuối cùng mà Spec Kit giúp chúng ta tạo định nghĩa nhiệm vụ cho tác nhân lập trình đã chọn. Bước này không yêu cầu thêm bất kỳ đặc tả nào vào việc thực thi tệp prompt. Đơn giản chỉ cần chạy lệnh `/tasks` trong cửa sổ chat của bạn và đợi trong khi tác nhân lập trình định nghĩa tất cả các nhiệm vụ cần thiết để triển khai đặc tả đã được định nghĩa rõ ràng của bạn. Hãy kiên nhẫn, vì quá trình này có thể mất vài phút để hoàn thành.
Ảnh: Tạo các nhiệm vụ triển khai với Spec Kit
Sau khi thực thi prompt `tasks`, tác nhân tạo một tệp `tasks.md`, bao gồm định nghĩa từng bước của tất cả các nhiệm vụ cần được thực thi để tạo đặc tả đã định nghĩa của bạn. Một lần nữa, hãy xem xét tệp thủ công để đảm bảo mọi thứ đã được định nghĩa và không có `todo` nào còn tồn tại ở cuối tệp.
## Validation Checklist
**GATE: All requirements met for execution**
- [✅] All 3 contracts have corresponding tests (T006-T008)
- [✅] All 9 entities have model tasks (T015-T023)
- [✅] All tests come before implementation (T006-T014 before T024+)
- [✅] Parallel tasks truly independent (different files, no shared state)
- [✅] Each task specifies exact file path with Angular conventions
- [✅] No task modifies same file as another [P] task
- [✅] Constitutional compliance: Standalone components, signals, Material Design v3
- [✅] Domain boundaries respected: Pokemon, Favorites, Search
- [✅] Angular 20 modern patterns enforced throughout
**Total Tasks**: 44 tasks organized in 5 phases with clear dependencies
**Estimated Duration**: 3-4 weeks for full implementation with testing
**Parallel Opportunities**: 28 tasks marked [P] for parallel execution
Các nhiệm vụ được tổ chức thành các giai đoạn khác nhau dựa trên độ phức tạp của đặc tả. Trong ví dụ của tôi, có năm giai đoạn: Thiết lập (Setup), TDD, Triển khai Core (Core Implementation), Tích hợp (Integration) và Hoàn thiện (Polish). Mỗi nhiệm vụ có một mã định danh duy nhất (ví dụ: T001) mà bạn có thể tham chiếu khi hướng dẫn tác nhân của mình nhiệm vụ nào cần hoàn thành trước. Điều cần thiết là phải tuân theo các giai đoạn và nhiệm vụ theo đúng thứ tự của chúng. Nếu bạn hoàn thành một nhiệm vụ thủ công, hãy nhớ đánh dấu nó là đã hoàn thành trong tệp nhiệm vụ.
Bây giờ là lúc để tác nhân lập trình của bạn làm công việc khó khăn!
Hạn Chế Hiện Tại và Những Cân Nhắc Khi Áp Dụng SDD
Tính đến tháng 9 năm 2025, Spec Kit vẫn đang trong giai đoạn thử nghiệm (phiên bản 0.0.30+) và có một số hạn chế đáng cân nhắc:
- Không thể chuyển đổi công cụ: Một khi đã khởi tạo với một công cụ AI cụ thể, bạn không thể dễ dàng chuyển sang công cụ khác.
- Tập trung vào dự án mới: Phù hợp hơn cho các dự án mới (greenfield) hơn là các codebase hiện có.
- Phụ thuộc vào Python: Yêu cầu Python 3.11+ để cài đặt
uvx. - Phát triển nhanh chóng: Các tính năng và cấu trúc thay đổi thường xuyên; tài liệu có thể không theo kịp các khả năng mới nhất.
- Mở rộng dựa trên cộng đồng: Nhiều tích hợp công cụ AI mới đến từ các pull request của cộng đồng, tạo ra chất lượng không nhất quán.
Con Đường Phía Trước của Spec Driven Development
GitHub đã định vị Spec Kit như một thử nghiệm trong phát triển có cấu trúc, được hỗ trợ bởi AI. Thống kê áp dụng ban đầu cho thấy nhiều hứa hẹn – các công ty công nghệ lớn đã và đang tích hợp các nguyên tắc SDD vào quy trình phát triển của họ, và công cụ này đã thu hút được sự chú ý của các nhà phát triển cảm thấy thất vọng với các cách tiếp cận lập trình AI không có cấu trúc.
Hệ sinh thái tích hợp tiếp tục mở rộng. Các bản cập nhật gần đây cho GitHub Copilot (bao gồm cả Coding Agent mới trong bản xem trước công khai) và các phản hồi cạnh tranh từ Cursor và các công cụ lập trình AI khác cho thấy rằng các cách tiếp cận dựa trên đặc tả sẽ trở thành thực hành tiêu chuẩn hơn là các kỹ thuật thử nghiệm.
Kết Luận: Thách Thức và Tiềm Năng của SDD
Spec Driven Development hứa hẹn một cách tiếp cận có cấu trúc cho lập trình hỗ trợ AI, giải quyết các vấn đề về chất lượng và khả năng bảo trì vốn có trong “Vibe Coding”. GitHub Spec Kit đơn giản hóa quy trình này thông qua các prompt và mẫu được định nghĩa trước, cung cấp cho nhà phát triển những “hàng rào bảo vệ” cho việc tạo mã AI.
Về lý thuyết, SDD dường như là sự phát triển hợp lý của lập trình hỗ trợ AI ngày nay, nhưng trên thực tế, nó hiện đang đối mặt với thách thức cơ bản của đặc tả con người. Vấn đề chính không phải là AI – mà là yếu tố con người. SDD yêu cầu các nhà phát triển phải xác định chính xác ý định của họ, điều mà các tác nhân AI cuối cùng sẽ thực thi. Tuy nhiên, đây chính là nơi mô hình đối mặt với thử thách lớn nhất của nó.
Sau hơn 10 năm trong lĩnh vực phát triển phần mềm, tôi hiếm khi trải nghiệm các dự án mà các yêu cầu được xây dựng hoàn chỉnh trước khi triển khai – cả từ phía chủ sản phẩm lẫn từ chính các nhà phát triển. Trong các buổi nói chuyện của mình, tôi thường nói đùa rằng chúng ta, các nhà phát triển, “hiệu quả” nhưng “lười biếng” có lẽ là từ thành thật hơn.
Spec Kit khuyến khích các nhà phát triển liên tục mở rộng các tài liệu được tạo ra và tinh chỉnh các đặc tả. Tuy nhiên, dựa trên các ví dụ của tôi từ những tuần gần đây, cách tiếp cận này không tự động dẫn đến kết quả tốt hơn. Chỉ thông qua việc sử dụng các quy tắc bổ sung và máy chủ MCP, tôi mới có thể có các yêu cầu của mình – sử dụng GitHub Copilot – được triển khai một cách sạch sẽ và đầy đủ.
Câu hỏi vẫn còn đó là liệu mô hình này có thực sự giảm thời gian phát triển hay liệu việc giải quyết một vấn đề tự tạo ra – quản lý chất lượng mã nguồn do AI tạo ra – có dẫn đến nhiều sự thất vọng hơn về lâu dài do kiến trúc mã nguồn không tối ưu và chi phí đặc tả tăng lên hay không.
Tôi sẽ tiếp tục thử nghiệm với Spec Driven Development trong các dự án của mình và sẽ công bố các bản cập nhật khi phương pháp luận và công cụ phát triển. Các dấu hiệu ban đầu cho thấy rằng, mặc dù SDD bổ sung chi phí đặc tả ban đầu, nó có thể chứng tỏ là cần thiết để mở rộng quy mô phát triển hỗ trợ AI vượt ra ngoài các ứng dụng cấp prototype.
