Các tác tử lập trình tự chủ đã nâng hoạt động commit của lập trình viên lên 240% tích lũy. Còn phát hành — công đoạn phần mềm thực sự đến tay khách hàng — chỉ tăng 30% (Demirer, Musolff & Yang, NBER, 2026). Cùng nhóm lập trình viên, cùng công cụ, cùng nghiên cứu, cùng khung thời gian. Tám phần mười mức tăng đo được chưa bao giờ ra khỏi cửa công ty.
Khoảng cách đó chính là hình dạng của phần lớn luận chứng đầu tư AI được viết trong năm nay. Dự án thí điểm đo công đoạn mà công cụ tăng tốc. Không ai đo công đoạn quyết định việc bàn giao, bởi công đoạn ấy không gắn với khoản phí bản quyền nào.
Bài báo có tên Writing Code vs. Shipping Code, và sự phân biệt nằm trong tiêu đề chính là toàn bộ phát hiện. Lợi ích năng suất từ AI là có thật, lớn, và được đo ở cấp tác vụ. Chúng đến tay khách hàng sau khi đã bị chiết khấu nặng.
Điều một nghiên cứu 500.000 lập trình viên thấy được mà dự án thí điểm không thấy
Mert Demirer (MIT Sloan), Leon Musolff và Liyuan Yang đã ghép dữ liệu telemetry sử dụng AI với hơn 500.000 lập trình viên GitHub trong thiết kế nghiên cứu sự kiện có đối sánh, rồi theo dõi hiệu ứng qua các thế hệ công cụ kế tiếp nhau (NBER Working Paper 35275, 2026).
Kết quả theo từng thế hệ đáng được tách riêng, vì đây là phần đa số người đọc muốn trích dẫn:
- Tự động hoàn thành: hiệu ứng tích lũy +30% lên commit
- Tác tử lập trình tương tác: +180%
- Tác tử lập trình tự chủ: +240%
Mỗi thế hệ là một bước nhảy thực sự. Ai lập luận rằng công cụ tác tử không làm dịch chuyển thông lượng ở cấp tác vụ thì đang tranh cãi với một mẫu rất lớn.
Rồi đến sự suy giảm. Hiệu ứng 240% trên commit rơi xuống 80% ở số lượng dự án và 30% ở số bản phát hành thực tế. Và khi các tác giả bước ra khỏi GitHub để nhìn vào bốn sàn phần mềm lớn, họ thấy số ứng dụng mới tăng mạnh nhưng không có sự gia tăng nào ở tổng mức sử dụng.
Nhiều mã hơn được viết. Nhiều dự án hơn được khởi động đôi chút. Nhiều hơn một chút được chuyển giao. Không có gì được sử dụng nhiều hơn.
Kết quả trên các sàn xứng đáng một trọng số riêng, vì nó loại trừ một cách đọc dễ chịu. Nếu chỉ là nút thắt cổ chai, ta sẽ dự đoán một khối tồn đọng — đầu ra chờ sau cánh cổng, thu hồi được khi cổng mở rộng. Nhưng ứng dụng mới tăng trong khi tổng mức sử dụng thì không, và điều đó chỉ tới một thứ nằm sau công đoạn phát hành: thị trường hấp thụ thêm nguồn cung mà không tạo thêm nhu cầu. Một phần lợi ích thiếu hụt đang xếp hàng sau khâu rà soát của con người. Một phần khác vốn dĩ chẳng bao giờ trở thành giá trị, vì làm ra nhiều hơn một thứ không ai yêu cầu thì không phải là đầu ra. Cả hai cách đọc đều nên khiến một người điều hành thận trọng với luận chứng quy đổi tốc độ cấp tác vụ thẳng thành doanh thu.
Vì sao lợi ích năng suất từ AI chết trước công đoạn cuối
Giải thích của các tác giả là giả thuyết mắt xích yếu, và nó cổ xưa cũng như vững chắc hơn bất cứ điều gì riêng của AI: trong một chuỗi sản xuất nhiều công đoạn, tổng đầu ra bị chi phối bởi công đoạn được cải thiện ít nhất, chứ không phải mức trung bình.
Viết mã là một công đoạn. Rà soát, kiểm thử tích hợp, phê duyệt bảo mật, cấp phép phát hành và triển khai là những công đoạn còn lại — và không thế hệ công cụ lập trình nào chạm tới chúng. Vậy nên ràng buộc đã dịch chuyển. Nó không biến mất; nó dời tới cánh cổng con người đầu tiên nằm dưới dòng của phần được tăng tốc.
Con số độ co giãn chính là lập luận
Bài báo đặt lên đó một hệ số: độ co giãn thay thế ước lượng 0,23 giữa AI và nỗ lực con người (Demirer et al., NBER, 2026).
Hãy đọc thẳng. Độ co giãn thấp nghĩa là tính bổ trợ mạnh. AI và những con người ở phía sau không phải hai vật thay thế tranh cùng một phần việc — chúng là hai đầu vào cần nhau theo tỷ lệ tương đối. Nhân ba cái này mà không động tới cái kia, bạn không được gấp ba đầu ra. Bạn được một hàng chờ.
Đây là con số nên đặt trước mặt bất kỳ ai có kế hoạch ngầm giả định rằng một tác tử đủ tốt rồi sẽ hấp thụ luôn cả người rà soát. Ước lượng tốt nhất hiện có nói điều ngược lại, và nói bằng một chữ số thập phân.
Quy trình của bạn cũng cùng hình dạng ấy
Phần mềm là bối cảnh, không phải phạm vi. Cấu trúc tạo ra kết quả này — các công đoạn tuần tự, phần việc máy tăng tốc được ở đầu, các cổng phán đoán của con người ở cuối — là cấu trúc của gần như mọi quy trình vận hành trong một công ty 50–500 nhân sự toàn thời gian.
Từ đơn hàng đến thu tiền: tạo báo giá có thể tự động hóa; phê duyệt tín dụng và xử lý ngoại lệ thì không. Từ tuyển dụng đến hội nhập: tìm nguồn và sàng lọc có thể tự động hóa; quyết định gửi thư mời và các bàn giao tuần đầu thì không. Từ ticket đến xử lý xong: phân loại và soạn thảo có thể tự động hóa; phán đoán leo thang thì không.
Trong mọi trường hợp, ngân sách AI nằm ở công đoạn đầu còn trần công suất nằm ở công đoạn cuối.
Cách tìm mắt xích yếu của bạn trong một buổi chiều
Chẩn đoán không cần công cụ mới. Lấy một quy trình và viết ra các công đoạn của nó từ đầu đến cuối — sáu hoặc bảy là điển hình. Với mỗi công đoạn, đánh dấu hai điều: AI có chạm vào nó trong mười hai tháng qua không, và hàng chờ trước nó hôm nay trông thế nào.
Mắt xích yếu gần như luôn là công đoạn đầu tiên trả lời không cho câu hỏi thứ nhất và đang tăng cho câu hỏi thứ hai. Thường đó là công đoạn do một hoặc hai người kỳ cựu đảm nhiệm — những người vốn đã là điểm leo thang từ trước khi mọi chuyện này bắt đầu, chính vì thế không ai đề xuất tự động hóa nó, và cũng chính vì thế nó không thể hấp thụ thêm khối lượng.
Rồi hãy hỏi câu hỏi tái định khung cuộc trò chuyện ngân sách: nếu công đoạn này xử lý thêm 20% đơn vị mỗi tuần thì giá trị là bao nhiêu? Đem so với chi phí đợt giấy phép kế tiếp ở đầu nguồn. Ở phần lớn quy trình của doanh nghiệp tầm trung, phép so sánh thậm chí không sát nhau.
Bằng chứng độc lập cho thấy sự lệch pha này gần như phổ quát. Telemetry hành vi trên 120.620 người lao động chỉ tìm thấy 2% đạt độ trưởng thành tích hợp vào quy trình — dùng AI bên trong một quy trình đã được thiết kế lại thay vì như một chỗ tra cứu bên lề, trong khi 27% vẫn ở mức hỗ trợ tra cứu đơn giản (ActivTrak Productivity Lab, 2026). Nếu 98% mức áp dụng diễn ra xung quanh quy trình chứ không bên trong nó, thì các công đoạn cuối chưa từng nằm trong phạm vi ngay từ đầu.
Dữ liệu vận hành chỉ về cùng một hướng từ đầu kia. Một nghiên cứu so sánh việc dùng tác tử với dùng tìm kiếm cho thấy các tác vụ đối sánh hoàn thành trong 36 phút so với 269 phút, giảm 87% thời gian — trong khi phần việc tiếp nối dịch lên trên, sang kiểm chứng và mở rộng, thay vì biến mất (Perplexity & HBS, arXiv, 2026). Phần việc của con người không rời đi. Nó chuyển sang công đoạn mà bạn không đo.
Cánh cổng bạn không cấp ngân sách cũng là cánh cổng đắt đỏ
Hai phát hiện nữa khiến công đoạn cuối khó bỏ qua hơn một bài toán xếp hàng đơn thuần.
Thứ nhất, nó tốn hơn công cụ. Phân tích kinh tế đơn vị của tác tử do McKinsey QuantumBlack thực hiện cho thấy với một tác tử chăm sóc khách hàng ngân hàng, chi phí token chỉ chiếm 20–25% chi phí vận hành biến đổi, trong khi giám sát của con người chiếm 70–75% (McKinsey QuantumBlack, 2026). Công đoạn mà luận chứng của bạn coi là chi phí chung miễn phí lại chiếm phần lớn chi phí vận hành.
Thứ hai, nó suy giảm dưới tải. Một khảo sát 2.500 lao động tri thức cho thấy 42% dành nhiều thời gian kiểm chứng đầu ra của AI hơn thời gian tiết kiệm được nhờ dùng nó, và 52% thường xuyên sửa phần việc do AI tạo ra của đồng nghiệp (Adaptavist, 2026). Đẩy thêm khối lượng qua một công đoạn rà soát không thay đổi, người rà soát sẽ hấp thụ nó thành việc làm lại — và đó chính xác là cách mức tăng 240% ở đầu nguồn chuyển thành 30% ở cuối nguồn.
Vậy nên mắt xích yếu không chỉ chậm. Nó là trung tâm chi phí, và nó đã bão hòa.
Phản biện trung thực
Ba giới hạn, nói ra trước khi người khác nói.
Các tác giả có quan hệ đã công bố với một nhà cung cấp. Demirer và Musolff đều từng giữ vị trí nghiên cứu sau tiến sĩ tại Microsoft và hiện làm cố vấn nghiên cứu có thù lao cho công ty — điều này được công bố ngay trên bài báo. Phát hiện lại đi ngược lợi ích thương mại (nó đặt trần cho hiệu ứng đầu ra mà công cụ lập trình có thể tuyên bố), và đó là hướng khiến xung đột lợi ích bớt đáng lo. Dù vậy vẫn nên ghi nhận.
Các ước lượng đã thay đổi giữa các bản thảo, và điều đó quan trọng với cách bạn trích dẫn. Bản tháng 5/2026 báo cáo mẫu nhỏ hơn và hệ số khác; bản sửa tháng 9/2026 báo cáo hơn 500.000 lập trình viên, các hiệu ứng thế hệ 30/180/240% và độ co giãn 0,23. Mô thức suy giảm giữ nguyên ở cả hai bản. Nếu trích một con số từ bài này vào tài liệu hội đồng quản trị, hãy trích bản sửa hiện hành và ghi ngày — working paper không phải kết quả đã chốt, và những cái đáng trích là những cái có hình dạng sống sót qua lần sửa.
Một ngành không phải mọi ngành. Phần mềm có ranh giới công đoạn sạch sẽ một cách bất thường và telemetry tốt một cách bất thường. Kỳ khóa sổ tài chính hay chuỗi giao hàng của bạn có thể có sự tham gia sâu hơn của con người ở mọi công đoạn, điều này sẽ nén cả mức tăng đầu nguồn lẫn mức suy giảm. Chiều hướng thì chuyển được. Độ lớn thì chưa phải của bạn cho tới khi bạn đo.
Cần quyết gì trong quý này
Bốn nước đi. Ba trong số đó không tốn gì ngoài sự chú ý.
- Gọi tên cánh cổng con người cuối cùng trong một quy trình. Không phải chủ quy trình — mà là bước phê duyệt, rà soát hay ký duyệt cụ thể mà mọi đơn vị công việc phải đi qua trước khi được tính là đã bàn giao. Nếu bạn không gọi tên được nó trong một câu, thì đó chính là phát hiện.
- Đo hai công đoạn riêng rẽ. Chỉ số hiện tại của bạn gần như chắc chắn đang đếm hoạt động ở công đoạn được tăng tốc: bản nháp tạo ra, ticket được phân loại, báo giá được sinh. Hãy thêm một bộ đếm ở công đoạn bàn giao. Tỷ lệ giữa hai con số là mức suy giảm của bạn, và là con số duy nhất trong bài viết này thực sự nói về công ty bạn.
- Chuyển phần ngân sách AI tăng thêm tiếp theo về cuối nguồn. Nếu kết quả mắt xích yếu đúng với quy trình của bạn, lợi suất biên của thêm một giấy phép đầu nguồn gần bằng không, còn lợi suất biên của việc khơi thông cánh cổng đúng bằng tất cả những gì cánh cổng đó đang giữ lại. Đó là tái phân bổ, không phải chi mới.
- Thiết kế lại cánh cổng trước khi mở rộng phễu. Nâng khối lượng đầu nguồn trong khi công đoạn rà soát không đổi sẽ tạo ra hàng chờ và việc làm lại, chứ không phải đầu ra. Hãy đảo thứ tự: sửa cánh cổng trước, rồi mới cho khối lượng đi qua.
Lợi ích năng suất từ AI của bạn là có thật. Nghiên cứu nói vậy, ở quy mô mà không dự án thí điểm nội bộ nào chạm tới được.
Chúng cũng đang xếp hàng sau một con người mà không ai đưa vào ngân sách. Câu hỏi của quý này không phải đội của bạn có thể tạo ra công việc nhanh đến đâu. Mà là trong khối công việc ấy, tổ chức của bạn còn hoàn tất được bao nhiêu.
