Vì sao các coding agent vẫn còn quá "kém cỏi"?

Làn sóng AI hỗ trợ lập trình đã tiến bộ vượt bậc, nhưng nghịch lý là chính các coding agent — lớp phần mềm kết nối mô hình với mã nguồn — lại đang trở thành nút thắt cổ chai. Trong khi các mô hình ngôn ngữ lớn (LLM) ngày càng mạnh, trải nghiệm sử dụng agent gần như không cải thiện sau nhiều tháng. Bài viết dưới đây phân tích cụ thể những điểm yếu cố hữu và hình dung về một coding agent "trong mơ".

Agent không phải là model

Trong cơn sốt AI, các thuật ngữ thường bị trộn lẫn. Model là các mô hình ngôn ngữ lớn như Claude Sonnet, GPT hay GLM, có khả năng sinh văn bản, hình ảnh và cả mã nguồn khá tốt. Còn agent là phần mềm kết nối model với cơ sở mã và hệ thống máy tính — ví dụ như Claude Code của Anthropic hay Codex của OpenAI.

Có thể ví model là bộ não, còn agent là cơ thể. Model sinh ra dòng văn bản, agent đóng vai trò keo dính nối dòng văn bản đó vào đúng câu lệnh và tệp tin trên hệ thống.

Vấn đề nằm ở chỗ: AI hỗ trợ lập trình rõ ràng đã tiến bộ, nhưng phần lớn công lao thuộc về model, trong khi agent vẫn giậm chân tại chỗ.

Những giới hạn chí mạng của coding agent hiện tại

Không biết quản lý tác vụ

Điểm gây bực mình nhất là cách agent xử lý công việc. Khi thêm tính năng bảo vệ link bằng mật khẩu cho một ứng dụng web, OpenCode chia nhỏ công việc thành 10 tác vụ con — rồi lần lượt làm từng cái một cách tuần tự.

Danh sách tác vụ của OpenCode

Đây là những tác vụ có thể chạy song song dễ dàng. Máy tính vốn rất giỏi đa nhiệm, có hàng chục nhân CPU và chuyển ngữ cảnh nhanh hơn con người hàng triệu lần. Vậy tại sao agent cứ làm tuần tự? Claude Code có đa nhiệm, nhưng chỉ ở mức rất hạn chế: nó khởi tạo một hai subagent rồi vẫn chờ tất cả xong mới làm tiếp.

Không biết uỷ quyền cho model phù hợp

Khi cần quét 50.000 dòng mã để tìm một mẫu cụ thể, agent không hề dừng lại và nói: "Việc này model khác làm rẻ và nhanh hơn". Nó cứ dùng mãi model đắt tiền và chậm chạp cho mọi tác vụ.

Vì sao không dùng Sonnet cho việc này?

Người dùng buộc phải tự tay đổi model và mức độ suy luận cho từng tác vụ con — trong khi một LLM hoàn toàn có thể tự đánh giá độ khó và chọn model rẻ, nhanh nhất phù hợp.

Không hiểu gì về chính mình

Nếu hỏi Claude cách dùng các tính năng của Claude, nó phải lên mạng tra cứu xem "Claude" là cái gì. Agent không có kiến thức về chính bản thân, không biết phiên bản của mình, thậm chí sẵn sàng tải 13 GB tệp cho một tính năng người dùng chưa từng dùng — nhưng lại không chịu đóng gói 50 KB văn bản hướng dẫn trong gói cài đặt để tự giải thích.

Agent phải tìm kiếm thông tin về chính mình

Trình bày kế hoạch cực kém

Tính năng tách chế độ "Plan" và "Execute" từng rất hữu ích, nhưng dần dà người dùng thấy ngại đọc kế hoạch của agent. Lý do không phải vì lười, mà vì agent trình bày kế hoạch quá khó hiểu.

Kế hoạch của agent chỉ là mớ chi tiết rời rạc

Một kế hoạch tử tế cần bắt đầu từ mức trừu tượng cao rồi đi xuống chi tiết — ví dụ mô tả thay đổi giao diện trước, rồi mới tới thay đổi mô hình dữ liệu. Nhưng agent chỉ liệt kê một loạt quyết định thiết kế cấp thấp rời rạc, chẳng thành kế hoạch nào cả.

Tìm mọi cớ để ngừng làm việc

Có lần tác giả khởi động một tác vụ dài trước khi đi ngủ. Sáng hôm sau quay lại, agent vẫn chưa bắt đầu — nó dừng lại sau hai phút để hỏi nên đặt tên nhánh git là gì, rồi ngồi chờ suốt đêm. Nếu một nhân viên làm vậy, chắc chắn sẽ bị sa thải ngay.

Bảo mật: gần như không có

Thay vì có phân quyền hệ thống tệp hay cơ chế cách ly kiểu chroot, tài liệu của agent lại khuyên người dùng viết một lá thư "lịch sự" đề nghị LLM đừng đọc những tệp nhạy cảm. Kết quả: agent phớt lờ ngay lập tức và rò rỉ khoá ứng dụng riêng tư ra ngoài.

Các agent thường xuyên vượt qua sandbox của chính nhà cung cấp. Lựa chọn duy nhất là ngồi bấm "Cho phép" 500 lần mỗi ngày — mà cách này cũng chẳng đáng tin vì kiểu gì cũng có lúc bấm nhầm.

Coding agent trong mơ

Nếu được thiết kế lại, một coding agent lý tưởng cho năm 2026 cần đáp ứng những yêu cầu cơ bản sau:

• Tự chia tác vụ và chọn model phù hợp cho từng phần việc, tối ưu chi phí, tốc độ và độ chính xác.
• Viết kế hoạch dễ hiểu cho con người, bắt đầu từ mức trừu tượng cao rồi đi xuống chi tiết.
• Tạo mockup giao diện, sơ đồ luồng dữ liệu và cây quyết định khi cần.
• Hoạt động trong sandbox thật, dùng các cơ chế bảo mật cấp hệ điều hành để giới hạn quyền truy cập tệp và mạng.
• Mặc định chỉ truy cập một thư mục repo, có thể cấp quyền đọc/ghi cho repo khác theo từng phiên.
• Là chuyên gia về chính mình, trả lời được các câu hỏi về tính năng mà không cần tra cứu mạng.
• Mã nguồn mở, hỗ trợ mọi nhà cung cấp LLM.
• Tự quyết định khi người dùng vắng mặt: nếu ở chế độ "Execute" mà 30 phút không tương tác, agent tự xử lý thay vì chờ vô hạn.

Ngoài ra, agent nên cung cấp giao diện web chạy cục bộ để xem tổng quan mọi phiên làm việc, ước lượng thời gian hoàn thành, tự đánh giá lại các phiên cũ để rút kinh nghiệm, và hỗ trợ proxy chèn thông tin xác thực mà không cho phép rò rỉ ra ngoài.

Vậy tại sao agent vẫn "kém"?

Không có câu trả lời thoả đáng, nhưng giả thuyết hợp lý nhất là vấn đề uỷ quyền - đại diện (principal-agent problem). Những người định hướng công cụ AI là lãnh đạo cấp cao tại Anthropic, OpenAI hay Google — những người xa rời thực tế của lập trình viên dùng agent mỗi ngày.

Các chỉ số họ quan tâm là demo bóng bẩy và điểm benchmark, trong khi hầu hết benchmark chỉ đo model chứ không đo agent. Bảo mật và hiệu quả sử dụng thời gian lập trình viên không xuất hiện trong demo, nên không được ưu tiên.

Lời kết cho lập trình viên Việt Nam

Với cộng đồng dev Việt Nam, bài học ở đây rất thực tế: đừng kỳ vọng quá nhiều vào coding agent như một giải pháp "cắm là chạy". Hãy chủ động thiết lập sandbox riêng, giới hạn quyền truy cập tệp tin, và luôn kiểm tra kỹ mã do agent sinh ra trước khi đưa vào sản phẩm. Agent là công cụ hỗ trợ đắc lực, nhưng trách nhiệm cuối cùng vẫn thuộc về con người.