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 thực hiện. 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 đó từ bạn.
Chúng tôi ở đây để nói về ngày thứ hai, vì không có luồng 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 sự đăng nhập, làm điều gì đó mà bạn không nghĩ tới để kiểm tra, và ứng dụng của bạn đối mặt với khoảng cách giữa “được tạo ra” và “được kỹ thuật hóa”.
Ngày thứ hai thực sự trông như thế nào
Nó hiếm khi bắt đầu bằng một cú sập nguồn. 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ố 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 thứ khác.
Chào mừng bạn đến với trò chơi đập chuột prompt. Vì AI sửa các triệu chứng thay vì nguyên nhân gốc rễ, mỗi bản vá được đắp lên bản vá trước, và mã nguồn lặng lẽ trở thành thứ mà các nhà phát triển gọi là mã 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 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 duy 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 thầm lặng. 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. Sau vài vòng, bạn có một phiên bản v5 cồng kềnh của đoạn mã mà phiên bản v1 của nó vốn đã ổn.
Phần bạn không thể nhìn thấy
Chiếc máy chạy bộ gỡ lỗi ít nhất còn hiển hiện. Các vấn đề bảo mật thì không, và đó là lý do chúng tôi trở nên nghiêm khắc về điều này đối với các bản build cho doanh nghiệp.
Nghiên cứu ở đây thực sự gây khó chịu. 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 - kiểm tra đăng nhập có thể vượt qua, lỗi injection. Các công cụ AI tối ưu hóa để bản demo hoạt động, điều này tạo ra những lối tắt dễ đoán: kiểm soát truy cập được triển khai trong trình duyệt nơi bất kỳ người dùng nào cũng có thể vượt qua bằng cách chỉnh sửa trang, quyền cơ sở dữ liệu được mở rộng để không có lỗi nào xảy ra trong quá trình build, và các API key được viết cứng vào tệp vì người xây dựng không biết biến môi trường 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 đúng lịch trình.
Đây là lý do khiến điều này trở thành 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 hồ sơ 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 nó đ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 kiểm tra luồng hoạt động bình thường, trong khi lỗi nằm ở các trường hợp biên - lỗi đồng thời, luồng đặt lại mật khẩu bị lãng quên mà AI không bao giờ tạo ra vì bản demo không cần đến.
Khoả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ó thứ mà chúng tôi coi là khoản vay nóng của nợ kỹ thuật: có phần mềm ngay lập tức, trả lãi kép sau này. Mỗi lối tắt mà AI thực hiện là một bản sửa lỗi trong tương lai. Mỗi bản sửa lỗi là thêm vài credit và mã nguồn cồng kềnh hơn một chút. Các bản cập nhật nền tảng ra mắt 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 năm 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 thoái lui từ chính nền tảng đó.
Đây là trò đùa cay đắng ở trung tâm của vấn đề: vibe coding hứa hẹn dân chủ hóa phần mềm, và đối với các ứng dụng 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 về kỹ thuật cuối cùng lại nắm giữ chính thứ mà họ đã dùng AI để tránh - một mã nguồn yêu cầu sự phán đoán của lập trình viên - ngoại trừ việc giờ đây nó là trụ cột cho doanh nghiệp của họ, và họ không thể đọc được nó.
Sự phân tách 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ĩ điều đó gói gọn trong một sự phân tách 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 để đi sâu hơn, vibe coding sẽ trở thành một công cụ tăng tốc hợp pháp thay vì 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 bạn ra mắt một ứng dụng phụ thuộc vào nó. Hãy nâng cấp 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 phán đoán thực sự. Con đường này thực sự tuyệt vời - nó chỉ là một con đường, với nhiều tháng rèn luyện, và việc giả vờ mình đang đi trên đó trong khi giao mã nguồn 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 phải do AI tạo ra. 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à phần hạ tầ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 danh mục đó trên một nền tảng no-code như Softr, nơi hạ tầng là cơ sở đã được kiểm thử mà bạn cấu hình bằng hình ảnh, 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 phong cách tùy chỉnh, khối vibe-coding của nó giới hạn mã được tạo ra 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. Ngày thứ hai trên con đường này là một thao tác chỉnh sửa, không phải 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 những thứ thú vị - các 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 sự xuất hiện, bạn đang đứng ở phía nào của sự phân tách. Ngày thứ hai sẽ không hỏi bạn một cách lịch sự đâu.