Demo đẹp có sức thôi miên. Nhất là với vibe coding, nơi bạn có thể đi từ một đoạn mô tả mơ hồ tới một app có màu sắc, card, chart, sidebar, animation và deploy URL trong một buổi.

Vấn đề không phải demo đẹp. Vấn đề là demo đẹp làm mọi người ngừng hỏi những câu xấu xí.

Data ở đâu? Auth thật chưa? Mobile có vỡ không? Empty state ra sao? User nhập sai thì sao? Flow chính có persist không? Có rollback không? Ai đọc diff? Những câu đó nghe kém vui hơn nhiều so với “wow nhìn chuyên nghiệp”.

Vì vậy demo đẹp nhất thường là demo nguy hiểm nhất: nó khiến prototype trông giống sản phẩm trước khi hành vi của nó đủ giống sản phẩm.

Đẹp làm giảm sức đề kháng

Một UI xấu khiến ai cũng nghi ngờ. Một UI đẹp khiến mọi người tự điền niềm tin vào chỗ trống.

Khi thấy dashboard có chart, não mình giả định có data pipeline. Khi thấy login screen, mình giả định có auth. Khi thấy admin page, mình giả định có permission. Khi thấy toast “Saved”, mình giả định server đã lưu.

AI rất giỏi tạo các tín hiệu bề mặt đó.

Nó có thể dựng:

  • Sidebar giống SaaS thật.
  • Avatar và role badge.
  • Loading spinner.
  • Empty state lịch sự.
  • Toast success.
  • Table filter.
  • Settings page.

Tất cả đều có thể là sân khấu. Sân khấu không xấu nếu bạn biết mình đang diễn. Nó nguy hiểm khi bạn tưởng đã xây nhà.

Demo càng mượt càng phải test bẩn

Sau một demo đẹp, việc đúng không phải là thêm polish. Việc đúng là làm nó xấu đi bằng test bẩn.

Thử:

  • Nhập tên dài 200 ký tự.
  • Bỏ trống field bắt buộc.
  • Submit hai lần liên tục.
  • Refresh giữa flow.
  • Dùng mobile nhỏ.
  • Tắt mạng sau khi bấm save.
  • Login bằng user không có quyền.
  • Mở cùng lúc hai tab.
  • Xóa record đang được edit.

Nếu app vẫn đứng được, demo bắt đầu có giá trị. Nếu app vỡ, bạn vừa phát hiện sự thật sớm.

Đừng để agent chỉ quay lại happy path. Vibe coding có kiểm soát cần biến happy path thành một trong nhiều path, không phải toàn bộ sự thật.

Một demo tốt phải nói phần chưa làm

Demo xấu nhất không phải demo nhiều bug. Demo xấu nhất là demo không nói mình còn giả ở đâu.

Một bản demo gửi stakeholder nên có phần ngắn:

Works now:
- Search by customer name
- Create booking
- Admin list updates after submit

Prototype-only:
- Auth is not implemented
- Payment is mocked
- Email is not sent
- Data is stored in local browser state

Not safe for production:
- No role permission
- No server-side validation
- No rollback plan

Non-tech vẫn đọc được. Dev vẫn audit được. Stakeholder không bị lừa bởi vẻ ngoài.

Nếu agent chỉ đưa link và nói “done”, hãy bắt nó viết đoạn này.

Cái bẫy của fake completeness

Vibe coding hay tạo fake completeness: app có đủ màn hình nên trông như xong.

Nhưng số màn hình không đo mức hoàn thiện. Một app có 12 page có thể chưa có flow nào thật. Một app có 2 page nhưng có auth thật, data thật, validation thật, log thật có thể đáng tin hơn nhiều.

Với non-tech, đây là bẫy lớn. Bạn nhìn vào sitemap và nghĩ sản phẩm đã rộng. Nhưng software chết ở contract nhỏ:

  • Field này có bắt buộc không?
  • Timezone xử lý thế nào?
  • User không có quyền thấy gì?
  • API lỗi trả message nào?
  • Record duplicate có bị chặn không?
  • Data cũ migrate ra sao?

AI có thể vẽ mặt tiền nhanh hơn rất nhiều so với việc đóng đinh từng contract này.

Review demo bằng câu hỏi phản cảm

Khi ai đó khoe một app vibe-coded đẹp, hãy hỏi vài câu phản cảm nhưng cần thiết:

  1. Phần nào đang mock?
  2. Nếu refresh, data còn không?
  3. Nếu user khác login, data có tách không?
  4. Nếu deploy lỗi, rollback ở đâu?
  5. Nếu khách dùng sai flow, app nói gì?
  6. Nếu API chậm 10 giây, UI ra sao?
  7. Nếu secret lộ, rotate thế nào?
  8. Ai chịu trách nhiệm đọc diff?

Đây không phải phá mood. Đây là đưa demo về đúng tầng của nó.

Prompt chống demo lừa mắt

Sau khi agent làm UI đẹp, dùng prompt này:

Audit this demo as if you are trying to disprove that it is production-ready.
List visual completeness signals that may be misleading.
Then list the smallest tests I should run manually to verify real behavior.
Do not add new features.

Prompt này buộc agent tách “looks complete” khỏi “works correctly”. Với vibe coding, tách được hai thứ đó là một nửa trận.

Chốt lại

Demo đẹp là tài sản tốt. Nó giúp người khác hiểu ý tưởng, góp ý nhanh, và quyết định có nên đi tiếp.

Nhưng demo đẹp không được quyền giả làm software trưởng thành. Càng đẹp càng phải ghi rõ phần nào chưa thật, test bẩn hơn, và bắt agent chỉ ra các điểm gây hiểu nhầm.

Một demo đẹp có kiểm soát sẽ nói: “Đây là thứ đang hoạt động, đây là thứ đang giả, đây là thứ chưa được phép dùng thật.”

Một demo đẹp nguy hiểm chỉ nói: “Xong rồi.”

Đọc thêm trong series