Real data, auth, API: đoạn vibe coding dễ tự lừa mình nhất

Vibe coding dễ làm bạn tự lừa mình nhất ở đoạn data. UI chạy. Table có dữ liệu. Form submit xong record hiện lên. Login screen trông như thật. Dashboard có chart. Nhưng phía sau có thể chỉ là array trong file, local state trong browser, fake auth luôn trả true, hoặc API client không bao giờ gọi network.

Prototype kiểu đó không sai nếu nó được gọi đúng tên: prototype. Nó sai khi bạn tưởng nó đã là sản phẩm thật.

Real data, auth, API là điểm chuyển từ “demo nhìn được” sang “software có trách nhiệm”. Ở đoạn này, bạn phải chậm lại. Không phải vì AI không làm được. Vì hậu quả của nhầm lẫn lớn hơn: lộ secret, sai quyền, mất data, ghi nhầm dữ liệu khách hàng, hoặc ship một app chỉ hoạt động với sample data.

Mock data không xấu, nhưng phải dán nhãn

Mock data rất hữu ích ở vòng đầu. Nó giúp bạn test layout, flow, field, empty state trước khi backend sẵn sàng. Vấn đề là mock data thường bị giấu quá kỹ. Sau ba vòng prompt, không ai nhớ table đang đọc từ sampleBookings hay API thật.

Rule đơn giản:

Dùng mock data trong vòng đầu thì được.
Ghi rõ trong prompt và trong summary.
Nếu app dành cho stakeholder không kỹ thuật, UI hoặc docs phải nói đây là sample data.
Trước khi production, có task riêng để thay mock bằng real API.

Prompt an toàn:

Use clearly labeled sample data for this first UI prototype.
After building, list every place that uses sample or mock data.
Do not present mock data as production-ready.

Khi muốn chuyển sang real API:

Replace the booking sample data with the existing booking API.
Do not create new endpoints.
Do not create fallback mock data unless I explicitly ask.
If the required endpoint or auth token is missing, stop and report what is missing.

Câu “do not create fallback mock data” rất quan trọng. Nhiều agent thấy API lỗi sẽ thêm fallback để UI xanh. Demo đẹp hơn, sự thật xấu hơn.

Dấu hiệu app vẫn đang giả

Bạn có thể kiểm tra bằng cách rất thực dụng:

Refresh page sau khi tạo record. Record còn không?
Mở devtools Network. Có request API thật không?
Tắt mạng. App báo lỗi hay vẫn “thành công”?
Đăng nhập bằng password sai. Có bị chặn không?
Đổi user khác. Data có tách theo user không?
Mở incognito. Session còn không?
Xóa sample data trong code. UI còn chạy không?

Non-tech không cần đọc toàn bộ code để phát hiện giả. Chỉ cần test hành vi. Nếu record biến mất sau refresh, data chưa persist. Nếu login nào cũng pass, auth giả. Nếu Network không có request, API chưa được gọi. Nếu user A thấy data user B, permission sai.

Một login screen không chứng minh app có auth. Auth thật gồm nhiều phần:

User là ai.
Session sống bao lâu.
Token lưu ở đâu.
Request API gửi token thế nào.
Logout xử lý ra sao.
User chưa đăng nhập bị chặn ở đâu.
User hết hạn session thấy gì.

Với vibe coding, AI rất dễ dựng login UI trước rồi để logic giả phía sau. Có khi chỉ cần nhập email bất kỳ là vào dashboard. Điều đó ổn cho prototype nếu label rõ. Không ổn nếu stakeholder tưởng app đã bảo mật.

Prompt nên rõ:

For this prototype, do not implement fake login.
If real auth is not available, show the app without login and clearly state auth is out of scope.

Hoặc nếu repo đã có auth:

Use the existing auth system.
Do not create a new login flow.
Do not store tokens manually.
If you cannot find the existing auth hook/client, stop and report.

Fake login nguy hiểm hơn không có login, vì nó tạo cảm giác an toàn giả.

Role và permission mới là chỗ dễ hỏng

Auth trả lời “ai đang dùng”. Permission trả lời “người đó được làm gì”. Nhiều app vibe-coded dừng ở auth và quên permission.

Ví dụ app booking có ba role:

Owner xem tất cả booking.
Staff chỉ xem booking được assign.
Accountant chỉ xem payment/deposit, không sửa lịch.

Nếu UI chỉ ẩn button nhưng API vẫn cho gọi endpoint, permission chưa đủ. Nếu staff đổi URL và xem booking người khác, sai. Nếu accountant không thấy button edit nhưng request PATCH vẫn thành công, sai.

Với non-tech, checklist test đơn giản:

Tạo hai user khác role.
Login từng user.
Thử xem data không thuộc quyền.
Thử bấm action không thuộc quyền.
Nếu biết dùng devtools hoặc nhờ dev, thử gọi API trực tiếp.

Prompt cho agent:

Respect existing role permissions.
Do not rely only on hiding UI buttons.
If backend permission is not available, do not claim this is secure.
List which permission checks are frontend-only and which are enforced by API.

Câu cuối ép AI phân biệt thật/giả.

Data ownership: data này thuộc về ai

App multi-user hoặc multi-tenant dễ sai data ownership. Một founder tạo app CRM bằng vibe coding có thể thấy mọi lead của mọi user vì prototype chưa có tenant boundary. Với demo cá nhân thì không sao. Với sản phẩm thật thì rất nghiêm trọng.

Hãy hỏi:

Record này thuộc user, team, workspace, company hay tenant nào?
API query có filter theo owner/tenant không?
Create record có gắn owner/tenant từ session không?
User có thể đoán ID record khác để xem không?
Export CSV có lọc đúng phạm vi không?

Đừng để AI tự invent mô hình ownership. Bạn phải cung cấp rule nghiệp vụ hoặc backend contract. Nếu chưa có, ghi rõ “single-user prototype only”. Đừng dùng prototype single-user để demo như multi-user SaaS.

Secrets và environment variables

Một failure mode rất thực tế: AI paste API key vào code frontend để gọi service cho nhanh. App chạy. Key lộ.

Rule:

Không paste secret vào prompt nếu không cần.
Không lưu API key trong client code.
Dùng .env hoặc secret manager theo platform.
.env.local không commit.
Nếu cần public key, phân biệt rõ public vs secret.
Log không được in token.

Prompt:

Do not hard-code API keys or secrets.
Use environment variables according to the existing project pattern.
Do not print secrets in logs.
If a required secret is missing, stop and tell me the variable name needed, without inventing a value.

Với non-tech, nếu tool hỏi “paste your API key”, hãy hiểu đó là credential. Chỉ dùng test key nếu được, giới hạn quyền, và rotate sau demo nếu đã paste vào môi trường không chắc.

API rate limit và error state

App demo thường chỉ test happy path. API thật có rate limit, timeout, validation error, permission error, server error. Vibe-coded UI hay thiếu các trạng thái này.

Checklist cơ bản:

Loading state có rõ không?
Submit bị disable khi đang gửi không?
API lỗi có hiện message không?
Form có giữ dữ liệu sau lỗi không?
Retry có tạo duplicate không?
Rate limit có được báo dễ hiểu không?
Empty response có làm vỡ layout không?

Prompt:

Handle API loading and error states for this flow.
On create error, keep the user's form input and show an inline error.
Prevent double submit while request is pending.
Do not show success until the API confirms success.

“Do not show success until API confirms success” là câu nên dùng thường xuyên. Nếu không, AI có thể optimistic update quá mức và báo thành công dù server fail.

Prompt thay mock bằng real endpoint

Đây là template thực dụng:

Replace mock booking data with the existing real API.

Source of truth:
- API docs: [paste endpoint contract or link]
- Existing client/hook: [path if in repo]

Requirements:
1. Load bookings from the real API.
2. Create booking through the real API.
3. Update deposit status through the real API.
4. Show loading, empty, and error states.
5. Prevent double submit.

Do not:
- Do not create new endpoints.
- Do not keep silent mock fallback.
- Do not hard-code secrets.
- Do not change auth logic.
- Do not change data model without asking.

If anything is missing:
- Stop and list the missing endpoint, field, permission, or environment variable.

Template này giúp AI không “giúp quá tay”. Nếu endpoint thiếu, dừng là đúng. Đừng để nó dựng một backend tạm mà bạn không biết.

Chốt lại

Mock data, fake auth và local state không sai trong prototype. Sai là quên chúng là giả. Đoạn real data/auth/API là lúc vibe coding cần chuyển từ tốc độ sang kiểm soát. Hãy yêu cầu AI phân biệt mock và real, không tạo fallback im lặng, không hard-code secret, không claim secure nếu permission chỉ nằm ở UI. App chạy được chưa đủ. App phải chạy với dữ liệu thật, quyền thật, lỗi thật, và rollback thật.