Công cụ lập trình AI: Tăng 281% lượng code trong tháng đầu nhưng lợi thế biến mất vào tháng thứ ba

Một nghiên cứu của Đại học Carnegie Mellon đã theo dõi 807 dự án GitHub chuyển sang sử dụng Cursor (một trình soạn thảo code tích hợp AI) và so sánh chúng với 1.380 kho lưu trữ (repo) đối chứng trong suốt 20 tháng. Kết quả mang lại bức tranh chi tiết nhất về tác động thực tế của các công cụ lập trình AI đối với mã nguồn theo thời gian.

Điểm nhấn của nghiên cứu: trong tháng đầu tiên sau khi áp dụng Cursor, các nhà phát triển đã viết ra nhiều hơn 281% dòng code. Đến tháng thứ hai, mức tăng này giảm xuống còn 48%. Và đến tháng thứ ba, con số về hiệu quả thực tế bằng không. Tuy nhiên, độ phức tạp của code lại tăng 41% và các cảnh báo từ phân tích tĩnh tăng 30% — những con số này không bao giờ giảm xuống.

Đây là nghiên cứu quy mô lớn đầu tiên theo chiều dọc về việc áp dụng công cụ lập trình AI, và mô hình nó tiết lộ là rất quan trọng đối với mọi đội ngũ đang đánh giá các công cụ này.

Sự bùng nổ về tốc độ là có thật nhưng chỉ mang tính nhất thời

Các nhà nghiên cứu từ CMU (He, Miller, Agarwal, Kastner, Vasilescu) đã đo lường số dòng code thêm vào mỗi tháng như một thước đo cho tốc độ phát triển (velocity). Dữ liệu trong tháng đầu tiên rất rõ ràng: các nhà phát triển được hỗ trợ bởi AI tạo ra lượng mã nguồn lớn hơn đáng kể.

Thời gian sau khi áp dụng	Thay đổi tốc độ so với đối chứng	Thay đổi độ phức tạp
Tháng 1	+281%	+41%
Tháng 2	+48%	+41%
Tháng 3	+12%	+41%
Tháng 6 trở đi	~0%	+41%

Lợi thế về tốc độ tiêu tan hoàn toàn. Nhưng độ phức tạp thì vẫn còn đó.

Tại sao lợi thế về tốc độ lại biến mất? Bài viết cho rằng đây là một vòng lặp phản hồi (feedback loop): độ phức tạp gia tăng từ code do AI tạo ra khiến những thay đổi sau đó trở nên khó khăn hơn, từ đó làm chậm quá trình phát triển và loại bỏ lợi thế về tốc độ. Nợ kỹ thuật (technical debt) từ giai đoạn nhanh chóng trở thành lực cản trong giai đoạn chậm chạp hơn.

Kết quả này phù hợp với các nghiên cứu khác

Các phát hiện của CMU tương đồng với ba bộ dữ liệu độc lập khác.

• GitClear đã phân tích 211 triệu dòng code thay đổi trên các kho lưu trữ của Google, Microsoft và Meta (2020-2024). Họ phát hiện lượng code sao chép-dán đã vượt qua lượng code được tái cấu trúc (refactor) lần đầu tiên trong năm 2024. Tỷ lệ "code churn" (code mới bị viết lại trong vòng hai tuần) gần như tăng gấp đôi, từ 3,1% lên 5,7%.
• Thử nghiệm ngẫu nhiên của METR đã kiểm tra 16 nhà phát triển mã nguồn mở giàu kinh nghiệm (các repo trung bình có hơn 22.000 sao) trên 246 nhiệm vụ. Khi sử dụng Cursor Pro và Claude 3.5 Sonnet, họ chậm hơn 19%. Họ kỳ vọng sẽ nhanh hơn 24% và vẫn tin rằng AI đã giúp đỡ sau khi nhìn thấy dữ liệu thực tế.
• Khảo sát của Qodo trên 609 nhà phát triển cho thấy 65% người nói rằng AI bỏ sót ngữ cảnh liên quan trong quá trình tái cấu trúc và xét duyệt code. Phát hiện đáng báo động nhất: các nhà phát triển cấp dưới (dưới 2 năm kinh nghiệm) báo cáo mức cải thiện chất lượng thấp nhất từ AI nhưng lại có sự tự tin cao nhất trong việc vận chuyển (ship) code AI chưa được xem xét.

Nghiên cứu	Mẫu	Phát hiện chính
CMU/Cursor (2025)	807 repo	+41% độ phức tạp, tốc độ biến mất vào tháng 3
GitClear (2025)	211 triệu dòng	Sao chép-dán vượt qua tái cấu trúc lần đầu tiên
METR (2025)	16 dev, 246 nhiệm vụ	Chậm hơn 19% với AI (cảm thấy nhanh hơn 24%)
Qodo (2025)	609 dev	65% nói AI thiếu ngữ cảnh, người mới quá tự tin

Tại sao độ phức tạp tăng nhưng tốc độ không giữ được

Cơ chế cốt lõi nằm ở sự mất mát ngữ cảnh (context loss). Các công cụ lập trình AI tạo ra code hoạt động độc lập nhưng không tính toán đến cách nó tương tác với phần còn lại của dự án. Code được tạo ra có thể biên dịch được và vượt qua bài kiểm tra mà nó được viết cho, nhưng nó lại giới thiệu các sự phụ thuộc (coupling) và giả định cấu trúc khiến những thay đổi tiếp theo trở nên khó khăn hơn.

Điều này được khuếch đại trong các cơ sở mã có các hệ thống liên kết chặt chẽ. Phát triển trò chơi là một ví dụ rõ ràng: vật lý, kết xuất (rendering), đầu vào, âm thanh và quản lý trạng thái đều tương tác với nhau, nghĩa là code do AI tạo ra hoạt động độc lập có thể phá vỡ năm hệ thống khác. Tuy nhiên, động thái tương tự cũng áp dụng cho bất kỳ backend nào đủ phức tạp: các tương tác microservice, di chuyển cơ sở dữ liệu, luồng xác thực và các lớp bộ nhớ đệm đều chia sẻ thuộc tính này.

Khảo sát Stack Overflow năm 2025 cung cấp bối cảnh áp dụng: 84% trong số hơn 49.000 nhà phát triển sử dụng hoặc dự định sử dụng công cụ AI, nhưng 46% không tin tưởng vào độ chính xác của chúng (tăng từ 31% vào năm 2024). Việc áp dụng gần như phổ quát, nhưng sự tin tưởng lại đang giảm sút. Dữ liệu của CMU giải thích lý do tại sao.

Dữ liệu gợi ý cách sử dụng công cụ AI hiệu quả

Nghiên cứu của CMU không kết luận rằng các công cụ lập trình AI là vô dụng. Nó gợi ý một điều cụ thể hơn: giá trị được tập trung ở giai đoạn đầu và chi phí dồn ở giai đoạn sau. Điều này có tác động trực tiếp đến cách các đội ngũ nên tích hợp các công cụ này.

AI hoạt động tốt nhất cho các nhiệm vụ riêng lẻ, giới hạn. Việc tạo một hàm, viết một bài kiểm tra (test), dựng khung (scaffolding) code mẫu (boilerplate). Đây là những nhiệm vụ thực hiện một lần mà cửa sổ ngữ cảnh đủ nhỏ để mô hình thực hiện đúng. Sự tăng tốc độ trong tháng đầu của CMU có khả năng được thúc đẩy bởi việc áp dụng ban đầu hái những quả dễ kiếm: code mẫu và các triển khai đơn giản.

AI thất bại khi đưa ra quyết định kiến trúc. Tổ chức tệp, ranh giới hệ thống, sự liên kết giữa các module. Đây chính là những quyết định thúc đẩy sự gia tăng 41% về độ phức tạp. Mô hình không hiểu kiến trúc của dự án, vì vậy các bổ sung code của nó sẽ chống lại cấu trúc hiện có.

Các công cụ nhận biết ngữ cảnh hoạt động khác nhau. Các công cụ tích hợp với hệ thống xây dựng, bộ kiểm tra kiểu hoặc môi trường thời gian chạy của dự án có thể tránh được một số sự mất mát ngữ cảnh gây ra độ phức tạp. Trong phát triển trò chơi, các công cụ như Ziva đọc cây cảnh (scene tree) và cấu trúc nút của động cơ sẽ tạo ra code tuân theo thành ngữ của động cơ thay vì phán đoán. Nguyên tắc tương tự áp dụng cho bất kỳ lĩnh vực nào: một công cụ AI hiểu mô hình Rails của bạn, trạng thái Terraform của bạn, hoặc cấu hình Kubernetes của bạn sẽ tạo ra code tốt hơn so với công cụ chỉ thấy tệp bạn đang mở.

Rà soát (review) code AI một cách quyết liệt hơn, không phải ít hơn. Dữ liệu của Qodo về sự tự tin quá mức của các nhà phát triển cấp dưới là phát hiện đáng hành động nhất. Các nhà phát triển cấp cao nhận được lợi ích chất lượng lớn nhất từ AI (68,2%) chính xác vì họ rà soát kỹ hơn. Người mới nhận được lợi ích ít hơn (51,9%) nhưng lại bỏ qua việc rà soát thường xuyên hơn. Nếu đội ngũ của bạn sử dụng công cụ AI, quy trình rà soát code càng quan trọng hơn, chứ không phải ít đi.

Kết luận

Các công cụ lập trình AI là công cụ năng suất với một mức lãi suất ẩn. Tốc độ bạn vay mượn trong tháng đầu tiên sẽ đến hạn thanh toán dưới dạng độ phức tạp vào tháng thứ ba. Dữ liệu của CMU đã chứng minh điều này định lượng trên 807 repo.

Khảo sát GDC 2026 cho thấy chỉ 7% các nhà phát triển trò chơi xem xét AI một cách tích cực, giảm từ 13% của năm trước. Khảo sát Stack Overflow 2025 cho thấy 77% nhà phát triển nói rằng "lập trình theo cảm hứng" (vibe coding) không phải là một phần của công việc chuyên nghiệp của họ. Ngành công nghiệp đã qua giai đoạn thổi phồng. Điều còn lại là một công cụ hoạt động trong phạm vi cụ thể và thất bại một cách dự đoán khi nằm ngoài phạm vi đó.

Hãy sử dụng AI cho những việc nó làm tốt. Rà soát những gì nó tạo ra. Đừng để nó quyết định cách hệ thống của bạn kết nối. Dữ liệu giờ đây đã đủ rõ ràng để đưa ra những quyết định này dựa trên sự tự tin thay vì hy vọng mong manh.