Có một meme đang được anh em r/vibecoding bàn khá sôi nổi: cùng là “vibe coding”, nhưng nhóm công cụ kiểu Lovable, Bolt, Replit, v0 bị ví như căn nhà nhìn được bên ngoài nhưng bên trong dây nhợ, ống nước và móng nhà rất rối; còn Claude Code, Codex, Antigravity được ví như căn nhà có nền móng và hệ thống kỹ thuật gọn gàng hơn.
Meme hơi cực đoan, nhưng chạm đúng một vấn đề thật: tốc độ dựng app không còn là điểm khác biệt lớn nhất. Câu hỏi quan trọng hơn là sau 3 ngày, 3 tuần, hoặc 3 tháng, anh em có còn hiểu và sửa được cái app đó không.
Vì sao các nền tảng “bấm là ra app” vẫn sống khỏe
Mình không nghĩ Replit, Lovable, Bolt hay v0 sẽ biến mất chỉ vì có các coding agent mạnh hơn. Chúng phục vụ một nhu cầu khác:
- Người mới muốn có giao diện và sản phẩm chạy được ngay.
- Founder muốn test ý tưởng trước khi thuê dev hoặc viết lại nghiêm túc.
- Team nội bộ cần một dashboard, form, landing page hoặc prototype nhanh.
- Người làm sản phẩm muốn nhìn thấy flow thật thay vì chỉ mô tả bằng tài liệu.
Ở giai đoạn này, “code đẹp” chưa chắc là tiêu chí số một. Cái cần là phản hồi thị trường, demo được, hoặc giải quyết một việc nhỏ trong nội bộ.
Vấn đề bắt đầu khi anh em nhầm prototype với nền móng sản phẩm.
Hai kiểu vibe coding đang tách ra rõ hơn
Theo mình, thị trường đang tách thành hai nhánh.
1. Vibe coding để tạo sản phẩm nhìn thấy được
Đây là nhóm công cụ thiên về trải nghiệm end-to-end: nhập prompt, chọn UI, kết nối database, deploy, sửa vài lỗi bằng chat. Điểm mạnh là giảm ma sát cho người không chuyên kỹ thuật.
Nhánh này phù hợp khi:
- Chưa rõ ý tưởng có đáng làm không.
- Cần landing page, form, demo, MVP rất nhỏ.
- Người dùng chính của công cụ không muốn mở terminal.
- Sẵn sàng chấp nhận code chưa tối ưu để đổi lấy tốc độ.
Nhược điểm là khi app phình ra, người dùng dễ gặp “nợ kiến trúc”: file khó đọc, logic trộn lẫn, schema thay đổi tùy hứng, auth và permission vá từng mảng.
2. Vibe coding để cộng tác với codebase thật
Nhánh còn lại giống một lớp AI pair programmer hoặc AI agent chạy trong repo thật. Nó không chỉ tạo UI, mà còn đọc cấu trúc dự án, sửa nhiều file, chạy test, giải thích diff, refactor, và giữ ngữ cảnh kỹ thuật sâu hơn.
Nhánh này phù hợp khi:
- Repo đã có conventions, test, CI, review.
- Team cần tăng tốc nhưng vẫn muốn kiểm soát chất lượng.
- Vấn đề nằm ở logic, kiến trúc, integration, migration, performance.
- Người dùng có khả năng đọc diff và quyết định merge hay không.
Điểm mạnh là AI không thay thế quy trình kỹ thuật, mà được đặt vào trong quy trình đó.
Bài học thực tế: chọn công cụ theo vòng đời, không theo hype
Nếu anh em dùng một công cụ làm mọi thứ từ ý tưởng đến sản phẩm production, rất dễ thất vọng. Một cách thực tế hơn là chia vòng đời sản phẩm thành các pha.
Pha 1: Khám phá ý tưởng
Dùng công cụ dựng app nhanh là hợp lý. Mục tiêu là trả lời:
- Người dùng có hiểu sản phẩm không?
- Flow chính có hợp lý không?
- Tính năng nào thật sự đáng giữ?
- Có ai sẵn sàng dùng hoặc trả tiền không?
Ở pha này, đừng quá cầu toàn. Nhưng nên ghi chú rõ phần nào là tạm, phần nào là logic cốt lõi.
Pha 2: Chuyển sang codebase có kỷ luật
Khi ý tưởng bắt đầu có tín hiệu tốt, nên dừng việc “prompt chồng prompt” và chuyển sang repo có cấu trúc rõ:
- Tách frontend, backend, schema, config.
- Có quy ước đặt tên và tổ chức thư mục.
- Có test tối thiểu cho luồng quan trọng.
- Có migration thay vì sửa database thủ công.
- Có quản lý secret và quyền truy cập đúng cách.
Đây là lúc các coding agent kiểu làm việc trực tiếp trong repo phát huy giá trị hơn.
Pha 3: Vận hành và mở rộng
Khi đã có người dùng thật, câu hỏi không còn là “AI có tạo được không”, mà là:
- Khi bug xảy ra, có trace được không?
- Khi thêm tính năng, có phá luồng cũ không?
- Khi đổi model hoặc API, có cô lập được rủi ro không?
- Khi onboard người mới, họ có hiểu hệ thống không?
Một sản phẩm sống lâu cần khả năng bảo trì. AI có thể giúp rất nhiều, nhưng chỉ khi repo đủ sạch để AI và con người cùng hiểu.
Checklist nhanh trước khi đưa app vibe-coded vào production
Trước khi xem một app tạo bằng AI là “xong”, mình sẽ kiểm tra tối thiểu các điểm sau:
- Có biết entry point chính nằm ở đâu không?
- Có đọc được luồng dữ liệu từ UI đến database không?
- Có danh sách biến môi trường và secret cần thiết không?
- Có phân quyền rõ giữa user thường, admin và service không?
- Có xử lý lỗi và trạng thái loading trông tử tế không?
- Có backup hoặc migration cho dữ liệu quan trọng không?
- Có test hoặc script kiểm tra những luồng dễ hỏng nhất không?
- Có thể giải thích kiến trúc cho một người khác trong 10 phút không?
Nếu câu trả lời là không ở quá nhiều mục, app đó vẫn nên được xem là prototype, dù giao diện có đẹp đến đâu.
Kết luận
Meme “nhà rối” và “nhà chắc” vui vì nó phản ánh một cảm giác thật trong cộng đồng. Nhưng kết luận không nên là công cụ này chết, công cụ kia thắng. Đúng hơn là mỗi nhóm công cụ đang phục vụ một tầng khác nhau của quá trình làm phần mềm.
Với mình, công thức an toàn là: dùng công cụ dựng nhanh để học từ người dùng, rồi dùng coding agent trong repo có kỷ luật để biến phần đã được kiểm chứng thành sản phẩm bền hơn.
Vibe coding không xấu. Xấu là quên rằng một bản demo chạy được chưa tự động trở thành một hệ thống có thể vận hành lâu dài.
Top comments (0)