Hầu như ai dùng AI đủ lâu cũng biết một câu:

AI có thể sai.

Câu này đúng. Nhưng chưa đủ.

Biết AI có thể sai không tự động giúp bạn bắt lỗi. Vấn đề không phải awareness. Vấn đề là verification skill.

Nhiều người biết phải cẩn thận, nhưng khi app AI-built chạy được, họ vẫn không biết phải kiểm gì tiếp theo.

Vibe coding chuyển trọng tâm từ prompt sang verify

Một nghiên cứu gần đây về vibe coding practices mô tả cách người dùng tạo software bằng natural-language prompts và thường evaluate output chủ yếu bằng execution: chạy thử xem có hoạt động không.

Đó là điểm bắt đầu hợp lý. Nhưng execution chỉ là tầng đầu.

Một app có thể chạy mà vẫn:

  • Dùng mock data.
  • Bỏ auth.
  • Không lưu database.
  • Không xử lý error.
  • Leak data giữa hai user.
  • Sai business rule.
  • Không deploy được.
  • Phá flow cũ.
  • Chỉ pass vì test quá nông.

Prompt tốt giúp AI viết. Verify tốt giúp bạn biết thứ vừa viết có đáng tin không.

Verification ladder cho non-tech

Bạn không cần nhảy thẳng vào code review. Có thể đi theo thang:

  1. Click test: dùng flow chính từ đầu tới cuối.
  2. Refresh test: reload page sau khi tạo data.
  3. Empty test: dùng app khi chưa có data.
  4. Bad input test: nhập sai, thiếu, trùng.
  5. Mobile test: mở viewport nhỏ.
  6. Second-user test: account A không thấy data account B.
  7. Network test: tắt mạng hoặc làm API fail nếu có thể.
  8. Log test: xem app có báo lỗi thật không.
  9. Diff test: xem agent có sửa ngoài scope không.
  10. Deploy test: mở public preview, không chỉ local.

Mỗi tầng bắt một nhóm lỗi khác nhau. Không tầng nào thay thế tầng nào.

Đừng hỏi “ổn chưa”, hỏi “verified bằng gì”

Prompt yếu:

Check if everything is good.

Prompt tốt hơn:

Audit this change.
Classify every claim as:
- verified by command
- verified manually
- inferred from code
- assumed
- not implemented
Include the command output or manual steps for verified claims.
Do not mark anything verified without evidence.

Từ “verified” phải có bằng chứng đi kèm. Nếu không, nó chỉ là cảm giác.

Tách builder và auditor

Nếu cùng một agent vừa build vừa tự tuyên bố pass, bạn có rủi ro confirmation bias.

Trong workflow nhỏ, vẫn có thể tách vai bằng prompt:

You are now the auditor, not the builder.
Do not edit files.
Find ways this implementation can fail.
Focus on auth, data persistence, edge cases, mobile, deploy, and unrelated changes.

Nếu có nhiều agent, càng nên tách:

  • Agent 1 build.
  • Agent 2 audit diff.
  • Agent 3 test browser.
  • Human owner quyết định ship.

Không cần làm nặng cho mọi prototype. Nhưng với data thật, auth thật, payment thật, tách vai là rẻ hơn sửa hậu quả.

Verification report mẫu

Yêu cầu agent trả report như sau:

## Verified
- Build: pass, command output included.
- Main flow: pass, browser steps listed.

## Failed
- Mobile menu overlaps title at 375px.

## Unknown
- Payment webhook not tested because no test credential.

## Assumed
- User role mapping based on README, not verified against API.

## Not implemented
- Password reset flow.

Unknown không phải xấu. Unknown là trung thực.

Claim nguy hiểm nhất là claim không có bằng chứng nhưng được viết như chắc chắn.

Chốt lại

Biết AI có rủi ro là mức nhập môn. Biết verify mới là kỹ năng làm vibe coding hữu ích.

Nếu bạn là non-tech, đừng cố đọc toàn bộ code ngay ngày đầu. Hãy bắt đầu bằng verification ladder: click, refresh, bad input, second user, mobile, deploy, log, diff.

Vibe coding có kiểm soát không phải prompt hay hơn người khác. Nó là khả năng bắt AI chứng minh những gì nó vừa nói.

Tham khảo