AI giúp dev nhanh hơn 55% hay chậm hơn 19%? Đọc kỹ hai nghiên cứu

"AI giúp dev nhanh gấp đôi" hay "AI làm dev chậm đi"? Cả hai tiêu đề đều có nghiên cứu đứng sau. Nếu bạn là Tech Lead hay PM đang quyết định đầu tư công cụ AI cho team, cần đọc kỹ điều kiện của từng nghiên cứu thay vì chỉ nhìn con số. Bài này so sánh hai thí nghiệm có đối chứng được trích dẫn nhiều nhất và rút ra cách đo năng suất trong team của bạn.

Nghiên cứu 1: Copilot giúp nhanh hơn 55% (2022–2023)

• Peng và cộng sự (cùng GitHub, Microsoft) tuyển lập trình viên, chia ngẫu nhiên hai nhóm, giao cùng một việc: viết một HTTP server bằng JavaScript.
• Nhóm dùng GitHub Copilot hoàn thành nhanh hơn 55,8%.
• Khảo sát đi kèm của GitHub cho thấy phần lớn người dùng thấy đỡ bực bội và giữ được sự tập trung tốt hơn với việc lặp đi lặp lại.

Nghiên cứu 2: Dev kỳ cựu chậm hơn 19% (METR, 2025)

• METR chạy thử nghiệm ngẫu nhiên với 16 lập trình viên giàu kinh nghiệm trên chính các repo mã nguồn mở lớn mà họ đóng góp lâu năm, tổng cộng 246 issue thật.
• Mỗi issue được chia ngẫu nhiên: được dùng AI (chủ yếu Cursor với Claude 3.5/3.7 Sonnet) hoặc không.
• Khi được dùng AI, họ mất thời gian nhiều hơn 19%.
• Điểm đáng chú ý nhất: trước khi làm, họ dự đoán AI giúp nhanh hơn 24%; sau khi làm xong vẫn tin mình nhanh hơn khoảng 20%.

Vì sao kết quả trái ngược?

METR tự nhấn mạnh kết quả không có nghĩa AI vô dụng với mọi dev hay mọi tác vụ; nó cho thấy lợi ích phụ thuộc mạnh vào bối cảnh, và công cụ thay đổi rất nhanh.

Bài học quan trọng nhất: cảm nhận không phải số đo

Khoảng cách giữa "tin là nhanh hơn 20%" và "thực tế chậm hơn 19%" là lý do bạn không thể dựa vào khảo sát cảm nhận để quyết định đầu tư. Thời gian viết prompt, chờ, đọc và sửa output AI dễ bị đánh giá thấp.

Đo năng suất trong team của bạn

1. Chọn việc thật, chia ngẫu nhiên: cùng loại task, một nửa dùng AI, một nửa không.
2. Đo kết quả, không đo hoạt động: thời gian từ nhận việc đến merge, số lỗi sau release, số vòng review; không đo số dòng code.
3. Tách theo loại việc: viết mới, sửa bug, refactor, viết test cho kết quả rất khác nhau.
4. Theo dõi đủ lâu: vài tuần đầu là giai đoạn học công cụ.

Rủi ro và lưu ý

• Trích nghiên cứu sai bối cảnh: dùng con số 55% để hứa với ban lãnh đạo cho dự án bảo trì codebase cũ là đặt kỳ vọng sai.
• Bỏ qua chất lượng: nhanh hơn nhưng nhiều bug hơn thì không phải năng suất.
• Kết quả lỗi thời nhanh: cả hai nghiên cứu dùng công cụ của thời điểm đó; hãy đo lại định kỳ.

Áp dụng thế nào?

• Dev: Tự ghi thời gian thực tế cho vài task có và không có AI; bạn có thể bất ngờ.
• Tech Lead: Chạy thử nghiệm nhỏ 4–6 tuần với chỉ số lead time và tỷ lệ lỗi trước khi mua công cụ cho cả phòng.
• PM: Báo cáo lợi ích AI theo loại việc, kèm điều kiện, thay vì một con số "% năng suất" chung.