Vibe coding nghe như một trò đùa: mô tả app bằng vài câu, để AI dựng giao diện, sửa lỗi qua chat, rồi bấm preview xem chạy chưa. Nhưng nếu bỏ lớp meme đi, bên dưới là một thay đổi thật trong cách làm software. Người dùng không còn phải viết từng dòng code trước khi nhìn thấy sản phẩm chạy. Họ có thể bắt đầu từ ý tưởng, flow, screenshot, data mẫu, rồi điều khiển một vòng lặp build, test, feedback.

Điểm nguy hiểm cũng nằm ngay ở đó. Khi app chạy được sau vài phút, não mình dễ nhầm “chạy được” thành “đúng sản phẩm”, “đúng sản phẩm” thành “an toàn để ship”. Vibe coding có ích nếu nó rút ngắn vòng từ idea tới working software. Nó nguy hiểm nếu mình giao luôn product judgment, security, testing và quyết định ship cho AI.

Series này không cổ vũ chuyện non-tech tự build production app một mình. Nó cũng không phủ nhận giá trị của vibe coding. Cách đúng hơn là xem vibe coding như một workflow prototype mạnh: nhanh để nhìn thấy, nhanh để sai, nhanh để sửa, nhưng luôn có biên kiểm soát.

Vibe coding là gì

Vibe coding là cách làm app bằng natural language và feedback trực tiếp thay vì bắt đầu bằng code thủ công. Bạn nói với tool: “Tạo cho tôi app quản lý booking cho studio chụp ảnh, có danh sách khách, lịch hẹn, trạng thái cọc, ghi chú.” Tool tạo project, UI, state, đôi khi cả database, auth, deploy preview. Bạn mở app, click thử, thấy sai, rồi nhắn tiếp: “Form tạo booking thiếu số điện thoại, đổi status thành pending, confirmed, cancelled, và thêm filter theo ngày.”

Nó là một loop:

  • Nói mục tiêu.
  • Nhận bản chạy được.
  • Dùng thử như người dùng thật.
  • Chỉ ra điểm sai bằng feedback cụ thể.
  • Cho AI sửa.
  • Lặp lại cho tới khi đủ tốt hoặc phải dừng.

Trong workflow cũ, phần “nhìn thấy app chạy” thường đến sau khi đã setup repo, chọn framework, tạo component, nối route, build layout. Với vibe coding, phần đó đến rất sớm. Người không code có thể kiểm tra flow sản phẩm trước khi hiểu code bên dưới. Designer có thể thử interaction. Founder có thể validate admin dashboard. PM có thể biến requirement mơ hồ thành prototype để team tranh luận trên thứ nhìn thấy.

Nhưng “vibe” không có nghĩa là làm bằng cảm xúc mù. Nó có nghĩa là bạn steer bằng cảm giác sản phẩm: flow có tự nhiên không, form có thiếu trường không, màn hình có đúng job-to-be-done không, người dùng có biết bấm gì tiếp không. AI lo phần dựng nhanh. Bạn lo phần quyết định app có đúng việc cần làm không.

Khác no-code ở đâu

No-code truyền thống thường cho bạn một bộ block có sẵn: table, form, workflow, automation, database. Bạn kéo thả trong một môi trường đã được thiết kế để không cần code. Đổi lại, bạn bị giới hạn bởi block đó. Cái gì platform hỗ trợ thì làm nhanh. Cái gì lệch mô hình thì bắt đầu khó.

Vibe coding linh hoạt hơn vì AI có thể sinh code và chỉnh code. Bạn không chỉ cấu hình block có sẵn. Bạn có thể yêu cầu layout riêng, logic riêng, API riêng, rule riêng. Nhưng sự linh hoạt này đi kèm rủi ro: code có thể rối, dependency có thể thừa, mock data có thể giả, auth có thể hổng, deploy có thể chỉ đúng trong demo.

Nói ngắn: no-code giảm nhu cầu code bằng giới hạn platform; vibe coding giảm lực cản viết code bằng AI. No-code thường an toàn hơn trong phạm vi hẹp. Vibe coding mạnh hơn khi cần prototype custom, nhưng cần review kỹ hơn khi đi xa khỏi demo.

Khác autocomplete và pair programming ở đâu

IDE autocomplete như Copilot trong editor giúp developer viết nhanh từng dòng hoặc từng block code. Developer vẫn đang cầm lái ở mức code: mở file, chọn function, đọc type, chạy test, sửa diff. AI gợi ý phần tiếp theo.

Pair programming với AI cũng vậy, nhưng rộng hơn. Bạn chat với assistant trong repo, hỏi kiến trúc, nhờ sửa bug, nhờ viết test. Nó hỗ trợ dev trong workflow dev.

Vibe coding thường bắt đầu từ sản phẩm, không phải từ file. Người dùng nói “tôi cần app đặt lịch”, không nói “sửa BookingForm.tsx”. Tool tự scaffold nhiều phần trước. Với non-tech, đây là khác biệt lớn. Họ có thể bắt đầu bằng nhu cầu thật thay vì cấu trúc repo.

Nhưng khi prototype lớn lên, ranh giới sẽ đổi. Lúc đầu bạn vibe trong Replit, Lovable hoặc Bolt. Tới lúc cần review code, nối API thật, viết test, sửa deploy, bạn sẽ cần workflow giống AI coding hơn: Cursor, Codex, Claude Code, GitHub Copilot cloud agent, hoặc một developer thật cầm repo.

Khác background coding agent ở đâu

Background coding agent như GitHub Copilot cloud agent hoặc Codex cloud phù hợp hơn với repo đã tồn tại. Bạn giao issue, agent đọc code, tạo plan, sửa branch, chạy test, mở PR hoặc trả diff. Đây không còn là “tôi muốn một app booking đẹp đẹp”. Đây là “trong repo này, thêm filter theo trạng thái vào trang booking, dùng API hiện có, không sửa schema”.

Vibe coding prompt-to-app phù hợp với giai đoạn mơ hồ: khám phá sản phẩm, prototype nhanh, thử interaction. Background agent phù hợp với giai đoạn repo có luật: branch, diff, test, PR, review. Cả hai đều là AI coding, nhưng độ chín của project khác nhau.

Một failure mode phổ biến là dùng sai tool cho sai giai đoạn. Dùng prompt-to-app để sửa production repo dễ tạo rewrite ngoài ý muốn. Dùng background agent để khám phá ý tưởng chưa rõ sẽ tốn nhiều vòng vì agent phải đoán requirement. Hãy chọn theo trạng thái sản phẩm, không theo tool đang hot.

Replit, Lovable, Bolt nằm ở đâu

Các tool như Replit Agent, Lovable, Bolt thường được nhắc tới nhiều trong vibe coding vì chúng giảm setup. Bạn có thể mô tả app, xem preview, yêu cầu sửa, và trong một số trường hợp nối database, auth, deploy hoặc GitHub sync. Tính năng cụ thể thay đổi theo thời gian và theo plan, nên trước khi viết hoặc ship thật phải kiểm tra docs hiện tại của từng tool.

Điểm chung của nhóm này là làm idea-to-preview rất nhanh. Điểm cần cảnh giác là ownership. Code nằm ở đâu? Có export được không? Có sync GitHub không? Database do ai quản lý? Secrets cất ở đâu? Có rollback không? Có branch hoặc checkpoint không? Khi hết credit hoặc đổi platform thì project đi tiếp thế nào?

Nếu chỉ demo một flow cho khách hàng nội bộ, những câu hỏi này có thể nhẹ. Nếu định dùng làm app thật cho data thật, chúng là câu hỏi bắt buộc.

Chuyên môn không biến mất, nó đổi chỗ

Vibe coding không xóa expertise. Nó chuyển expertise từ “tôi tự viết từng dòng code” sang năm việc khác.

Thứ nhất là goal setting. Bạn phải biết app này phục vụ ai, job-to-be-done là gì, flow nào quan trọng nhất. Nếu mục tiêu mơ hồ, AI sẽ tạo một app nhìn có vẻ đầy đủ nhưng lệch việc.

Thứ hai là context. AI cần screenshot, data mẫu, rule nghiệp vụ, edge case, brand note, constraint. Không đưa context thì nó invent. Invent requirement là cách prototype thành ảo giác sản phẩm.

Thứ ba là review. Bạn phải mở app và dùng thử. Không chỉ nhìn homepage. Tạo record, sửa record, xóa record, refresh trang, thử mobile, thử empty state, thử lỗi validation.

Thứ tư là testing. Với non-tech, testing ban đầu có thể là checklist thủ công. Với team dev, phải có unit test, integration test, e2e hoặc ít nhất là build/typecheck. Không có test thì mỗi prompt sau có thể phá prompt trước.

Thứ năm là ship decision. AI có thể nói “done”. Tool có thể hiện preview xanh. Nhưng người quyết định ship phải là bạn hoặc team có trách nhiệm. Data khách hàng, payment, auth, permission, legal, rollback không thể giao cho cảm giác.

Một ví dụ nhỏ

Prompt mơ hồ:

Build me a CRM for my photography studio.

AI có thể tạo dashboard, list khách hàng, biểu đồ doanh thu, login giả, vài card đẹp. Nhìn ổn, nhưng chưa chắc giúp studio vận hành.

Prompt có kiểm soát hơn:

Build a small web app prototype for a photography studio owner.

Main user: studio owner, not a developer.
Main job: track upcoming bookings and deposit status.

Core flow for first version:
1. View bookings in a table.
2. Add a booking with customer name, phone, shoot date, package, deposit status, note.
3. Filter bookings by date and deposit status.
4. Edit booking note and deposit status.

Use sample data only for this first prototype and label it clearly as sample data.
Do not add payment, staff management, email automation, or analytics yet.
Keep the UI simple and mobile-friendly.
After building, tell me exactly what is mock and what must be replaced before production.

Prompt thứ hai không hay vì câu chữ đẹp. Nó hay vì giới hạn được bản đầu. Tool biết phải build gì, không build gì, và người dùng biết phần nào còn giả.

Khi nào nên dừng vibe coding

Dừng không có nghĩa là bỏ. Dừng nghĩa là chuyển mode.

Bạn nên dừng vòng vibe nếu agent sửa một lỗi ba lần vẫn sai, nếu mỗi yêu cầu nhỏ kéo theo rewrite lớn, nếu app bắt đầu có auth thật, data thật, payment thật, hoặc nếu bạn không còn hiểu thay đổi mới ảnh hưởng phần nào. Lúc đó cần checkpoint, export repo, mở diff, nhờ dev review, hoặc chuyển sang coding agent repo-aware với rule rõ.

Vibe coding tốt nhất ở đoạn tìm hình dạng sản phẩm. Khi hình dạng đã rõ, software cần kỷ luật quen thuộc: source control, test, review, deploy, rollback.

Checklist trước khi tin prototype

  • Tôi có biết user chính là ai không?
  • Tôi có biết flow quan trọng nhất là flow nào không?
  • Tôi đã click hết flow chính chưa?
  • Tôi có phân biệt mock data và real data chưa?
  • Tôi có biết auth, database, secrets nằm ở đâu không?
  • Tôi có checkpoint hoặc Git commit trước thay đổi lớn chưa?
  • Tôi có thể export hoặc chuyển repo đi nơi khác không?
  • Tôi đã ghi lại phần cần dev review chưa?

Nếu nhiều câu trả lời là “chưa”, prototype vẫn chỉ là prototype. Không sao cả. Biết nó là prototype đã là một nửa kiểm soát.

Chốt lại

Vibe coding là một cách rút ngắn vòng từ ý tưởng tới phần mềm chạy được. Nó không thay thế product thinking, testing, security hay trách nhiệm ship. Người dùng giỏi vibe coding không phải người prompt hoa mỹ. Là người biết chia nhỏ mục tiêu, cung cấp context đúng, test thật, phát hiện app đang tự lừa mình, và chuyển sang workflow nghiêm túc đúng lúc.