Giới thiệu ‒ Những hiểu lầm và thực tế về năng suất của lập trình viên khi dùng AI
- Mark Zuckerberg (CEO Meta) tuyên bố rằng "đến cuối năm 2025 sẽ thay thế toàn bộ kỹ sư cấp trung bằng AI", khiến các CTO ở nhiều công ty khác cũng chịu áp lực tương tự.
- Diễn giả nhấn mạnh rõ rằng "AI không thể thay thế hoàn toàn lập trình viên"; việc áp dụng AI rõ ràng có thể giúp tăng năng suất, nhưng không phải lúc nào cũng vậy, và cũng không hiếm trường hợp năng suất còn giảm đi.
Thiết kế nghiên cứu và dữ liệu
- Đo lường trong 3 năm, trên hơn 600 công ty, hơn 100.000 kỹ sư phần mềm, hơn một tỷ dòng mã và hàng chục triệu commit.
- Phần lớn là dữ liệu dựa trên kho lưu trữ riêng tư (private repo) → có thể đo được thay đổi năng suất thực tế ở cấp đội ngũ phát triển và cấp doanh nghiệp.
Hạn chế của các nghiên cứu trước đây
- Các báo cáo do nhà cung cấp dẫn dắt thường mang mục đích quảng bá công cụ AI của chính họ nên thiếu tính khách quan.
- Chỉ nhìn vào số lượng commit/PR đơn thuần hoặc thay đổi về thời gian làm việc trung bình có thể làm méo mó năng suất thực tế.
- Ví dụ: ngay sau khi dùng AI, các commit liên quan đến bug hoặc làm lại (rework) cũng tăng theo, nên bề ngoài có thể trông như năng suất tăng.
- Trong các thử nghiệm greenfield (dự án mới), hiệu quả của AI có vẻ rất lớn, nhưng với mã nguồn hiện có (brownfield), khác biệt này giảm đi.
- Khảo sát lập trình viên (self-report) hầu như không tương quan mạnh với năng suất thực tế (độ vênh giữa cảm nhận và thực tế có thể vượt quá 30 điểm phần trăm).
Mô hình đo năng suất của Stanford
- Sử dụng mô hình tự động hóa dựa trên AI tương tự cách hội đồng chuyên gia đánh giá:
- Đo thay đổi chức năng theo từng commit (added/removed/refactored/rework)
- Không chỉ dựa vào "số dòng", mà tập trung vào "chức năng, khả năng bảo trì và chất lượng"
- Đánh giá chi tiết lượng tính năng được đưa vào, mức độ refactor, tỷ trọng chỉnh sửa lại (rework) của các commit gần đây, v.v.
Kết quả nghiên cứu chính
- Nhìn chung, khi áp dụng AI, năng suất trung bình tăng 15~20%.
- Tuy nhiên, đi kèm là một lượng đáng kể "làm lại" (rework), nên lợi ích cảm nhận được đôi khi bị phóng đại.
- Có độ chênh lệch rất lớn giữa các đội, công ty và loại nhiệm vụ.
Nguyên nhân của chênh lệch năng suất: độ khó nhiệm vụ, loại dự án, ngôn ngữ, kích thước codebase
| Loại dự án | Độ phức tạp thấp | Độ phức tạp cao |
|---|---|---|
| Greenfield (mới) | 30~40% ↑ | 10~15% ↑ |
| Brownfield (hiện có) | 15~20% ↑ | 0~10% ↑ |
- AI phát huy hiệu quả lớn trong các dự án mới (greenfield), độ phức tạp thấp.
- Với hệ thống hiện có (brownfield) và phức tạp, hiệu quả giảm rõ rệt; trong một số trường hợp còn ghi nhận cả sự sụt giảm năng suất.
- Theo mẫu thực tế gồm 27 công ty và 136 đội ngũ (được nhắc trong bài giảng).
Độ phổ biến của ngôn ngữ và hiệu quả của AI
- Với Python/Java/JavaScript (các ngôn ngữ phổ biến), AI giúp cải thiện năng suất đáng kể,
- Còn COBOL/Elixir/Haskell (các ngôn ngữ kém phổ biến): AI gần như không giúp được gì, thậm chí trong các tác vụ phức tạp còn gây lãng phí thời gian và làm giảm năng suất.
- Ví dụ: trong trường hợp ngôn ngữ ít phổ biến & độ khó cao, AI "nhiều lỗi, không tạo ra được đoạn mã đúng" → thà không có còn hơn.
Kích thước codebase và hiệu quả của AI
- Codebase càng lớn thì hiệu quả tăng năng suất của AI càng giảm mạnh.
- Nguyên nhân:
- Giới hạn context window: LLM không thể đưa toàn bộ ngữ cảnh của nhiều file hoặc hàng trăm nghìn đến hàng triệu dòng mã vào cùng lúc.
- Tỷ lệ "signal/noise" giảm: càng có nhiều thông tin ngữ cảnh, AI càng khó xác định chính xác thông tin phù hợp.
- Khi độ phức tạp theo domain và dịch vụ tăng lên, độ khó triển khai lại trong thực tế cũng tăng theo.
- Trên thực tế, các LLM lớn mới nhất (như Gemini 1.5 Pro) cho thấy khi "số token" tăng lên, độ chính xác có thể giảm mạnh từ 90% xuống dưới 50%.
- Nguyên nhân:
Tổng kết: Khi nào AI thực sự hiệu quả?
- AI trong đa số trường hợp (đặc biệt là viết mã mới, đơn giản) thực sự giúp cải thiện năng suất của lập trình viên.
- Tuy nhiên, trong môi trường có bảo trì phức tạp, mã cũ (quy mô lớn), ngôn ngữ không phổ biến, nhiều phụ thuộc, hạn chế là rất lớn.
- Chiến lược năng suất AI tối ưu cần được thiết kế cẩn trọng theo đặc thù của công ty, đội ngũ và nhiệm vụ (không phải kiểu "one size fits all").
- Khó có thể tin tưởng vào khảo sát, chỉ số marketing hay việc tăng số commit đơn thuần; cần đo theo tiêu chí thực tế như tính chức năng của mã, tỷ lệ công việc lặp lại, lượng làm lại, v.v.
Bình luận bổ sung và ví dụ
- "Ghost engineer": trong dữ liệu, cũng phát hiện khoảng 10% kỹ sư gần như không làm việc mà vẫn nhận lương.
- Nhấn mạnh sự cần thiết của các công cụ ra quyết định dựa trên chỉ số để trưởng nhóm và CTO có thể chẩn đoán vấn đề thực tế một cách nhanh chóng.
Kết luận
- AI giúp tăng năng suất trong "phần lớn tình huống" nhưng cần tránh cả việc đánh giá quá cao lẫn quá thấp.
- Cần xác định rõ những điều kiện cụ thể giúp việc áp dụng đạt hiệu quả (đơn giản/mới/ngôn ngữ phổ biến/codebase nhỏ) rồi mới triển khai; việc áp dụng thiếu chọn lọc và thiếu phản biện thậm chí có thể phản tác dụng.
2 bình luận
Ngay cả khi không áp dụng vào phần mềm chính, AI vẫn giúp tiết kiệm rất nhiều thời gian ở các chương trình thử nghiệm hoặc giai đoạn khởi đầu của dự án.
Ngay cả khi không tính đến việc nó viết mã giúp, tôi thấy các tính năng trợ lý đã thay đổi một trời một vực kể từ khi AI được đưa vào. Giờ đây, tôi cho rằng chúng ta đã bước vào thời đại mà AI không còn là lựa chọn mà là điều bắt buộc.
Thực tế thì nó rất hữu ích ở giai đoạn MVP. Đặc biệt, tôi nghĩ nhất định phải dùng cho việc viết chú thích, logging và ghi lại lịch sử.
Tuy nhiên, khi codebase lớn lên thì nó hay bị ảo giác, quên mất mã hiện có và tạo ra những kết quả kỳ quặc. Cần cân nhắc dùng context engineering hoặc tìm cách thu gọn codebase.
Có lẽ nếu có thể dùng prompt lớn hơn thì sẽ cải thiện được.
Hiện tại có vẻ nó làm tốt với Java, Python, JavaScript và Go. Tôi chủ yếu dùng Copilot, đồng thời dùng cả Claude và ChatGPT.