7 Thứ Vibe Coding Không Làm Được (Và Cách Xử Lý)

Vibe coding rút ngắn khâu viết code, nhưng nó không thay được người ra quyết định. Bảy giới hạn lớn nhất: AI không chọn ngách giúp bạn, hay dùng thư viện lỗi thời, bịa hàm không tồn tại, bỏ qua xử lý lỗi và bảo mật, không hiểu chính sách nền tảng, chạm trần với logic phức tạp, và không biết sản phẩm của bạn khác đối thủ ở đâu. Mỗi giới hạn đều có cách xử lý — bài này đưa cả hai.

Bài này không phải để dìm vibe coding. Tôi đang dùng nó hằng ngày và tin nó là thay đổi lớn nhất với người làm sản phẩm một mình trong nhiều năm qua.

Nhưng phần lớn bài viết tiếng Việt về chủ đề này rơi vào hai thái cực: hoặc khen quá đà để bán khoá học, hoặc hù doạ quá mức để bán dịch vụ thuê lập trình. Bài này nằm ở giữa — tôi nói đúng những gì tôi gặp phải khi làm thật.

1. AI không chọn ngách giúp bạn

Giới hạn: AI viết được app bạn bảo nó viết, nhưng nó không biết app nào nên làm. Nó không biết ngách nào đang có nhu cầu mà ít người phục vụ, không biết đối thủ của bạn đang làm gì chưa tốt.

Vì sao đây là giới hạn nghiêm trọng nhất: một app làm cẩu thả trong ngách tốt vẫn có người dùng; một app làm công phu trong ngách bão hoà thì vô hình. Việc AI làm nhanh khâu build khiến người ta bỏ qua khâu chọn — và đó là sai lầm tốn kém nhất.

Cách xử lý: dành ít nhất vài giờ cho việc quan sát trước khi mở công cụ. Xem store đang thiếu gì, đọc đánh giá 1–3 sao của đối thủ để tìm chỗ họ làm chưa tốt. Chỉ mở AI sau khi đã trả lời được: làm cho ai, giải quyết việc gì, hơn đối thủ ở điểm nào.

2. AI dùng thư viện lỗi thời

Giới hạn: đây là nguyên nhân số một khiến build thất bại. AI học từ dữ liệu có thời điểm, nên hay đề xuất phiên bản thư viện đã cũ hoặc không còn tương thích.

Cách xử lý: trước mỗi lần build lớn, hỏi thẳng công cụ: “Thư viện nào trong dự án này đã lỗi thời hoặc không tương thích?” Và ghi rõ phiên bản thư viện được phép dùng vào file ngữ cảnh thường trực của dự án — xem cách làm ở bài viết spec cho AI.

3. AI bịa hàm không tồn tại

Giới hạn: AI viết code trông rất hợp lý, cấu trúc đúng, tên hàm nghe thuyết phục — nhưng hàm đó không có thật. Bạn chỉ phát hiện khi build báo lỗi.

Điều làm giới hạn này khó chịu là AI rất tự tin khi bịa. Nó không nói “tôi không chắc”, nó viết như thật.

Cách xử lý: build thử thường xuyên, sau mỗi tính năng nhỏ. Khi lỗi “không tìm thấy hàm” xuất hiện, copy nguyên văn đưa lại cho AI — đừng diễn giải. Và với dữ kiện quan trọng như số liệu, thông số kỹ thuật, hãy tự kiểm chứng ở tài liệu gốc.

4. AI bỏ qua xử lý lỗi và bảo mật

Giới hạn: AI viết code chạy đúng trong trường hợp thuận lợi. Nó ít khi tự thêm xử lý cho tình huống bất thường: người dùng nhập sai, mất mạng giữa chừng, dữ liệu trống, thao tác hai lần liên tiếp.

Với bảo mật thì nghiêm trọng hơn: xác thực đầu vào, giới hạn quyền truy cập, bảo vệ khoá API — đây là những thứ AI thường bỏ qua nếu bạn không yêu cầu rõ.

Cách xử lý: sau khi tính năng chạy được, hỏi thêm một lượt: “Nếu người dùng nhập sai, mất mạng giữa chừng, hoặc bấm hai lần liên tiếp thì sao?” Với app có đăng nhập hoặc thanh toán, hãy nhờ người biết code xem qua — xem mục “vùng nguy hiểm” bên dưới.

5. AI không hiểu chính sách nền tảng

Giới hạn: Google Play và AdMob có rất nhiều yêu cầu không liên quan gì đến code — target API level, khai báo dữ liệu thu thập, chính sách bảo mật, luồng xin đồng ý người dùng, vị trí đặt quảng cáo không gây bấm nhầm.

Đây là khoảng trống lớn nhất giữa “app chạy được” và “app lên được store”. Rất nhiều người làm xong app rồi mới phát hiện ra.

Cách xử lý: đọc yêu cầu của nền tảng trước khi build, không phải sau. Với app Android, hai bài này nên đọc trước: tích hợp AdMob và UMP consent và hướng dẫn submit lên Google Play.

6. AI chạm trần với logic phức tạp

Giới hạn: với sản phẩm có nhiều luồng nghiệp vụ chồng chéo — nhiều vai trò người dùng, nhiều trạng thái, nhiều quy tắc phụ thuộc lẫn nhau — AI bắt đầu mâu thuẫn với chính nó. Sửa chỗ này hỏng chỗ kia.

Dấu hiệu bạn đã chạm trần: cứ sửa xong một lỗi lại phát sinh lỗi mới ở chỗ khác, lặp lại ba bốn vòng mà không thoát ra được.

Cách xử lý: chia nhỏ sản phẩm. Thay vì một app làm mười việc, làm ba app mỗi app làm ba việc. Nếu không chia được vì bản chất sản phẩm, đó là tín hiệu bạn cần người có chuyên môn tham gia.

7. AI không biết sản phẩm của bạn khác đối thủ ở đâu

Giới hạn: AI có thể dựng cho bạn một app giống hệt mười app đang có trên store. Nó không biết điều gì làm sản phẩm của bạn đáng được chọn.

Vì sao điều này ngày càng quan trọng: khi ai cũng dùng được AI để làm app, số lượng app tăng vọt và sự khác biệt trở thành thứ khan hiếm. Lợi thế không còn nằm ở việc làm được, mà ở việc làm cái gì.

Cách xử lý: trước khi build, viết một câu trả lời cho: “Vì sao người ta chọn sản phẩm của tôi thay vì cái đang có?” Nếu không trả lời được, đừng build vội — quay lại giới hạn số 1.

Vùng nguy hiểm — khi nào bắt buộc nhờ người biết code

Có những loại sản phẩm mà làm sai không chỉ là mất thời gian, mà là gây hại cho người dùng. Với ba nhóm dưới đây, hãy nhờ người có chuyên môn kiểm tra trước khi công khai:

Sản phẩm có đăng nhập và lưu dữ liệu người dùng. Rò rỉ dữ liệu là chuyện không sửa lại được sau khi đã xảy ra.

Sản phẩm có thanh toán. Kể cả khi dùng cổng thanh toán có sẵn, phần ghép nối vẫn có thể sai.

Sản phẩm xử lý thông tin sức khoẻ, tài chính hoặc pháp lý. Thông tin sai ở đây gây hậu quả thật cho người dùng, và trách nhiệm thuộc về bạn.

Chi phí nhờ người xem qua một lượt nhỏ hơn rất nhiều so với chi phí xử lý sự cố.

Vibe coding vẫn thắng ở đâu

Sau bảy mục ở trên, cần nói rõ phần còn lại — vì bức tranh không phải màu xám.

Tốc độ ra bản thử. Việc trước đây mất vài tuần giờ mất vài giờ. Điều này thay đổi cách bạn làm việc: bạn dám thử nhiều ý tưởng vì chi phí thử rất thấp.

Rào cản vào nghề thấp hơn hẳn. Người không học lập trình vẫn ra được sản phẩm thật. Đây là thay đổi lớn nhất.

Lặp lại rất rẻ. Sản phẩm thứ hai cùng kiểu nhanh hơn nhiều lần, vì bạn đã có mẫu spec và đã biết chỗ AI hay sai.

Sửa theo phản hồi nhanh. Người dùng chê một chỗ, bạn mô tả, AI sửa, phát hành lại trong ngày.

Bảy giới hạn ở trên không làm vibe coding kém giá trị. Chúng chỉ nói rằng vai trò của bạn chuyển từ người viết code sang người ra quyết định — và đó là vai trò khó hơn, nhưng cũng đáng giá hơn.

Câu hỏi thường gặp

Vibe coding có nhược điểm gì?
Lớn nhất là AI không thay bạn quyết định làm gì. Ngoài ra: hay dùng thư viện lỗi thời, bịa hàm không tồn tại, bỏ qua xử lý lỗi và bảo mật, không hiểu chính sách nền tảng, và chạm trần với logic phức tạp.

Code do AI viết có an toàn không?
Không mặc định an toàn. AI thường bỏ qua xác thực đầu vào và xử lý ngoại lệ nếu bạn không yêu cầu. Với sản phẩm có đăng nhập, thanh toán hoặc dữ liệu người dùng, nên nhờ người có chuyên môn kiểm tra.

Khi nào không nên dùng vibe coding?
Khi sản phẩm có logic nghiệp vụ phức tạp nhiều luồng chồng chéo, khi xử lý dữ liệu nhạy cảm mà không có ai review, hoặc khi cần tối ưu hiệu năng cho lượng lớn người dùng đồng thời.

Vibe coding có thay thế lập trình viên không?
Không. Nó rút ngắn khâu gõ code cho sản phẩm đơn giản. Với hệ thống phức tạp, vai trò người có chuyên môn càng quan trọng — nhất là ở khâu review và bảo mật.

Làm sao biết mình đã chạm trần của AI?
Dấu hiệu rõ nhất: sửa xong một lỗi lại phát sinh lỗi mới ở chỗ khác, lặp lại ba bốn vòng không thoát ra được. Lúc đó nên chia nhỏ sản phẩm hoặc nhờ người có chuyên môn.

Người mới có nên lo lắng về những giới hạn này không?
Không nên lo, nhưng nên biết. Với sản phẩm đầu tiên đơn giản, bạn gặp chủ yếu giới hạn số 2 và số 5. Những giới hạn còn lại xuất hiện khi sản phẩm lớn dần.

Bước tiếp theo

Biết giới hạn rồi thì bước tiếp là giảm thiểu chúng: viết spec cho AI xử lý được phần lớn giới hạn số 2, 4 và 7. Còn nếu bạn đang ở giai đoạn cân nhắc có nên bắt đầu không, đọc vibe coding là gì và không biết code có làm được app không.

Bài viết dựa trên kinh nghiệm sử dụng thực tế. Năng lực của công cụ AI thay đổi nhanh — một số giới hạn nêu trên có thể được cải thiện theo thời gian.