Ảo tưởng vibe coding: app chạy được không có nghĩa là software

Ảo tưởng nguy hiểm nhất của vibe coding không phải là “AI sẽ thay dev”. Câu đó quá lớn, quá chung, và thường chỉ để tranh cãi. Ảo tưởng nguy hiểm hơn là câu nhỏ hơn: “app chạy rồi”.

App chạy trong browser. Button bấm được. Form submit. Chart hiện. Deploy có URL. Bạn gửi link cho bạn bè, mọi người bảo nhìn chuyên nghiệp. Cảm giác rất thật.

Nhưng software không chỉ là thứ mở được trên màn hình. Software là thứ có thể sống qua dữ liệu bẩn, user sai, network lỗi, deploy hỏng, secret bị lộ, permission lệch, schema đổi, và một người khác ngoài bạn phải maintain.

Vibe coding làm phần nhìn thấy xuất hiện rất nhanh. Vì vậy nó cũng làm phần chưa nhìn thấy dễ bị quên hơn.

Demo không phải bằng chứng

Demo trả lời một câu hỏi hẹp:

Ý tưởng này có thể nhìn như thế nào nếu mọi thứ đi đúng?

Software phải trả lời câu hỏi khó hơn:

Nó làm gì khi mọi thứ không đi đúng?

Hai câu hỏi này khác nhau hoàn toàn. Demo chỉ cần happy path. Software cần unhappy path, partial failure, quyền truy cập, data ownership, log, backup, rollback, deploy history, và người chịu trách nhiệm khi nó sai.

Vì vậy app vibe-coded chạy được chưa chứng minh bạn có sản phẩm. Nó chỉ chứng minh bạn có một trạng thái tốt trong một điều kiện kiểm soát.

UI là lớp dễ lừa nhất

UI có thể rất thuyết phục trong khi logic phía sau vẫn giả.

Login screen có thể chỉ accept email bất kỳ.
Table có thể đọc từ array local.
Chart có thể vẽ từ sample data.
Save button có thể update state trong browser, không gọi API.
Admin page có thể ẩn button nhưng backend vẫn cho update.
Success toast có thể hiện trước khi server confirm.

Người không code rất dễ bị UI thuyết phục, vì đó là phần họ nhìn thấy. Nhưng chính vì vậy, UI là nơi dễ tạo ảo tưởng nhất.

Một câu hỏi nên hỏi sau mỗi demo:

Nếu refresh, đổi user, tắt mạng, nhập dữ liệu sai, hoặc gọi API trực tiếp thì chuyện gì xảy ra?

Nếu chưa biết, app chưa được hiểu.

”Có deploy” không có nghĩa là production

Deploy cũng tạo ảo tưởng mạnh. Trước đây phải có dev, repo, build pipeline, server, domain. Bây giờ một agent có thể đẩy app lên một URL trong vài phút. Điều đó tốt. Nhưng URL không biến prototype thành production.

Production cần ít nhất:

Environment tách khỏi local.
Secret không nằm trong frontend.
Database không dùng bảng test chung với user thật.
Log có thể đọc được sau khi lỗi xảy ra.
Rollback có đường quay lại.
Error tracking biết version nào đang crash.
Người owner biết khi nào phải dừng deploy.

Nếu thiếu các điểm đó, bạn có hosted prototype. Không sao cả. Chỉ cần gọi đúng tên.

Ảo tưởng ownership

Một rủi ro khó nói hơn: bạn tưởng mình sở hữu app vì bạn prompt ra nó. Nhưng ownership trong software không phải cảm giác “tôi tạo ra”. Ownership là khả năng trả lời khi app hỏng.

Bạn có trả lời được không:

Dữ liệu đang nằm ở đâu?
Auth check nằm ở frontend hay backend?
Nếu user A thấy data user B, sửa ở layer nào?
Nếu deploy mới hỏng, rollback bằng gì?
Nếu API key lộ, rotate ở đâu?
Nếu agent sửa sai, file nào phải revert?

Nếu không trả lời được, bạn chưa thật sự sở hữu app. Bạn chỉ sở hữu prompt và kết quả tạm thời.

Đây không phải lý do để dừng vibe coding. Đây là lý do để thêm checkpoint.

Một test rất thô nhưng hiệu quả

Trước khi gọi một app là “xong”, thử checklist này:

Tạo một record thật, refresh page, record còn không?
Đăng nhập user khác, data có tách không?
Nhập dữ liệu sai, app có chặn đúng không?
Tắt mạng, app có báo lỗi thật không?
Mở devtools Network, có request thật không?
Xóa sample data, app còn chạy đúng không?
Deploy bản mới lỗi, bạn có rollback được không?
Log có đủ để biết lỗi xảy ra ở đâu không?
Secret có nằm trong code frontend không?
Có ai ngoài agent đọc diff chưa?

Nếu phần lớn câu trả lời là “không biết”, app chưa sẵn sàng. Không cần xấu hổ. Chỉ cần đổi label từ “xong” thành “prototype”.

Prompt để phá ảo tưởng

Sau khi agent build xong, đừng hỏi:

Is it done?

Hỏi như này:

List everything that is still fake, mocked, local-only, untested, or unsafe for real users.
Do not fix yet.
Separate prototype limitations from production blockers.

Prompt này biến agent từ người bán demo thành người audit demo. Câu “do not fix yet” quan trọng, vì nếu không agent sẽ sửa vội và lại tạo thêm ảo tưởng mới.

Sau đó mới chọn một blocker để xử lý.

Chốt lại

Vibe coding mạnh vì nó rút ngắn đường từ ý tưởng tới feedback. Nhưng chính tốc độ đó làm bạn dễ nhầm “có thứ để xem” với “có thứ để vận hành”.

App chạy được là một milestone. Không phải kết luận.

Nếu bạn giữ được câu này trong đầu, vibe coding vẫn rất đáng dùng: demo nhanh, học nhanh, validate nhanh. Nhưng mỗi lần app nhìn quá thật, hãy tự hỏi phần nào vẫn đang giả. Câu hỏi đó là ranh giới giữa prototype có kiểm soát và ảo tưởng software.