Sai lầm phổ biến nhất khi vibe coding là ném một prompt khổng lồ vào tool và chờ một app hoàn chỉnh. “Build me a marketplace with auth, seller dashboard, buyer checkout, payment, admin, analytics, notification, review system.” Mười phút sau bạn có một app nhìn rất bận rộn. Ba mươi phút sau bạn phát hiện login giả, checkout không xử lý lỗi, dashboard dùng mock data, admin sửa gì cũng mất sau refresh. Hai giờ sau bạn không còn biết sửa từ đâu.

Vấn đề không phải AI quá yếu. Vấn đề là bạn tạo review debt quá lớn. Một prompt quá rộng sinh ra quá nhiều thứ cần kiểm tra cùng lúc. Khi có bug, bạn không biết bug nằm ở requirement, UI, data, state, auth, API hay prompt.

Build theo lát mỏng là cách giảm nợ đó. Mỗi vòng chỉ tạo một phần nhỏ nhưng phải nhìn thấy được, click được, test được, và quay lại được.

Lát mỏng là gì

Một lát mỏng không phải một task kỹ thuật nhỏ như “tạo component Button”. Với vibe coding, lát mỏng nên là một miếng sản phẩm end-to-end đủ nhỏ để người dùng kiểm tra.

Ví dụ app booking:

  • Lát quá mỏng theo kiểu kỹ thuật: tạo database model booking.
  • Lát quá dày: build toàn bộ booking app với payment, calendar, email.
  • Lát mỏng đúng: tạo màn hình danh sách booking với sample data rõ ràng, có filter theo ngày và status.

Lát đúng có bốn tiêu chí:

  • Visible: mở app lên thấy kết quả.
  • Clickable: có interaction thật, không chỉ layout tĩnh.
  • Testable: bạn biết cách kiểm tra đúng/sai.
  • Reversible: nếu sai, rollback hoặc bỏ lát đó mà không phá toàn app.

Nếu một vòng build không thỏa bốn tiêu chí này, nó quá mơ hồ hoặc quá lớn.

Vì sao full-app prompt tạo review debt

Full-app prompt hấp dẫn vì nó cho cảm giác đi nhanh. Bạn nói một lần, AI làm nhiều màn hình. Nhưng càng nhiều màn hình, càng nhiều giả định ẩn.

AI phải đoán:

  • Data model gồm những field nào.
  • Auth có cần role không.
  • Flow nào là chính.
  • Empty state hiển thị gì.
  • Error state xử lý ra sao.
  • Mobile layout ưu tiên phần nào.
  • Feature nào version 1, feature nào sau này.

Mỗi giả định sai là một lỗi. Nhưng lỗi không hiện ngay vì app vẫn chạy. Bạn nhìn dashboard đẹp và tưởng ổn. Tới lúc dùng thật mới thấy form thiếu trường quan trọng hoặc data không lưu.

Review debt là phần kiểm tra bạn nợ sau khi AI build quá nhiều. Debt này không tự biến mất. Nó chuyển thành bug, rewrite, hoặc cảm giác “AI làm nhanh nhưng sao cuối cùng vẫn mất thời gian”.

Cách chia app thành lát

Hãy chia theo flow người dùng, không chia theo module kỹ thuật trước.

Với app SaaS nhỏ, thứ tự thường hợp lý là:

  1. Public hoặc entry screen tối thiểu.
  2. Auth hoặc fake gate rõ ràng tùy giai đoạn.
  3. Core form tạo record.
  4. List/table xem record.
  5. Detail/edit flow.
  6. Dashboard hoặc summary.
  7. Admin hoặc settings.
  8. Payment, integration, automation.

Không phải app nào cũng cần đủ tám lát. Điểm chính là payment và admin thường không nên nằm trong vòng đầu nếu core form còn chưa chắc.

Ví dụ app quản lý lead du lịch:

Slice 1:
Build the lead list screen with clearly labeled sample data.
Show customer name, destination, travel date, group size, budget, status, note.
Add filter by status.
Do not add create/edit yet.
After building, tell me how to test the filter.

Slice 2:

Add a create lead form.
Fields: customer name, WhatsApp, destination, travel date, group size, budget, status, note.
After submit, the new lead should appear in the list without page reload.
Keep data in local state for now and label it as temporary prototype data.
Do not add backend yet.

Slice 3:

Add lead detail editing.
User can update status and note only.
Do not change the create form fields.
Do not add delete.

Ba lát này cho phép bạn kiểm tra từng phần. Nếu filter sai, sửa trước khi thêm form. Nếu form sai, sửa trước khi thêm edit. Nếu edit sai, bạn biết phạm vi bug.

Homepage, auth, form, dashboard, payment, admin

Một cách chia cụ thể hơn:

Homepage hoặc landing:

  • Chỉ cần nếu app có public visitor.
  • Nếu là internal tool, đừng tốn vòng đầu làm hero.
  • Test bằng câu hỏi: người dùng biết app dùng để làm gì và bấm gì tiếp không?

Auth:

  • Nếu prototype chưa nối auth thật, ghi rõ đây là placeholder.
  • Nếu dùng auth thật, phải test logout, expired session, wrong role.
  • Không để AI tạo “fake login” rồi quên mất.

Form:

  • Đây thường là lát quan trọng nhất.
  • Test required fields, validation, cancel, submit, duplicate, mobile keyboard.
  • Form thiếu field nghiệp vụ thì dashboard đẹp cũng vô ích.

Dashboard/list:

  • Bắt đầu bằng table hoặc list scan được.
  • Chart để sau nếu chưa có data thật.
  • Test sort, filter, empty state, long text.

Payment:

  • Để riêng.
  • Không trộn với form đầu tiên.
  • Payment cần sandbox account, webhook, error state, refund, receipt, security review.

Admin:

  • Để sau khi user flow chính ổn.
  • Admin thường đụng permission và destructive action.
  • Test role boundary trước khi tin.

Prompt cho từng lát

Một prompt lát mỏng nên có cấu trúc:

Continue from the current prototype.

Goal for this slice:
- [One user-visible outcome]

Allowed changes:
- [Area allowed]

Do not change:
- [Known good parts]

Acceptance checks:
1. [Manual check]
2. [Manual check]
3. [Manual check]

After building:
- Summarize changed files or changed areas.
- List anything still mock/temporary.

Ví dụ:

Continue from the current booking prototype.

Goal for this slice:
- Add edit deposit status from the booking detail panel.

Allowed changes:
- Booking list row action.
- Booking detail panel.
- Booking state update.

Do not change:
- Booking creation form fields.
- Date filter behavior.
- Visual style of the table.

Acceptance checks:
1. Open a booking and change deposit status from unpaid to paid.
2. Close detail panel and confirm table status updates.
3. Refresh page and confirm data persistence behavior is clearly labeled. If data is not persisted, say so in UI or summary.

Đây là prompt boring nhưng hiệu quả. Nó giảm khả năng AI sửa lại cả app vì hiểu nhầm “improve booking”.

Khi nào tiếp tục chat, khi nào mở chat mới

Continue chat khi:

  • Bạn đang sửa cùng một lát.
  • Context còn ngắn và rõ.
  • AI vẫn nhớ đúng constraint.
  • Những lần sửa gần nhất có chất lượng tốt.

Mở chat mới khi:

  • Chat đã quá dài và nhiều quyết định cũ gây nhiễu.
  • AI bắt đầu nhắc lại lỗi đã sửa.
  • Bạn chuyển từ prototype UI sang real API/auth.
  • Bạn muốn một agent khác review độc lập.
  • Bạn cần reset scope sau khi AI tự mở rộng quá nhiều.

Khi mở chat mới, đừng paste toàn bộ lịch sử. Tạo handoff ngắn:

Current state:
- Booking list, create form, edit deposit status are working with sample data.
- Payment, staff, email automation are intentionally not built.
- Data is still local state.

Next slice:
- Replace local sample data with existing bookings API.

Do not change:
- Form fields.
- Table layout.
- Status values.

Known issue:
- Mobile filter row wraps awkwardly at 390px.

Chat mới không phải mất context nếu bạn handoff tốt. Nó giúp giảm nhiễu.

Failure modes cần nhận ra sớm

AI rewrite lại phần đã đúng. Dấu hiệu: bạn yêu cầu thêm filter, nó đổi layout, đổi field, đổi color, đổi navigation. Cách xử lý: yêu cầu revert phần không liên quan hoặc rollback checkpoint, rồi prompt lại với do not change.

AI thêm feature ngoài scope. Dấu hiệu: bạn yêu cầu form, nó thêm analytics. Cách xử lý: ghi defer list rõ hơn. Đừng khen app “đầy đủ” rồi cố dùng tiếp, vì feature thừa vẫn phải maintain.

AI sửa bug bằng cách che bug. Dấu hiệu: error biến mất nhưng flow không còn chạy, validation bị bỏ, button disabled luôn. Cách xử lý: yêu cầu giải thích root cause và acceptance check.

AI dùng mock để làm app xanh. Dấu hiệu: refresh mất data, login luôn pass, API call không xuất hiện, status update chỉ đổi local state. Cách xử lý: label mock rõ hoặc chuyển sang lát real data riêng.

Checklist sau mỗi lát

  • Tôi có biết lát này thêm gì không?
  • Có phần nào ngoài scope bị đổi không?
  • Tôi đã click flow chính chưa?
  • Tôi đã thử mobile chưa?
  • Tôi đã thử empty/loading/error nếu liên quan chưa?
  • Data đang mock hay real?
  • Có checkpoint hoặc Git state để quay lại không?
  • Lát tiếp theo có phụ thuộc vào bug chưa sửa không?

Nếu lát hiện tại chưa ổn, đừng thêm lát mới. Vibe coding nhanh nhất khi mỗi vòng đủ nhỏ để sửa ngay.

Chốt lại

Build theo lát mỏng không phải Scrum thu nhỏ. Nó là guardrail thực dụng cho vibe coding. Mỗi vòng phải tạo ra thứ nhìn thấy được, click được, test được, và rollback được. Full-app prompt cho cảm giác nhanh ở phút đầu, nhưng thường chuyển chi phí sang review và rewrite. Prototype tốt không phải app nhiều màn hình nhất. Là app mà mỗi bước đều biết đúng hay sai.