Tại sao các tác nhân AI hiện tại vẫn chưa thể tự thay đổi hệ thống phần mềm

Giấc mơ về tự động hóa quy trình giao phần mềm vào năm 2026 là hình dung về một tác nhân AI có thể đọc kho mã (repository), hiểu cấu trúc dự án, lập kế hoạch thay đổi đa bước, viết code cùng với các bài kiểm thử và tài liệu, tự chạy code để sửa lỗi và cuối cùng tạo ra một Pull Request (PR) sẵn sàng để hợp nhất.

Ba nhiệm vụ đầu tiên mang tính chất "cộng thêm" (additive): đọc, ánh xạ và lập kế hoạch mà không làm thay đổi hành vi của hệ thống. Tuy nhiên, ba nhiệm vụ cuối lại mang tính chất "chuyển đổi" (transformative), đòi hỏi sự thay đổi đối với cấu trúc nhân quả hiện có trong codebase. Sự phân biệt giữa công việc cộng thêm và chuyển đổi này chính là lý do cốt lõi khiến các LLM hiện nay chỉ có thể hỗ trợ chứ không thể tự chủ giao phần mềm.

Thực tế từ các phòng Lab

Các công việc liên quan đến tác nhân AI từ OpenAI, Google, Cognition Labs, GitHub, Sourcegraph, JetBrains, Replit, Amazon, Meta và Anthropic đã được công bố vào năm 2023 và 2024. Tùy vào nơi bạn nhìn nhận, bạn có thể có cảm giác rằng "các tác nhân AI đã đến". Tuy nhiên, thực tế lại kể một câu chuyện khác.

Các tác nhân AI đang được cải thiện, nhưng chúng chưa đủ độ tin cậy, không tự chủ và chưa an toàn để đưa vào môi trường sản xuất (production). LLM có thể hỗ trợ quy trình giao phần mềm, nhưng không thể "sở hữu" hoàn toàn quy trình đó.

Tại sao LLM gặp khó khăn?

LLM tạo ra các đoạn tiếp theo của văn bản dựa trên xác suất thống kê. Điều này hoạt động tốt cho các nhiệm vụ độc lập (self-contained) như viết một hàm function hay soạn thảo tài liệu, vì đây là các bài toán mở rộng mẫu (pattern extension).

Tuy nhiên, khớp mẫu (pattern matching) không phải là hiểu hệ thống, và tính hợp lý (plausibility) không đồng nghĩa với tính đúng đắn (correctness).

Các hệ thống phần mềm mang tính nhân quả (causal): các thành phần phụ thuộc lẫn nhau, các bất biến (invariants) ràng buộc hành vi, và các thay đổi sẽ lan truyền qua hệ thống. Ngay khi nhiệm vụ chuyển từ độc lập sang phụ thuộc hệ thống — đòi hỏi sự nhất quán về phụ thuộc, trạng thái liên tục, hay nhận thức về tác động lan tỏa trong một codebase thực tế — thì việc khớp mẫu không còn đủ khả năng giải quyết.

Hiện tại, LLM có thể bắt chước hình thức của công việc kỹ thuật, nhưng không thể duy trì một biểu diễn nội bộ ổn định của hệ thống cần được thay đổi một cách mạch lạc. Khoảng cách này chính là lý do LLM thất bại ngay khi nhiệm vụ chuyển sang cấp độ hệ thống.

Khoảng cách giữa viết code và sửa đổi hệ thống

Khoảng cách này trở nên rõ ràng khi so sánh hai hoạt động: viết code mới và sửa đổi hệ thống hiện có.

Viết code mang tính cục bộ và cộng thêm: mô hình mở rộng một mẫu mà không cần hiểu sâu về hệ thống.

Ngược lại, công việc của một tác nhân AI mang tính toàn cầu và chuyển đổi: LLM phải thay đổi chính hệ thống, đòi hỏi sự hiểu biết về phụ thuộc, bất biến, tương tác và các hậu quả downstream. Đây là lập luận nhân quả, không phải mở rộng mẫu. LLM dự đoán các token (ký hiệu), không phải các hậu quả — và đó là lý do bước nhảy từ viết code đến tạo ra một diff PR an toàn, nhận thức hệ thống không phải là gia tăng mà là bước chuyển sang một không gian vấn đề hoàn toàn khác.

Pull Request: Thử thách về tính an toàn

Một Pull Request (PR) là một đoạn code sẽ thay đổi hệ thống. Để thay đổi đó an toàn, nó phải tôn trọng kiến trúc hiện tại, ý định của hệ thống và tất cả các hậu quả đi kèm.

Các kỹ sư phần mềm nỗ lực đảm bảo tính an toàn này thông qua kiểm thử (testing) và phán xét, kinh nghiệm của mình trước khi đồng nghiệp review. Việc áp dụng thay đổi không còn là khớp mẫu, mà là hiểu hành vi nhân quả: hệ thống sẽ thay đổi như thế nào nếu PR này được áp dụng?

Tính đúng đắn của PR phụ thuộc vào việc hiểu toàn bộ hệ thống, không chỉ là việc tạo văn bản. LLM phải thay đổi hệ thống, đòi hỏi sự hiểu biết về phụ thuộc, bất biến, tương tác và hậu quả, tất cả đều yêu cầu lập luận nhân quả chứ không phải khớp mẫu. Khớp mẫu có thể viết code, nhưng chỉ lập luận nhân quả mới có thể bảo trì hệ thống.

Lời khuyên cho các nhà phát triển

Tác giả khuyên cộng đồng kỹ thuật nên tự mình xác minh bất kỳ tuyên bố nào về khả năng của AI. Hãy định nghĩa một kho mã thực tế của riêng bạn với hàng nghìn dòng code để làm việc, thay vì dựa vào các demo đơn giản.

Hiện tại, chúng ta nên:

• Coi AI tác nhân là một định hướng chiến lược.
• Coi các công cụ hiện tại là trợ lý, không phải là kỹ sư.
• Đầu tư vào sự rõ ràng, kiến trúc và kỷ luật kiểm thử.
• Mong đợi sự tiến bộ, nhưng không nên mong chờ phép màu.
• Không lên kế hoạch cho các pipeline giao phần mềm dựa trên các khả năng chưa được chứng minh.

Hãy giữ phán xét của con người làm trung tâm của hệ thống. Giấc mơ vẫn còn đó, nhưng bằng chứng chưa xuất hiện.

Kết luận: Code rẻ, phán xét đắt

Giao phần mềm được hỗ trợ bởi LLM không loại bỏ kỹ thuật, mà nâng tầm kỹ thuật lên một cấp độ cao hơn. Con người cần tập trung vào: ý định, ràng buộc, kiến trúc, tính đúng đắn, an toàn và sự đánh đổi.

Trạng thái mong muốn cuối cùng không phải là "AI viết code", mà là "AI bảo trì hệ thống". Nếu đạt được điều đó, con người vẫn sẽ cần duy trì ý định. Hậu quả của hệ thống tác nhân không phải là loại bỏ kỹ thuật, mà là nâng cao nó, giúp các đội nhóm dành ít thời gian hơn cho việc xây dựng cơ học và nhiều thời gian hơn cho việc phán xét, sự liên kết và định hình môi trường hoạt động của các tác nhân.

Cho đến khi AI có thể lập luận nhân quả về các hệ thống, phán xét của con người vẫn là nền tảng của việc giao phần mềm.