Ngày đầu tiên của một ứng dụng vibe-coded là bản demo tuyệt vời nhất bạn từng trình bày. Prompt hoạt động, các màn hình sạch sẽ, cơ sở dữ liệu đã có dữ liệu, và bạn đã đăng một tweet kèm video quay màn hình. Chúng tôi đã trải qua ngày đó nhiều lần. Chúng tôi không ở đây để tước đi điều đó của bạn.
Chúng tôi ở đây để nói về ngày thứ hai, vì không có bài đăng ra mắt nào đề cập đến nó. Ngày thứ hai là khi một người dùng thực đăng nhập, làm điều gì đó mà bạn không nghĩ đến việc kiểm tra, và ứng dụng của bạn vấp phải khoảng cách giữa “được tạo ra” (generated) và “được kỹ thuật hóa” (engineered).
Ngày thứ hai thực tế trông như thế nào
Nó hiếm khi bắt đầu bằng một cú sập (crash). Nó bắt đầu bằng một điều kỳ lạ: một biểu mẫu chấp nhận dữ liệu rác, một trang bị lỗi đối với một người dùng cụ thể, một con số bị sai theo cách mà không ai có thể tái hiện được. Bạn dán lỗi vào khung chat. AI tự tin sửa nó. Bản sửa lỗi đó lại làm hỏng một thứ khác.
Chào mừng bạn đến với trò chơi “đập chuột” (whack-a-mole) bằng prompt. Vì AI sửa triệu chứng thay vì nguyên nhân gốc rễ, mỗi bản vá đè lên bản vá trước, và codebase dần trở thành cái mà các nhà phát triển gọi là “code Frankenstein”: một mảnh vá của các phong cách xung đột, các hàm trùng lặp và logic rối rắm, nơi các truy vấn cơ sở dữ liệu nằm ngay trong mã giao diện. Khi dự án phát triển vượt quá cửa sổ ngữ cảnh (context window) của AI, mô hình bắt đầu quên các quyết định trước đó của chính nó và đề xuất mã mâu thuẫn với chúng. Bạn không còn đang bảo trì một ứng dụng nữa. Bạn đang thương lượng với nó.
Có một biến thể thậm chí còn nghiệt ngã hơn: lỗi triển khai âm thầm. Bản build hosting của bạn thất bại vì một lỗi nhỏ, URL trực tiếp vẫn hiển thị phiên bản cũ, và bạn - vì không thấy thay đổi - nói với AI rằng bản sửa lỗi của nó “không hoạt động”. Vì vậy, nó tạo ra một giải pháp hoàn toàn khác, phức tạp hơn cho một vấn đề vốn đã được giải quyết. Vài vòng sau, bạn có một phiên bản v5 phình to của đoạn code mà bản v1 vốn đã ổn.
Phần bạn không thể nhìn thấy
Vòng lặp gỡ lỗi ít nhất là có thể nhìn thấy được. Các vấn đề bảo mật thì không, và đó là lý do tại sao chúng tôi trở nên khắt khe về điều này với các bản build cho doanh nghiệp.
Kết quả nghiên cứu ở đây thực sự đáng lo ngại. Mã do LLM tạo ra biên dịch thành công khoảng 90% thời gian, nhưng khoảng 45% trong số đó chứa các lỗ hổng OWASP Top 10 - như bỏ qua kiểm tra đăng nhập, lỗi injection. Các công cụ AI tối ưu hóa để bản demo chạy được, điều này dẫn đến những lối tắt dễ đoán: kiểm soát truy cập được thực hiện trong trình duyệt nơi bất kỳ người dùng nào cũng có thể bỏ qua bằng cách chỉnh sửa trang, quyền cơ sở dữ liệu được mở toang để không có lỗi nào xảy ra trong quá trình build, và API key bị ghi cứng vào tệp vì người xây dựng không biết biến môi trường (environment variable) là gì. Những tệp đó sau đó được đẩy lên các repo GitHub công khai, nơi các trình quét thông tin xác thực tìm thấy chúng theo lịch trình.
Đây chính là lý do tại sao đây là vấn đề của ngày thứ hai: một ứng dụng có thể bị khai thác vẫn chạy hoàn hảo. Không có thông báo lỗi cho việc “khách hàng A về mặt kỹ thuật có thể đọc bản ghi của khách hàng B”. Bạn biết điều đó từ một người dùng, nếu bạn may mắn, hoặc tệ hơn nhiều nếu không. Và lời khuyên tiêu chuẩn (“cứ kiểm tra đi!”) va chạm với thực tế: những người xây dựng không chuyên về kỹ thuật chỉ kiểm tra luồng chạy thuận lợi (happy path), trong khi lỗi nằm ở các trường hợp biên - lỗi đồng thời (concurrency bug), luồng đặt lại mật khẩu bị quên mà AI không bao giờ tạo ra vì bản demo không cần đến.
Nợ bảo trì mà không ai liệt kê
Cộng dồn những cơ chế đó qua nhiều tháng và bạn sẽ có cái mà chúng tôi gọi là “khoản vay nóng” của nợ kỹ thuật: có phần mềm ngay lập tức, nhưng lãi suất cộng dồn về sau. Mỗi lối tắt mà AI thực hiện là một lỗi cần sửa trong tương lai. Mỗi lần sửa là tốn thêm vài credit và làm code phình to thêm một chút. Các bản cập nhật nền tảng ra đời và làm hỏng những thứ bạn không hề chạm vào - những người xây dựng lâu dài trên các nền tảng prompt-to-app báo cáo rằng họ phải thu phí bảo trì hàng tháng từ khách hàng chỉ để xử lý các lỗi hồi quy từ chính nền tảng đó.
Đây là một trò đùa cay đắng: vibe coding hứa hẹn dân chủ hóa phần mềm, nhưng đối với các ứng dụng vận hành thực tế, nó chủ yếu dân chủ hóa nợ kỹ thuật. Người xây dựng không chuyên cuối cùng lại nắm giữ chính điều mà họ dùng AI để tránh - một codebase yêu cầu sự đánh giá của nhà phát triển - ngoại trừ việc giờ đây nó là trụ cột cho doanh nghiệp của họ, mà họ lại không thể đọc hiểu.
Ngã rẽ trung thực
Vậy bạn thực sự phải làm gì? Sau nhiều bản build và một vài “vết sẹo”, chúng tôi nghĩ rằng mọi thứ gói gọn trong một ngã rẽ với hai con đường trung thực, và lựa chọn lấp lửng ở giữa là câu trả lời sai duy nhất.
Con đường một: học cách bảo trì mã. Nếu bạn đủ yêu thích điều này để đào sâu hơn, vibe coding sẽ trở thành một công cụ tăng tốc chính đáng thay vì là một cái bẫy. Hãy đọc những gì agent viết. Hãy tìm hiểu RLS nghĩa là gì trước khi triển khai một ứng dụng phụ thuộc vào nó. Hãy tiến từ các công cụ chỉ dùng prompt sang Cursor hoặc Replit, nơi mã nguồn là giao diện và bạn có thể xây dựng khả năng đánh giá thực sự. Con đường này thực sự tuyệt vời - nó chỉ là một con đường, đòi hỏi nhiều tháng kiên trì, và việc giả vờ mình đang đi trên đó trong khi giao code chưa đọc cho khách hàng chính là cái bẫy.
Con đường hai: đặt những phần nguy hiểm lên một nền tảng không được tạo tự động. Hãy thành thật rằng ứng dụng của bạn là một công cụ kinh doanh - một cổng thông tin khách hàng, một trình theo dõi, một CRM nội bộ - và nhận ra rằng 80% trong số đó chính là những phần “đường ống” mà AI tạo ra tệ nhất: xác thực, quyền hạn, đặt lại mật khẩu, truy cập dữ liệu. Hãy xây dựng hạng mục đó trên một nền tảng no-code như Softr, nơi hệ thống đường ống là cơ sở hạ tầng đã được kiểm chứng mà bạn cấu hình trực quan, và AI Co-Builder vẫn mang lại cho bạn tốc độ của ngày đầu tiên. Khi bạn muốn thêm nét tùy chỉnh, khối vibe-coding của nó sẽ giới hạn mã được tạo trong một thành phần duy nhất, vì vậy AI có thể “trang trí ngôi nhà” mà không làm sập mái nhà. Ngày thứ hai trên con đường này là một lần chỉnh sửa, không phải là một cuộc khai quật khảo cổ - đó là lý do tại sao nó đứng đầu bảng xếp hạng cổng thông tin khách hàng của chúng tôi.
Hãy cứ thoải mái vibe coding cho những thứ thú vị - bản mẫu, đồ chơi, các thử nghiệm cuối tuần chính là điều mà những công cụ này cực kỳ xuất sắc. Chỉ cần quyết định, trước khi người dùng thực xuất hiện, bạn đang đứng ở phía nào của ngã rẽ. Ngày thứ hai sẽ không hỏi bạn một cách lịch sự đâu.