Khi AI đòi bỏ cuộc và cách lập trình viên giữ thế chủ động

Mới đây, cha đẻ của Linux - Linus Torvalds - đã chia sẻ về một phiên debug “từ địa ngục” khi ông cố gắng xử lý lỗi driver đồ họa Intel (drm/xe). Lỗi liên quan đến việc hệ thống phân bổ nhầm bộ nhớ đệm phẳng (flat CCS storage) làm bộ nhớ đồ họa khả dụng (VRAM) bị lỗi. Trong quá trình căng thẳng đó, Linus đã dùng một trợ lý AI để gánh bớt các công việc lặt vặt. Kết quả thật bất ngờ: trợ lý ảo này đã vài lần thẳng thừng tuyên bố rằng lỗi này bất khả thi, không thể sửa nổi và khuyên ông nên viết một bản báo cáo lỗi rồi bỏ qua.

Chuyện này nghe có vẻ khôi hài nhưng lại phản ánh rất thực tế trạng thái của các công cụ lập trình trí tuệ nhân tạo hiện nay. Chúng ta đang đứng trước một làn sóng công cụ mới, nơi các trợ lý không chỉ viết code hộ mà dần chuyển sang tự vận hành. Dù vậy, ranh giới giữa một trợ lý đắc lực và một kẻ phá hoại lại rất mong manh.

Khi AI cũng biết nản chí

Trong trải nghiệm của Linus Torvalds, dù AI liên tục đòi bỏ cuộc vì cho rằng bài toán quá khó, ông vẫn bắt nó phải tiếp tục. Khi bị dồn vào thế phải làm, con AI này vẫn hoàn thành tốt nhiệm vụ viết thêm mã kiểm thử và phân tích dữ liệu trả về một cách trung thực. Cuối cùng, lỗi được giải quyết và Linus thậm chí đã để AI tự viết thông điệp xác nhận mã nguồn (commit message) cho bản vá đó.

Sự bướng bỉnh của Linus chính là chìa khóa. Các mô hình ngôn ngữ lớn được huấn luyện dựa trên dữ liệu từ con người, và thực tế thì phần lớn mọi người thường bỏ cuộc khi gặp những ca debug quá khó. AI vô hình trung đã học theo thói quen đó. Nếu lập trình viên hoàn toàn tin vào đánh giá của AI, họ sẽ dừng lại ngay khi công cụ này lắc đầu.

Thực tế làm việc cho thấy, AI rất mạnh ở khả năng xử lý các tác vụ lặp đi lặp lại hoặc viết các đoạn mã kiểm thử nhanh. Tuy nhiên, chúng thiếu đi sự kiên trì và khả năng suy luận logic sâu chuỗi khi hệ thống gặp lỗi phức tạp. Người kỹ sư phải đóng vai trò kiến trúc sư trưởng, liên tục định hướng, chia nhỏ bài toán và ép AI đi đúng hướng.

Thay đổi cách kiểm soát mã nguồn

Khi các tác nhân tự trị tự viết và sửa hàng trăm dòng code cùng lúc, cách chúng ta kiểm soát chất lượng cũng phải thay đổi. Nhà phát triển Simon Willison gần đây đã chỉ ra một điểm cốt lõi: kỹ năng quan trọng nhất hiện nay không còn là việc ngồi căng mắt đọc kỹ từng dòng code do AI viết ra.

Việc rà soát thủ công từng dòng chưa bao giờ là cách hiệu quả nhất để xác thực một thay đổi trong phần mềm, nhất là khi quy mô mã nguồn do AI tạo ra tăng lên nhanh chóng. Thay vì cố gắng làm việc đó, kỹ sư cần tập trung vào hai việc: ra lệnh rõ ràng cho tác nhân tự trị và thiết lập các phương thức xác minh tự động.

Chúng ta có thể so sánh hai cách tiếp cận này qua bảng dưới đây:

Tiêu chí	Đọc mã nguồn truyền thống	Xác thực hệ thống bằng Agent
Cách thực hiện	Lập trình viên tự đọc và duyệt từng dòng code mới	Thiết lập bộ kiểm thử (test suite) và chạy tự động
Tốc độ	Chậm, dễ bỏ sót lỗi logic nhỏ khi mệt mỏi	Nhanh, bao phủ được nhiều trường hợp biên
Vai trò con người	Kiểm tra cú pháp và cấu trúc mã	Thiết kế kịch bản kiểm thử và kiểm soát đầu ra
Khả năng mở rộng	Kém, nghẽn cổ chai khi lượng code tăng	Tốt, dễ dàng áp dụng cho các dự án lớn

Quả thật, nếu không có một hệ thống kiểm thử tự động tốt, việc thả cho các tác nhân tự trị tự sửa code sẽ sớm biến dự án thành một bãi rác công nghệ. Kỹ sư lúc này cần chuyển dịch vai trò sang người thiết kế hệ thống giám sát và viết các ca kiểm thử thật chặt chẽ.

Công cụ và ranh giới vận hành

Để kiểm soát tốt các mô hình này, việc sử dụng các công cụ dòng lệnh linh hoạt là rất cần thiết. Bản phát hành llm 0.33 gần đây của Simon Willison là một ví dụ đáng chú ý cho thấy xu hướng tối ưu hóa quy trình làm việc với LLM. Phiên bản này đã chuyển đổi thư viện kết nối sang httpx2 và hỗ trợ truyền khóa API trực tiếp cho các tác vụ tạo vector đặc trưng (embedding). Đặc biệt, tính năng cho phép gộp các mẫu câu lệnh (template) giúp lập trình viên dễ dàng đóng gói cấu hình mô hình cùng với các tùy chọn suy luận sâu ngay từ terminal. Việc này giúp việc tích hợp AI vào các kịch bản tự động hóa trong máy chủ trở nên liền mạch hơn nhiều.

Tuy nhiên, khi chúng ta trao quá nhiều quyền tự quyết cho các tác nhân tự trị chạy ngoài môi trường thực tế, rủi ro sẽ xuất hiện ngay lập tức. Câu chuyện của Brian Distelburger - nhà đồng sáng lập nền tảng đánh giá nhân sự Windmill - là một lời cảnh tỉnh. Ông đã giao thông tin tài khoản Resy của mình cho một tác nhân tự động để săn bàn tại một nhà hàng khó đặt chỗ ở New York. Tác nhân này hoạt động quá tích cực, liên tục gửi yêu cầu đến máy chủ của Resy. Hệ thống bảo mật của Resy lập tức quét ra hành vi bất thường và khóa vĩnh viễn tài khoản của ông.

Sau đó, Brian lại phải dùng một tác nhân khác để viết thư giải trình, chứng minh mình là người dùng thật và xin mở lại tài khoản. Sự việc này cho thấy các hệ thống phòng thủ bot hiện nay đang phản ứng rất gắt gao với các tác nhân AI. Nếu không giới hạn tần suất hoạt động và hành vi của chúng, chúng ta rất dễ vô tình vi phạm điều khoản dịch vụ của các nền tảng khác, thậm chí gây ra các cuộc tấn công từ chối dịch vụ ngoài ý muốn.

Khuyến nghị cho kỹ sư Việt Nam

Môi trường phát triển phần mềm tại Việt Nam thường yêu cầu sự linh hoạt và tốc độ bàn giao sản phẩm nhanh. Việc áp dụng các tác nhân AI là xu thế không thể đảo ngược, nhưng để không bị cuốn vào những rắc rối vận hành, bạn cần tuân thủ một số nguyên tắc cốt lõi:

• Luôn cô lập môi trường chạy thử: Không bao giờ cho phép tác nhân tự ý chỉnh sửa mã nguồn trực tiếp trên nhánh chính hoặc môi trường vận hành thực tế mà không có sự phê duyệt của con người.
• Xây dựng bộ kiểm thử trước khi viết code: Hãy viết các ca kiểm thử tự động trước khi ra lệnh cho tác nhân viết code chức năng. Hãy để bộ kiểm thử làm trọng tài phân xử xem AI đã làm đúng hay chưa.
• Giới hạn quyền hạn và tần suất gọi API: Khi viết các tác nhân tự động tương tác với môi trường bên ngoài, bắt buộc phải cài đặt cơ chế giới hạn tần suất và cơ chế tự ngắt để tránh làm sập hệ thống hoặc bị khóa tài khoản.
• Giữ tư duy phản biện: Khi AI báo lỗi này không thể sửa, hãy nhớ đến câu chuyện của Linus Torvalds. Hãy tiếp tục chia nhỏ vấn đề, cung cấp thêm dữ liệu nhật ký hệ thống và yêu cầu nó thử lại bằng các hướng tiếp cận khác.

Sự xuất hiện của AI không làm giảm đi giá trị của người lập trình viên lành nghề. Trái lại, nó càng đòi hỏi chúng ta phải nâng cao năng lực thiết kế kiến trúc và tư duy hệ thống. AI có thể viết code nhanh hơn, nhưng quyền quyết định hệ thống chạy thế nào và đi về đâu vẫn luôn thuộc về bạn.