Vibe Coding An Toàn: Quy Trình Spec → Build → Test → Review → Deploy Cho Dự Án Thực Tế

Vibe Coding giúp người không chuyên hoặc đội ngũ nhỏ biến ý tưởng thành phần mềm nhanh hơn bằng cách mô tả mục tiêu cho coding agent. Vấn đề bắt đầu khi tốc độ tạo mã bị nhầm với tốc độ tạo sản phẩm ổn định. Một agent có thể sinh giao diện đẹp, kết nối API và sửa lỗi trong vài phút, nhưng vẫn có thể hiểu sai nghiệp vụ, mở quyền quá rộng, làm hỏng dữ liệu hoặc tạo code khó bảo trì.

Quy trình dưới đây đặt AI vào một hệ thống có đặc tả, nhánh làm việc, kiểm thử, review, giới hạn quyền và rollback. Mục tiêu không phải làm chậm AI, mà biến tốc độ thành kết quả có thể kiểm soát.

1. Phân biệt prototype, internal tool và production

Mức	Mục đích	Yêu cầu tối thiểu
Prototype	Kiểm chứng ý tưởng và luồng chính	Dữ liệu giả, không có secret thật, không phục vụ khách hàng
Internal tool	Hỗ trợ một nhóm nội bộ	Đăng nhập, quyền, backup, log, owner vận hành
Production	Phục vụ người dùng hoặc giao dịch thật	Security, monitoring, test, migration, rollback, support

Phần lớn demo vibe coding chỉ chứng minh happy path. Đừng đưa prototype thẳng lên production vì “chạy được trên máy tôi”.

2. Viết spec trước prompt

Prompt dài không thay thế spec. Spec nên đủ để người khác đọc và biết thế nào là hoàn thành:

• Problem: vấn đề cụ thể và người dùng mục tiêu.
• Scope: chức năng có trong phiên bản này.
• Out of scope: phần chưa làm.
• User flow: các bước từ đầu đến kết quả.
• Data: bảng, trường, quan hệ, retention.
• Permissions: ai được đọc, tạo, sửa, xóa.
• Acceptance criteria: điều kiện nghiệm thu có thể kiểm tra.
• Constraints: stack, ngân sách, deadline, hosting, compliance.

Ví dụ acceptance criteria

Người dùng đã đăng nhập có thể tạo draft bài viết với tiêu đề bắt buộc; không thể publish nếu thiếu featured image; mọi lần publish được ghi actor và thời gian; khi API lỗi, draft vẫn được giữ và người dùng thấy thông báo có thể thử lại.

3. Cung cấp context có chọn lọc

Agent cần context nhưng không cần toàn bộ hệ thống. Hãy đưa:

• Cây thư mục và file liên quan.
• README, coding convention và lệnh test.
• Schema hoặc interface cần dùng.
• Ảnh/chỉ dẫn UI đã duyệt.
• Ví dụ input-output.
• Quy tắc không được vi phạm.

Không đưa secret, dữ liệu khách hàng thật hoặc file môi trường production vào context. Dùng sample data đã loại thông tin nhạy cảm.

4. Chia nhiệm vụ thành patch nhỏ

Yêu cầu “xây toàn bộ SaaS” làm tăng xác suất agent tự suy đoán. Chia thành vertical slice:

1. Tạo schema và migration có thể rollback.
2. Xây API đọc/ghi với validation.
3. Tạo UI cho một flow.
4. Viết test cho flow đó.
5. Review và merge trước khi sang phần tiếp theo.

Mỗi patch nhỏ giúp diff dễ đọc, test nhanh và quay lại khi sai.

5. Luôn làm việc trên branch hoặc worktree riêng

Coding agent không nên sửa trực tiếp nhánh chính. Quy ước:

main              # production-ready
staging           # tích hợp trước khi release
feature/auth-rbac # một nhiệm vụ cụ thể
fix/payment-retry # một lỗi cụ thể

Bật branch protection để yêu cầu pull request, review và status checks trước khi merge. Với nhiều agent, dùng worktree hoặc nhánh riêng để tránh cùng sửa một file.

6. Quy tắc quyền tối thiểu

Agent chỉ cần quyền tương ứng nhiệm vụ:

• Agent review chỉ cần đọc.
• Agent tạo patch cần ghi trong repository, không cần deploy.
• Agent chạy test không cần secret thanh toán production.
• Agent migration phải chạy trên database staging hoặc bản sao.
• Agent release không được tự đổi DNS hoặc payment config nếu chưa phê duyệt.

Không dùng một token administrator cho mọi workflow. Secret nên đặt trong secret manager, scope nhỏ và có thể thu hồi.

7. Đặt test trước khi yêu cầu sửa lớn

Nếu hệ thống chưa có test, yêu cầu agent viết reproduction hoặc characterization test trước. Bộ kiểm tra nên gồm:

• Unit test cho logic thuần.
• Integration test cho API, database và queue.
• E2E cho flow quan trọng.
• Type check, lint và build.
• Security checks cho dependency và secret.

Test do agent viết cũng phải review. Một test có thể chỉ xác nhận implementation hiện tại thay vì hành vi đúng.

8. Review diff, không chỉ xem giao diện

UI chạy đẹp có thể che lỗi phía sau. Khi review pull request, kiểm tra:

• Agent đã sửa đúng file cần thiết hay thay đổi lan rộng?
• Có duplicate logic, hard-code, dead code hoặc dependency thừa?
• Validation có ở server hay chỉ ở client?
• Error handling và retry có giới hạn?
• Log có chứa secret hoặc dữ liệu cá nhân?
• Migration có backward-compatible và rollback?
• Permission được kiểm tra ở backend?

9. Dùng AI reviewer như lớp bổ sung

Một agent thứ hai có thể review patch của agent thứ nhất, nhưng không thay người chịu trách nhiệm. Reviewer nên nhận spec, diff, test result và threat model ngắn. Yêu cầu trả về finding có file, dòng, mức độ và cách tái hiện; tránh nhận xét chung chung.

10. Security checklist cho ứng dụng do agent tạo

• Không commit API key, cookie, private key hoặc file .env.
• Validate và sanitize input tại server.
• Dùng parameterized query/ORM đúng cách.
• Phân quyền theo tài nguyên, không chỉ vai trò giao diện.
• Rate limit endpoint nhạy cảm.
• CSRF/CORS/cookie cấu hình đúng.
• Upload file có kiểm tra type, size và nơi lưu.
• Webhook xác minh chữ ký và chống replay.
• Log hành động quan trọng nhưng redact dữ liệu nhạy cảm.
• Dependency được pin và theo dõi advisory.

11. Staging phải đủ giống production

Staging cần cùng loại database, cache, queue, storage và biến cấu hình chính; chỉ khác dữ liệu và credential. Nếu local dùng SQLite nhưng production dùng PostgreSQL, nhiều lỗi migration và concurrency sẽ chỉ xuất hiện sau deploy.

12. Canary deploy và rollback

Không mở toàn bộ traffic ngay. Có thể deploy cho tài khoản nội bộ, một nhóm người dùng hoặc phần trăm nhỏ. Theo dõi:

• Error rate và latency.
• Failed jobs, retry, queue backlog.
• Conversion hoặc task success.
• Database locks và resource usage.
• Feedback của người dùng canary.

Rollback phải được chuẩn bị trước release: phiên bản container trước, backup, migration down hoặc chiến lược roll-forward. Không chờ sự cố mới nghĩ cách quay lại.

13. Prompt mẫu cho một task an toàn

Mục tiêu: thêm chức năng lưu draft tự động.
Phạm vi: editor blog và API draft; không thay đổi publish flow.
Đọc trước: README, schema, editor service, test hiện có.
Ràng buộc: không thêm dependency; không thay đổi migration.
Acceptance: lưu sau 5 giây không nhập; không ghi đè bản mới hơn;
hiện trạng thái saving/saved/error; có test race condition.
Quy trình: phân tích -> đề xuất plan -> chờ duyệt -> tạo patch -> chạy test.
Không deploy, không dùng credential production.

14. Các dấu hiệu cần dừng agent

• Agent liên tục sửa nhiều file không liên quan.
• Đề xuất tắt test, bỏ validation hoặc dùng quyền admin để “chạy cho nhanh”.
• Tạo migration phá dữ liệu mà không cảnh báo.
• Không giải thích được nguyên nhân lỗi nhưng tiếp tục thử ngẫu nhiên.
• Muốn truy cập Internet, secret hoặc production ngoài scope.

15. Definition of Done

Một task chỉ hoàn thành khi code, test, tài liệu và vận hành cùng đạt:

• Acceptance criteria pass.
• Build, lint, type check và test pass.
• PR đã review.
• Không có finding security nghiêm trọng chưa xử lý.
• Monitoring và error handling được cập nhật.
• Migration, backup và rollback rõ.
• Changelog hoặc tài liệu người dùng đã sửa nếu cần.

2A. Viết acceptance criteria có thể kiểm chứng

Acceptance criteria phải mô tả hành vi quan sát được, không mô tả ý định mơ hồ. “Giao diện hiện đại” không thể test; “người dùng đã đăng nhập thấy trạng thái saved sau khi autosave thành công và thấy lỗi có thể thử lại khi API thất bại” thì có thể. Mỗi tiêu chí nên nêu actor, điều kiện trước, hành động, kết quả mong đợi và dữ liệu biên. Agent có thể dùng chúng để tạo test, người review có thể dùng chúng để đọc diff và người vận hành có thể dùng chúng để xác nhận sau deploy.

Ghi cả out-of-scope. Nếu task chỉ thêm draft autosave, không cho agent tự ý đổi publish flow, permission, schema thanh toán hoặc notification. Ranh giới rõ giúp giảm “suy đoán có vẻ hợp lý” và làm review nhanh hơn.

3A. Context cho coding agent có giới hạn

Agent cần context đủ dùng nhưng không cần toàn bộ repository. Cung cấp cây thư mục liên quan, README, coding conventions, interface, migration hiện tại, lệnh test, ví dụ input-output và điều không được thay đổi. Không đưa secret, cookie, dữ liệu khách hàng thật hoặc file môi trường production vào prompt. Dùng sample data đã loại định danh và chỉ cấp quyền file tương ứng task.

Để kiểm soát context drift, ghi file nào agent đã đọc và giả định nào agent đang dùng. Nếu agent phải suy đoán schema, yêu cầu nó dừng và nêu câu hỏi thay vì tự tạo bảng song song. Một task nhỏ với context đúng thường an toàn hơn prompt dài chứa mọi thứ.

4A. Vertical slice trước khi mở rộng

Chia việc thành vertical slice có thể chạy từ đầu đến cuối: schema/validation, API, UI, test và log cho một flow nhỏ. Sau khi slice pass, mới mở rộng trạng thái, quyền hoặc loại dữ liệu. Patch nhỏ tạo diff dễ đọc, giảm conflict giữa agent và làm rollback rõ. Nếu một agent sửa cả auth, billing, editor và deploy trong một lần, không ai biết failure đến từ đâu.

Đặt giới hạn file và dependency trong prompt. Nếu agent muốn sửa ngoài phạm vi, yêu cầu nó liệt kê lý do và chờ quyết định. Không cho phép “dọn code” lan rộng trong cùng patch chức năng nếu chưa có test bảo vệ hành vi hiện tại.

6A. Test phải bắt lỗi, không chỉ làm xanh pipeline

Unit test phù hợp với logic thuần; integration test kiểm tra API, database, queue và permission; E2E kiểm tra flow người dùng; type check, lint, build và dependency scan kiểm tra lớp khác. Viết reproduction test cho bug trước khi sửa để chứng minh lỗi thật sự biến mất. Test do agent tạo cũng cần review vì agent có thể viết assertion khớp implementation hiện tại nhưng không khớp requirement.

Bổ sung case lỗi: timeout, retry trùng, dữ liệu rỗng, quyền sai, schema cũ, migration giữa chừng và request đồng thời. Một happy path pass không chứng minh production an toàn. Lưu artifact test, log và phiên bản commit trong pull request để người khác có thể lặp lại.

8A. Review diff theo rủi ro

Review không chỉ hỏi “UI có đẹp không”. Hãy kiểm tra agent sửa đúng file, validation ở server, permission theo tài nguyên, query có parameterized, log có lộ secret, retry có giới hạn và migration có backward-compatible. Tìm duplicate logic, hard-code, dead code và dependency không cần. Nếu patch chạm payment, user data, upload hoặc webhook, tăng mức review và yêu cầu test lỗi tương ứng.

AI reviewer có thể trả finding có file, dòng, mức độ và cách tái hiện, nhưng không thay người chịu trách nhiệm. Review thứ hai cần nhận spec, diff, test result và threat model ngắn; không nhận toàn bộ repository không cần thiết.

10A. Quyền tối thiểu và secret

Agent review chỉ cần đọc; agent tạo patch cần ghi trong branch nhưng không cần deploy; agent chạy test không cần secret thanh toán production; migration phải chạy trên staging hoặc bản sao; release agent không được tự đổi DNS. Secret đặt trong secret manager, scope nhỏ, có audit và có thể thu hồi. Không copy token vào prompt, issue, screenshot hay log.

Upload file, webhook và endpoint admin cần kiểm tra type, size, signature, nonce, rate limit và permission ở backend. CORS, CSRF, cookie, SSRF và redirect phải được xem như acceptance criteria khi chức năng liên quan mạng. “Agent tự biết bảo mật” không phải một kiểm soát.

11A. Staging, canary và observability

Staging nên gần production về database, cache, queue, storage và cấu hình chính; chỉ khác credential và dữ liệu. Nếu local dùng SQLite nhưng production dùng PostgreSQL, test local không bắt được lock, transaction hay migration khác biệt. Chạy migration trên bản sao, đo thời gian, kiểm tra rollback và chuẩn bị kế hoạch roll-forward nếu down migration không an toàn.

Canary có thể mở cho tài khoản nội bộ hoặc phần trăm nhỏ. Theo dõi error rate, latency, failed jobs, queue backlog, database locks, task success và phản hồi người dùng. Alert phải gắn với owner và runbook; dashboard không có người hành động chỉ tạo cảm giác an toàn.

12A. Rollback và definition of done

Rollback phải được chuẩn bị trước release: phiên bản container trước, backup, migration strategy, feature flag hoặc roll-forward. Xác định điều kiện dừng canary và người có quyền rollback. Không chờ production lỗi mới tìm backup hoặc hỏi ai có SSH.

Definition of Done gồm acceptance criteria pass, build/lint/type check/test pass, diff đã review, không còn finding security nghiêm trọng, monitoring/error handling đủ, migration và rollback rõ, tài liệu/changelog cập nhật. Nếu một mục chưa làm, trạng thái phải là chưa hoàn thành, không đổi tên thành “đã xong về cơ bản”.

13A. Handoff và audit sau deploy

Ghi commit, artifact, người duyệt, thời điểm deploy, thay đổi config, migration, dashboard và cách rollback. Sau canary, đối chiếu telemetry với baseline và lưu kết luận. Nếu có incident, cập nhật reproduction test và runbook, không chỉ sửa nóng production rồi đóng issue. Audit trail giúp phân biệt lỗi do code, dữ liệu, cấu hình hay quy trình review.

14A. Quy trình xử lý khi agent làm sai

Khi agent tạo patch sai, đừng yêu cầu “sửa cho chạy” ngay lập tức. Đầu tiên giữ nguyên reproduction, ghi input, output, log và commit gây lỗi. Sau đó phân loại lỗi: hiểu sai requirement, thiếu validation, sai state transition, race condition, dependency, cấu hình hay dữ liệu. Phân loại giúp prompt sửa có nguyên nhân cụ thể và ngăn agent phủ lên lỗi cũ bằng một workaround khó đọc.

Hãy yêu cầu agent giải thích giả thuyết, file liên quan, test sẽ chứng minh điều gì và rủi ro còn lại. Nếu agent đề xuất thay đổi schema hoặc quyền, tách thành một patch riêng có review. Sau khi sửa, chạy lại reproduction, test regression và kiểm tra diff xem có code chết hoặc fallback nguy hiểm không. Một incident nhỏ là cơ hội làm bộ test và runbook tốt hơn.

16. Bàn giao vận hành sau khi release

Người vận hành cần biết version nào đang chạy, feature flag nào bật, migration nào đã chạy, dashboard nào cần xem và ai có quyền rollback. Ghi rõ endpoint health, ngưỡng alert, cách lấy log đã redact, cách dừng queue và cách khôi phục dữ liệu. Không để kiến thức chỉ nằm trong prompt hoặc trí nhớ của agent.

Cuối mỗi release, lưu changelog, diff, artifact test, ảnh hưởng người dùng, thay đổi cấu hình và quyết định chưa làm. Tài liệu này giúp lần thay đổi tiếp theo bắt đầu từ sự thật, không phải từ một bản tóm tắt do model tự đoán. Đó là phần quan trọng để vibe coding trở thành năng lực kỹ thuật lặp lại được.

Kết luận

Vibe Coding an toàn không phụ thuộc vào việc model “thông minh đến đâu”, mà phụ thuộc ranh giới và bằng chứng. Spec giảm suy đoán; patch nhỏ giảm blast radius; test tạo bằng chứng; review kiểm tra quyết định; staging và canary giảm rủi ro release.

Để xây workflow agent có approval, queue và audit, đọc thêm bài n8n Deep Dive và bài 10 plugin Codex.

Nguồn tham khảo

• OpenAI Codex
• GitHub Protected Branches
• OWASP – Security for LLM Applications

15A. Đánh giá rủi ro trước khi merge

Trước khi merge, nhóm cần đánh giá dữ liệu nào bị chạm, người dùng nào bị ảnh hưởng và bán kính sự cố nếu patch sai. Hãy phân loại thay đổi theo mức thấp, trung bình và cao; thay đổi liên quan đăng nhập, thanh toán, dữ liệu cá nhân, upload hoặc quyền quản trị luôn cần reviewer có chuyên môn. Ghi rõ giả định, dependency bên ngoài, giới hạn rate và điều kiện rollback. Nếu không thể chứng minh an toàn bằng test, thu hẹp phạm vi hoặc giữ tính năng sau feature flag.

Threat model ngắn nên trả lời ai có thể tấn công, tài sản cần bảo vệ, đường vào nào mới xuất hiện và log nào sẽ giúp phát hiện. Đừng biến checklist thành thủ tục hình thức: mỗi mục phải liên kết với một test, một owner hoặc một quyết định được ghi lại.

17. Đo chất lượng workflow agent

Sau vài sprint, hãy đo lead time từ spec đến merge, tỷ lệ rework, số defect lọt qua review, số lần rollback, thời gian phục hồi và tỷ lệ test thất bại do môi trường. Chỉ nhìn số dòng code hoặc số task hoàn thành sẽ khuyến khích tốc độ giả. Nếu lead time giảm nhưng rework và incident tăng, workflow đang tối ưu sai mục tiêu.

Định kỳ chọn một số patch để audit thủ công: requirement có khớp code không, test có bao phủ lỗi thực tế không, tài liệu có cập nhật không và quyền agent có bị mở rộng quá mức không. Kết quả audit nên quay lại template prompt, policy branch và runbook. Khi đó agent trở thành một phần của hệ thống học hỏi, thay vì một hộp đen tạo mã.