Productivity Paradox: AI Giúp Viết Code Nhanh Hơn, Nhưng Chúng Ta Không Deliver Nhiều Hơn
Đã bao giờ bạn nhìn vào dashboard sprint và tự hỏi, 80% code đã có AI viết, vậy tại sao số feature chúng ta ship ra vẫn y hệt tháng trước?
Nghịch lý lớn nhất khi áp dụng AI vào phát triển phần mềm: công cụ mạnh hơn, nhưng output không đổi. Có vẻ như vấn đề không nằm ở AI, mà nằm ở cách chúng ta tổ chức công việc.
Jevons Paradox: khi hiệu quả không tạo ra nhiều giá trị hơn
Năm 1865, nhà kinh tế học William Stanley Jevons phát hiện ra một nghịch lý: càng làm cho động cơ hơi nước hoạt động hiệu quả hơn, nước Anh lại càng tiêu thụ nhiều than hơn, không phải ít hơn.
Tại sao? Vì khi máy chạy tốt hơn, chi phí vận hành rẻ hơn, nên ngày càng nhiều nhà máy, tàu hỏa, và xưởng sản xuất dám đầu tư mua máy. Tổng số máy tăng vọt. Và dù mỗi cái máy tốn ít than hơn trước, nhưng tổng lượng than cả nước cần lại lớn hơn nhiều.
Nhưng trong thế giới phần mềm, chúng ta đang chứng kiến một biến thể tệ hơn: AI giúp developer làm việc nhanh hơn, nhưng thay vì dùng thời gian đó để làm thêm, họ dùng nó để… nghỉ ngơi. Không có ai sai ở đây cả. Đây là phản ứng hết sức tự nhiên của con người.
Tại sao điều này xảy ra?
Phía developer: Không có kỳ vọng mới
Con người làm việc dựa trên kỳ vọng rõ ràng. Khi sprint vẫn có cùng số story points, khi definition of done không thay đổi, khi không ai nói “giờ bạn cần deliver nhiều hơn”, thì mặc nhiên developer sẽ làm đúng phần việc đó và dùng thời gian còn lại theo cách họ muốn.
Điều này không phải là lỗi về đạo đức. Đây là hành vi hoàn toàn hợp lý khi thiếu signal rõ ràng từ tổ chức.
Phía tổ chức: Planning chưa điều chỉnh theo capacity mới
- Backlog không đủ lớn để fill thời gian dôi ra
- Sprint planning vẫn estimate theo capacity cũ (trước AI)
- Không có metric nào đo được lượng thời gian “tiết kiệm được”
- Không có cơ chế tái phân bổ thời gian rảnh vào việc có giá trị
Nếu 80% code được viết bởi AI nhưng velocity không tăng, bottleneck của bạn đã không còn là việc viết code nữa. Nó đang nằm ở requirements, code review, testing, deployment pipeline, hay product decision-making, những thứ AI chưa thay thế được.
Bottleneck đã dịch chuyển
Đây là insight quan trọng nhất: AI không tạo ra thêm thời gian trống trong hệ thống. Nó chỉ làm cho một bước cụ thể trong quy trình nhanh hơn. Nếu những bước khác không được tối ưu tương ứng, thời gian tiết kiệm được sẽ tích lại ở đó, dưới dạng idle time.
# Quy trình phần mềm điển hình
bottleneck_cũ = "viết code" # <-- AI đã giải quyết rồi ✅
bottleneck_mới = "requirements clarity"
| "code review quality"
| "testing coverage"
| "deployment frequency"
| "product decision speed"
# Câu hỏi cần trả lời:
where_is("bottleneck của bạn hiện tại?")
Gợi ý một số hành động cụ thể
1. Công khai định nghĩa lại kỳ vọng
Nói thẳng với team: “AI giúp chúng ta code nhanh hơn, nên chúng ta sẽ deliver nhiều hơn.” Đừng để kỳ vọng ngầm, phải explicit và có văn bản rõ ràng.
2. Luôn có backlog đủ lớn
Technical debt, test coverage, refactoring, performance improvements… nếu developer xong việc và không biết làm gì tiếp, đó là lỗi của planning, không phải developer.
3. Đo output, không đo giờ ngồi
Chuyển từ “làm bao nhiêu giờ” sang “deliver bao nhiêu value” Features shipped/tháng, bug rate, deployment frequency là những số liệu thực sự quan trọng.
4. Đầu tư thời gian dôi ra có chủ đích
Review code AI kỹ hơn (AI code cần review nghiêm túc hơn, không phải ít hơn), viết test, làm tool nội bộ, hướng dẫn cho junior member…
5. Tăng velocity từng bước có kiểm soát
Tăng scope 15~20% mỗi sprint thay vì tăng đột ngột. Để team thích nghi dần với capacity mới. Tránh bị shock về kỳ vọng.
6. Tìm và phá bottleneck tiếp theo
Có thể sử dụng Value Stream Mapping (VSM) để tìm nơi work items “ngồi chờ” lâu nhất. Bottleneck mới thường là requirements, review, hay deployment, không phải coding.
AI không phải là câu trả lời, nó là câu hỏi tiếp theo
Khi một công ty thành công đưa AI vào quy trình phát triển phần mềm, điều đó không có nghĩa là hành trình tối ưu hóa đã kết thúc. Nó có nghĩa là một bottleneck đã được giải quyết và hệ thống đang chờ bạn tìm ra bottleneck tiếp theo.
Productivity paradox là dấu hiệu cho thấy tổ chức chưa sẵn sàng về mặt process và culture để hấp thụ năng lực mới mà AI mang lại. Đây không phải thất bại, đây là giai đoạn chuyển tiếp hoàn toàn bình thường, và nó có thể được giải quyết có hệ thống.
AI giúp bạn viết code nhanh gấp đôi. Nhưng nếu bạn vẫn chỉ build những thứ đúng bằng một nửa tốc độ cũ, thì lợi thế đó đã biến mất hoàn toàn.
Câu hỏi không phải là “Làm sao để developer không nhàn rỗi?” Câu hỏi đúng là: “Chúng ta cần tổ chức công việc như thế nào để toàn bộ hệ thống, từ idea đến production, chạy nhanh hơn tương xứng với tốc độ coding mới?”
Áp dụng AI thành công không phải là hành trình của leadership, cũng không phải hành trình của từng developer riêng lẻ. Đó là hành trình của cả một team, khi mọi người cùng thấy rõ vấn đề, cùng chịu trách nhiệm, và cùng quyết định rằng thời gian vừa được giải phóng xứng đáng được dùng cho thứ gì đó lớn hơn.
About The Author
