Spec Driven Development - tăng sức mạnh cho vibe coding

(ainativedev.io)

30 điểm bởi hexpeek 2025-09-06 | Chưa có bình luận nào. | Chia sẻ qua WhatsApp

Trước khi bắt đầu

IDE có tên Kiro đã từng được giới thiệu trên GeekNews.

Tuy nhiên, trước đây chưa có phần giới thiệu về phương pháp phát triển mà Kiro hướng tới dưới góc nhìn Spec Driven Development (SDD),

và hiện đã có một video rất phù hợp để hiểu về Spec Driven Development, nên xin giới thiệu tại đây.

IDE dạng agent: hỗ trợ phát triển bằng ngôn ngữ tự nhiên, nhưng có thiên hướng xem “spec là artifact hạng nhất”.
Vừa giữ được tốc độ của “vibe coding” trong các agent IDE hiện có, vừa định nghĩa các quyết định, giả định và ràng buộc bằng tài liệu spec.
Workflow: khi nhập ý tưởng, hệ thống lập tức tạo 3 file requirements / design / tasks để bắt đầu. Trình soạn thảo có dạng đặt thêm các tab “Specs / Hooks / Steering” lên trên một fork của Code OSS.
- Specs: cấu trúc hóa yêu cầu (user story + tiêu chí chấp nhận theo định dạng EAR), sau đó liên kết việc triển khai, kiểm thử và thay đổi với spec.
- Hooks: theo dõi thay đổi file/code để kích hoạt workflow spec.
- Steering: check-in hướng dẫn cho nhóm dưới dạng quy tắc (markdown) trong .kiro/ ở root của repository — ví dụ: thêm quy tắc TDD để nhất quán hóa hành vi của agent.

Bù đắp giới hạn của vibe coding: khi tạo mã nhanh bằng các lượt trao đổi chat, cơ sở của các quyết định dễ bị chôn vùi trong luồng hội thoại, khiến về sau khó hiểu rõ “đã xây cái gì và vì sao”. SDD đặt đặc tả theo hướng hành vi lên trước để làm kim chỉ nam ổn định.
Định nghĩa của spec (hành vi, thuộc tính, bất biến): thay vì mô tả cách triển khai, spec mô tả hệ thống phải hành xử như thế nào — đưa vào các khái niệm như thuộc tính an toàn (safety), tiến triển (liveness), và bất biến, nhưng với triết lý giúp chúng trở nên dễ tiếp cận hơn bằng cú pháp thân thiện với lập trình viên.

Trực quan hóa quyết định & tái sử dụng: spec trở thành “nguồn gốc” của các thay đổi mã, giúp review và đồng thuận dễ hơn, và ngay cả khi tính năng thay đổi thì ý đồ (behaviors) vẫn được lưu lại.
Living spec có thể kết hợp: có thể mô-đun hóa rồi tái sử dụng/kết hợp các kịch bản người dùng, tiêu chí chấp nhận, contract giao diện/dữ liệu, hiệu năng/SLA, v.v. (từ service đến cấp độ hệ thống).
Áp dụng xuyên suốt SDLC: từ căn chỉnh ở giai đoạn đầu của yêu cầu và thiết kế, cho đến feedback loop của các vấn đề sau triển khai — tức là ngay cả trong thời đại AI với tốc độ sinh mã rất nhanh, vẫn phải giữ được review, chất lượng và tính nhất quán.

Link thời điểm bắt đầu phần demo trong video được đăng ở Main link có thể tham khảo tại URL này: https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085

A. Thiết lập ban đầu

Thiết lập project - Hooks, Steering, MCP
Thiết lập TDD (khuyến nghị)
Thiết lập Spec - viết Spec dựa trên định dạng EAR (khuyến nghị) (có thể tự động tạo bằng AI từ việc phân tích project hiện có)

B. Triển khai tính năng

Suy ra từ Spec - phản ánh/cập nhật yêu cầu mới vào Spec
Thiết lập guardrail (khuyến nghị) - viết test stub, quy tắc
Triển khai <-> kiểm thử - phần lớn giai đoạn này được lặp đi lặp lại thông qua AI, và lập trình viên chỉ can thiệp ở mức chỉnh sửa những đoạn mã nhỏ mà AI khó sửa tốt

Sau khi hoàn tất cấu hình project, tính năng được mở rộng bằng cách lặp lại giai đoạn 'B. Triển khai tính năng'

Nếu chất lượng tài liệu Spec không đạt mức tiêu chuẩn thì sẽ không vận hành tốt.
Trong video không giải thích chi tiết các quy tắc tiêu chuẩn cho tài liệu Spec. (tham khảo: https://kiro.dev/docs/specs/)
TDD được khuyến nghị, và có nói rằng phần lớn các project không áp dụng TDD đã không cảm nhận được hiệu quả rõ rệt từ phương pháp này.

Đây là một trong những phương pháp được đề xuất từ một góc nhìn khác để tận dụng AI tốt hơn.
Tài liệu được viết 'tốt' luôn mang lại rất nhiều lợi ích. Tuy vậy, từ kinh nghiệm thực tế rằng khá nhiều tài liệu không được bảo trì tốt, có lẽ mấu chốt là liệu phương pháp này có thể tạo được sự đồng thuận từ bao nhiêu người.
Ở thời điểm hiện tại, chiến lược phát triển AI + TDD là một phương pháp đã được khá nhiều lập trình viên đồng tình và phần nào được kiểm chứng. Nếu hiệu quả được xác minh thông qua so sánh giữa trường hợp chỉ dùng TDD độc lập và trường hợp dùng cùng với SDD, có lẽ nó sẽ nhận được sự đồng thuận lớn hơn nhiều.