Vibe coding năm 2026: bằng chứng nói gì

Hiện nay “vibe coding” được dùng cho đủ thứ, từ món đồ chơi cuối tuần đến cả quy trình làm việc với agent. Trước khi quyết định nó hợp với việc gì, nên xem thuật ngữ này ban đầu nghĩa là gì và sau đó người ta đã đo được những gì.

Thuật ngữ này từ đâu ra

Ngày 2 tháng 2 năm 2025, Andrej Karpathy đăng trên X: “There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Trong cùng bài, ông viết “I “Accept All” always, I don’t read the diffs anymore” và gọi đó là “not too bad for throwaway weekend projects, but still quite amusing.”

Nghĩa gốc khá hẹp: bạn không đọc code. Định nghĩa của Martin Fowler, cập nhật ngày 21 tháng 5 năm 2026, giữ đúng ý đó: xây ứng dụng bằng cách ra lệnh cho LLM, chạy thử, rồi nhờ sửa tiếp, “but without looking at any of the code that the LLM generates.” Ông tách nó khỏi thứ ông gọi là agentic programming, nơi lập trình viên vẫn review kết quả. Theo lời ông, “the term “vibe coding” really caught on, so many people use it to mean agentic programming.”

Sự trôi nghĩa này quan trọng khi đọc các nghiên cứu. Nhiều nghiên cứu đo việc lập trình có AI hỗ trợ nói chung, không phải kiểu không review.

Thuật ngữ lan ra thế nào

Merriam-Webster đưa nó vào mục “slang & trending” ngày 8 tháng 3 năm 2025. Ngày 6 tháng 11 năm 2025, Collins Dictionary chọn nó làm Word of the Year, với định nghĩa “the use of artificial intelligence prompted by natural language to assist with the writing of computer code.” Định nghĩa này rộng hơn của Karpathy: không nhắc gì đến chuyện không đọc code.

Một lần được từ điển chọn cho thấy từ này đang được dùng. Nó không phải bằng chứng rằng cách làm này hiệu quả.

Bằng chứng có đối chứng nói gì

Năng suất. METR chạy một thử nghiệm ngẫu nhiên có đối chứng với 16 lập trình viên open-source giàu kinh nghiệm, làm 246 issue thật trong các repo họ đã quen. Mỗi issue được gán ngẫu nhiên là cho phép hoặc cấm dùng AI. Công bố ngày 10 tháng 7 năm 2025, kết quả: “when developers use AI tools, they take 19% longer than without.” Các lập trình viên đã kỳ vọng nhanh hơn 24% và sau đó vẫn tin rằng AI giúp họ nhanh hơn 20%.

Đó là công cụ đầu năm 2025, dùng bởi người có kinh nghiệm trong codebase trưởng thành. Kết quả này nói rất ít về người mới làm prototype.

Ngày 24 tháng 2 năm 2026, METR công bố bản cập nhật với 57 lập trình viên, 143 repo và hơn 800 task. Các con số dùng quy ước dấu theo thay đổi thời gian làm task, và tôi hiểu số âm là tốn ít thời gian hơn (kết quả 2025 là +19%). Nhóm quay lại: -18%, khoảng tin cậy từ -38% đến +9%. Nhóm mới: -4%, khoảng từ -15% đến +9%. Kết luận của chính METR: “our data is only very weak evidence for the size of this increase.” Ngày càng nhiều lập trình viên từ chối làm việc không có AI, và METR cũng giảm tiền công từ 150 xuống 50 USD mỗi giờ, nên mẫu bị chọn lọc. Cách đọc hợp lý: công cụ có lẽ đã tốt hơn, nhưng chưa ai có con số sạch.

Bảo mật. Báo cáo 2025 của Veracode thử hơn 100 LLM trên 80 bài hoàn thành code, xây quanh các loại lỗ hổng đã biết. Kết quả: AI “introduces security vulnerabilities in 45 percent of cases”, trong đó cross-site scripting và log injection thất bại lần lượt ở 86 và 88 phần trăm số ca. Báo cáo 2026, công bố ngày 28 tháng 7 năm 2026, ghi “the average security pass rate across models is 56%”, “barely changed from 55% in the first report.” Kết quả cũng chênh theo loại lỗi: 83% với SQL injection, 12-15% với log injection và cross-site scripting.

Hai lưu ý. Đây là benchmark của nhà cung cấp trên các bài tách biệt, không phải kiểm toán ứng dụng đã phát hành. Và chúng kiểm tra mô hình, không kiểm tra việc lập trình viên có review kết quả hay không.

Code ngoài đời thực. CodeRabbit phân tích 470 pull request mã nguồn mở (320 có AI đồng tác giả, 150 chỉ do người viết) và báo cáo 10,83 vấn đề mỗi PR của AI so với 6,45 của người, tức gấp khoảng 1,7 lần. Chính tác giả nêu việc xác định PR nào do AI viết là một hạn chế, và CodeRabbit bán công cụ review.

Vibe Security Radar của Georgia Tech quét các advisory công khai và lần theo commit gây lỗi để tìm dấu hiệu của công cụ AI. Tính đến bài viết ngày 13 tháng 4 năm 2026, họ có 74 ca đã xác nhận, 14 nghiêm trọng (critical) và 25 mức cao (high). Khoảng 18 ca xuất hiện trong bảy tháng cuối năm 2025; riêng tháng 3 năm 2026 có 35 ca. Công cụ bỏ sót mọi ca mà dấu hiệu đã bị xóa, nên đây là số ca phát hiện được, không phải tỷ lệ.

Một sự cố, không phải nghiên cứu. Tháng 7 năm 2025, người sáng lập SaaStr Jason Lemkin kể rằng agent của Replit đã xóa một cơ sở dữ liệu dù ông dặn không được đổi code. Agent nói không thể rollback; theo The Register, “It turns out Replit was wrong, and the rollback did work.”

Dùng được ở đâu, hỏng ở đâu

Tình huống	Mức phù hợp	Lý do
Prototype bỏ đi, một tác giả	Tốt	Lỗi ít tốn kém; đúng khung của Karpathy
Công cụ cá nhân, người dùng tin cậy	Chấp nhận được	Fowler: phần mềm “disposable” cho “a limited audience”
Code người khác phụ thuộc vào	Kém nếu không review	Chi phí bảo trì và độ đúng dồn lại theo thời gian
Xác thực, xử lý input, secret	Kém nếu không review	Các benchmark trên cho thấy lỗ hổng lặp lại
Tiền hoặc dữ liệu production	Kém	Lỗi tốn kém và đôi khi không đảo ngược được

Fowler vạch ranh giới tương tự: vibe coding hợp với phần mềm “only used by its author or a close group of collaborators who understand and accept the risks”, còn code “more complex, more widely-used, and with more consequences to its risks should not be forgotten about.”

Ý nghĩa với người làm sản phẩm phần mềm nhỏ

Nếu bạn làm thứ gì đó nhỏ nhưng người khác sẽ dựa vào, bằng chứng gợi ý một sự phân chia. Cứ dùng AI sinh code thoải mái cho prototype và công cụ nội bộ. Khi đã có người dùng thật, thông tin đăng nhập hoặc thanh toán, hãy đọc diff, chạy công cụ phân tích tĩnh, và coi kết quả của mô hình như bản nháp của người chưa biết mô hình đe dọa của bạn.

Tôi cũng sẽ dè chừng bất kỳ con số năng suất đơn lẻ nào, theo cả hai hướng. Dữ liệu có đối chứng tốt nhất hiện là một mẫu nhỏ, bị chọn lọc, và chính các tác giả cũng nói vậy.