Mở LinkedIn ra ngay bây giờ, bạn sẽ thấy ba nhóm người đang lao vào Vibe Code với tốc độ đáng sợ.

Nhóm thứ nhất: các founder và CEO đang đăng ký khóa học Vibe Code hàng loạt. Có người nói thẳng rằng mọi founder chạy startup dưới 10 người đều nên biết code. Nhóm thứ hai: dân kỹ thuật đã biết code, bây giờ dùng AI để tuyên bố tăng năng suất gấp 10, rồi chuyển từ engineer sang làm founder. Nhóm thứ ba: những người không có nền tảng kỹ thuật, cứ vài tuần lại “ship” một sản phẩm mới — rồi im lặng bỏ nó hai tuần sau.

Tôi hiểu cảm giác đó. Bản thân tôi cũng dùng các công cụ Vibe Code. Nhưng sau khi quan sát làn sóng này suốt một năm vừa qua, tôi muốn nói thẳng với bạn những gì dữ liệu thực sự cho thấy — vì các bài viết ăn mừng Vibe Code ngoài kia chỉ đang kể một nửa câu chuyện.

Lời Hứa Là Thật

Để tôi nói rõ: Vibe Code thực sự hiệu quả cho một số việc nhất định. Tôi không đến đây để phủ nhận điều đó.

Lô Y Combinator W25 ghi nhận 25% startup có codebase được AI tạo ra tới 95% trở lên. Lovable đạt $100M ARR chỉ trong 8 tháng — có thể là mức tăng trưởng SaaS nhanh nhất từng được ghi nhận. Garry Tan rebuild lại 70.000 dòng code trong 90 giờ nhờ công cụ AI. McKinsey đo được mức tăng năng suất 55% cho developer dùng GitHub Copilot. Đúng vậy — build một MVP hoạt động trong hai tuần giờ là thực sự có thể. Điều đó có thật, và quan trọng.

Lời hứa không phải hype. Vấn đề là những gì xảy ra tiếp theo.

Vấn Đề Mà Không Ai Đăng Lên Mạng

Dành Cho Những Founder Bắt Đầu Code

Đây là vòng lặp tôi đã chứng kiến diễn ra hết lần này đến lần khác.

Một CEO gặp điểm nghẽn — có thể team dev chậm, có thể không có ngân sách cho một tính năng, có thể họ chỉ muốn hiểu sản phẩm hơn. Họ cầm lên một công cụ Vibe Code để fix đúng một thứ đó. Và nó hoạt động. Hoạt động quá tốt đến mức họ tiếp tục. “Dễ quá mà,” họ nói. Họ bắt đầu giải quyết vấn đề X, rồi Y, rồi Z. Sản phẩm trông tuyệt vời. Demo mượt mà. Founder cảm thấy không thể dừng lại.

Rồi có gì đó crash trên production.

Bây giờ CEO đang nhìn vào một stack trace mà họ không hiểu. Họ hỏi AI để fix. AI fix được lỗi đó nhưng lại sinh ra hai hoặc ba lỗi mới. Founder thức cả đêm chạy theo những lỗi mới. Dopamine tăng vọt với mỗi chiến thắng nhỏ. Đây trở thành một vòng lặp. Hàng tuần trôi qua.

Cuối cùng, họ thuê một developer để dọn dẹp. Nhưng đây là điều không ai cảnh báo họ: không một senior developer nào muốn đụng vào cái codebase đó.

Đây không phải lý thuyết. Phân tích năm 2024 của GitClear cho thấy code duplication tăng gấp 8 lần so với trước thời AI, và refactoring giảm từ 25% xuống còn chưa đến 10% tổng số thay đổi code. CodeRabbit phát hiện code do AI tạo ra có lỗi nghiêm trọng nhiều gấp 1.7 lần và lỗ hổng bảo mật nhiều gấp 2.74 lần so với code do người viết. Trong một khảo sát của BayTech, 16 trong số 18 CTO cho biết đã trải qua thảm họa production do code AI tạo ra.

James Gosling, cha đẻ của Java, nói thẳng: “Ngay khi dự án vibe code của bạn trở nên phức tạp hơn một chút, chúng hầu như luôn sụp đổ hoàn toàn.”

Và rủi ro bảo mật không phải lý thuyết. Moltbook bị hack trong vòng 3 ngày sau khi ra mắt — 1.5 triệu API token bị lộ. Một ứng dụng được build trên Lovable đã làm lộ 18.697 hồ sơ người dùng, trong đó có 4.538 tài khoản học sinh. Đây không phải cảnh báo giả định. Đây là sản phẩm thật, người dùng thật, hậu quả thật.

“Giải pháp tiết kiệm chi phí” đã trở thành sai lầm tốn kém nhất.

Dành Cho Những Người Kỹ Thuật Đang Build Sản Phẩm

Với developer-turned-founder, cái bẫy khác nhưng không kém nguy hiểm. Khi bạn có thể build bất cứ thứ gì, bạn bắt đầu build mọi thứ. Sản phẩm ngày càng tinh vi. Tính năng chồng chất. Và đâu đó trong quá trình đó, bạn quên mất năm câu hỏi thực sự quan trọng:

1. Có bao nhiêu người gặp vấn đề này, và họ có thực sự trả tiền để giải quyết không?
2. Bạn vừa build cái này trong một cuối tuần — mười người khác cũng vậy. Lợi thế cạnh tranh của bạn là gì?
3. Điều gì xảy ra khi một nền tảng lớn copy tính năng này vào hệ sinh thái của họ?
4. Bạn có thể duy trì dự án này bao lâu mà không có doanh thu?
5. Ai sẽ giúp bạn về marketing, sales, tài chính và nhân sự?

Dữ liệu ở đây rất khắc nghiệt. CB Insights cho thấy 42% startup thất bại do không có nhu cầu thị trường — đó là nguyên nhân lớn nhất, vượt qua cả việc hết tiền. Chỉ 10-15% MVP đạt được product-market fit mà không cần pivot đáng kể. Nghiên cứu MIT năm 2025 cho thấy 95% dự án AI thí điểm không tạo ra ROI có thể đo lường được. Tỷ lệ thất bại của tech startup là 63%. Với AI startup, con số đó lên đến 90%.

“Bạn có thể vibe code một sản phẩm. Bạn không thể build một doanh nghiệp trong 24 giờ.”

Câu đó nên được khắc ở nơi dễ thấy cho mọi technical founder đang cầm lên một công cụ AI mới vào chiều thứ Bảy.

Rủi Ro Thật Sự: Mất Hai Lần

Đây là điều tôi muốn bạn ngồi suy nghĩ một chút. Khi điều này đi sai, bạn không chỉ mất dự án. Bạn mất:

Thời gian — hàng tuần hoặc hàng tháng thức đêm cảm thấy có năng suất nhưng thực ra không làm được điều gì có ý nghĩa cho doanh nghiệp của bạn.

Tiền bạc — token API, SaaS subscription, chi phí server, và cuối cùng là developer bạn thuê để gỡ rối mớ hỗn độn đó.

Sự tập trung — trong khi bạn đang code, doanh nghiệp cốt lõi của bạn không nhận được sự chú tâm tốt nhất. Các cuộc gọi bán hàng không diễn ra. Mối quan hệ đối tác không được nuôi dưỡng. Quyết định bị trì hoãn.

Uy tín — nếu bạn mang vào một technical co-founder hoặc thuê một senior engineer và cho họ xem những gì bạn đã build, cuộc trò chuyện sẽ trở nên khó xử ngay lập tức.

Khả năng tuyển dụng — một senior developer giỏi sẽ đánh giá codebase của bạn trước khi nhận offer. Code lộn xộn là vấn đề tuyển dụng.

Và thực tế tàn nhẫn nhất: nếu doanh nghiệp của bạn cần sự hiện diện tích cực của bạn trong những tuần bạn ngồi code, nó đã xuống cấp. Không rõ ràng — chỉ âm thầm. Đến khi bạn nhận ra, bạn đang tụt hậu trên hai mặt trận thay vì một.

Cộng đồng developer rộng hơn cũng đang cảm nhận điều này. Khảo sát Stack Overflow 2025 cho thấy 46% developer không tin tưởng vào các công cụ AI coding. Niềm tin vào độ chính xác của code AI giảm từ 40% xuống 29% chỉ trong một năm. Những người gần gũi nhất với công nghệ này đang trở nên hoài nghi hơn, không phải ít đi.

Cách Dùng Vibe Coding Đúng Đắn

Tôi vẫn dùng công cụ Vibe Code. Tôi muốn thành thật về điều đó. Sự khác biệt nằm ở mục đích.

Dùng nó để hiểu công nghệ đang đi về đâu — không phải để build hệ thống production mà bạn không thể bảo trì. Dùng nó để tạo prototype và mockup giúp truyền đạt ý tưởng với team hoặc nhà đầu tư nhanh hơn. Dùng nó cùng với một developer thật, người review, refactor và chịu trách nhiệm về những gì đưa lên production. Đừng bao giờ để code AI tự động đưa lên live mà không có kỹ thuật viên review. Và nếu bạn là founder cầm nó lên để giải quyết một điểm nghẽn — fix đúng một thứ đó rồi dừng.

Andrej Karpathy, người đặt ra thuật ngữ “vibe coding”, đã tự nói: “Về cơ bản bạn vẫn phải là người phụ trách thẩm mỹ, phán đoán, khẩu vị, và một chút giám sát.”

Addy Osmani từ Google Chrome phân biệt rõ hơn: “Vibe coding không giống với AI-assisted engineering.”

Công cụ không phải vấn đề. Sự vắng mặt của phán đoán mới là vấn đề.

”Rác Công Nghệ” Thực Ra Là Gì

Từ “rác” trong tiêu đề là có chủ ý, và đúng là nặng nề.

Khi bạn build thứ gì đó mà thị trường không chấp nhận, bạn không thể bảo trì, không thể mở rộng, và không ai có thể tiếp quản từ bạn — cuối cùng nó bị vứt đi. Đó là rác. Không phải bình luận về trí thông minh hay nỗ lực của bạn. Đó là mô tả về kết quả.

Vibe coding là một công cụ mạnh mẽ. Nhưng một công cụ mạnh mẽ trong tay sai, vì lý do sai, vào thời điểm sai — tạo ra chính xác điều đó.

Hãy có chủ ý về lý do tại sao bạn đang build. Hãy rõ ràng về thành công thực sự trông như thế nào — không phải “chạy được trên máy tôi” mà là “có người trả tiền cho cái này và tiếp tục trả.” Biết ai sẽ giúp bạn đến đó, vì code là phần nhỏ nhất của một doanh nghiệp thật.

Làn sóng là thật. Năng suất tăng là thật. Tỷ lệ thất bại cũng thật.

Đừng để làn sóng cuốn bạn đến một hòn đảo mà bạn không thể rời đi.