Chuyển đến nội dung chính
Tất cả bài viết

Từ 7 năm xuống 7 ngày với AI tác tử

bởi Ghazi Triki · 7 phút đọc

Từ bảy năm xuống bảy ngày
Trong bài viết này

Nếu bạn từng nhìn chằm chằm vào bảng tính COCOMO II và thấy nó dự báo 33 tháng lịch cho một dự án mà nhóm của bạn đã hoàn thành trong hai sprint, hẳn bạn đã biết vấn đề: mọi mô hình ước lượng đang được dùng hiện nay đều được hiệu chỉnh trong một thế giới nơi lập trình viên gõ từng dòng mã, việc chuyển ngữ cảnh luôn có cái giá của nó, và ngày làm việc kết thúc lúc 5 giờ chiều. Thế giới đó không còn nữa. Gần đây, chúng tôi đã phát triển từ đầu một ứng dụng nhiều hệ thống con, 286 KLOC, 672 tệp, gồm lớp giao thức, lớp dữ liệu, engine kết xuất và tích hợp nền tảng, và đạt bản alpha sẵn sàng kiểm thử chỉ trong 7 ngày. Toàn bộ bộ mô hình (COCOMO Basic/Intermediate/Post-Architecture, Function Points, đường cơ sở SLOC, Putnam/SLIM) cho ra dự báo trung vị là 30,3 tháng lịch. Hệ số năng suất trung vị: 4.240×. Ngay cả đường cơ sở thận trọng nhất (25 SLOC/ngày công cho hệ thống phức tạp) cũng lệch tới 1.433×. Các mô hình không sai. Chúng bị áp dụng sai chỗ. Dưới đây là phân tích chi tiết từng mô hình, kết quả hiệu chỉnh thực nghiệm trên chính các dự án của cùng một tác giả, và những gì các nghiên cứu RCT giai đoạn 2024 đến 2026 thực sự nói về việc AI tác tử rút ngắn thời gian ở đâu, và không rút ngắn ở đâu.

Dự án đã phá vỡ mọi ước lượng

Tại RIADVICE, gần đây chúng tôi đã phát triển một ứng dụng phức tạp, giàu tính năng, thuộc loại điều phối nhiều hệ thống con trên một kiến trúc phân tán, dưới dạng một môi trường đa nền tảng gốc nhắm đến cả di động lẫn máy tính để bàn từ một cơ sở mã duy nhất, xuất phát từ yêu cầu thị trường đòi hỏi một bản triển khai mới. Cơ sở mã cho thấy quy mô của dự án:

  • 286.662 SLOC (~286 KLOC) trải trên 672 tệp mã nguồn
  • 1.329.399 dòng thay đổi tổng cộng: 862.488 dòng thêm và 466.911 dòng xóa
  • 700 commit trong 7 ngày phát triển thực tế để đạt bản alpha đầu tiên sẵn sàng kiểm thử
  • Bản địa hóa đầy đủ sang hàng chục ngôn ngữ
  • Nhiều hệ thống con hoàn toàn không liên quan đến nhau, gồm xử lý giao thức, quản lý dữ liệu, kết xuất và tích hợp nền tảng, tất cả đều được xây dựng từ đầu cho môi trường mục tiêu

Đây không phải là một lớp vỏ bọc hay một bản thay giao diện mỏng. Đó là một bản triển khai gốc xây dựng từ nền móng để đáp ứng những yêu cầu thị trường mà các giải pháp hiện có không đáp ứng được. Trước khi viết dòng mã đầu tiên, tôi đã gắn vào dự án một công cụ phân tích tùy chỉnh, chạy toàn bộ bộ mô hình ước lượng nỗ lực phần mềm tiêu chuẩn ngành trên cơ sở mã khi nó lớn dần. Mục tiêu rất trung thực: đo khoảng cách giữa những gì các mô hình cổ điển dự báo và những gì một quá trình phát triển có AI hỗ trợ thực sự tạo ra. Kết quả không phải là sai số làm tròn. Đó là một sự đứt gãy về bản chất.

Các mô hình ước lượng dự báo gì và thực tế ra sao

Công cụ chạy mọi mô hình ước lượng lớn trong tài liệu kỹ thuật phần mềm, gồm COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached và Embedded, đã tinh chỉnh), COCOMO II Post-Architecture (đã tinh chỉnh), Function Points, đường cơ sở năng suất SLOC và Putnam/SLIM, được hiệu chỉnh theo loại dự án bằng các hằng số công bố trong tài liệu gốc.

Mô hình ước lượngNỗ lực dự báoThời gian lịch dự báoTăng tốc so với thực tế
COCOMO Basic (Organic)913 người-tháng33,3 tháng2.282×
COCOMO Basic (Semi-Detached)1.696 người-tháng33,7 tháng4.240×
COCOMO Basic (Embedded)3.200 người-tháng33,1 tháng8.000×
COCOMO Intermediate (Semi-Det., tinh chỉnh)1.259 người-tháng30,4 tháng3.148×
COCOMO Intermediate (Embedded, tinh chỉnh)2.376 người-tháng30,1 tháng5.940×
COCOMO II Post-Architecture (tinh chỉnh)1.703 người-tháng30,3 tháng4.257×
Function Points (ước tính nhanh)17,9 người-tháng7,5 tháng45×
Đường cơ sở năng suất SLOC (25 SLOC/ngày công)573 người-tháng573,3 tháng1.433×
Putnam/SLIMbỏ qua (thời lượng < 30 ngày; T 4/3 bùng nổ)không áp dụngkhông áp dụng

Hệ số năng suất trung vị trên tất cả các mô hình là 4.240×. Ngay cả mô hình thận trọng nhất cũng dự báo thời gian bàn giao dài hơn thực tế khoảng 1.400 lần. Mô hình lạc quan nhất, Function Points, vẫn dự báo 7,5 tháng lịch, dài hơn 45 lần so với 7 ngày thực tế. Theo các mô hình, dự án này lẽ ra phải mất từ 7 tháng đến 47 năm. Một bản alpha đã sẵn sàng kiểm thử sau 7 ngày.

Các mô hình mâu thuẫn với nhau, từ 50× đến 8.000×

Các mô hình này không thống nhất với nhau. Trên cùng một cơ sở mã, các dự báo dao động từ 17,9 đến 3.200 người-tháng, chênh lệch tới 178×. Đánh giá chuẩn SEAA 2013 về COCOMO II, SEER-SEM, SLIM và TruePlanning trên 51 dự án thực tế cho thấy MMRE ở mức 50 đến 100%. Một đánh giá năm 2023 trên bộ dữ liệu COCOMO NASA cho thấy MMRE gần 1,0 và PRED(0,25) = 0,0: không một dự án nào được ước lượng trong biên sai số 25%. Các mô hình này chưa bao giờ được thiết kế cho một dự án có AI hỗ trợ. Nhưng độ lớn của khoảng cách, ngay cả khi đã tính đến độ thiếu chính xác của mô hình, cho thấy một điều gì đó mang tính cấu trúc đã thay đổi.

Nghiên cứu thực sự nói gì về AI tác tử và năng suất lập trình viên

Con số 4.240× là cực đoan, và tôi không muốn thổi phồng nó. Việc dựng khung cho dự án mới từ đầu làm phình số dòng thay đổi, và SLOC là một thước đo yếu cho giá trị. Vậy hãy cùng xem các nghiên cứu có bình duyệt. Các trợ lý kiểu Copilot mang lại lợi ích khiêm tốn nhưng có thật. Peng và cộng sự (2023) cho thấy lập trình viên dùng một trợ lý lập trình AI hoàn thành nhiệm vụ nhanh hơn 55,8% (khoảng tin cậy 95%: 21 đến 89%). RCT của Microsoft/Accenture/Fortune 100 (2025), nghiên cứu lớn nhất cho đến nay với n=4.867, ghi nhận số nhiệm vụ hoàn thành tăng 26%. RCT nội bộ của Google (2024) ghi nhận thời gian thực hiện nhiệm vụ giảm ~21%. Thí nghiệm thực địa của BIS/Ant Group (2024) đo được sản lượng mã tăng 55% ở nhân viên mới vào nghề. Tóm lại một cách trung thực: 1,26× đến 1,56× với những nhiệm vụ phù hợp. Có thật, nhưng chưa mang tính chuyển đổi. AI tác tử hoạt động ở một cấp độ khác. Bản đánh giá năm 2025 của Cognition về Devin báo cáo kết quả của khách hàng: 10× với các đợt di chuyển ETL, 14× với di chuyển phiên bản Java và 20× với các bản sửa lỗi bảo mật. Nubank báo cáo hiệu quả tăng 12× và tiết kiệm chi phí 20× trong một đợt tái cấu trúc hàng triệu dòng mã vốn được ước tính cần nhiều năm và hàng nghìn kỹ sư. Dự án chuyển đổi của chúng tôi nằm gọn trong khoảng này: biểu đồ commit cho thấy những đợt dày đặc vào lúc 22:00, 00:00 và 01:00, dấu hiệu đặc trưng của các phiên làm việc do tác tử dẫn dắt. Bằng chứng ngược chiều cũng có thật. RCT năm 2025 của Metr.org (16 lập trình viên giàu kinh nghiệm, 246 nhiệm vụ trên các dự án trưởng thành) cho thấy AI làm tăng thời gian hoàn thành thêm 19%: nó làm chậm những lập trình viên giàu kinh nghiệm trên các cơ sở mã quen thuộc. Một nghiên cứu sai biệt kép (difference-in-differences) năm 2026 trên 807 kho mã GitHub áp dụng công cụ AI (He và cộng sự, MSR ’26) ghi nhận mức tăng tốc độ "tạm thời" và độ phức tạp của mã tăng "kéo dài", dẫn đến sự chậm lại về lâu dài. Tiêu đề nói lên tất cả: Speed at the Cost of Quality (tốc độ đánh đổi bằng chất lượng). Đồng thuận chung: AI giúp ích rất nhiều với phát triển dự án mới và phát triển có cấu trúc, giúp ích vừa phải với các nhiệm vụ hoàn thiện mã, và có thể làm giảm tốc độ trên các cơ sở mã trưởng thành. Món nợ chất lượng là có thật.

Vì sao các mô hình đổ vỡ: ba chuyển dịch mang tính cấu trúc

Không có hệ số chi phí nào trong các mô hình cổ điển có thiết lập cho trường hợp "lập trình viên có một tác tử tự động không bao giờ ngủ và nắm toàn bộ cơ sở mã trong ngữ cảnh". Ba chuyển dịch làm sụp đổ đường cong thời gian:

  1. Nút thắt gõ phím đã biến mất.

Các mô hình giả định rằng một phần đáng kể nỗ lực mang tính cơ học: mã mẫu, dựng khung, tái cấu trúc lặp đi lặp lại, tài nguyên bản địa hóa và các dữ liệu có cấu trúc khác. Trong dự án chuyển đổi này, phần lớn khối lượng là văn bản và mã kết nối rất đều đặn, thứ mà một tác tử có thể tạo ra hoặc biến đổi hàng loạt. Bản thân phần mã viết tay, như dựng khung, hàm khởi tạo, mã kết nối nền tảng, giờ đây được tạo ra theo từng đợt, không còn gõ từng dòng.

  1. Chi phí chuyển ngữ cảnh đang sụp đổ.

Một người chuyển qua lại giữa lớp giao thức, lớp dữ liệu và engine kết xuất phải trả "thuế" nạp lại ngữ cảnh mỗi lần. Một tác tử đã đọc toàn bộ kho mã 672 tệp chỉ phải trả một lần. Sự bất cân xứng đó cộng dồn rất nhanh trên một cơ sở mã cỡ này.

  1. Lịch làm việc không còn là nút thắt.

Các mô hình chuyển người-tháng thành tháng lịch thông qua một phương trình nhân sự giả định ngày làm việc của con người. Các phiên làm việc của tác tử chạy suốt đêm. Biểu đồ commit cho thấy sản lượng duy trì từ 07:00 đến 01:00: 18 giờ hoạt động, không phải 8.

Hiệu chỉnh thực nghiệm trên cùng một tác giả

Vì các mô hình tham số chênh lệch nhau tới nhiều bậc độ lớn, tôi cũng thực hiện một đợt hiệu chỉnh thực nghiệm liên dự án, so sánh lượng mã thay đổi trên mỗi ngày công của chính tôi trước và sau khi áp dụng công cụ AI tác tử, trên ba kho mã production khác trong cùng hệ sinh thái:

Dự ánThay đổi/ngày công trước AIThay đổi/ngày công thời AIHệ số
Dự án A (bộ cân bằng tải)6732.0563,1×
Dự án B (dịch vụ báo cáo)2392.1278,9×
Dự án C (dịch vụ xử lý)1.3229820,7×
Tổng hợp (trung bình / trung vị)không áp dụngkhông áp dụng4,2× / 3,1×

Cùng tác giả, cùng lĩnh vực, công việc bảo trì thực tế. Hệ số thực nghiệm là 3 đến 9×, thận trọng hơn nhiều so với con số 4.240× của dự án mới, và phù hợp với mức cao của các nghiên cứu đã công bố về AI tác tử. Một dự án thực tế còn chậm đi: lợi ích phụ thuộc vào nhiệm vụ, không mang tính phổ quát.

Điều này có ý nghĩa gì với việc lập kế hoạch dự án

Nếu bạn vẫn ước lượng dự án phần mềm bằng các mô hình chưa hiệu chỉnh và đường cơ sở 25 SLOC mỗi ngày, bạn sẽ sai từ một đến ba bậc độ lớn với công việc có AI hỗ trợ. Đây là cách chúng tôi làm tại RIADVICE:

  1. Hiệu chỉnh theo lịch sử của chính bạn. So sánh sản lượng mã trên mỗi ngày công của chính bạn khi có và không có AI. Cách này rẻ hơn, trung thực hơn và cho ra khoảng 3 đến 9× mà bạn có thể bảo vệ trong kế hoạch dự án.
  2. Tách dự án mới khỏi công việc bảo trì. Hệ số của AI tác tử lớn nhất với phát triển dự án mới và phát triển có cấu trúc, nhỏ nhất (đôi khi âm) với việc bảo trì cơ sở mã trưởng thành. Đừng áp dụng một con số cho cả hai.
  3. Dự trù cho món nợ chất lượng. Tốc độ nhờ AI đi kèm sự gia tăng độ phức tạp kéo dài. Hãy lên kế hoạch cho một giai đoạn củng cố và đo lường nó: theo dõi độ phức tạp chu trình (cyclomatic complexity) và chạy công cụ phát hiện mã sao chép ở mỗi bản phát hành.
  4. Ước lượng toàn bộ đường cong, không chỉ phần đầu. Mức tăng tốc 10× mà làm mật độ lỗi tăng gấp đôi thì không phải là mức tăng 10×: đó là một lịch trình được kéo sớm lên, đổi lại một giai đoạn ổn định hóa kéo dài hơn.

Kết luận

Một dự án mà mọi mô hình ước lượng đều cho rằng phải mất từ 7 tháng đến 47 năm đã đạt bản alpha sẵn sàng kiểm thử sau 7 ngày. Hệ số trung vị 4.240× không nên trở thành kế hoạch dự án của bất kỳ ai. Nhưng đó là tín hiệu rõ ràng cho thấy thời gian phát triển phần mềm phức tạp đang bị nén lại bởi chính lực đang nén nỗ lực. Các nghiên cứu đã công bố cho thấy AI mang lại từ một cú hích 1,26× đến một bước nhảy 20×, với nguy cơ thực sự về lợi ích âm trên các cơ sở mã trưởng thành và một khoản "thuế chất lượng" đo lường được. Những mô hình từng cho rằng dự án này phải mất hàng chục năm vẫn đang chạy trong các bảng tính ước lượng của doanh nghiệp ngày nay. Câu hỏi không phải là AI tác tử có thay đổi thời gian dự án hay không: nghiên cứu đã trả lời điều đó. Câu hỏi là phương pháp ước lượng của bạn đã theo kịp bằng chứng hay chưa. Nếu các con số của bạn vẫn đến từ một mô hình năm 1981 được hiệu chỉnh trên COBOL và hợp ngữ, đã đến lúc hiệu chỉnh lại, hoặc ít nhất là thôi tin vào cái lịch mà nó in ra.

"Vẫn còn nhiều dư địa cải thiện để giải quyết tốt hơn những thách thức dự báo gặp phải trong thực tế."

Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013

🏆 Chuyên môn kỹ thuật và đám mây đáng tin cậy

RIADVICE: đối tác tin cậy của bạn về kỹ thuật phần mềm

Chúng tôi thiết kế, xây dựng và triển khai các hệ thống phần mềm phức tạp với kỷ luật kỹ thuật và công cụ cần thiết để bàn giao trong kỷ nguyên AI: đúng hạn, đúng ngân sách và đúng chất lượng.

Tìm hiểu thêm về dịch vụ của chúng tôi →

📚 Nguồn tham khảo và tài liệu đọc thêm

Bài viết này dựa trên các nghiên cứu có bình duyệt, thử nghiệm ngẫu nhiên có đối chứng và báo cáo thực địa của ngành về năng suất phát triển phần mềm có AI hỗ trợ và ước lượng nỗ lực phần mềm:

⚡ RIADVICE.com mang đến chuyên môn kỹ thuật đáng tin cậy, kinh nghiệm về đám mây và các giải pháp phần mềm cấp doanh nghiệp: đúng hạn, đúng ngân sách và đúng chất lượng.

Chia sẻ bài viết này

Bài viết liên quan