27 Công Ty Tăng Gấp Nhiều Lần Chi Tiêu Cho AI Coding. Gần Như Không Ai Chứng Minh Được Nó Đáng Tiền.

Gergely Orosz, người viết bản tin The Pragmatic Engineer, đã dành nhiều tuần phỏng vấn các lãnh đạo kỹ thuật và kỹ sư senior tại 27 công ty về đúng một câu hỏi: tiền chi cho công cụ AI coding thực sự mang lại gì? Bài viết công bố ngày 20/10/2026. Tóm lại: chi tiêu tăng rất nhanh, một chỉ số hoạt động đơn giản (số lượng pull request) tăng còn nhanh hơn, còn khi hỏi liệu năng suất thực — giá trị thực sự đưa tới người dùng — có tăng cùng tốc độ hay không, gần như không ai trả lời được chắc chắn.

Số tiền chi ra là thật, và rất lớn

Con số gây chú ý nhất trong bài đến từ một công ty giao dịch định lượng (quant trading) với khoảng 2.000 kỹ sư. Tổng chi tiêu hàng tháng cho công cụ AI coding của công ty này tăng từ khoảng 500.000 USD vào tháng 1 lên khoảng 8 triệu USD vào tháng 9 — tăng 16 lần chỉ trong chín tháng. Chi tiêu trung bình mỗi kỹ sư tăng từ khoảng 80 USD/tháng lên khoảng 1.600 USD/tháng trong cùng kỳ, với mức giới hạn cá nhân tối đa 25.000 USD/nhân viên/tháng.

Công ty này là trường hợp cực đoan, nhưng xu hướng chung khá nhất quán ở các công ty khác mà Orosz phỏng vấn. Một startup .NET chỉ 2 người báo cáo chi khoảng 3.000 USD/tháng/kỹ sư cho các công cụ như Claude Opus và GitHub Copilot. Một công ty hospitality ở vòng Series D (khoảng 200 kỹ sư) đặt mức giới hạn mặc định 1.500 USD/kỹ sư/tháng và thực tế chi khoảng 2.200 USD/tháng vào tháng 9. Một công ty SaaS niêm yết đại chúng với khoảng 600 kỹ sư giới hạn chi tiêu ở mức 1.200 USD/kỹ sư/tháng, trong đó chưa tới 5% kỹ sư chạm mức trần này. Các công ty khác trong mẫu khảo sát dao động từ mức trung bình 1.000 USD/kỹ sư/tháng ở các công ty lớn hơn, đến mức trần cứng 4.000 USD/kỹ sư/tháng tại một tập đoàn đa quốc gia trên 10.000 nhân viên — nơi chi tiêu thực tế trung bình lại gần với 1.000 USD/kỹ sư/tháng hơn. Tính trên toàn bộ 27 nơi làm việc được khảo sát, ngân sách được báo cáo dao động từ khoảng 150 USD đến khoảng 3.000 USD/kỹ sư/tháng, với Claude và Opus 5.5 là các mô hình được nhắc tới nhiều nhất.

Chi tiêu tăng thì không có gì phải tranh luận. Mọi công ty trong bài đều đang chi nhiều hơn cho công cụ AI coding so với một năm trước. Câu hỏi khó hơn là số tiền đó đang mua được gì.

Số lượng pull request tăng còn nhanh hơn — và đó chính là vấn đề

Orosz bổ sung thêm dữ liệu tổng hợp từ hai nhà cung cấp dịch vụ review code bằng AI: CodeRabbit và Gitar. Số liệu của CodeRabbit, lấy từ nhóm 20.000 developer dùng nền tảng của họ, cho thấy số PR hàng tuần tăng 113% và số PR hàng tháng tăng 127% so với cùng kỳ năm trước; theo dõi cùng nhóm này trong suốt một năm thì mức tăng là 128%. Dữ liệu của Gitar cho thấy sự phân tách giữa nhóm ‘chuẩn’ tạo ra khoảng 5 PR/kỹ sư/tuần và nhóm ‘AI-native’ tạo ra 60 PR hoặc hơn.

Từng công ty trong mẫu phỏng vấn cũng cho thấy mức tăng tương tự. Startup .NET 2 người (Ix Technologies) tăng từ 1-2 PR/ngày/kỹ sư lên 60 PR/tuần (10-15 PR/ngày) — tăng 5-10 lần. Một nhóm tại tập đoàn đa quốc gia trên 10.000 nhân viên tăng từ 1,5 lên 4 PR/kỹ sư/tuần, tức tăng 4 lần, với trưởng nhóm cho biết họ hiện đóng được gấp 3 lần số user story mỗi tháng và đang giao nhiều giá trị kinh doanh hơn. Một công ty niêm yết đại chúng khác báo cáo kích thước PR tự nó tăng khoảng 3 lần tính theo số dòng code mỗi thay đổi.

Sơ đồ trên tóm tắt toàn bộ bài viết trong bốn bước. Chi tiêu tăng. Số lượng PR tăng nhanh hơn. Năng suất thực có tăng theo hay không thì tùy vào ai được hỏi trong cùng một công ty. Và kết luận trung dung, lặp lại ở nhiều cuộc phỏng vấn, là kích thước PR và số lượng PR có thể cùng tăng mà tốc độ làm việc thực tế không nhích chút nào.

“Tốc độ phát triển thực tế không tăng nhiều”

Phản biện rõ ràng nhất trong bài đến từ một staff engineer tại công ty SaaS niêm yết đại chúng với khoảng 600 kỹ sư. Công ty này vẫn duy trì việc review PR bằng người — kỹ sư này được trích lời nói rằng người review ‘bắt được rất nhiều lỗi mà agent bỏ sót’ — và riêng về câu hỏi năng suất: “Khi team quan tâm đến chất lượng code production và muốn giữ nguyên như trước thời AI, thì tốc độ phát triển thực tế không tăng nhiều.”

Một kỹ sư tại công ty AI SaaS khoảng 100 người nói thẳng hơn: “Chúng tôi không thấy việc gì được hoàn thành nhanh hơn trước.” Một kỹ sư tại công ty hospitality vòng Series D mô tả việc chủ động giữ vững tiêu chuẩn kích thước và chất lượng PR, không để khối lượng được AI hỗ trợ phình to tùy ý: “Chúng tôi cố giữ tiêu chuẩn PR như trước, cả về kích thước và chất lượng.”

Đối lập với những ý kiến đó là câu chuyện tích cực thực sự từ trưởng nhóm tại tập đoàn đa quốc gia — đóng được gấp 3 lần user story mỗi tháng, kèm khẳng định giao nhiều giá trị kinh doanh hơn, không chỉ viết nhiều code hơn. Chính Orosz cũng thẳng thắn khi tổng kết hiện trạng ngành: “ROI của AI là gì? Một câu hỏi mà rất ít công ty có vẻ trả lời được — ít nhất là ở thời điểm này.” Cần lưu ý rằng mọi số liệu năng suất trong bài, dù tích cực hay hoài nghi, đều do người được phỏng vấn tự báo cáo hoặc lấy từ dữ liệu tổng hợp của nhà cung cấp dịch vụ. Không có nhóm đối chứng được đo đạc bằng công cụ nào trong toàn bộ mẫu khảo sát.

Vì sao đếm PR vẫn luôn thắng làm chỉ số mặc định

Điều này không có nghĩa các lãnh đạo kỹ thuật đang đo số lượng PR là làm sai một cách cố ý. Đếm PR thắng theo mặc định vì, như Orosz mô tả, đó là “một chỉ số rất đơn giản, và là một trong những phép đo ‘có sẵn’ ở gần như mọi công ty” — lấy thẳng từ GitHub, GitLab, hay bất kỳ Git host nào đang dùng, không cần dự án đo đạc riêng. Đây cũng là chỉ số, ít nhất ở thời điểm này, chưa bị ‘chơi’ (gamed) theo kiểu số dòng code hay số lượng commit từng bị thao túng một thập kỷ trước.

Nhưng “dễ đo” và “đo đúng thứ quan trọng” là hai thuộc tính khác nhau, và dữ liệu này cho thấy chúng đang tách rời nhau ngay trước mắt. Một công cụ AI coding có thể thực sự giúp tạo pull request nhanh hơn mà không giúp tạo ra pull request đúng, có thể triển khai, đã được review nhanh hơn. Một model có thể biến một bản fix 5 dòng thành bản fix 15 dòng làm cùng một việc nhưng có diện tích cần review lớn hơn. Cả hai trường hợp đều thể hiện là PR tăng trưởng. Không trường hợp nào rõ ràng là một chiến thắng về năng suất, và câu trích dẫn của kỹ sư công ty hospitality ở trên chính là mô tả trực tiếp một team đang cố chống lại đúng xu hướng trôi dạt đó.

Nên đo cái gì thực sự

Nếu chỉ đếm PR không trả lời được câu hỏi ROI, giải pháp không phải là bỏ chỉ số này — nó rẻ và đã có sẵn, nên cứ tiếp tục thu thập — mà là ghép nó với ít nhất một tín hiệu đo kết quả, không phải hoạt động. Dựa trên những điểm bất đồng thực sự giữa các team mà khảo sát này phơi bày, bốn thứ sau đáng được theo dõi trước khi tin vào biểu đồ tăng trưởng PR:

• Kích thước PR, chuẩn hóa theo số lượng PR. Nếu số PR tăng 4 lần và kích thước PR trung bình (số dòng thay đổi, số file bị động) cũng tăng 3 lần, bạn chưa chứng minh được năng suất tăng gấp bốn — có thể chỉ là cùng một lượng code đó bị chia nhỏ hoặc phình to theo cách khác. Theo dõi cả hai số song song, không chỉ riêng số PR.
• Cycle time từ khi mở PR đến khi merge, và từ khi mở ticket đến khi deploy. Đây là con số thực sự trả lời câu hỏi “việc giao hàng có nhanh hơn không,” độc lập với việc công việc đó được chia thành bao nhiêu PR. Một team hoàn thành cùng lượng việc thực trong ít thời gian thực hơn thì có câu chuyện năng suất thật; một team mở nhiều PR hơn trong cùng khoảng thời gian thực thì không.
• Tỷ lệ revert và tỷ lệ lỗi sau merge. Tạo PR nhanh hơn nhưng dẫn tới nhiều rollback, hotfix, hoặc sự cố production hơn không phải là lợi ích thuần — đó là chi phí bị dịch chuyển, từ giai đoạn viết code sang giai đoạn vận hành. Nếu PR được AI hỗ trợ có tỷ lệ revert cao hơn mức nền, con số đó cần nằm trong cùng báo cáo với số tiền chi tiêu.
• Tín hiệu định tính từ chính các kỹ sư đang review công việc. Những câu trích dẫn hữu ích nhất trong bài của Pragmatic Engineer không đến từ dashboard — mà từ việc hỏi trực tiếp một staff engineer rằng công việc có cảm giác nhanh hơn không. “Tốc độ phát triển không tăng nhiều” và “chúng tôi không thấy việc gì nhanh hơn” là những dữ liệu mà biểu đồ đếm PR không thể tự tạo ra. Một khảo sát ngắn, lặp lại định kỳ với các kỹ sư senior và người review, hỏi theo cùng cách mỗi quý, sẽ bắt được sự trôi dạt mà chỉ số hoạt động bỏ sót.

Kết luận thành thật

Dữ liệu trong khảo sát này không ủng hộ câu chuyện gọn gàng “công cụ AI coding đang đáng tiền,” cũng không ủng hộ câu chuyện gọn gàng “tất cả chỉ là thổi phồng.” Nó ủng hộ một vùng trung gian gây tranh cãi, khác nhau theo từng công ty: chi tiêu tăng ở mọi nơi, số lượng PR tăng ở mọi nơi và tăng nhanh hơn chi tiêu, còn việc đó có chuyển hóa thành nhiều giá trị được giao hơn hay không thì tùy vào việc mỗi team đang tối ưu cho điều gì trước khi công cụ AI xuất hiện, và tùy vào việc mỗi team hiện có đang kiểm tra kỹ giả định của chính mình — rằng nhiều PR hơn nghĩa là tiến bộ hơn — hay không. Các lãnh đạo kỹ thuật muốn có câu trả lời thật cho tổ chức của mình sẽ cần nhìn vào cycle time, tỷ lệ revert, và điều mà các kỹ sư senior của chính họ nói khi được hỏi thẳng — vì biểu đồ đếm PR, một mình nó, sẽ luôn kể một câu chuyện đẹp, bất kể câu chuyện đó có đúng hay không.

Nguồn: Gergely Orosz, “What’s the ROI of software engineers’ spending on AI?”, The Pragmatic Engineer, 20/10/2026.