Vibe coding không xấu. Nó chỉ dễ tạo cảm giác tiến triển nhanh hơn thực tế. App nhìn đẹp hơn, file nhiều hơn, agent nói đã fix, nhưng core flow vẫn hỏng hoặc rủi ro nằm dưới lớp UI.

Checklist này để đọc trước khi bạn share link, merge code, hoặc giao prototype cho người khác. Nó không nhằm làm bạn mất hứng. Nó giúp bạn phân biệt prototype có kiểm soát với nợ kỹ thuật đang mặc áo demo.

1. Một prompt khổng lồ cho cả app

Prompt kiểu:

Build a complete SaaS with auth, payments, dashboard, admin, email, analytics, and deployment.

Nghe đã. Nhưng output sẽ rất khó review. Khi hỏng, bạn không biết hỏng vì auth, payment, dashboard hay database.

Cách sửa: chia thành lát mỏng. Mỗi lát có flow test được và checkpoint riêng.

2. Tin plan của agent mà không đọc scope

Agent có thể tạo plan rất hợp lý trên bề mặt. Nhưng plan có thể thêm feature bạn không yêu cầu: role system, settings page, chart, notification, queue, migration.

Trước khi approve plan, đọc câu hỏi này:

Plan này có đang giải quyết task hay mở thêm dự án?

Nếu mở thêm dự án, yêu cầu thu hẹp.

3. Không nói rõ thứ không được đổi

Bạn yêu cầu sửa form, agent đổi luôn layout. Bạn yêu cầu thêm export, agent đổi data model. Lỗi một phần do prompt thiếu constraint.

Prompt nên có:

Do not change auth, database schema, routes, styling system, or existing public flow.

Không phải lúc nào cũng cần dài, nhưng thay đổi rủi ro phải khóa rõ.

4. Quên checkpoint trước prompt rủi ro

Không có checkpoint nghĩa là mỗi prompt mới có thể phá app mà bạn không có đường quay lại.

Tạo checkpoint sau mỗi state tốt:

  • Flow chính chạy.
  • Build pass.
  • Data đúng.
  • UI mobile ổn.

Sau đó mới làm prompt tiếp.

5. Cứ “fix it” nhiều vòng

“Fix it” sau lỗi đầu tiên có thể được. Sau lỗi thứ ba, nó là anti-pattern. Agent có thể đang kẹt và mỗi vòng làm diff rối hơn.

Sau hai vòng không tiến triển:

Stop editing.
Summarize what failed, what you tried, and smallest next options.

6. UI nhìn đúng nhưng core flow fail

Landing đẹp, form đẹp, admin table đẹp. Nhưng submit không lưu data, export dùng sample rows, confirmation hiển thị state cũ.

Test bằng flow thật:

Enter new data.
Submit.
Confirm it appears in the next screen.
Reload if persistence is expected.
Export if export exists.

Đừng test bằng mắt ở màn hình đầu.

7. Không test mobile

Vibe-coded UI rất dễ đẹp ở desktop preview và vỡ ở mobile: button bị che, form quá rộng, keyboard làm layout nhảy, modal không scroll.

Trước khi share public, test mobile width. Không cần lab phức tạp. Chỉ cần mở responsive preview và đi hết flow chính.

8. Mock data bị quên trong app thật

Mock data có ích trong screen đầu. Nhưng nếu app chuẩn bị demo với người dùng thật, mock phải được gỡ hoặc đánh dấu rõ.

Search:

mock
dummy
sample
fake
placeholder

Nếu admin dashboard vẫn đọc array mẫu, bạn chưa có app thật. Bạn có ảnh minh họa.

9. Endpoint bị bịa

Agent không tìm thấy API nên tự gọi /api/bookings hoặc tự tạo route mới. Có thể chạy local, nhưng lệch backend thật.

Cách chặn:

Use existing APIs only.
If you cannot find the endpoint/hook, stop and ask.

Với repo thật, endpoint là contract. Không đoán.

10. Secret bị paste vào chat

API key, database URL, OAuth secret, token, cookie không nên vào chat. Nếu lỡ paste, coi như đã lộ và rotate.

Đúng hơn:

Use EMAIL_API_KEY from environment variables.
Do not include the real value in code, logs, docs, or chat.

11. .env thật bị commit

Một lỗi rất đời thường: agent tạo .env và Git stage luôn. Trước khi commit/share:

git status --short

Chỉ .env.example với placeholder nên được tracked. .env.local, .env.production, .env thật phải gitignored.

12. Auth đổi mà không review

Nếu agent thêm login, role, admin route, session, token refresh, hoặc permission check, cần review nghiêm túc.

UI hide không phải auth. Server/API/database phải kiểm tra quyền. Admin page không được chỉ dựa vào việc user không thấy link.

13. Database đổi mà không migration plan

Thêm bảng thì còn nhẹ. Xoá cột, đổi type, đổi enum, thêm cascade delete, đổi relation là vùng nguy hiểm.

Trước migration:

Explain schema change, data-loss risk, and rollback plan.
Do not run migration until approved.

Không hiểu migration thì đừng deploy.

14. File upload làm cho có

Upload không chỉ là input file. Cần size limit, type limit, storage access, error state, và không expose file private nhầm.

Nếu app cho upload public mà bạn chưa review storage rule, chưa public-ready.

15. Dependency mới không có lý do

Agent thêm package để xử lý việc nhỏ. Mỗi package thêm maintenance và risk.

Hỏi:

Why is this dependency needed?
What existing code or platform API cannot handle?
Where is it used?

Nếu câu trả lời không rõ, bỏ dependency.

16. Không xem diff trước khi accept

Preview đẹp không thay thế diff. Ít nhất phải xem file list. Task nhỏ mà diff động nhiều shared config là tín hiệu đỏ.

Checklist nhanh:

Files changed match task?
Lockfile changed?
Env file changed?
Schema changed?
Auth changed?
Deploy config changed?

17. Test chỉ nghe agent nói

“It passes” không đủ. Cần command hoặc manual step.

Prompt:

List exact verification steps and results.
If you could not run a test, say so clearly.

Sau đó tự click flow chính. Với non-tech, manual test vẫn là evidence tốt hơn summary mượt.

18. Không có owner sau prototype

App có user thật mà không ai chịu trách nhiệm là nợ. Ai quản lý secret? Ai deploy? Ai đọc bug report? Ai quyết định feature bị reject?

Nếu không có owner, giữ app ở mức demo nội bộ.

19. Không có rollback path

Trước khi share hoặc deploy:

Nếu prompt/deploy này làm hỏng app, quay lại bằng cách nào?

Nếu câu trả lời là “không biết”, dừng. Tạo checkpoint, commit, hoặc deploy rollback path trước.

20. Coi “AI nói đã fix” là bằng chứng

Agent có thể tự tin và sai. Evidence là build, test, screenshot, manual flow, diff đúng scope, hoặc log sạch.

Hãy tập phản xạ:

Show evidence, not confidence.

Checklist trước khi ship hoặc handoff

Đọc nhanh trước khi đưa app cho người khác:

Core flow đã test bằng data mới.
Mobile đã test.
Mock data đã gỡ hoặc đánh dấu.
Secrets không nằm trong chat/code/log.
.env thật không tracked.
Auth/database/payment/upload được review nếu có.
Diff đúng scope.
Dependency mới có lý do.
Rollback point tồn tại.
Owner được chỉ định.
Limitations được ghi rõ.

Nếu app chỉ là demo, bạn có thể ghi “prototype only” và share nội bộ. Nếu app public hoặc dùng data thật, checklist này là mức tối thiểu.

Chốt lại

Vibe coding biến ý tưởng thành app nhanh hơn. Nhưng nợ kỹ thuật cũng sinh nhanh hơn nếu bạn không đặt ranh giới. Hầu hết anti-pattern ở trên không cần kiến thức quá sâu để phát hiện. Chúng cần thói quen: đọc scope, tạo checkpoint, test flow thật, xem diff, giữ secret sạch, và biết khi nào phải gọi dev review.

Đừng dùng vibe coding như cách giao não cho AI. Dùng nó như một vòng build nhanh có phanh, có gương chiếu hậu, và có người cầm lái.