Contents
Chào mừng bạn đến với Fx Studio. AI giúp năng suất viết code tăng 30%, nhưng năng suất cả dự án chỉ tăng 10%. Hai mươi điểm chênh đó đi đâu?
Bài này viết cho những người đang điều hành một công ty phần mềm, và đang nghe mỗi ngày câu “AI viết code nhanh lắm rồi”. Tui muốn bắt đầu bằng một cặp số.
Theo chia sẻ từ phía FPT, công cụ CodeVista của họ giúp tăng năng suất viết code khoảng 30%, và năng suất của cả dự án theo đó tăng khoảng 10%.
Ba mươi và mười. Con số ba mươi là con số lên slide, lên báo. Nó cũng là con số mà nhiều người đang dùng cho một phép tính trong đầu: code nhanh hơn chừng đó thì chắc cần ít người hơn chừng đó. Bài này đi theo phép tính ấy tới cùng xem nó dẫn về đâu. Nhưng trước hết phải hiểu vì sao ba mươi chỉ ra được mười.
Tóm ý: khi AI làm khâu viết code nhanh lên, cả dự án không nhanh lên theo cùng tỷ lệ, vì viết code chưa bao giờ là điểm nghẽn duy nhất. Điểm nghẽn dời sang hai khâu ở hai đầu: quyết định đúng thứ cần xây, và đưa nó vào vận hành thật. Hai khâu này vẫn do con người gánh, và thường đó chính là những người đang viết code.
Brooks đã nói điều này từ năm 1986
Fred Brooks, trong bài No Silver Bullet, chia độ phức tạp của phần mềm làm hai loại. Loại phụ đến từ công cụ: cú pháp, boilerplate, cấu hình, những thứ mình phải làm chỉ vì máy tính cần được nói theo cách của nó. Loại bản chất đến từ chính bài toán: hệ thống này phải làm gì, cho ai, nối với cái gì, sai thì sao.
Câu nổi tiếng nhất của bài đó là:
“The hardest single part of building a software system is deciding precisely what to build.”
(Phần khó nhất khi xây một hệ thống phần mềm là quyết định chính xác cần xây cái gì.)
Brooks viết tiếp rằng không phần nào làm hỏng hệ thống nặng bằng phần này khi làm sai, và cũng không phần nào khó sửa về sau bằng nó.
Nhìn AI coding bằng khung của Brooks thì mọi thứ rõ ra. Claude Code, Cursor, Codex đang cắt rất mạnh vào phần phụ. Phần bản chất thì gần như còn nguyên: vẫn phải có người ngồi với khách để hiểu họ thật sự mất ba tiếng mỗi ngày vào việc gì, vẫn phải có người quyết định dữ liệu nối vào hệ thống ERP của khách ra sao. Brooks lập luận rằng kể cả khi phần phụ co về gần bằng không, năng suất cũng không thể tăng gấp mười, vì phần bản chất vẫn nằm đó. Bốn mươi năm sau, AI coding đang đem lập luận ấy ra thử lại ở quy mô chưa từng có.
Làm nhanh một khâu không nghẽn thì việc dồn sang khâu sau
Thuyết điểm nghẽn của Eliyahu Goldratt nói một điều nghe đơn giản mà hay bị quên: cả dây chuyền chỉ chạy nhanh bằng khâu chậm nhất. Làm nhanh một khâu khác không làm dây chuyền nhanh hơn, chỉ làm việc ứ lại trước khâu chậm.
Dữ liệu năm 2025 cho thấy hiện tượng này khá rõ trong phát triển phần mềm.
DORA 2025, khảo sát thường niên do Google Cloud thực hiện về năng lực giao phần mềm, ghi nhận rằng năm nay việc dùng AI đã đi cùng tốc độ giao việc cao hơn, ngược với năm 2024. Nhưng nó cũng đi cùng độ bất ổn cao hơn: nhiều lần thay đổi gây lỗi hơn, nhiều việc phải làm lại hơn. Nhóm nghiên cứu giải thích rằng thời gian tiết kiệm được ở khâu viết thường bị chuyển sang khâu rà soát và kiểm chứng. Kết luận chung của báo cáo: AI không sửa được một đội, nó khuếch đại những gì đội đó vốn có.
METR, một tổ chức nghiên cứu độc lập, làm một thử nghiệm ngẫu nhiên có đối chứng vào đầu năm 2025: 16 lập trình viên giàu kinh nghiệm, 246 việc thật trên chính những repo họ đã quen. Khi được dùng AI, họ làm chậm hơn 19%. Điều đáng chú ý hơn con số là cảm nhận: xong việc, chính họ ước rằng AI đã giúp mình nhanh hơn 20%. Một phần thời gian bị mất nằm ở việc đọc, rà và sửa những gì AI sinh ra.
Con số này có giới hạn, và cần nói rõ. Tháng 2/2026, chính METR thừa nhận kết quả 19% có thể không còn đúng với công cụ hiện tại. Họ phải đổi cách làm thí nghiệm vì nhiều lập trình viên không chịu làm việc mà không có AI, kể cả khi được trả 50 USD/giờ, nên dữ liệu mới bị lệch mẫu. Vì vậy tui không dùng METR để nói “AI làm chậm”. Tui chỉ dùng nó cho hai điều vẫn đứng được: cảm giác nhanh và năng suất đo được có thể lệch nhau rất xa, và thời gian gỡ ra ở khâu viết rất dễ chảy sang khâu kiểm.
Điểm nghẽn mới nằm ở hai đầu
Khi khâu ở giữa rẻ đi, hai khâu ở hai đầu lộ ra.
Đầu vào là quyết định xây gì. Đây là phần Brooks gọi là khó nhất, và AI chưa gánh được. Ra code nhanh gấp đôi mà xây sai thứ thì cũng chỉ là sai nhanh gấp đôi.
Đầu ra là đưa vào vận hành. Báo cáo The GenAI Divide của dự án NANDA thuộc MIT (2025) đưa ra một con số được trích rất nhiều: 95% dự án GenAI trong doanh nghiệp không tạo ra tác động đo được lên lãi lỗ. Con số này cần đọc kỹ. Nó dựa trên 52 cuộc phỏng vấn, khảo sát 153 lãnh đạo và phân tích khoảng 300 dự án công khai. Nhiều phân tích sau đó cũng chỉ ra rằng “không đo được tác động” khác với “thất bại”: không ít dự án đơn giản là không có số liệu nền trước khi triển khai để mà so. Nhưng ngay cả cách đọc thận trọng đó cũng hướng về cùng một chỗ: khâu đưa vào vận hành, gồm đặt KPI, tích hợp và đo lường, đang là khâu yếu.
Chuyện này không mới trong lịch sử kinh tế. Năm 1990, nhà kinh tế học Paul David viết bài The Dynamo and the Computer để giải thích vì sao máy tính có mặt khắp nơi mà năng suất không tăng. Ông lấy ví dụ điện khí hoá. Điện có mặt từ cuối thế kỷ 19, nhưng phải tới những năm 1920 mới thấy năng suất nhà máy tăng rõ. Lý do: ban đầu các nhà máy chỉ tháo máy hơi nước ra, lắp một động cơ điện vào chỗ đó, và giữ nguyên hệ trục truyền động cũ. Năng suất chỉ tăng khi họ thiết kế lại cả nhà máy, mỗi máy một động cơ riêng.
Brynjolfsson, Rock và Syverson (2021) gọi hiện tượng này là đường cong J của năng suất. Công nghệ dùng được cho mọi ngành, như điện, máy tính và giờ là AI, đòi hỏi một khoản đầu tư đi kèm rất lớn vào quy trình, mô hình kinh doanh và con người. Khoản đầu tư này gần như không hiện ra trong số liệu, nên những năm đầu năng suất đo được thấp hơn thực tế, về sau mới vọt lên.
Đi hết phép tính “code nhanh hơn thì cần ít người hơn”
Giờ quay lại phép tính ở đầu bài.
Phép tính đó có một giả định ngầm: người viết code là một nhóm, còn người hiểu bài toán và người đưa hệ thống vào vận hành là nhóm khác. Ở nhiều công ty phần mềm, nhất là công ty làm dự án cho khách, giả định này không đúng. Cùng một kỹ sư, sáng họp với khách để làm rõ yêu cầu, chiều viết code, tối gỡ lỗi tích hợp với hệ thống của khách, cuối tuần trực khi hệ thống lên production. Khi AI làm phần viết code nhanh hơn, người đó không tự biến thành “phần dư 30%”. Người đó có thêm thời gian cho đúng những khâu đang nghẽn.
Vậy nếu đọc con số 30% thành “cần ít người hơn cỡ đó”, thứ bị bớt đi không chỉ là năng lực viết code. Năng lực ở khâu hiểu bài toán, khâu kiểm và khâu vận hành cũng giảm theo. Đây là những khâu AI chưa gánh được, và khâu kiểm, theo DORA, còn đang nặng thêm. Dây chuyền mất người ở đúng khâu chậm nhất. Từng người gõ nhanh hơn, nhưng cả đội có thể giao chậm hơn trước.
Đây là suy luận của tui từ các nguồn ở trên, chưa có nghiên cứu nào đo thẳng điều này. Con số của FPT không chứng minh được suy luận đó. Nó chỉ cho thấy phần thời gian thật sự dư ra ở cấp dự án nhỏ hơn nhiều so với con số trên slide.
Klarna, công ty thanh toán của Thuỵ Điển, là một ví dụ công khai về phép tính này ở mảng chăm sóc khách hàng. Từ cuối năm 2023, họ ngừng tuyển mới hầu hết các vị trí, lấy lý do AI giúp tăng năng suất. Đầu năm 2024, họ công bố trợ lý AI xử lý được khối lượng chat tương đương 700 nhân viên toàn thời gian. Nhân sự của họ co lại đáng kể, chủ yếu vì người nghỉ mà không tuyển thay chứ không phải do cho nghỉ hàng loạt. Tới tháng 5/2025, CEO của Klarna nói với Bloomberg rằng khi chi phí trở thành yếu tố đánh giá quá lớn trong cách tổ chức, “what you end up having is lower quality” (thứ bạn nhận lại là chất lượng thấp hơn). Klarna không bỏ AI. Họ giữ AI cho các ca đơn giản, số lượng lớn, và tuyển người trở lại cho các ca phức tạp. Phép tính đúng ở tầng việc dễ, hụt ở tầng việc khó, mà tầng việc khó mới là thứ khách hàng nhớ.
Còn một điều nữa: khách hàng cũng biết làm phép tính này. Báo chí trong nước, dẫn các báo cáo của ngành, ghi nhận khách hàng đã bắt đầu đòi giảm giá ngay giữa hợp đồng, lấy lý do AI đã làm việc lập trình rẻ đi. Nếu doanh thu của công ty bằng số đầu người nhân đơn giá, thì mỗi lần tự làm phép tính “ít người hơn” cũng là một lần tự co doanh thu của mình, trước cả khi khách đòi. Thứ khách vẫn sẵn lòng trả giá cao là thứ còn khan hiếm: hiểu bài toán, tích hợp vào hệ thống thật, cam kết kết quả vận hành. Nói gọn lại, đó chính là khâu đang nghẽn.
Phép tính này cũng hay bắt đầu từ tầng dưới cùng, vì việc của junior là việc AI làm giống nhất. Nhưng những người hôm nay giữ được hai đầu, tức người hiểu nghiệp vụ và nhận ra khi AI sai, phần lớn là junior của năm bảy năm trước đã đi qua đủ dự án thật. Đây cũng là suy luận, chưa có dữ liệu. Nếu nó đúng, cái giá sẽ không hiện ra trong năm nay. Nó hiện ra vào lúc cần người lên thay tầng trên mà không có ai.
Chỗ lập luận này có thể sai
Để công bằng, có bốn chỗ bạn nên tự cân nhắc thay vì tin tui.
Mười phần trăm vẫn là mười phần trăm. Tăng 10% năng suất dự án là một kết quả thật, không nhỏ. Và theo đường cong J, con số này có thể còn tăng khi quy trình được xếp lại. Bài này không nói AI không tiết kiệm được gì. Nó chỉ nói phần tiết kiệm được nhỏ hơn con số trên slide, và không nằm ở chỗ ta tưởng.
AI có thể leo lên cả hai đầu. Cả bài dựa trên giả định rằng khâu hiểu bài toán và khâu vận hành vẫn cần con người. Agent đang học cách phỏng vấn người dùng, đọc log, phân tích quy trình. Nếu AI làm được cả những việc đó thì điểm nghẽn sẽ dời tiếp, và bài này chỉ đúng trong vài năm.
Dữ liệu còn rất sớm. Chính METR nói dữ liệu mới của họ chỉ là bằng chứng rất yếu. DORA là khảo sát tự khai. Báo cáo của MIT có phương pháp đang bị tranh cãi. Tui dùng chúng như những tín hiệu cùng chiều, chưa phải phép đo chắc chắn.
Nhu cầu tăng chưa chắc chảy về công ty làm dịch vụ. Theo nghịch lý Jevons, thứ gì rẻ đi thì người ta dùng nhiều hơn, nên code rẻ đi thì tổng nhu cầu phần mềm có thể tăng. Theo dữ liệu của TrueUp, số tin tuyển kỹ sư phần mềm trên toàn cầu năm 2026 tăng khoảng 30%, lên hơn 67.000 tin. Nhưng nhu cầu tăng không có nghĩa là nó chảy về công ty outsource. Khách có AI trong tay có thể tự làm những việc trước đây họ thuê ngoài.
Tạm Kết
Quay lại những nhà máy đầu thế kỷ 20 trong bài của Paul David.
Nhà máy nào chỉ thay máy hơi nước bằng động cơ điện rồi giữ nguyên mọi thứ còn lại thì có một nhà máy sạch hơn, êm hơn, nhưng làm ra chừng ấy sản phẩm như cũ. Năng suất chỉ tăng ở những nhà máy chịu xếp lại cả dây chuyền quanh thứ công nghệ mới cho phép: bỏ trục truyền động chung, sắp máy theo luồng công việc thay vì theo đường trục. Việc đó tốn kém, chậm, và mấy năm đầu gần như không hiện ra trong sổ sách.
AI coding đang đặt các công ty phần mềm vào đúng chỗ đó. Cách dùng dễ nhất là coi nó như động cơ điện thay máy hơi nước: giữ nguyên quy trình, giữ nguyên cách báo giá, giữ nguyên thước đo, rồi nhìn con số 30% và tính xem bớt được bao nhiêu. Cách khó hơn là hỏi dây chuyền phải xếp lại thế nào khi viết code không còn là khâu chậm nhất:
- Ai đang ngồi ở hai đầu, chỗ hiểu bài toán và chỗ đưa hệ thống vào vận hành?
- Mình đang đo năng suất ở khâu viết, hay ở chỗ giá trị chạy thật trên hệ thống của khách?
- Ngoài giờ công, mình còn bán cho khách thứ gì?
Con số ba mươi là thứ dễ thấy nhất. Con số mười mới là thứ khách hàng nhận được. Hai mươi điểm nằm giữa hai con số đó không biến mất khi mình bớt người. Nó chỉ chuyển sang vai những người còn lại.
Nguồn
- Frederick P. Brooks, No Silver Bullet: Essence and Accident in Software Engineering (1986) — bản PDF
- Google Cloud, DORA — State of AI-assisted Software Development 2025 — dora.dev
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (7/2025) — metr.org; cập nhật cách làm thí nghiệm (2/2026) — metr.org
- MIT Project NANDA, The GenAI Divide: State of AI in Business 2025 — tóm tắt và phân tích phương pháp: agentmodeai.com
- Paul A. David, The Dynamo and the Computer (American Economic Review, 1990) — bản PDF
- Brynjolfsson, Rock & Syverson, The Productivity J-Curve (AEJ: Macroeconomics, 2021) — NBER
- Klarna: công bố trợ lý AI (2/2024) — Klarna; đảo chiều (5/2025) — CX Dive
- FPT: số liệu về CodeVista — VietnamBiz
- Áp lực giá lên ngành gia công phần mềm — GenK
- Số tin tuyển kỹ sư phần mềm 2026 (dữ liệu TrueUp) — CafeBiz
Cảm ơn bạn đã đọc bài viết này!
Related Posts:
