Đừng để AI tự quyết data model: bài học thực chiến từ một post đang nóng trên r/vibecoding

Vibe coding rất vui ở giai đoạn dựng nhanh giao diện, nối flow, lên ý tưởng tính năng. Nhưng tới đoạn data model thì nhiều anh em bắt đầu chững lại: bảo AI làm tiếp thì sợ nó bẻ cong cấu trúc, còn tự làm tay hoàn toàn thì mất đi lợi thế tăng tốc ban đầu.

Một post đang được quan tâm trên r/vibecoding chạm đúng nỗi đau đó: tác giả kể rằng đã thử đưa schema cho Claude, nhưng kết quả lại càng rối hơn. Đây không phải vấn đề riêng của một người mới. Nó là điểm gãy rất phổ biến khi sản phẩm bắt đầu đi từ demo sang thứ có thể sống lâu.

Thứ cần nhìn thẳng là data model không nên được giao trọn gói cho AI ở ngay vòng đầu. Nếu prompt chỉ nói đại ý kiểu “thiết kế schema cho app này”, model thường sẽ cố đoán trước mọi use case, nhồi thêm bảng, quan hệ và field để tỏ ra đầy đủ. Kết quả là nhìn thì có vẻ bài bản nhưng cực khó vận hành, khó sửa và dễ lệch khỏi nhu cầu thật.

Cách mình thấy ổn hơn là tách bài toán thành ba lớp.

• Lớp 1: ngôn ngữ nghiệp vụ. Viết ra thật rõ các thực thể cốt lõi, ví dụ user, workspace, project, task, invoice hay session. Mỗi thực thể chỉ cần trả lời ba câu hỏi: nó là gì, ai tạo ra nó, khi nào nó đổi trạng thái.
• Lớp 2: vòng đời dữ liệu. Dữ liệu được sinh ra ở đâu, ai đọc, ai sửa, khi nào bị khóa, khi nào có thể xóa hay archive.
• Lớp 3: ràng buộc hệ thống. Quan hệ một-nhiều hay nhiều-nhiều, field nào bắt buộc, field nào chỉ là cache, field nào là derived data không nên lưu cứng.

Khi ba lớp này được viết bằng tiếng người trước, AI mới có nền để hỗ trợ đúng. Nếu bỏ qua bước đó, model sẽ tự bù chỗ trống bằng suy đoán, và suy đoán đó thường là nguồn gốc của schema lộn xộn.

Một workflow khá thực chiến cho anh em đang dùng Claude, GPT hay Gemini để dựng app là như sau.

1. Đừng yêu cầu AI thiết kế toàn bộ schema trước.
   Hãy bắt đầu bằng một danh sách thực thể tối thiểu và bảo model phản biện giúp: thiếu gì, thừa gì, chỗ nào trùng nghĩa.

2. Sinh schema theo từng bounded context.
   Ví dụ phần auth làm riêng, billing làm riêng, content làm riêng. Không đẻ ra một sơ đồ khổng lồ ngay từ đầu.

3. Bắt AI giải thích trade-off thay vì chỉ xuất code.
   Prompt nên hỏi: vì sao chọn quan hệ này, nếu scale lên thì điểm yếu là gì, nếu cần đổi rule nghiệp vụ thì bảng nào dễ vỡ nhất.

4. Chốt invariant trước khi chốt bảng.
   Ví dụ: một order chỉ có một owner; một subscription chỉ có một trạng thái active tại một thời điểm; một task có thể đổi assignee nhưng không được mất audit trail. Invariant đúng thì schema mới bền.

5. Yêu cầu migration test case song song với schema.
   Đừng chỉ xin file SQL hay ORM model. Hãy bắt model viết luôn ví dụ tạo dữ liệu, sửa dữ liệu và các tình huống edge case. Chỗ nào test nghe vô lý thì thiết kế thường cũng đang có vấn đề.

6. Giữ một bản glossary làm nguồn chân lý.
   Nhiều dự án gãy không phải vì thiếu bảng, mà vì cùng một khái niệm bị gọi bằng ba tên khác nhau giữa prompt, code và database.

Một lỗi rất hay gặp ở vibe-coded app là trộn event với state. Ví dụ lưu cả “current_status” lẫn một đống cờ boolean phản ánh lịch sử, xong sau đó không biết cái nào mới là thật. Nếu sản phẩm có workflow rõ ràng, anh em nên quyết định sớm: đây là hệ thống state-based hay event-driven ở mức nào. Chỉ riêng việc này thôi đã giúp AI bớt sinh ra các field mâu thuẫn nhau.

Một lỗi khác là lưu quá nhiều thứ ở dạng JSON chỉ vì nó linh hoạt. JSON có chỗ đứng, nhất là cho metadata hoặc payload ít truy vấn. Nhưng nếu một thuộc tính sẽ được filter, sort, join hoặc kiểm tra tính hợp lệ thường xuyên, sớm muộn gì nó cũng nên thành cột hoặc bảng riêng. AI thường thích đẩy vào JSON để giải quyết nhanh, còn người vận hành sẽ là người trả nợ kỹ thuật về sau.

Nếu đang bí, anh em có thể dùng AI đúng vai hơn bằng một prompt kiểu này:

Mình sẽ mô tả domain và invariant. Bạn không được thiết kế schema ngay.
Bước 1: liệt kê các thực thể cốt lõi.
Bước 2: chỉ ra chỗ mơ hồ hoặc mâu thuẫn.
Bước 3: đề xuất schema tối thiểu để chạy MVP.
Bước 4: nêu các quyết định tạm thời và điều kiện cần để refactor sau này.
Bước 5: tạo migration và 5 test case dữ liệu quan trọng.

Cách này ép model đi từ hiểu bài toán sang thiết kế, thay vì từ cảm hứng sang cấu trúc. Chậm hơn một chút ở ngày đầu, nhưng thường đỡ tốn nhiều ngày sửa nát về sau.

Nhìn rộng hơn, đây cũng là một tín hiệu thú vị của làn sóng vibe coding hiện tại. Giai đoạn “ai cũng dựng được cái gì đó” đã qua. Giai đoạn tiếp theo là “ai dựng được thứ sống được bao lâu”. Và data model chính là nơi phân biệt một bản demo ấn tượng với một sản phẩm có thể vận hành.

Với anh em đang build nhanh bằng AI, bài học rút ra khá rõ: hãy để model tăng tốc phần diễn đạt, phản biện và draft phương án; còn phần định nghĩa thực thể, invariant và ranh giới nghiệp vụ thì con người vẫn phải cầm lái. Đó không phải làm chậm vibe coding. Đó là cách để vibe coding bớt thành vibe debugging.