Cụm từ vibe coding bắt đầu từ một tweet và biến thành một phong trào. Bóc hết phần lãng mạn, nó mô tả một dịch chuyển có thật: bạn nói mình muốn gì, AI viết code, bạn bấm thử xem có chạy không. Không học cú pháp. Không thuộc framework. Bạn ship được thứ mình cần.
Nghe như phép thuật hoặc như nói dối, tuỳ ai kể cho bạn. Cả hai phản ứng đều sai theo cùng một cách. Vibe code chạy được — nhưng theo kiểu nấu ăn ở nhà: bạn không cần bằng đầu bếp, nhưng phải nếm món ăn trước khi bưng lên cho ai đó. Những người lặng lẽ ship side project từ bàn cafe năm nay không thông minh hơn bạn. Họ đang follow một quy trình. Bài này là quy trình đó, viết cho người chưa bao giờ mở terminal.
"Vibe coding" thực sự là gì
Andrej Karpathy đặt tên cụm này tháng 2/2025: "Có một kiểu code mới mình gọi là 'vibe coding', bạn buông xuôi theo vibe, ôm lấy đường cong exponential, và quên rằng code thậm chí có tồn tại." Tweet gốc nửa đùa nửa thật. Hành vi nó mô tả thì rất thật.
Một năm sau, toolchain đã chín tới mức một người không phải dev có thể mô tả một app nhỏ bằng tiếng Anh — hoặc tiếng Việt — cho Claude Code hay Cursor, nhìn agent generate một folder đầy file, chạy một câu lệnh, rồi có một thứ chạy được trên laptop. Kỹ năng bạn cần không còn là biết viết code. Mà là biết mô tả rõ thứ mình muốn, nhận ra khi agent đi lạc, và backup công sức trước khi nó lạc.
Kỹ năng cuối cùng đó là toàn bộ lý do bài này tồn tại. Người thử vibe code một lần rồi bỏ gần như luôn là người bỏ qua một trong bảy bước dưới, đâm vào tường, rồi kết luận "AI code chưa hợp với mình". Nó hợp. Bạn chỉ cần làm cả phần chán nữa thôi.
Bảy bước không thể bỏ
Bảy bước này không phải tùy chọn. Bỏ bất kỳ bước nào, cuối cùng bạn có một app gãy lúc 11 giờ tối Chủ Nhật và không biết prompt nào đã làm nó gãy.
1. Bắt đầu bằng một mục tiêu cụ thể, không phải một vibe
Yếu tố dự báo lớn nhất xem session vibe code có kết thúc ra cái gì hay không là câu đầu tiên bạn gõ. "Làm cho tôi một app" thất bại. "Làm một trang web có ô paste link YouTube, trả về tóm tắt một đoạn văn" thành công. Agent rất giỏi cái thứ hai và bó tay với cái thứ nhất.
Prompt khởi đầu tốt có ba thứ: input (user gõ hoặc upload gì), output (cái gì hiện trên màn hình), và khoảnh khắc thành công (chính xác điều gì nghĩa là "nó chạy"). Nếu bạn chưa viết được ba câu đó cho ý tưởng của mình, bạn chưa sẵn sàng gõ — bạn sẵn sàng để nghĩ thêm mười phút nữa.
2. Chọn stack mà bạn không cần thấy mặt
Đừng nhảy vào cuộc chiến tôn giáo về stack. Đừng Google "Next.js vs Astro vs Remix". Bảo agent: "Chọn cho tôi stack nào dễ setup và chạy được trên laptop. Tôi không quan tâm là cái nào." Nó sẽ chọn cái hợp lý. Bạn sẽ không nhìn thấy phần lớn code đâu. Stack thật sự không quan trọng cho mười project đầu tiên.
Cái bẫy ở đây là đi shopping tool thay vì xây. Hai tiếng xem YouTube so sánh framework là hai tiếng bạn không ship được gì. Cứ chọn theo agent.
3. Bắt đầu từ một scaffold đã chạy được
Folder rỗng cộng "build cho tôi X" là chế độ khó. Agent phải tự nghĩ ra mọi thứ, và lỗi nào cũng cộng dồn. Chế độ dễ là: bảo agent clone một starter, hoặc dùng một template như Next.js starter, hoặc dán một skeleton Bolt.new / v0 mà bạn đã thấy chạy trên trình duyệt.
Prompt đầu tiên trong terminal nên cho ra một folder mà npm run dev (hoặc câu lệnh agent bảo) mở được một trang thật trong trình duyệt. Nếu không tới được trang đó trong mười phút, dừng lại. Restart. Chọn scaffold nhỏ hơn. Cả quy trình còn lại phụ thuộc vào việc bạn có một baseline chạy được để quay về.
4. Commit sau mỗi bước chạy được (đúng, bạn cần git)
Đây là chỗ gần như mọi người đang "thử AI coding" sa lầy. Agent đổi một thứ, một thứ khác gãy, bạn bảo nó fix, nó lại làm gãy thứ khác, ba vòng sau bạn không còn biết project đang ở state nào nữa. Bạn xoá project. Bạn bỏ cuộc.
Cách chữa là git, và bạn không cần hiểu sâu. Bạn cần đúng bốn lệnh, agent sẽ set up cho bạn trong khoảng ba phút:
git init— chạy một lần cho mỗi project, ngay từ đầugit add .— đánh dấu trạng thái hiện tạigit commit -m "vừa làm gì"— lưu một snapshot để có thể quay vềgit checkout .— Tôi làm hỏng hết rồi, xoá mọi thay đổi từ lần lưu gần nhất
Câu thứ tư là câu mua hết can đảm cho bạn. Cứ thứ gì chạy được, commit ngay. Rồi thí nghiệm. Nếu cái tiếp theo gãy, vứt đi và bạn trở về phiên bản chạy được. Người dùng git mạnh tay không bao giờ mất công sức; người không dùng thì sớm muộn cũng mất.
5. Test ngay sau mỗi thay đổi nhỏ
Bug bạn fix được là bug bạn phát hiện 30 giây sau khi nó xuất hiện. Bug huỷ buổi tối của bạn là bug đã lén lút vào hai thay đổi trước, lúc bạn đang tập trung vào tính năng khác. Mỗi thay đổi → reload trang → còn chạy không? → thay đổi tiếp theo.
Nghe có vẻ phiền. Không hề. Đó là khác biệt giữa fix năm phút và sa lầy ba tiếng. Agent không bao giờ tự nói cho bạn biết một tính năng cũ vừa bị gãy. Chỉ có bạn bắt được điều đó.
6. Đọc thông báo lỗi — chỉ vậy thôi, chỉ thông báo lỗi
Bạn không cần đọc code. Bạn rất cần đọc chữ đỏ. Lỗi là thứ agent cần để fix. Copy nguyên thông báo lỗi, dán vào chat, nói "lỗi này xảy ra khi tôi bấm save, please fix". Agent gần như luôn xử được.
Chỗ này hay fail: người ta lướt qua lỗi, paraphrase ("có cái gì đó hỏng khi save"), agent đoán sai. Copy nguyên văn. Toàn bộ. Kể cả stack trace nếu có. Năm giây paste dài hơn, một tiếng "sao nó không chạy" ngắn lại.
7. Biết khi nào dừng và mô tả lại
Nếu bạn prompt agent năm lần liên tiếp về cùng một vấn đề mà nó vẫn gãy, agent không phải vấn đề. Prompt mới là. Bạn đang yêu cầu agent fix triệu chứng và nó không nhìn ra bệnh. Dừng. Lùi lại. Mở chat mới. Mô tả cả tính năng đó từ đầu, kèm những gì đã thử và lý do không work.
Một rule hữu ích: bất kỳ tính năng đơn lẻ nào đã ngốn hơn 45 phút qua lại đều nên scope lại hoặc vứt đi. Chi phí làm lại tính năng đó gần như luôn nhỏ hơn chi phí cố cứu vớt.
Ba cái bẫy bắt mọi người mới
Một danh sách ngắn các pattern bọn mình thấy bạn bè sa vào. Cảnh báo trước thì đỡ một nửa.
Bẫy "gần được rồi". App bạn chạy với happy path — paste URL, ra tóm tắt. Nhưng nó crash với input rỗng, hoặc URL không phải YouTube, hoặc khi bấm hai cú nhanh. Mỗi edge case bạn tặc lưỡi "để mai fix" là một cái rồi sẽ ship cho người thật. Quyết định trước khi bắt đầu edge nào bạn quan tâm. Project đầu tiên có thể chỉ là "happy path thôi" — nhưng nói rõ ra.
Bẫy "thêm cái này nữa". Bạn muốn một timer Pomodoro. Nó chạy. Giờ bạn muốn thêm âm thanh. Rồi theme. Rồi tài khoản. Rồi bảng xếp hạng. Mỗi thứ thêm vào nhân ba bề mặt bug. Kỷ luật nói "version này xong rồi, ý tưởng tiếp theo là project mới" là khác biệt giữa ba app hoàn thành và một app dang dở.
Bẫy "mai deploy". Chạy trên laptop không giống chạy trên server. Có environment variable, có bước build, có domain, và hàng trăm lựa chọn nhỏ agent âm thầm chốt khi chạy local mà bạn phải nói rõ khi deploy. Deploy tính là project riêng — cho nó một buổi chiều riêng, đừng cố nhét vào cuối session build.
Project đầu tiên thực sự hoàn thành được
Sai lầm to nhất là chọn project quá lớn cho lần đầu. Ba ý tưởng nhỏ đủ để ship trong một tối, và trực quan đủ để khoe bạn bè.
Timer Pomodoro cá nhân với một twist. 25 phút làm, 5 phút nghỉ, kèm một twist chỉ quan trọng với bạn — một âm thanh từ bộ phim yêu thích, một màu chuyển từ xanh sang đỏ khi phút cạn dần, một task list reset mỗi vòng. Một user (bạn), không database, kết quả trực quan ngay.
Trang "tối nay ăn gì". Một nút bấm chọn ngẫu nhiên một món từ list bạn tự gõ. Thêm filter "đừng phải pasta". Thêm filter "đừng chọn món tôi ăn trong vòng tuần qua" — và học luôn local storage trên đường đi.
Generator "ý tưởng mỗi ngày". Chọn một chủ đề (đề bài viết, bài tập gym, bài tập vẽ), nhận một gợi ý mỗi ngày, kèm nút reroll. Bonus: copy link để share gợi ý của hôm nay với bạn.
Điểm chung của ba project này là chỉ hữu ích cho đúng một người — bạn — và có kết quả trực quan ngay lần load đầu. Đó là sweet spot cho lần build đầu.
Bộ tool tự thu hồi vốn
Bạn không cần nhiều tool. Bạn cần đúng tool.
- Agent trong vòng làm việc. Claude Code chạy trong terminal, code-aware nhất. Cursor là editor có chat built-in, thân thiện hơn cho người thiên visual. Chọn một, gắn bó một tháng trước khi đem so.
- Tool scaffold UI cho ngay. v0.dev hoặc Bolt.new cho bạn một interface chạy được trong trình duyệt trước cả khi bạn đụng laptop. Dùng một cái để prototype hình hài, rồi bảo agent recreate vào project local.
- Tài khoản GitHub miễn phí. Push project lên private repo sau mỗi commit quan trọng. Đây là backup ngoài laptop. Setup mất mười phút, agent dẫn bạn một lần, sau đó được bảo vệ mãi.
- Một chỗ deploy không cần config. Vercel và Netlify đều cho bạn trỏ vào repo GitHub và bấm "deploy". Với loại project đầu tiên mô tả ở trên, đây là hai phút setup.
Hết stack. Bạn không cần Docker. Không cần database cho project một. Không cần học khác biệt giữa npm và yarn cho tới ít nhất project bốn.
Khi không nên vibe code
Phần thành thật. Có những thứ vibe code thực sự không nên dùng, và lờ đi điều đó là cách người ta bị tổn thương. Đừng dùng app vibe-code để:
- Nhận tiền của người khác hoặc lưu thông tin thanh toán của họ.
- Lưu dữ liệu cá nhân người khác, đặc biệt thứ bị quản lý (sức khoẻ, tài chính, giấy tờ tuỳ thân).
- Chạy bất cứ thứ gì mà downtime ảnh hưởng tới người khác — một dịch vụ thật cho khách hàng, một API public người khác phụ thuộc.
Bạn hoàn toàn có thể prototype các thứ đó. Build checkout giả, dashboard sức khoẻ mô phỏng, flow thanh toán demo — là bài tập tuyệt vời và là project vibe code an toàn. Cái không an toàn là cầm prototype đó đưa cho người dùng thật như thể đó là product thật. Bước đó cần một engineer đọc code.
Tin tốt: với chín mươi phần trăm project cá nhân, tool nội bộ, ý tưởng cuối tuần, prototype "không biết cái này có hữu ích không" — không một ràng buộc nào ở trên áp dụng. Cứ vibe code thoải mái.
Đỉnh điểm của approach này trông như thế nào
Nếu muốn xem cách approach này đi xa tới đâu, hai pipeline open-source của team bọn mình về cơ bản là "18 tháng vibe code khi nó trưởng thành thành phần mềm ship được": FLOW KIT (studio YouTube AI một terminal) và FLOWBOARD (infinite canvas cho workflow video sản phẩm). Cùng quy trình vừa đi qua — mô tả mục tiêu, scaffold, commit, test, dừng và mô tả lại — đã tạo ra cả hai. Khác biệt giữa cái Pomodoro timer đầu tiên của bạn và FLOW KIT không phải tài năng. Là số reps.
Bài tập cuối tuần
Chọn một trong ba project đầu ở trên. Block hai tiếng sáng thứ Bảy. Cài Claude Code hoặc Cursor. Nói cho agent đúng mục tiêu cụ thể đó. Đi tới phiên bản chạy được. Commit. Dừng. Khoe một ai đó.
Nếu bạn ship được một thứ cuối tuần này, bạn đã vượt qua ranh giới duy nhất quan trọng. Mọi thứ sau chỉ là lặp lại.
Muốn xem ISEMI còn build gì khác, open-source umbrella là cửa chính. Nếu bạn làm gì đó với quy trình này, bọn mình muốn xem — thả link vào nhóm cộng đồng, hoặc tag bọn mình khi đăng.