Mục lục
Cứ nhắc đến mặt trái của vibe coding là mọi người nói cùng một câu: "AI viết code chưa đủ tốt", hoặc phiên bản u ám hơn — "dev sẽ lười đi, kỹ năng thui chột".
Tôi nghĩ cả hai đều trượt mục tiêu. Code AI viết ra càng ngày càng tốt, và chuyện kỹ năng tôi đã viết ở bài trước. Còn một thứ bị lấy mất mà gần như không ai gọi tên:
Vibe code xóa mất những điểm dừng bắt buộc — những khoảnh khắc mà sự chậm chạp của code tay từng ép bạn phải suy nghĩ trước khi cam kết.
Nghe trừu tượng? Để tôi kể chuyện vừa xảy ra với chính tôi.
Chuyện tech A và tech B — một buổi build, hai tuần đập
Một dự án gần đây, tôi cần chọn công nghệ cho một tính năng lớn. Ngày xưa, quyết định kiểu này ngốn của tôi vài ngày: đọc docs, dựng demo nhỏ, cân đo. Lần này thì không. AI gợi ý phương án A nghe rất hợp lý, và vì build gần như miễn phí, tôi gật đầu. Một buổi chiều, tính năng chạy hoàn chỉnh.
Hai tuần sau, tôi phát hiện phương án B — hợp hệ sinh thái đang có hơn, ít phải tự vá hơn. Và thế là đập toàn bộ phần đã làm với A, xây lại bằng B.
Điều đáng nói không phải chuyện tôi chọn sai. Điều đáng nói là ngày xưa tôi sẽ không sai kiểu đó — không phải vì tôi giỏi hơn, mà vì code tay đắt đến mức tôi buộc phải nghiên cứu trước khi viết dòng đầu tiên. Cái "đắt" đó chính là một điểm dừng bắt buộc. Vibe code làm việc build rẻ đi trăm lần, và cùng với nó, xóa luôn lý do để dừng lại.
Giai đoạn đánh giá không biến mất. Nó chỉ bị đẩy ra sau khi đã build xong — dưới dạng "ơ, hình như B tốt hơn". Đập đi xây lại chính là hóa đơn trả chậm cho phần nghiên cứu đã bỏ qua.
Và nếu bạn đang thấy thiếu tự tin với đống code AI viết ra dù test vẫn xanh — cảm giác đó không phải bạn yếu đi. Dữ liệu nói nó là tín hiệu đúng.
Dữ liệu: nhanh hơn ở khâu build, mù hơn ở khâu quyết định
Bạn tưởng mình nhanh hơn. Đồng hồ nói ngược lại
Giữa năm 2025, tổ chức nghiên cứu METR công bố một thử nghiệm đối chứng ngẫu nhiên — chuẩn phương pháp của thử nghiệm thuốc — trên 16 lập trình viên kỳ cựu, làm 246 task thật trên chính những repo mã nguồn mở họ đóng góp thường xuyên. Kết quả: khi dùng công cụ AI, họ chậm hơn 19%.
Con số gây sốc hơn nằm ở phần cảm nhận: trước thử nghiệm, nhóm dev dự đoán AI giúp họ nhanh hơn 24%. Sau khi đã bị chậm đi 19%, họ vẫn ước lượng mình nhanh hơn 20% (nghiên cứu đầy đủ trên arXiv). Khoảng lệch 39 điểm phần trăm giữa cảm giác và thực tế.
Vì sao lệch xa vậy? Vì vibe code cho bạn cảm giác chuyển động liên tục — code tuôn ra, màn hình thay đổi, tính năng thành hình. Cảm giác chuyển động che mất thời gian bạn đốt vào việc kiểm lại, sửa "gần đúng", và — như chuyện tech A của tôi — đập đi xây lại.
Code sinh ra dễ, giữ lại khó
Báo cáo chất lượng code 2025 của GitClear, phân tích 211 triệu dòng code thay đổi từ 2020–2024, vẽ đúng chân dung đó:
- Code churn — code vừa viết xong đã phải sửa lại — tăng từ 3,3% (2021) lên 5,7% (2024). Gần gấp đôi.
- Tỷ lệ dòng copy/paste tăng từ 8,3% lên 12,3%; số khối code trùng lặp tăng gấp 8 lần riêng trong 2024.
- Trong khi đó, tỷ lệ dòng thuộc về refactoring rơi từ 25% xuống dưới 10% — 2024 là năm đầu tiên trong bộ dữ liệu mà copy/paste vượt qua code được di chuyển/tái cấu trúc.
Dịch ra tiếng người: chúng ta đang sinh code nhanh hơn bao giờ hết, và chăm sóc nó ít hơn bao giờ hết. Churn gần gấp đôi nghĩa là một phần đáng kể "năng suất" chỉ là viết lại thứ vừa viết — phiên bản thống kê của chuyện tech A sang tech B.
Giao nhanh hơn, vỡ nhiều hơn
Báo cáo DORA 2025 của Google khảo sát gần 5.000 người làm phần mềm: 90% đã dùng AI trong công việc. Tin tốt — AI giờ gắn với thông lượng giao hàng cao hơn. Tin xấu — nó vẫn có quan hệ tiêu cực với độ ổn định của hệ thống: giao nhanh hơn, nhưng vỡ nhiều hơn, trừ khi có hệ thống phanh đủ mạnh (test tự động, version control chặt, vòng phản hồi nhanh).
Kết luận của chính DORA: AI là bộ khuếch đại, không phải bộ sửa lỗi. Đội có quy trình tốt dùng AI sẽ tốt hơn nữa. Đội thiếu quy trình dùng AI sẽ... thiếu quy trình nhanh gấp mười.
Ba nghiên cứu, một câu chuyện: AI tăng tốc phần build, nhưng phần quyết định và giữ gìn — đánh giá trước khi chọn, refactor, ổn định hệ thống — đang teo đi. Không phải vì AI làm kém, mà vì tốc độ của nó đã xóa những điểm dừng từng ép chúng ta làm các việc đó.
Khung 4 điểm dừng: đặt lại phanh một cách có chủ đích
Giải pháp không phải quay về code tay — chậm toàn tập là phí phạm đúng bằng nhanh toàn tập. Giải pháp là tự đặt lại các điểm dừng, ở đúng chỗ chúng từng tồn tại tự nhiên. Đây là bốn điểm tôi đang áp dụng sau vụ tech A.
1. Dừng trước khi chọn — tách quyết định ra khỏi việc build
Trước khi cho AI viết dòng code nào, bắt nó làm việc khác trước: so sánh phương án A, B, C theo đúng ràng buộc của dự án này — quy mô, đội ngũ, hệ sinh thái đang có, khả năng bảo trì — và chỉ ra điểm chết của từng phương án. AI làm việc này rất tốt, nhưng chỉ khi bạn hỏi; mặc định nó sẽ chiều theo hướng đầu tiên trong đầu bạn.
Rồi ghi lại quyết định bằng một ghi chú 5 dòng (dạng ADR): "Chọn A vì X, Y. Đã cân nhắc B, loại vì Z." Ba mươi phút. Rẻ hơn một lần đập đi xây lại khoảng một trăm lần.
Nếu thật sự phân vân? Đây là chỗ vibe code đảo luật chơi có lợi cho bạn: cho AI dựng bản mỏng nhất bằng cả A lẫn B trong một buổi, so trực tiếp, rồi mới build thật. Code vứt đi có chủ đích là chi phí nghiên cứu. Code vứt đi vì lỡ build full rồi mới nghĩ mới là lãng phí.
2. Dừng trước khi build — bạn viết đề bài, AI viết lời giải
Sự tự tin kiểu cũ đến từ "tôi viết nên tôi hiểu từng dòng". Kiểu đó không quay lại nữa — và không cần quay lại. Thứ thay thế nó là "tôi kiểm chứng nên tôi biết nó làm đúng": bạn định nghĩa tiêu chí nghiệm thu và các test case quan trọng trước, AI lo phần hiện thực. Một tech lead giỏi vốn chưa bao giờ đọc hết code của cả team — họ tin vào hành vi được kiểm chứng, không phải vào việc thuộc lòng từng dòng.
3. Dừng trước khi merge — review theo tầng rủi ro, không review đều
"Không đủ thời gian đọc hết" là thực tế không đổi được, nên đừng cố. Phân tầng: code chạm đến tiền, xác thực, dữ liệu người dùng, API contract — đọc từng dòng. UI, nội dung, refactor nội bộ có test phủ — đọc lướt diff và tin vào test. Cố đọc đều mọi thứ nghĩa là chỗ nguy hiểm nhất cũng chỉ được đọc lướt.
Mẹo tăng tốc: bắt AI giải thích trước khi bạn đọc code — thay đổi gì, tại sao, đánh đổi gì, rủi ro ở đâu. Chỗ nào trong lời giải thích khiến bạn "ơ, sao lại thế?" — đó chính là chỗ cần soi kỹ. Nhớ khoảng lệch 39 điểm của METR: cảm giác "ổn rồi" của chính bạn cũng cần được kiểm chứng.
4. Dừng trước khi đổi — nâng chuẩn cho việc đổi, không phải việc chọn
Chọn ban đầu chỉ cần "đủ tốt". Nhưng đổi thì phải vượt một cái bar cao hơn hẳn: phương án mới phải tốt hơn đủ nhiều để bù chi phí viết lại, rủi ro bug mới, và thời gian bạn phải review lại toàn bộ từ đầu. "B tốt hơn A" gần như không bao giờ đủ. Câu đúng phải là: "A đang gây một cơn đau cụ thể mà B giải được." Mở lại ghi chú ADR ở điểm dừng số 1 — nếu B không thắng ở đúng tiêu chí khiến bạn chọn A, thì đó chỉ là cỏ-bên-kia-đồi-xanh-hơn. Phần lớn cơn "muốn đổi" chết ngay ở bước này.
Cái giá và phần thưởng, tính bằng tiền
Nói chuyện kinh doanh cho sòng phẳng.
Khi 90% đội ngũ ngoài kia đều dùng AI, tốc độ build không còn là lợi thế cạnh tranh — nó là mặt bằng chung. Ai cũng giao tính năng trong một buổi chiều được rồi. Thứ phân hóa kẻ thắng người thua, theo đúng dữ liệu DORA, là hệ thống phanh: đội nào giữ được ổn định trong khi vẫn nhanh, đội đó thắng. Đội nào chỉ nhanh, đội đó tích lũy churn 5,7%, code trùng lặp gấp 8 lần, và những cú "đập đi xây lại" không ai ghi hóa đơn.
Còn nếu bạn là chủ doanh nghiệp đang thuê một đội "làm web bằng AI, nhanh lắm" — câu hỏi đáng hỏi không phải "các bạn làm nhanh không?". Câu đó ai cũng trả lời được. Câu đáng hỏi là: "Điểm dừng của các bạn nằm ở đâu?" Ai quyết định chọn công nghệ, dựa trên gì? Ai định nghĩa test? Code chạm đến tiền của tôi được review kiểu gì? Đội nào trả lời trôi chảy, đội đó xứng đáng với dự án của bạn. (Và vâng, chúng tôi sẵn sàng trả lời bốn câu đó — bằng văn bản.)
Vibe code không lấy đi kỹ năng của bạn. Nó lấy đi những chỗ mà sự chậm chạp từng bắt bạn suy nghĩ. Kỹ năng vẫn còn nguyên đó — chỉ là không còn gì ép nó phải lên tiếng. Đặt lại bốn điểm dừng, và bạn lấy lại được thứ quý nhất mà cơn sốt tốc độ này đang xóa dần: quyền quyết định một cách tỉnh táo.
Nguồn số liệu: METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089); GitClear — AI Copilot Code Quality: 2025 Research; Google Cloud — 2025 DORA Report: State of AI-assisted Software Development (dora.dev).
