Khi lập trình không còn là rào cản: Berkeley RDI đề xuất khung 3 cấp độ cho phần mềm tự phát triển

Khi lập trình không còn là nút thắt cổ chai

Tại sao AI sẽ thay đổi hoàn toàn, chứ không chỉ đơn thuần là tăng tốc, kỹ thuật phần mềm

Hao Wang, Ruijie Meng, Zhe Ye, Alex Gu, Naman Jain, Xiaoyuan Liu, Swarat Chaudhuri, Thomas Zimmermann, Sumit Gulwani, Armando Solar-Lezama, Ion Stoica, Dawn Song UC Berkeley, CISPA, MIT, Cursor, UT Austin, UC Irvine, Microsoft 26 tháng 7, 2026 (Bài viết quan điểm đầy đủ: Hướng tới phát triển phần mềm tự hành)

Trong phần lớn lịch sử, kỹ thuật phần mềm được tổ chức xoay quanh một nguồn lực khan hiếm: con người, những người có khả năng viết và đánh giá mã nguồn. Tất cả các phương pháp thực hành tốt nhất hiện nay về ngôn ngữ lập trình, framework, hệ thống kiểm thử và tổ chức đều được xây dựng dựa trên ràng buộc này. Mục đích của chúng là giúp con người chuyển đổi các yêu cầu thành phần mềm đáng tin cậy trong khi vẫn phải quản lý thời gian, sự chú ý và năng lực nhận thức hữu hạn.

Với AI, ràng buộc này đang bắt đầu nới lỏng.

Các tác nhân (agent) lập trình tiên phong hiện đã có thể tự chủ suy luận trên các kho lưu trữ, tạo và thực thi các bài kiểm thử, xác định lỗ hổng bảo mật và điều phối công việc đa giai đoạn. Trong một minh chứng ấn tượng, một nhóm gồm mười sáu tác nhân Claude chạy song song đã xây dựng một trình biên dịch C hoạt động được với chi phí dưới 20.000 USD. Tuy nhiên, trên các bộ tiêu chuẩn đánh giá (benchmark) được thiết kế để kiểm tra sự phát triển phần mềm liên tục thay vì các tác vụ đơn lẻ, các tác nhân tiên phong vẫn suy giảm hiệu suất đáng kể: chúng có thể thêm tính năng, nhưng lại gặp khó khăn trong việc duy trì tính đúng đắn và sự nhất quán về kiến trúc qua các thay đổi liên tiếp.

Hai thực tế này cần được xem xét cùng nhau. Các tác nhân lập trình đang trở nên đủ năng lực để đảm nhận quyền sở hữu có ý nghĩa, nhưng chưa đủ tin cậy để chúng ta coi quyền tự chủ là một khả năng đơn nhất, không phân biệt.

Do đó, câu hỏi then chốt không còn chỉ là "Làm thế nào AI có thể giúp lập trình viên hoàn thành một tác vụ cụ thể?", mà là "Làm thế nào trách nhiệm có thể được chuyển giao từ con người sang AI trong suốt vòng đời phát triển phần mềm, và điều gì phải được đảm bảo để quá trình chuyển giao đó an toàn, đáng tin cậy và có trách nhiệm?"

Nghiên cứu về xe tự hành đã sớm nhận ra rằng một lĩnh vực không thể suy luận rõ ràng về an toàn, năng lực và trách nhiệm nếu thiếu một hệ thống thuật ngữ chung. Các cấp độ tự động hóa của SAE đã giúp phân biệt giữa hỗ trợ lái xe, tự động hóa có điều kiện và tự động hóa hoàn toàn, đồng thời xác định ai là người chịu trách nhiệm ở mỗi giai đoạn.

Phát triển phần mềm chưa có một khung tham chiếu tương đương. "Tác nhân lập trình tự hành" hiện nay có thể chỉ một công cụ gợi ý vài dòng mã, một tác nhân mở pull request, một hệ thống tự kiểm thử và triển khai các thay đổi của chính nó, hoặc một tác nhân quyết định tính năng nào cần xây dựng. Đây là những hệ thống hoàn toàn khác biệt với các kiểu lỗi (failure mode) hoàn toàn khác biệt.

Lấy cảm hứng từ các cấp độ tự động hóa của SAE, chúng tôi đề xuất và định nghĩa ba cấp độ tự chủ trong phát triển phần mềm dựa trên việc các giai đoạn nào của vòng đời phát triển phần mềm đã chuyển từ trách nhiệm của con người sang sự kiểm soát hoàn toàn của AI.

Các cấp độ của chúng tôi phân loại mức độ sở hữu của hệ thống AI đối với vòng đời phát triển phần mềm và những trách nhiệm nào vẫn thuộc về con người.

Cấp độ I — Tự chủ mã nguồn (Code Autonomy)

AI đảm nhận toàn bộ quyền sở hữu đối với thiết kế và triển khai hệ thống mà không cần sự phê duyệt từng dòng từ con người. Tác nhân tạo ra một pull request hoàn chỉnh, bao gồm cơ sở thiết kế, mã nguồn và tài liệu. Con người vẫn quyết định những gì cần xây dựng, đánh giá các thay đổi được đề xuất ở mức độ pull request, giám sát kiểm thử và kiểm định bảo mật, cũng như kiểm soát việc triển khai. Chúng tôi coi việc lập trình có sự hỗ trợ của AI hiện nay là tiền thân của cấp độ này.

Cấp độ II — Tự chủ quy trình (Pipeline Autonomy)

AI vận hành toàn bộ quy trình từ thiết kế và triển khai cho đến kiểm thử, kiểm định và triển khai thực tế. Con người không viết cũng không đánh giá mã nguồn. Họ chỉ đưa ra yêu cầu ở mức độ cao và đánh giá hành vi kết quả. Đây là một bước ngoặt về chất: nó giả định rằng ý định của con người có thể được nắm bắt trong một đặc tả đủ hoàn chỉnh và việc xác thực, kiểm chứng tự động có thể được tin tưởng ngay cả khi không có con người kiểm tra các sản phẩm trung gian. Hiện tại, cả hai giả định này đều chưa khả thi ở quy mô lớn.

Cấp độ III — Tự chủ nhu cầu (Demand Autonomy)

AI không chỉ xây dựng, kiểm thử và triển khai phần mềm; nó còn quyết định những gì cần được xây dựng. Nó xác định nhu cầu từ dữ liệu đo lường (telemetry), hành vi người dùng, các cảnh báo bảo mật, thay đổi về phụ thuộc và trạng thái tiến hóa của hệ thống. Vai trò cuối cùng của con người trong vòng lặp phát triển định kỳ sẽ biến mất, mặc dù hệ thống vẫn bị giới hạn bởi sứ mệnh nền tảng do con người thiết lập. Thách thức trung tâm trở thành việc đảm bảo rằng các nhu cầu do hệ thống tự tạo ra vẫn tiếp tục phục vụ sứ mệnh đó thay vì âm thầm định nghĩa lại nó.

Chúng tôi dự đoán các tổ chức trong các lĩnh vực khác nhau sẽ tiến triển qua khung tự chủ này với tốc độ khác nhau. Các lĩnh vực đòi hỏi độ an toàn cao có thể duy trì ở Cấp độ I hoặc thấp hơn trong một thời gian dài, trong khi các công cụ nội bộ và ứng dụng dùng một lần có thể tiếp cận Cấp độ II sớm hơn nhiều. Hệ thống phân loại này là một cách để làm cho các tuyên bố về năng lực, lựa chọn triển khai và trách nhiệm giải trình trở nên minh bạch.

Tự chủ có nhiều hơn một chiều kích

Ba cấp độ tự chủ trả lời một câu hỏi chính: Hệ thống AI sở hữu những giai đoạn nào của vòng đời phát triển phần mềm? Nhưng cấp độ thôi là chưa đủ để mô tả đầy đủ mức độ tự chủ của hệ thống. Hai hệ thống ở cùng một cấp độ có thể vận hành rất khác nhau tùy thuộc vào ba chiều kích bổ sung, mang tính xuyên suốt:

Vấn đề thống nhất: Bảo tồn ý định của con người

Ở cả ba cấp độ, một thách thức xuất hiện dưới các hình thức khác nhau: bảo tồn và thực thi trung thực ý định của con người khi sự kiểm soát trực tiếp của con người giảm dần.

Ở Cấp độ I, con người vẫn có thể khôi phục ý định thông qua việc đánh giá. Ở Cấp độ II, ý định phải được mã hóa thành một đặc tả mà không ai kiểm chứng từ đầu đến cuối. Ở Cấp độ III, AI phải tự tổng hợp và duy trì đặc tả đó trong khi hệ thống tiến hóa qua nhiều năm.

Nhiều lỗi có vẻ riêng biệt thực chất là biểu hiện của cùng một vấn đề. Sự lệch lạc đặc tả (specification drift) có nghĩa là việc triển khai dần dần khác biệt so với những gì con người mong muốn. "Hack phần thưởng" (reward hacking) có nghĩa là hệ thống thỏa mãn một đại diện đo lường được trong khi vi phạm mục tiêu cốt lõi. Sự bất đồng giữa các tác nhân (multi-agent disagreement) có nghĩa là các tác nhân khác nhau hành động dựa trên những cách hiểu không tương thích mà không làm lộ ra xung đột. Một tác nhân viết kiểm thử có thể tạo ra một bản triển khai và một bộ kiểm thử nhất quán với nhau nhưng lại sai lệch hoàn toàn về tổng thể.

RỦI RO CỐT LÕI: Khi cùng một tác nhân viết mã triển khai và viết kiểm thử, việc vượt qua các bài kiểm thử chỉ chứng minh tính nhất quán, không phải tính đúng đắn.

Đây là lý do tại sao mức độ tự chủ cao hơn làm thay đổi đối tượng cần đảm bảo. Việc xác thực sản phẩm phần mềm không còn là đủ. Chúng ta cũng cần kiểm định tác nhân đã tạo ra nó: đặc tả, kỹ năng, bộ nhớ, nguồn gốc quyết định, giao thức giao tiếp và dấu vết thực thi của nó.

Thực trạng sai lầm đang nổi lên: Nhảy cấp (Level-Skipping)

Rủi ro cấp bách nhất không phải là một hệ thống tự hành hoàn toàn kỳ lạ. Đó là việc các tổ chức bỏ qua các cấp độ.

Một nhóm có thể vận hành trên danh nghĩa ở Cấp độ I, với con người vẫn chịu trách nhiệm hoàn toàn về đánh giá và triển khai, nhưng trong thực tế lại hợp nhất các thay đổi do tác nhân tạo ra mà không ai kiểm tra một cách nghiêm túc. Nhóm áp dụng các phương pháp của Cấp độ II mà không có sự xác thực, quản trị hoặc trách nhiệm giải trình của Cấp độ II. Áp lực tương tự xuất hiện khi các nhóm để các tác nhân khởi tạo thay đổi từ dữ liệu đo lường hoặc nội dung bên ngoài mà không bảo mật các kênh kích hoạt những thay đổi đó.

Do đó, chúng tôi ủng hộ việc kiểm soát cấp độ rõ ràng: các hệ thống chỉ nên tiến lên khi các thách thức liên quan đến cấp độ hiện tại của chúng đã được giải quyết một cách minh chứng. Gánh nặng chứng minh phải tăng dần theo mức độ tự chủ, thời gian và rủi ro của việc triển khai.

Sáu thay đổi cấu trúc

Nếu việc triển khai trở nên dồi dào, phát triển phần mềm sẽ không chỉ đơn thuần là một phiên bản nhanh hơn của quy trình làm việc hiện nay. Nó trải qua một sự chuyển đổi sâu sắc hơn. Các sản phẩm chính của kỹ thuật phần mềm thay đổi. Bản thân quy trình kỹ thuật cũng thay đổi. Và cuối cùng, hệ sinh thái kỹ thuật phần mềm sẽ tái tổ chức.

Chúng tôi dự đoán sáu thay đổi cấu trúc sẽ diễn ra trên ba lớp này.

I. Phần mềm trở nên mang tính tạo sinh (Generative)

Sự chuyển đổi đầu tiên nằm ở chính sản phẩm phần mềm. Ý định của con người ngày càng thay thế việc triển khai để trở thành đại diện bền vững của phần mềm, trong khi việc triển khai trở nên dễ dàng hơn để tạo ra, sửa đổi và tái tạo.

1. Đặc tả trở thành sản phẩm phát triển chính

Khi con người tương tác ít hơn với mã nguồn, các đặc tả trở thành giao diện thống trị giữa ý định của con người và sự thực thi của máy móc. Chúng phải nắm bắt không chỉ các yêu cầu chức năng mà còn cả các ràng buộc bảo mật, kỳ vọng về khả năng bảo trì, các bất biến kiến trúc, quy ước sản phẩm và chiến lược kiểm thử.

Việc duy trì các đặc tả như vậy theo cách thủ công cuối cùng có thể trở nên khó khăn hơn việc duy trì lịch sử tương tác mà từ đó chúng hình thành. Do đó, chúng tôi dự đoán về sự chưng cất đặc tả (specification distillation): con người cộng tác với các tác nhân thông qua các cuộc hội thoại, ví dụ và phản hồi, trong khi các tác nhân liên tục biên dịch các tương tác đó thành các đặc tả bền vững, có cấu trúc. Theo thời gian, các đặc tả có thể tiến gần đến sự tương ứng một-một với các hệ thống phần mềm, giúp việc triển khai có thể được tái tạo chỉ từ các đặc tả.

2. Các ranh giới trừu tượng trở nên thẩm thấu