Khi AI viết và giao code, các lập trình viên giàu kinh nghiệm chậm hơn 19%

Các tác nhân phần mềm như Devin, Claude Code và GitHub Copilot Workspace giờ đây có thể tiếp nhận mô tả nhiệm vụ, đọc kho mã, viết mã để giải quyết nhiệm vụ đó, chạy các bài kiểm tra cho đến khi chúng vượt qua, và mở một pull request — mà không cần lập trình viên gõ một dòng nào. Devin, do Cognition AI xây dựng, thực hiện điều này trong các môi trường đám mây biệt lập. Trên cơ sở người dùng sản xuất của nó, 67% số pull request mà nó tự động mở được hợp nhất. Claude Code đọc toàn bộ kho lưu trữ, lên kế hoạch thay đổi trên nhiều tệp, chạy bộ kiểm thử và lặp lại mà không cần hướng dẫn giữa mỗi bước. Những công cụ này đang được sử dụng trong sản xuất, không phải trong bản xem trước nghiên cứu.

Điều phân biệt chúng với các công cụ tạo mã trước đây là vòng phản hồi. Một công cụ gợi ý tạo văn bản rồi dừng; một tác nhân tự động tạo mã, chạy nó, đọc kết quả phản hồi và thử lại. Khung cơ bản là giống nhau trên các công cụ: một mô hình ngôn ngữ lớn đọc ngữ cảnh — kho mã, mô tả vấn đề, nhật ký lỗi — tạo ra một kế hoạch, thực thi nó thông qua các công cụ như lệnh shell, chỉnh sửa tệp và thao tác git, đọc kết quả và sửa đổi. Vòng lặp tiếp tục cho đến khi tác nhân thành công hoặc cạn kiệt ngân sách tài nguyên của nó.

Vòng lặp thay thế trình soạn thảo

Phạm vi tự động hóa trên các công cụ có sẵn trải dài ba cấp độ. Ở cấp độ hỗ trợ, GitHub Copilot gợi ý vài dòng tiếp theo khi lập trình viên gõ. Một cấp độ cao hơn, các trình soạn thảo đa tệp như Cursor viết lại trên toàn bộ kho mã theo hướng dẫn của lập trình viên, thực hiện các thay đổi mà lập trình viên chỉ định. Ở cấp độ tự động, Devin và các hệ thống tương tự hoạt động độc lập trong thời gian dài, đưa ra các quyết định tuần tự về những gì cần đọc, thay đổi và kiểm tra, chỉ xuất hiện khi cần phê duyệt mà hệ thống không thể tự xử lý.

Khung đánh giá đo lường tiến trình trên các công cụ này là SWE-bench, được tạo bởi các nhà nghiên cứu tại Princeton và Stanford. Nó kiểm tra các tác nhân trên các báo cáo lỗi thực tế từ các kho mã Python nguồn mở — Django, Flask, scikit-learn — và đo lường tỷ lệ phần trăm mà một tác nhân có thể đóng chính xác. Điểm số cao nhất hiện được công bố trên tập con Verified đã được tuyển chọn, 96%, thuộc về Claude Opus 5. Con số đó đại diện cho năng lực thực sự: khả năng chẩn đoán một lỗi phần mềm thực tế, viết bản sửa lỗi và xác minh nó vượt qua các bài kiểm tra của chính dự án.

Điểm chuẩn che giấu điều gì

Điểm số 96% đi kèm với một dấu hoa thị quan trọng. SWE-bench Verified lấy từ 500 nhiệm vụ được lựa chọn cẩn thận. Khi các nhà nghiên cứu áp dụng một biến thể chống nhiễm — SWE-bench Pro, được thiết kế bằng các vấn đề không thể xuất hiện trong dữ liệu huấn luyện của bất kỳ mô hình nào — một mô hình trước đó đạt điểm trên 80% trên Verified đã giảm xuống dưới 50% trên Pro. Một số hiệu suất điểm chuẩn phản ánh sự quen thuộc với bộ đánh giá, không phải khả năng giải quyết vấn đề tổng quát. Khoảng cách này là một thách thức nghiên cứu đã biết, không phải là lời chỉ trích đối với bất kỳ công cụ cụ thể nào.

Một nghiên cứu riêng biệt đã tìm thấy điều khó giải thích hơn. METR, một tổ chức nghiên cứu an toàn AI, đã tiến hành một thử nghiệm ngẫu nhiên có đối chứng với các lập trình viên nguồn mở giàu kinh nghiệm làm việc trên các kho lưu trữ của chính họ. Các lập trình viên sử dụng các công cụ AI hiện tại chậm hơn 19% so với những người làm việc mà không có chúng — mặc dù họ ước tính độc lập rằng họ nhanh hơn 20%. Nguyên nhân cụ thể: thời gian dành cho việc nhắc lại khi tác nhân tạo ra kết quả không chính xác, thời gian dành cho việc xác minh đầu ra trước khi hợp nhất, và chi phí nhận thức của việc chuyển đổi giữa chỉ đạo tác nhân và theo dõi những gì tác nhân đã làm. Một điểm chuẩn kiểm tra liệu một tác nhân có thể đóng một lỗi được xác định rõ trong sự cô lập hay không. Một thử nghiệm ngẫu nhiên kiểm tra liệu một lập trình viên có làm việc nhanh hơn trong một ngày thực tế hay không. Chúng đo lường những thứ khác nhau.

Tại sao tỷ lệ áp dụng 93% chỉ mang lại mức tăng 10% về thông lượng

Tự động hóa mã hoạt động tốt nhất trên các nhiệm vụ có giới hạn, được xác định rõ: một lỗi có thể tái tạo với đầu vào và đầu ra rõ ràng, một hàm có đặc tả chính xác, một bộ kiểm thử cho một mô-đun có hành vi xác định. Khi phạm vi mở rộng đến các nhiệm vụ yêu cầu kiến thức kiến trúc ngầm, quy ước nhóm không được ghi chép, hoặc các quyết định về định hướng sản phẩm, độ tin cậy giảm — không phải vì các mô hình thiếu năng lực mà vì ngữ cảnh mà các quyết định đó yêu cầu không vừa trong hệ thống và không thể suy ra từ các tệp kho mã một mình.

Sự thay đổi thực tế nằm ở những gì công việc đòi hỏi. Các lập trình viên làm việc với các tác nhân tự động dành nhiều thời gian hơn để viết các đặc tả đủ chính xác để tác nhân thực thi: mô tả vấn đề chi tiết, hợp đồng kiểm thử rõ ràng, tiêu chí chấp nhận minh bạch. Họ dành nhiều thời gian hơn để xem xét mã mà họ không viết, điều này đòi hỏi một loại chú ý khác so với viết mã — tìm kiếm lỗi logic, lỗ hổng bảo mật và sai lệch kiến trúc mà tác nhân sẽ không tự cảnh báo. Một cuộc khảo sát năm 2026 với 121.000 lập trình viên cho thấy 93% sử dụng công cụ AI thường xuyên; thông lượng pull request tăng khoảng 10% trong cùng nhóm đó. Nút thắt cổ chai đã chuyển từ viết mã sang xem xét mã.

Giai đoạn tiếp theo đang được phát triển tích cực là các tác nhân tự quản lý hàng đợi nhiệm vụ của riêng chúng: nhận một đặc tả dự án, chia nó thành các nhiệm vụ con, phân công giữa các mô hình chuyên biệt và chỉ đưa ra các quyết định yêu cầu phán quyết của con người. Một số khung nguồn mở cho việc điều phối mã đa tác nhân đã được phát hành vào năm 2026. Việc áp dụng trong doanh nghiệp trong môi trường sản xuất vẫn còn hạn chế. Gartner dự báo rằng một phần đáng kể các dự án phần mềm tác nhân bắt đầu trong năm nay sẽ bị ngừng trước năm 2028, khi các nhóm khám phá ra khoảng cách giữa những gì một bản demo có kiểm soát cho thấy và những gì triển khai đáng tin cậy ở quy mô lớn yêu cầu.

Thẻ: trí tuệ nhân tạo, Lập trình, AI coding agents, phát triển phần mềm, tự động hóa code