Quy trình vibe coding: từ ý tưởng đến ship với Claude Code (2026)

Vibe coding là gì? (nhắc nhanh)

Vibe coding là cách lập trình mà bạn mô tả ý muốn bằng ngôn ngữ tự nhiên, để AI sinh code, rồi bạn nghiệm thu theo "cảm giác" kết quả chạy được thay vì gõ từng dòng. Thuật ngữ này do Andrej Karpathy đặt tên đầu năm 2025 và nhanh chóng thành cách làm phổ biến của indie hacker lẫn dev chuyên nghiệp. Nói ngắn gọn: bạn là người ra quyết định và kiểm duyệt, AI là người thực thi.

Điểm mấu chốt để vibe coding không biến thành mớ hỗn độn là quy trình - chứ không phải gõ prompt tùy hứng. Nếu bạn chưa nắm nền tảng, đọc trước bài vibe coding là gì rồi quay lại đây để học quy trình lặp-lại-được. Bài này tập trung vào phần "làm thế nào" của lập trình bằng AI từ đầu đến cuối.

Tổng quan quy trình vibe coding: 6 bước từ ý tưởng đến ship

Toàn bộ workflow vibe coding có thể gói trong sáu bước, mỗi bước có một output rõ ràng và một "decision gate" - điểm bạn dừng lại xem có nên đi tiếp hay quay lại sửa. Chính các decision gate này giữ AI đi đúng hướng thay vì lạc "vibe".

Sáu bước này khớp với một khung tư duy gọn hơn: khung brainstorm → plan → cook → ship. Brainstorm gộp bước 1-2, plan là bước 3, cook là bước 4, còn ship gói bước 5-6. Tôi minh họa quy trình bằng Claude Code - CLI agentic có thể đọc repo, sửa nhiều file và chạy lệnh trong một lượt (tài liệu Claude Code, Anthropic) - nhưng đúng nguyên tắc thì áp dụng được cho Cursor hoặc Copilot.

Bước 1 - Làm rõ ý tưởng & brainstorm

Sai lầm phổ biến nhất là mở terminal lên và gõ prompt ngay. Kết quả là AI đoán ý bạn, đoán sai, và bạn tốn nửa buổi sửa những thứ đáng lẽ không nên tồn tại. Bước 1 chặn AI slop từ gốc: bạn phải biết mình muốn gì trước khi bảo AI làm gì.

Trước khi gõ bất kỳ prompt nào, trả lời bốn câu:

• Outcome: sản phẩm này giúp ai làm được việc gì? Nói bằng một câu.
• Ràng buộc: ngôn ngữ/stack nào, chạy ở đâu, cần offline hay không, ngân sách thời gian.
• Non-goal: những gì cố tình không làm ở phiên bản này (rất quan trọng để AI không "vẽ" thêm).
• Tiêu chí "xong": nhìn vào đâu để biết đã đạt - ví dụ "người dùng thêm được một khoản chi và thấy tổng cộng cập nhật".

Ví dụ minh họa: ý tưởng "app quản lý chi tiêu cá nhân". Outcome: giúp cá nhân ghi nhanh khoản chi hằng ngày và xem tổng theo tháng. Ràng buộc: web tĩnh, chạy trên trình duyệt, lưu local, dựng trong một buổi. Non-goal: không đăng nhập, không đồng bộ cloud, không biểu đồ phức tạp. Tiêu chí xong: thêm được khoản chi, thấy danh sách và tổng tháng. Bốn câu này chính là "hiến pháp" mà mọi prompt sau đều phải tuân theo.

Bước 2 - Viết spec/brief cho AI (không chỉ "prompt vu vơ")

Đây là bước tạo khác biệt lớn nhất về chất lượng. Một prompt vu vơ kiểu "làm cho tôi app quản lý chi tiêu" sẽ cho ra kết quả ngẫu nhiên. Một spec có cấu trúc cho ra kết quả bám sát ý bạn. Bạn viết spec một lần rồi tái sử dụng cho cả plan lẫn cook.

Mẫu spec/brief bạn có thể copy-paste và điền vào (đặt trong file SPEC.md hoặc CLAUDE.md ở gốc repo để Claude Code tự đọc):

# SPEC - App quản lý chi tiêu

## Mục tiêu
Web app một trang giúp cá nhân ghi nhanh khoản chi và xem tổng theo tháng.

## User flow
1. Người dùng nhập số tiền + hạng mục + ngày, bấm "Thêm".
2. Khoản chi hiện trong danh sách, mới nhất lên đầu.
3. Tổng chi của tháng hiện tại hiển thị ở đầu trang, tự cập nhật.

## Dữ liệu mẫu
- { amount: 45000, category: "Ăn uống", date: "2026-08-09" }
- { amount: 120000, category: "Đi lại", date: "2026-08-08" }

## Ràng buộc kỹ thuật
- HTML + CSS + JavaScript thuần, không framework.
- Lưu bằng localStorage, không backend.
- Chạy được khi mở trực tiếp file index.html.

## Tiêu chí test (định nghĩa "xong")
- Thêm khoản chi → xuất hiện trong danh sách.
- Tải lại trang → dữ liệu vẫn còn.
- Tổng tháng đúng với các khoản đã nhập.

## Non-goal
- Không đăng nhập, không đồng bộ cloud, không biểu đồ.

Khi độ rủi ro thấp (prototype, công cụ nội bộ, trang tĩnh) bạn có thể vibe khá tự do. Nhưng khi độ rủi ro cao - dữ liệu người dùng, logic tính tiền, tích hợp bên thứ ba - hãy chuyển sang spec-driven development: spec chi tiết hơn, có tiêu chí nghiệm thu chặt, và AI phải bám đúng thay vì tự do sáng tạo. Spec càng rõ, AI slop càng ít.

Bước 3 - Lập kế hoạch & chia nhỏ (plan)

Đừng bảo AI "viết cả app một lượt". Model càng phải giữ nhiều thứ trong đầu cùng lúc thì càng dễ bỏ sót, mâu thuẫn, hoặc bịa API không tồn tại. Thay vào đó, yêu cầu AI lập plan trước khi code, rồi bạn duyệt plan đó.

Trong Claude Code, một prompt lập plan tốt trông như thế này:

Đọc SPEC.md. ĐỪNG viết code vội.
Hãy đề xuất plan: liệt kê các module cần làm,
thứ tự triển khai, và với mỗi module ghi rõ
input/output. Dừng lại chờ tôi duyệt.

Với app ví dụ, plan hợp lý là chia thành các module nhỏ, kiểm được "vibe" từng phần:

1. Khung HTML + form nhập - dựng giao diện, chưa cần logic.
2. Lưu & đọc localStorage - thêm/đọc dữ liệu, chưa cần tính tổng.
3. Render danh sách - hiển thị các khoản đã lưu.
4. Tính tổng theo tháng - logic cộng dồn + cập nhật khi thêm.

Chia nhỏ tác vụ có ba lợi ích: bạn nghiệm thu được từng bước, khi lỗi thì phạm vi tìm kiếm hẹp, và bạn giữ được quyền kiểm soát ở mỗi decision gate thay vì nhận về một khối code khổng lồ khó review.

Bước 4 - Cook: để AI viết code từng module

"Cook" là lúc AI thực sự viết code theo plan đã duyệt. Với Claude Code, một phiên cook điển hình là: agent đọc repo và SPEC.md → sửa hoặc tạo file cho module hiện tại → chạy lệnh/test → báo kết quả → chờ bạn duyệt qua module tiếp theo. Bạn làm việc theo từng module, không "buông" cả app.

Prompt cook cho module đầu tiên, bám vào plan:

Triển khai module 1 trong plan: khung HTML + form nhập
(số tiền, hạng mục, ngày, nút Thêm). Chưa cần logic lưu.
Sau khi xong, mô tả ngắn những gì đã tạo.

Vài mẹo kiểm ở mỗi checkpoint khi cook:

• Chạy thử ngay sau mỗi module thay vì đợi cuối cùng - phát hiện lệch hướng sớm rẻ hơn nhiều.
• Đọc diff AI vừa tạo. Nếu nó đụng vào file ngoài phạm vi module, hỏi lại tại sao.
• Can thiệp tay khi AI lặp lại một lỗi hai lần liên tiếp: sửa trực tiếp một chỗ nhỏ để "gỡ kẹt" thường nhanh hơn diễn giải lại bằng lời.
• Giữ commit nhỏ theo từng module để dễ quay lui nếu module sau làm hỏng module trước.

Bước 5 - Test, review & tránh AI slop

Code chạy được không có nghĩa là code tốt. Bước này là nơi bạn tách một sản phẩm khỏi một đống "AI slop" - code trông ổn nhưng thừa thãi, khó bảo trì, hoặc âm thầm sai. Nguyên tắc vàng: đừng ship thứ bạn không hiểu.

Checklist review nhanh sau mỗi phiên cook:

• Chạy test theo tiêu chí "xong" đã ghi trong spec. Với app ví dụ: thêm khoản chi, tải lại trang, kiểm tổng tháng.
• Đọc-hiểu code, không chỉ liếc. Nếu có đoạn bạn không giải thích được, bảo AI giải thích hoặc viết lại đơn giản hơn.
• Soát code thừa: hàm không ai gọi, thư viện cài mà không dùng, xử lý cho trường hợp không tồn tại.
• Kiểm biên: nhập rỗng, số âm, ngày sai định dạng - AI hay quên các case này.

Muốn hiểu sâu hơn về các "mùi" code AI hay sinh ra và cách chặn chúng, xem cách tránh AI slop. Khi test đỏ hoặc code hành xử lạ, quy trình gỡ lỗi có phương pháp nằm ở bài debug với AI - đừng chỉ dán lỗi rồi bảo "sửa đi", hãy cho AI ngữ cảnh và bắt nó chẩn đoán nguyên nhân trước.

Bước 6 - Ship: deploy sản phẩm chạy được

Nhiều bài về vibe coding dừng ở prototype. Nhưng "ship" mới là lúc ý tưởng thành sản phẩm người khác dùng được. Từ prototype đến deploy thật gồm mấy việc:

1. Build: nếu có bước đóng gói (bundler, framework), chạy build và sửa cảnh báo trước khi mang đi.
2. Cấu hình env: tách khóa/biến môi trường ra khỏi code; đừng commit secrets lên repo.
3. Hosting: chọn nơi chạy phù hợp - trang tĩnh có thể lên hosting tĩnh trong vài phút; app có backend cần nền tảng hỗ trợ server.
4. Docs: nhờ AI viết README từ chính spec + code - cách chạy, cách cấu hình, giới hạn hiện tại.

Một lưu ý trung thực để không tự lừa mình: một prototype tốt là công cụ ra quyết định, không phải bản production thu nhỏ. Nó giúp bạn xác nhận ý tưởng đáng làm hay không. Khi đã chắc đáng làm, hãy dành thời gian làm chắc phần lõi (bảo mật, xử lý lỗi, kiểm thử) trước khi mở cho nhiều người dùng thật.

Ví dụ thật: dựng 1 app nhỏ theo trọn 6 bước

Gộp tất cả lại, đây là cách app quản lý chi tiêu đi qua trọn quy trình. Đây là walkthrough tôi thực hiện bằng Claude Code, dạng minh họa từng bước để bạn hình dung nhịp làm việc.

• Bước 1 (ý tưởng): chốt outcome/ràng buộc/non-goal/tiêu chí xong như phần trên - web tĩnh, localStorage, một buổi.
• Bước 2 (spec): lưu đúng mẫu SPEC.md ở trên vào gốc thư mục dự án.
• Bước 3 (plan): yêu cầu Claude Code đọc spec và đề xuất 4 module; duyệt thứ tự triển khai.
• Bước 4 (cook): làm lần lượt từng module. Sau module "tính tổng theo tháng", chạy thử và thấy tổng cập nhật đúng khi thêm khoản mới.
• Bước 5 (test & review): chạy đủ ba tiêu chí "xong"; bắt được một lỗi biên - nhập số có dấu phẩy làm tổng sai - và yêu cầu AI chuẩn hóa input trước khi cộng.
• Bước 6 (ship): vì là trang tĩnh, chỉ cần đẩy thư mục lên một hosting tĩnh; nhờ AI sinh README kèm hướng dẫn chạy.

Kết quả: một app một trang, thêm/xem/tổng-hợp chi tiêu, dữ liệu bền qua reload - dựng gọn trong một buổi. Điều đáng giá không phải là app đó "hoành tráng", mà là quy trình lặp lại được cho dự án tiếp theo.

Khi nào vibe coding thất bại (giới hạn trung thực)

Vibe coding không phải chiếc búa cho mọi cây đinh. Có những vùng bạn nên chậm lại, chuyển sang spec-driven chặt hơn hoặc tự viết:

• Xác thực & phân quyền (auth): một lỗi nhỏ có thể mở toang dữ liệu. Đừng "vibe" phần đăng nhập/quyền truy cập.
• Thanh toán & tính tiền: sai số ở đây là mất tiền thật hoặc mất niềm tin. Cần spec chặt, test kỹ, review tay.
• Dữ liệu nhạy cảm: thông tin cá nhân, y tế, tài chính - sai sót có hậu quả pháp lý.
• Hệ thống lớn, nhiều ràng buộc: khi thay đổi một chỗ ảnh hưởng nhiều nơi, AI dễ phá vỡ thứ nó không "nhìn thấy".
• Khi bạn không đọc nổi code sinh ra: nếu không thể review, bạn không thể chịu trách nhiệm cho nó - đây là dấu hiệu cần dừng.

Hai rủi ro âm thầm cần nhớ: ảo giác (AI bịa API, hàm, hoặc kết quả không có thật) và nợ kỹ thuật (code chạy hôm nay nhưng tích tụ rối rắm khiến ngày mai khó sửa). Cả hai đều được kiểm soát bằng chính các decision gate ở mỗi bước - chứ không phải bằng việc tin tưởng mù quáng vào output.

Tăng tốc quy trình bằng bộ kit sẵn (AgentKit)

Sáu bước trên chạy nhanh và ổn định hơn khi mỗi bước có sẵn công cụ chuyên dụng - thay vì bạn phải tự nghĩ prompt brainstorm, tự dựng mẫu spec, tự nhắc AI lập plan mỗi lần. Đó là chỗ các bộ kit skills/subagents/workflows dựng sẵn cho Claude Code phát huy tác dụng.

Lưu ý: AgentKit ở đây = bộ kit cho Claude Code (agentkit.best, CLI ak), khác với OpenAI AgentKit. Engineer Kit — giảm 20%, còn $79.20 gói 60+ skills và 30+ workflow phủ đúng các bước của quy trình này (brainstorm, plan, cook, test, code review) với giá $99 - trang không nêu phí định kỳ, có "money-back guarantee" và cập nhật trọn đời. Nếu muốn xem chi tiết từng skill hợp với bước nào, đọc bài đánh giá Engineer Kit trước khi quyết định. Kit không thay bạn làm quy trình - nó chỉ bỏ bớt phần dựng khung lặp đi lặp lại.

Câu hỏi thường gặp (FAQ)

Quy trình vibe coding gồm mấy bước?

Quy trình gồm 6 bước lặp-lại-được: làm rõ ý tưởng & brainstorm, viết spec/brief cho AI, lập plan & chia nhỏ, cook (để AI code từng module), test & review để tránh AI slop, và ship (deploy sản phẩm). Mỗi bước có một decision gate để bạn kiểm trước khi đi tiếp.

Vibe coding có cần biết code không?

Bạn có thể bắt đầu mà không cần code giỏi, nhưng để ship sản phẩm đáng tin thì cần đọc-hiểu được code AI sinh ra. Nguyên tắc là đừng ship thứ bạn không hiểu. Càng đọc được code, bạn càng review tốt và tránh được lỗi âm thầm.

Vibe coding khác lập trình truyền thống thế nào?

Lập trình truyền thống bạn gõ từng dòng; vibe coding bạn mô tả ý muốn bằng ngôn ngữ tự nhiên để AI sinh code, còn bạn dẫn dắt và nghiệm thu. Vai trò dịch chuyển từ "người viết" sang "người ra quyết định và kiểm duyệt".

Nên dùng tool nào cho vibe coding?

Claude Code phù hợp cho quy trình agentic end-to-end vì nó đọc repo, sửa nhiều file và chạy lệnh trong một lượt. Cursor và GitHub Copilot cũng làm được, mạnh ở gợi ý trong editor. Chọn theo thói quen làm việc; quy trình 6 bước áp dụng cho cả ba.

Prototype vibe coding có deploy production được không?

Được với sản phẩm nhỏ, rủi ro thấp. Nhưng một prototype tốt là công cụ ra quyết định, không phải bản production thu nhỏ. Trước khi mở cho nhiều người dùng, hãy làm chắc bảo mật, xử lý lỗi và kiểm thử ở phần lõi.

Làm sao tránh AI slop khi vibe coding?

Viết spec rõ từ đầu, chia nhỏ tác vụ, và review từng module: chạy test theo tiêu chí "xong", đọc-hiểu code thay vì liếc, xóa code thừa và kiểm các trường hợp biên. Đừng ship thứ bạn không giải thích được.

Kết luận + bước tiếp theo

Quy trình vibe coding không phải phép màu - nó là kỷ luật sáu bước giúp bạn dùng AI mà vẫn giữ quyền kiểm soát: ý tưởng → spec → plan → cook → test → ship, với một decision gate ở mỗi chặng để chặn AI slop. Bước tiếp theo tùy nhu cầu của bạn: nếu cần spec chặt hơn cho dự án rủi ro cao, đọc spec-driven development; muốn nắm khung tư duy gọn, xem brainstorm → plan → cook → ship; còn để giữ code sạch, học cách tránh AI slop.