Vibe coding: nợ kỹ thuật đến hạn đúng ngày lên production

Tháng 7/2025, Jason Lemkin của SaaStr đang vibe coding trên Replit thì coding agent xóa mất database production. Agent còn khẳng định sai rằng không thể rollback, rồi tự nhận rằng nó đã mắc “một sai lầm phán đoán thảm khốc”.

Phản ứng của Replit sau đó nói lên nhiều điều: họ cho database dev và prod tự động tách khỏi nhau. Đó là một guardrail rất cơ bản, vậy mà trước đó không có. Lỗi nằm ở quy trình nhiều hơn ở model, vì một phiên làm prototype đã được phép chạm thẳng vào hệ thống thật.

Với người muốn làm Forward Deployed Engineer, câu chuyện này chính là mô tả công việc. FDE sống ở ranh giới giữa demo và deployment, nơi một bản prototype viết rất nhanh phải chịu được dữ liệu thật, người dùng thật và hậu quả thật.

Vibe coding giống một khoản vay không lãi khi code chỉ chạy trên máy bạn. Đến ngày lên production thì khoản vay bắt đầu tính lãi.

Ranh giới nằm ở chỗ bạn có hiểu code không

Simon Willison trích lại định nghĩa gốc của Andrej Karpathy: vibe coding là khi bạn buông theo cảm giác và quên luôn rằng code đang tồn tại. Cốt lõi của nó là không quan tâm đến code.

Willison vạch ranh giới rất rõ. Nếu AI viết code nhưng bạn đã review, đã test và giải thích được nó, thì theo ông đó không còn là vibe coding nữa, mà là phát triển phần mềm. Cách chia này có ích vì nó chuyển câu hỏi từ “có dùng AI không” sang “có ai chịu trách nhiệm về code này không”.

Vì thế, khoản nợ không đến từ việc dùng Copilot hay Claude. Nó đến từ phần code mà không ai trong team thật sự hiểu, vì code đó bỏ qua bước review, bước test và bước giải thích. Nếu bạn nhận lại một prototype khách hàng tự dựng bằng AI, câu hỏi đầu tiên nên là: phần nào trong đó chưa từng có người review?

Hóa đơn đầu tiên là bảo mật

Báo cáo GenAI Code Security 2025 của Veracode cho thấy code do AI sinh ra chạy được, nhưng có lỗ hổng bảo mật trong 45% trường hợp kiểm thử. Thử quy ra một prototype có 20 tác vụ tương đương: theo tỷ lệ đó, khoảng 9 tác vụ mang lỗ hổng, dù cả 20 đều qua bài demo.

Tệ hơn, con số này không tự giảm theo thời gian. CTO của Veracode nói các model GenAI chọn sai gần một nửa số lần và tình hình không cải thiện. Model lớn hơn cũng không an toàn hơn model nhỏ một cách đáng kể. Vậy nên chờ thế hệ model sau không phải là kế hoạch.

Chia theo ngôn ngữ thì Java có tỷ lệ thất bại cao nhất: code do LLM sinh ra có lỗi bảo mật trong hơn 70% trường hợp. 86% mẫu code liên quan không chống được cross-site scripting (CWE-80).

XSS là kiểu lỗi kinh điển, thường chỉ lộ ra khi ứng dụng mở cho người dùng thật, và chính điều đó giải thích vì sao nợ đến hạn đúng ngày lên production.

Thử hình dung bạn demo cho khách một form thu phản hồi. Trong buổi demo, mọi người gõ câu chữ bình thường và form chạy hoàn hảo. Khi mở cho hàng nghìn người dùng, chỉ cần một người gõ vào một đoạn script là lỗ hổng lộ ra, vì không ai trong phòng họp từng tấn công chính form đó.

Hóa đơn thứ hai đến chậm hơn và kéo dài

Nếu bảo mật là khoản phải trả ngay ngày launch, thì bảo trì là khoản trả góp kéo dài nhiều tháng sau đó. Production chỉ là kỳ thanh toán đầu tiên, các kỳ sau đến theo từng sprint mỗi khi có người phải sửa phần code không ai hiểu.

Phân tích của GitClear cho thấy trong năm 2024, số dòng code bị copy/paste đã vượt số dòng được di chuyển. Dòng “được di chuyển” thường là dấu vết của refactor, tức là gom logic về một chỗ. Khi copy/paste thắng thế, cùng một logic nằm rải rác ở nhiều nơi, và mỗi lần sửa bug phải sửa ở từng chỗ một.

GitClear còn đo code churn, tức tỷ lệ dòng code bị revert hoặc sửa lại chưa đầy hai tuần sau khi viết, và dùng nó làm thước đo code kém chất lượng. Chỉ số này đáng để FDE mang theo: nếu phần lớn code của một prototype phải viết lại trong hai tuần đầu chạy thật, tốc độ ban đầu chỉ là vay trước.

Gộp cả sự cố Replit vào, ba khoản nợ này đến hạn vào ba thời điểm khác nhau, và mỗi khoản đòi một việc làm trước khác nhau:

Loại nợ	Lúc demo	Lúc đến hạn	Việc FDE làm trước
Bảo mật	Form, API chạy đúng chức năng	Khi người dùng thật nhập dữ liệu, như XSS	Quét bảo mật, kiểm tra kỹ phần xử lý input
Bảo trì	Tính năng thêm vào rất nhanh	Các sprint sau, khi phải sửa logic bị nhân bản	Theo dõi churn, refactor phần copy/paste
Vận hành	Agent làm việc trơn tru	Lần đầu agent có quyền với dữ liệu thật	Tách dev/prod, giới hạn quyền, có đường rollback

Cảm giác nhanh hơn có đáng tin không?

Câu hỏi khó hơn là vì sao các team vẫn vay. Nghiên cứu có đối chứng của METR với 16 developer mã nguồn mở giàu kinh nghiệm cho thấy khi dùng công cụ AI, họ mất thêm 19% thời gian. METR sau đó lưu ý kết quả này phản ánh điều kiện đầu năm 2025 và đã cũ.

Phần đáng suy nghĩ hơn nằm ở cảm nhận của chính họ: ngay cả sau khi bị chậm đi, các developer vẫn tin AI đã giúp họ nhanh hơn 20%.

Cần nói rõ, METR đo tốc độ làm việc, không đo nợ kỹ thuật hay code chạy trên production. Vì thế đây không phải khoản nợ thứ tư mà là một loại rủi ro khác: team đánh giá sai chính mình.

Nhưng nó giúp hiểu vì sao các khoản nợ ở trên ít khi bị chặn sớm, và bài học cho FDE khá thực tế: trước khi kết luận AI giúp dự án đi nhanh hơn, hãy đo thời gian thật thay vì hỏi cảm giác của team.

Trả nợ trước bằng test và guardrail

Lối ra không phải là bỏ AI. Trong bài viết về “vibe engineering”, Willison cho rằng nếu dự án có test suite vững, đầy đủ và ổn định, các công cụ agentic coding có thể tăng tốc rất mạnh. Test suite giống tài sản thế chấp: có nó thì khoản vay tốc độ mới an toàn.

Sự cố Replit chỉ ra lớp bảo vệ thứ hai, đó là ranh giới môi trường. Agent cần làm việc trong một hộp cát nơi lỗi tệ nhất vẫn sửa được. Với Lemkin, chỉ cần database dev và prod tách nhau là sai lầm của agent đã không đụng tới dữ liệu thật.

Nếu bạn là FDE nhận một prototype vibe-coded tại khách hàng, thứ tự ưu tiên khá rõ. Ngày đầu, kiểm tra agent và ứng dụng đang dùng credential nào, có chạm được vào prod không, rollback bằng cách nào. Tuần đầu, dựng test cho các luồng chính và quét bảo mật trước khi thêm bất kỳ tính năng nào.

Developer Việt nên làm gì với khoản nợ này?

Với developer Việt Nam có 2 đến 8 năm kinh nghiệm, đây là chỗ để tạo khác biệt. Ai cũng có thể bảo AI viết ra một prototype; phần khó là đưa prototype đó lên production mà không để lại lỗ hổng, không để agent chạm vào dữ liệu thật và không để code nhân bản khắp nơi.

Khi đọc tin tuyển dụng trên ITviec, TopDev hay LinkedIn, đừng dừng ở dòng “thành thạo công cụ AI coding”. Hãy để ý tin nào hỏi thêm về testing, bảo mật ứng dụng, CI/CD hay vận hành production. Công ty viết như vậy nhiều khả năng đã nhìn thấy khoản nợ này.

Trong CV, hãy đổi câu “dùng AI để tăng năng suất” thành một câu chuyện có số liệu thật của bạn. Ví dụ: nhận một prototype viết bằng AI, tách môi trường dev/prod, viết test cho các luồng chính, sửa các lỗi XSS tìm được khi quét. Khi phỏng vấn, hãy kể bạn đã chặn được rủi ro gì, thay vì chỉ kể mình code nhanh đến đâu.

Vibe coding sẽ tiếp tục giúp các team làm demo nhanh hơn. Ngày demo thành production thì luôn phải có người trả khoản nợ, và người biết trả trước ngày đáo hạn sẽ có việc làm.