Vibe coding là gì: làm web không cần biết code

Một chị làm kế toán cho một công ty nội thất, ngoài giờ nhận thêm việc tính lương cho ba tiệm nhỏ. Chị muốn một trang web nhỏ để khách điền thông tin nhân viên rồi chị xuất ra bảng lương. Chị không biết lập trình. Ngồi với Lovable khoảng bốn tiếng, chị đã có giao diện chạy được. Đến lúc nối cơ sở dữ liệu thật và phân quyền đăng nhập thì dừng lại, vì không ai nói cho chị biết chỗ đó khó ở đâu.

Vibe coding là gì? Nói gọn: bạn mô tả bằng tiếng Việt thứ mình muốn, trợ lý AI viết mã, bạn xem kết quả rồi mô tả tiếp. Bạn không gõ từng dòng lệnh. Nhưng bạn vẫn phải quyết định mọi thứ về sản phẩm.

Vibe coding thực chất là gì

Cụm từ này do Andrej Karpathy nói ra đầu năm 2025, đại ý: bạn buông tay khỏi bàn phím, nhìn màn hình, nói ý muốn, chạy thử, sai thì nói lại. Nghe như một trò chơi. Thực tế nó là một cách làm việc, có quy trình và có chỗ chết người.

Điểm khác biệt so với "học lập trình cho biết" không nằm ở chỗ bạn có học hay không. Nó nằm ở chỗ bạn chịu trách nhiệm về cái gì. Người viết code chịu trách nhiệm về từng dòng. Người vibe code chịu trách nhiệm về kết quả: trang có chạy không, dữ liệu có mất không, khách có thanh toán được không.

Ba lớp công việc trong một dự án kiểu này, và rất nhiều người gộp cả ba làm một rồi tắc:

Chỗ người mới chết thường là lớp thứ ba. Không phải vì khó hiểu, mà vì nó nằm ngoài khung chat: bạn phải mở một trang khác, tạo tài khoản, dán khóa API, đặt biến môi trường. AI không bấm hộ bạn mấy nút đó.

Viết yêu cầu cho AI: đây mới là kỹ năng chính

Yêu cầu kiểu "làm cho tôi trang quản lý công việc đẹp đẹp" cho ra một cái gì đó trông ổn và vô dụng. Không phải AI kém. Yêu cầu không có thông tin.

Một yêu cầu dùng được phải trả lời được bốn câu.

Ai dùng, dùng để làm gì. "Nhân viên sale mở trang này mỗi sáng để xem đơn nào quá hạn giao." Câu này quyết định màn hình đầu tiên hiện gì.

Dữ liệu gồm những trường nào, kiểu gì. Không phải "thông tin khách hàng" mà là: tên (chữ, bắt buộc), số điện thoại (10 số, bắt buộc, không trùng), ngày sinh (có thể trống), ghi chú (chữ dài, không bắt buộc).

Chuyện gì xảy ra khi sai. "Nếu số điện thoại đã có trong hệ thống thì báo lỗi ngay dưới ô nhập, không cho lưu." Đây là phần AI hay bỏ qua nếu bạn không nói.

Một ví dụ cụ thể bằng số. "Đơn có hạn giao 20/10, hôm nay 23/10 thì hiện dòng màu đỏ, chữ 'Trễ 3 ngày'." Có ví dụ số, AI làm đúng ngay từ lần đầu. Không có, bạn sửa năm lần.

Mình hay khuyên chia yêu cầu thành từng miếng nhỏ, mỗi miếng một màn hình hoặc một chức năng. Yêu cầu một lúc mười chức năng thì AI sẽ làm hời hợt cả mười, và bạn không biết lỗi nằm ở đâu khi có chuyện.

Một mẹo nữa: đưa dữ liệu mẫu ngay trong câu lệnh. Thay vì nói "tạo bảng danh sách sinh viên", dán vào ba dòng thật:

Nguyễn Văn A | 21 | CNTT | 3.2
Trần Thị B | 20 | Kế toán | 3.6
Lê Văn C | 22 | CNTT | 2.8

AI sẽ dựng đúng cột, đúng kiểu dữ liệu, và bạn nhìn ra ngay nếu nó hiểu sai.

Bốn nhóm công cụ, chọn theo việc chứ không theo lời quảng cáo

Thị trường này đổi liên tục. Mấy cái tên dưới đây là những cái đang dùng được, nhưng đừng chọn theo bài giới thiệu của chính họ.

Với người mới, mình thấy Lovable và Bolt.new dễ vào nhất: gõ mô tả, vài phút có trang. Nhưng có một chỗ đau mà ít bài viết nói: khi bạn đã sửa hai chục lượt, AI bắt đầu quên những yêu cầu đầu tiên. Nó sửa cái nút, phá cái form. Cách chữa là yêu cầu AI viết ra một tệp ghi chú quy ước của dự án, rồi mỗi lần mở phiên mới bảo nó đọc tệp đó trước. Nghe thủ công, nhưng nó tiết kiệm cả buổi.

Cursor và Claude Code thì khác hẳn về cảm giác. Bạn làm việc trong thư mục dự án thật, AI đọc nhiều tệp cùng lúc và sửa tại chỗ. Đổi lại bạn phải cài Node, phải biết mở terminal, phải hiểu đại khái tệp nào làm gì. Không khó, nhưng không dành cho người muốn "làm trong buổi sáng".

Phần khó nhất: dữ liệu, đăng nhập, thanh toán

Đây là đoạn mà dự án của phần lớn người mới dừng lại. Không phải vì công cụ dở. Vì ba thứ này liên quan đến tài khoản bên ngoài và tiền.

Cơ sở dữ liệu. Supabase là lựa chọn phổ biến vì có bản miễn phí đủ dùng để học. Bạn tạo dự án, nó cho bạn một đường dẫn và một khóa. Dán hai thứ đó vào phần cấu hình của ứng dụng. Một lỗi kinh điển: dán nhầm khóa công khai vào chỗ cần khóa bí mật, hoặc ngược lại. Trang vẫn chạy, nhưng không đọc được dữ liệu, và thông báo lỗi không nói gì về chuyện đó.

Đăng nhập. Bật xác thực bằng email trong Supabase, chọn nhà cung cấp, khai đường dẫn chuyển về sau khi đăng nhập. Đường dẫn này phải khớp chính xác với tên miền bạn dùng, kể cả http hay https. Lệch một chữ là vòng đăng nhập quay mãi.

Thanh toán. Stripe có chế độ thử, dùng số thẻ 4242 4242 4242 4242 để kiểm tra. Đừng bao giờ thử bằng thẻ thật trước khi mọi thứ khác chạy đúng. Và có một điều luật sư nào cũng sẽ nhắc: thu tiền của người khác trên web của mình thì phải có trang điều khoản, chính sách hoàn tiền, thông tin liên hệ rõ ràng. Không phải thủ tục cho có.

Ví dụ một lần hỏng thật: một bạn làm trang bán tài liệu, thanh toán chạy, nhưng sau khi trả tiền khách không nhận được link tải. Nguyên nhân là webhook của Stripe trỏ về địa chỉ localhost. Trên máy bạn thì đúng, trên mạng thì không có gì ở địa chỉ đó. Lỗi mất hai ngày để tìm ra, sửa mất hai phút.

Đưa lên mạng: ba nút bấm và một tên miền

Xuất mã lên GitHub, nối GitHub với Vercel hoặc Netlify, mỗi lần đẩy mã mới thì web tự cập nhật. Phần này các nền tảng đã làm rất tốt, gần như không cần hiểu gì sâu.

Mấy chỗ vấp hay gặp:

Biến môi trường phải khai riêng trên Vercel, không tự theo mã lên. Quên bước này là web báo lỗi trắng trang, mà nhật ký build vẫn xanh.

Tên miền mua ở đâu cũng được, nhưng bản ghi DNS phải trỏ đúng. Đổi tên miền xong nhớ khai lại đường dẫn chuyển về trong phần đăng nhập, nếu không người dùng đăng nhập xong bị đá về trang cũ.

Và hãy chuẩn bị tinh thần: bản đầu tiên sẽ chậm. Không sao. Nhưng nếu bạn định gửi link cho khách, kiểm tra trên điện thoại thật, không chỉ thu nhỏ cửa sổ trình duyệt trên máy tính.

Bảng kiểm trước khi cho người khác dùng

Đây là phần mình thấy đáng giá nhất trong bất kỳ tài liệu nào về chủ đề này, vì nó biến một đống cảm hứng thành danh sách việc làm được.

Trước khi gửi link cho người ngoài, đi qua mười lăm mục sau. Không mục nào là lý thuyết.

Về dữ liệu

1. Đã bật chế độ bảo vệ dòng dữ liệu, người dùng chỉ đọc được dữ liệu của chính họ chưa?
2. Đã thử xóa một bản ghi và kiểm tra nó mất thật chưa?
3. Có ai đó nhập số điện thoại trùng thì hệ thống báo gì?
4. Đã sao lưu thử một lần chưa, và biết cách phục hồi chưa?

Về đăng nhập 5. Đăng xuất xong bấm nút Back của trình duyệt, có vào lại được trang riêng không? 6. Mở link riêng trong cửa sổ ẩn danh, có bị chặn không? 7. Quên mật khẩu thì thư có tới không, hay rơi vào thư rác?

Về tiền 8. Đã chạy một giao dịch thử bằng chế độ thử nghiệm chưa? 9. Sau khi thanh toán, người mua nhận được gì, bằng cách nào, trong bao lâu? 10. Hoàn tiền thì làm thế nào, có ai ghi lại quy trình chưa?

Về nội dung và pháp lý 11. Có trang điều khoản, chính sách riêng tư, thông tin liên hệ chưa? 12. Ảnh và chữ trên trang có phải của mình không?

Về vận hành 13. Khi trang lỗi, bạn biết xem nhật ký ở đâu chưa? 14. Tên miền đã trỏ đúng và có HTTPS chưa? 15. Đã thử trên một chiếc điện thoại thật, mạng 4G, chưa?

Mình biết nhiều người bỏ qua mục 5 và 9. Hai mục đó là hai mục gây thiệt hại thật.

Những chỗ vibe coding không cứu được bạn

Có ba loại việc mà mô tả giỏi đến đâu cũng không xong.

Thứ nhất là quyết định sản phẩm. AI không biết khách của bạn có chịu trả 200 nghìn hay không. Nó cũng không biết chức năng nào nên bỏ.

Thứ hai là bảo mật ở mức nghiêm túc. Với một trang nhỏ, vài người dùng, các nền tảng lo được phần lớn. Nhưng nếu bạn giữ dữ liệu sức khỏe, dữ liệu thanh toán của hàng nghìn người, thì cần người có nghề rà lại. Vibe code không thay được việc đó, và cũng đừng tin lời AI nói "đã bảo mật".

Thứ ba là bảo trì dài hạn. Sáu tháng sau bạn mở lại, mã đã lộn xộn vì ba chục lượt sửa chồng lên nhau. Không có cách nào tránh hoàn toàn. Cách giảm nhẹ: mỗi lần sửa xong một chức năng, nhờ AI ghi lại nó làm gì trong một tệp ghi chú, và giữ tệp đó tử tế. Nghe chán. Nhưng nó là khác biệt giữa dự án sống được và dự án phải làm lại từ đầu.

Một hạn chế nữa ít ai nói: vibe coding dạy bạn rất ít về lập trình. Bạn làm được sản phẩm, nhưng nền tảng vẫn trống. Nếu sau này muốn đi sâu, bạn sẽ phải học lại từ đầu những thứ mình đã "làm được" bằng cách nhờ vả.

Nếu bạn muốn đi theo hướng này một cách có thứ tự

Con đường mình thấy hiệu quả nhất cho người ngoại đạo, gói trong khoảng hai tuần lúc rảnh:

Ngày 1–2: dựng một trang một màn hình, có form nhập và bảng hiển thị, chưa cần lưu dữ liệu. Mục tiêu là làm quen với việc mô tả và sửa.

Ngày 3–5: nối cơ sở dữ liệu, cho dữ liệu lưu lại thật. Đây là lúc hiểu dòng, cột, khóa.

Ngày 6–8: thêm đăng nhập, chia hai vai, mỗi vai thấy dữ liệu khác nhau. Tập trung vào phần kiểm tra quyền, đừng bỏ qua.

Ngày 9–11: thêm một luồng thanh toán ở chế độ thử, rồi tự đóng vai người mua đi hết một vòng.

Ngày 12–14: đưa lên mạng với tên miền thật, chạy bảng kiểm mười lăm mục ở trên.

Làm theo trình tự này, bạn sẽ hỏng vài lần, nhưng hỏng ở chỗ nhỏ và biết vì sao. Làm gộp cả năm bước trong một buổi thì thường ra một trang đẹp, chạy được trên máy mình, và không dùng được cho ai.

Nếu bạn muốn có sẵn lộ trình chi tiết thay vì tự mò từng bước, cuốn Hướng dẫn sử dụng Vibe Coding là bản song ngữ Việt – Anh 292 trang, đi qua đúng mười chương: vibe coding là gì, cách viết yêu cầu, rồi từng công cụ Lovable, Bolt.new, v0, Replit, Cursor, Claude Code; phần dữ liệu và đăng nhập với Supabase, thanh toán thử với Stripe; sau cùng là đưa lên GitHub, Vercel, Netlify, đọc nhật ký lỗi và bảng kiểm mười lăm mục kèm mẫu lời nhắc dùng lại được. Giá 219.000 đồng.

Trên trang sản phẩm có 5 trang xem trước để bạn mở ra đọc trước khi quyết định: mục lục, một chương về cách viết yêu cầu, và phần bảng kiểm. Xem xong thấy không hợp thì thôi, đừng mua.

Thanh toán bằng chuyển khoản trong nước, không cần thẻ quốc tế. Đặt xong thì nhận hàng trong 24 giờ, file PDF gửi qua email bạn đã điền.