Khi Vibe Coding Chạm Ngưỡng

Bài này thảo luận về AI-Driven Development: From Vibe Coding to Structured Methodologies của Aakash Kavuru. Đáng đọc toàn bộ.

Vibe coding rất thú vị. Bạn mô tả thứ mình muốn, AI viết ra, bạn ship. Hoạt động tốt trong hai tuần đầu. Rồi codebase lớn lên, AI bắt đầu hiểu sai context, và bạn dành nhiều thời gian chiến đấu với output hơn là thực sự làm sản phẩm.

Đây không phải lỗi của AI. Đây là lỗi tài liệu mà bạn bỏ qua vì AI khiến việc bỏ qua trở nên quá dễ dàng. Bài gốc nói rất đúng: nguyên nhân gốc rễ của hầu hết mọi thất bại trong AI-driven development là “thứ cần được tạo ra không bao giờ được ghi lại.”

Tại sao Vibe Coding hoạt động tốt lúc đầu

Vibe coding nghĩa là không có spec, không có kế hoạch chính thức. Bạn mô tả thứ mình muốn và lặp lại trên output. Nó nhanh vì mọi thứ vẫn còn vừa trong đầu bạn.

Hãy nghĩ đến một project cuối tuần. Ba file, một tính năng, toàn bộ context nằm trong một cuộc hội thoại. Bạn prompt, nhận code, ship. Xong trong ba ngày.

Giờ nhìn vào sáu tháng sau: ba mươi file, hai người đóng góp, requirements đã thay đổi bốn lần. Bạn nhờ AI thêm một tính năng và nó làm đúng về mặt kỹ thuật, nhưng có gì đó khác bị ảnh hưởng. Bạn sửa cái đó, lại có cái khác bị ảnh hưởng. Bạn không còn đang build nữa. Bạn đang chạy theo drift. AI không kém hơn trước. Vấn đề là intent chưa bao giờ được ghi lại, nên không có gì để giữ output đi đúng hướng.

Khi nào thì mọi thứ bắt đầu sai

Dấu hiệu rất đặc trưng. Code chạy được. Test pass. Nhưng behavior lại sai theo cách khó giải thích.

Ví dụ: bạn prompt “thêm tính năng notifications.” Với bạn, đó là email digest mỗi ngày một lần. AI build real-time push notifications. Cả hai đều là cách hiểu hợp lý của cái prompt đó. AI không sai. Prompt chỉ đơn giản là mơ hồ.

Ở quy mô nhỏ, AI đoán đúng đủ nhiều nên không thành vấn đề. Ở quy mô lớn hơn, mỗi lần đoán sai cộng dồn lại. Bài gốc gọi đây là “implementation drift from specification.” Nói đơn giản hơn: bạn không bao giờ ghi lại mình đang build cái gì, nên AI không thể giữ đúng hướng.

SDD: Ghi lại thứ bạn muốn trước khi prompt

Spec-Driven Development nghe có vẻ nặng nề. Thực ra không phải. Chỉ một quy tắc: trước khi đưa cho AI một chỉ dẫn, viết ra một spec tối giản cho thứ chỉ dẫn đó cần tạo ra.

Không phải tài liệu năm mươi trang. Một đoạn văn. Đủ để xóa bỏ sự mơ hồ.

Thay vì prompt như vậy:

Thêm xác thực người dùng.

Viết spec này trước, rồi mới prompt:

Tính năng: Xác thực người dùng
- Chỉ đăng nhập bằng email + mật khẩu (chưa có OAuth)
- Mật khẩu hash bằng bcrypt, tối thiểu 8 ký tự
- JWT token, hết hạn sau 7 ngày
- Không có tùy chọn "ghi nhớ đăng nhập"
- Rate limit: 5 lần thất bại trong 10 phút thì khóa 15 phút
- Ngoài phạm vi: đăng nhập mạng xã hội, 2FA, khôi phục tài khoản

Output của AI trở nên dự đoán được hơn nhiều vì sự mơ hồ đã được xóa bỏ. Quan trọng hơn, bạn giờ có thứ để đối chiếu với output.

Dùng SDD cho bất kỳ project nào đã qua giai đoạn MVP, hoặc bất kỳ tính năng nào chạm vào code hiện có.

VSDD: Kiểm tra output so với spec

Verified SDD thêm một bước: sau khi AI tạo ra code, kiểm tra nó so với spec trước khi tiếp tục. Chỉ vậy thôi.

Hầu hết mọi người bỏ qua bước này. Họ đọc code, thấy có vẻ ổn, commit. Hai tuần sau phát hiện edge case trong spec chưa bao giờ được implement vì AI lặng lặng bỏ qua nó.

Không cần phải tự động hóa. Một checklist đơn giản là đủ:

Checklist tính năng auth:
[x] Chỉ email + mật khẩu
[x] Hash bằng bcrypt
[x] JWT hết hạn 7 ngày
[x] Không có "ghi nhớ đăng nhập"
[ ] Rate limit tại 5 lần  <-- AI dùng 10, không phải 5
[ ] Khóa 15 phút          <-- chưa được implement

Hai mục bị bỏ sót. Bạn phát hiện trong năm phút thay vì trong một sự cố production.

Với team hoặc bất cứ thứ gì đưa lên production: hãy tự động hóa việc này. Viết test dựa trực tiếp từ spec trước khi chạy AI. Nếu spec nói “rate limit tại 5 lần,” hãy viết test kiểm tra đúng con số đó. Một integration test mơ hồ sẽ không bắt được AI dùng giá trị khác một cách lặng lẽ.

CoDD: Giữ nhiều spec nhất quán với nhau

Coherence-Driven Development dành cho các hệ thống mà nhiều spec phụ thuộc vào nhau. Thay đổi một cái, mọi thứ phụ thuộc vào nó đều cần cập nhật theo.

Hệ thống thanh toán là ví dụ điển hình. Spec “tạo đơn hàng” phụ thuộc vào “xử lý thanh toán,” và cái đó phụ thuộc vào “chính sách hoàn tiền.” Nếu thời hạn hoàn tiền thay đổi từ 30 ngày xuống 14 ngày, mọi spec downstream đều phải phản ánh điều đó.

Nếu không có CoDD, điều xảy ra là: bạn cập nhật spec chính sách hoàn tiền, nhờ AI implement, AI làm đúng. Nhưng flow “tạo đơn hàng” vẫn tham chiếu 30 ngày vì bạn không cập nhật spec đó. Giờ hai phần của hệ thống đang bất đồng về cùng một quy tắc.

CoDD là quá mức cần thiết cho một project cá nhân. Nó cần thiết khi bạn có nhiều kỹ sư, nhiều service, và một sự không nhất quán nhỏ giữa hai component tạo ra bug mất ba ngày để tìm ra.

Nhìn thẳng vào vấn đề

SDD, VSDD, và CoDD tạo thành một sự tiến triển. Bắt đầu với SDD khi vibe coding bắt đầu mất kiểm soát. Thêm VSDD khi cần verification. Thêm CoDD khi hệ thống lớn đủ để tính nhất quán trở thành vấn đề.

Khung đó hữu ích. Nhưng cần nói thẳng: không có gì trong số này là mới.

Các team tốt đã viết spec, verify implementation, và quản lý dependencies giữa các component từ lâu trước khi AI tồn tại. Thứ AI làm là khiến bạn có thể bỏ qua tất cả những điều đó và vẫn ship được thứ gì đó. Một thời gian. Rồi khoản nợ đến hạn nhanh hơn và dưới dạng khó hiểu hơn.

Đóng góp thực sự của bài gốc không phải là tên các methodology. Mà là cách đặt vấn đề lại: “AI vượt con người về tốc độ viết code, nhưng việc xác định intent vẫn là công việc của con người.” Đó là sự dịch chuyển tương tự từ một góc độ khác như bài trước về phần mềm đang rẻ đi. Chi phí dịch chuyển từ viết code sang biết phải viết cái gì, rồi ghi nó ra đủ rõ để AI không bị lạc hướng.

Thay đổi thực tế là gì

Ba workflow, so sánh:

Trước AI:        xác định intent -> implement -> review
Vibe coding:     mô tả -> AI implement -> ship
SDD + VSDD:      viết spec -> AI implement -> verify so với spec

Bước giữa trở nên nhanh hơn. Bước đầu và bước cuối trở nên quan trọng hơn. Đầu tư vào spec và output của AI sẽ dự đoán được. Đầu tư vào verification và drift sẽ bị phát hiện sớm. Bỏ qua cả hai và bạn có một khởi đầu nhanh và một giai đoạn giữa đau đớn.

Kỹ năng tích lũy giá trị bây giờ không phải là kỹ thuật prompt. Đó là khả năng viết một spec rõ ràng, tối giản, loại bỏ sự mơ hồ mà không over-engineer. Đó là kỹ năng viết lách, đồng thời cũng là kỹ năng tư duy. Bạn không thể viết spec rõ ràng cho thứ bạn chưa hiểu.

Kết

Vibe coding là điểm khởi đầu ổn. Nó không phải là trạng thái bền vững.

Các team làm tốt với AI không phải là những người prompt sáng tạo nhất. Họ là những người đã có kỷ luật ghi lại thứ mình muốn trước khi nhờ AI build nó.

Nguồn: AI-Driven Development: From Vibe Coding to Structured Methodologies của Aakash Kavuru trên Qiita.