Tại sao nền tảng kỹ thuật phần mềm quan trọng hơn cơn sốt AI Agent?

Biểu hiện của hội chứng kẻ giả mạo (imposter syndrome) đối với tôi, ở thời điểm hiện tại, chính là câu hỏi: thế nào mới là một kỹ sư phần mềm? Trên Internet đang có quá nhiều thông tin nhiễu loạn về agentic engineering (kỹ thuật dựa trên tác nhân), những gì có thể đạt được và ý nghĩa của nó đối với tương lai. Tiêu đề tôi chọn đã phần nào nói lên điều đó; đó là về việc lựa chọn — một cách cẩn trọng — tất cả những thứ bạn cần chọn khi giải quyết các bài toán hóc búa trong phát triển phần mềm và hệ thống.

Vượt lên trên sự cường điệu và sự cuồng nhiệt tiếp thị kiểu "con nghiện" từ các "nhà cung cấp mô hình lớn", tôi đã tìm thấy một công cụ hỗ trợ thực sự thú vị nhờ sự kết hợp giữa harness (khung điều khiển) và các mô hình. Tôi đã theo dõi cách bạn bè sử dụng những công cụ này và học hỏi được rất nhiều điều. Như thường lệ, những người đang làm những việc tuyệt vời nhất lại không phải là những người huênh hoang về điều đó, hay đăng những bài viết kể lể trên mạng xã hội về sự kết thúc của nghề này. Họ đã tìm thấy một "đòn bẩy cực mạnh", họ đang khám phá các điểm tựa và họ đang vận dụng tinh thần của Archimedes để dựa vào đòn bẩy đó mà xoay chuyển thế giới.

Trong năm qua, các agent harness đã vượt qua cột mốc "liệu có làm được không" (vâng, tôi lại mượn điển tích La Mã). Tôi không hề mong muốn kiến thức của nhân loại bị lấy đi mà không có sự cho phép hay tôn trọng, cũng chẳng muốn những kẻ điên rồ lao vào các thương vụ trục lợi kinh tế, thứ đang làm lu mờ nền kinh tế Mỹ vốn đã suy yếu. Các mô hình kinh tế cho các mô hình lớn (large models) không hề khả thi theo bất kỳ báo cáo nào tôi từng đọc, nhưng năng lực của chúng thì không hề mất đi. Thay vào đó, chúng đang thu nhỏ lại (rất nhanh!). Các mô hình mã nguồn mở (open weight models) đang giúp những chiếc máy tính cá nhân (vốn mạnh mẽ) có khả năng thực hiện những tác vụ tương tự. Dù hiệu quả chưa bằng, nhưng khoảng cách về thời gian và năng lực không còn quá lớn.

"Liệu có làm được không" chỉ là sự khởi đầu, thậm chí còn chẳng chiếm phần lớn công việc của một kỹ sư phần mềm hay hệ thống. Nó giống như khi tôi học hàn vào những năm 20 tuổi – tôi nhanh chóng tạo ra những thứ mà tôi không thể nhấc nổi hoặc thậm chí không thể đưa ra khỏi cửa xưởng. (ơn trời vì đã có đèn khò acetylene). Bài học tôi rút ra lúc đó, tôi nghĩ cũng tương tự trong lĩnh vực này: Cách lắp ghép mọi thứ lại với nhau mới là điều tạo nên sự khác biệt.

Nếu bạn sử dụng các agentic harness để phát triển với một chút tầm nhìn xa, bạn không chỉ đạt được kết quả "nó hoạt động", mà còn đạt được "nó có thể kiểm thử" (tôi rất ủng hộ việc nhắc nhở "phát triển với TDD đỏ/xanh"). Nhưng ngoài mức đó ra thì nó không thực sự vững chắc. Các mối nối — cách mã nguồn của bạn vận hành, "API" của nó và cách nó khớp với các phần mềm khác — vừa là nghệ thuật vừa là khoa học. Nó được tạo thành từ những thước đo chủ quan dựa trên quan điểm (và kinh nghiệm, cũng như những phỏng đoán của bạn) cho cả những gì bạn đang giải quyết hiện tại và cách sống chung với phần mềm đó trong một thời gian dài.

Làm cho phần mềm có khả năng gỡ lỗi, bảo trì, phân lớp và có thể kết hợp được – đó vẫn là một kỹ năng khó. Phần lớn công việc đó đòi hỏi sự suy luận sâu sắc và thấu đáo. Và đó là nơi mà các LLM ngày nay, ngay cả những mô hình tiên tiến nhất về "năng lực" từ các frontier models, vẫn còn thiếu sót.

Cần hiểu rằng LLM không thực sự "suy luận". Chúng dự đoán, và bản thân các mô hình đó thực chất là tri thức nhân loại đã được nén lại. Vì vậy, nếu nó nằm trong tri thức nhân loại đã được mã hóa, nó có thể phản chiếu lại sự suy luận của con người. Đối với các tác nhân tập trung vào phát triển phần mềm, những dấu vết suy luận đó là dữ liệu quý giá cho các mô hình. Có một bài nghiên cứu rất dễ tiếp cận về việc LLM suy luận kém đến mức nào mang tên "The Illusion of Thinking" (Ảo tưởng về tư duy). Tôi đang theo dõi một số nghiên cứu bao gồm cả việc dự đoán kết quả của các hành động, nhưng đó không phải là những gì chúng ta có với các coding agent hiện nay. Đây là một lĩnh vực nghiên cứu khá khác biệt và đầy thú vị. Nếu bạn muốn khám phá, hãy tìm hiểu cách các "mô hình JEPA" hoạt động, LeWorld Model và các bài nói chuyện gần đây của Yann LeCun.

Tuy nhiên, trong khi làm việc với LLM, vẫn có vô số cách để làm cho chúng hiệu quả hơn. Tôi nghĩ có rất nhiều tiến bộ mà chúng ta thậm chí còn chưa thực sự khai thác hết. Hầu hết những thành công tôi thấy ngày nay đều liên quan đến việc cung cấp cho nó dữ liệu tốt, súc tích để làm việc vào đúng thời điểm, và cung cấp các công cụ xác thực mang tính tất định với phản hồi bằng ngôn ngữ tự nhiên để LLM có thể tự sửa lỗi. Điều kinh ngạc đối với tôi không phải là việc nó có thể dự đoán những gì cần viết, mà là nó rất hiệu quả trong việc gọi công cụ và tuân thủ hướng dẫn.

Một nhược điểm khác của việc tuân thủ hướng dẫn này là thứ mà Simon Willison gọi là "bộ ba gây chết người" (lethal trifecta). Về cơ bản – các mô hình LLM không thể phân biệt được lời khuyên tốt và xấu. Về mặt nền tảng, chúng không thể ngăn chặn các cuộc tấn công prompt injection một cách nhất quán. "Công tác căn chỉnh" (alignment work), các khung an toàn và sandbox đều giúp thêm các rào cản chống lại những điều tồi tệ nhất, nhưng vẫn tồn tại những lỗ hổng cơ bản. Và thẳng thắn mà nói, một thứ gì đó không biết mệt mỏi tuân theo các chỉ dẫn mà không có khả năng suy luận tốt là một cơn ác mộng đối với tôi.

Tôi hy vọng sẽ có những tiến bộ trong thời gian tới về cách huấn luyện các mô hình để bao gồm cả những dấu vết suy luận tương đương cho giai đoạn hậu huấn luyện (RLHF). Trong tương lai lý tưởng của tôi, những điều này bao gồm nhiều hơn về ý nghĩa của việc xây dựng phần mềm với các giao diện sạch, có khả năng gỡ lỗi và bảo trì như một phần quan trọng của các đánh giá được củng cố. Việc xem xét, lập kế hoạch và sửa chữa các mối nối của phần mềm (và hệ thống) một cách cẩn thận là một trong những kỹ năng quan trọng mà chúng ta vừa có thể, vừa cần phải áp dụng khi phát triển phần mềm – dù có hay không có các trợ lý tác nhân. Và khi tôi thấy làn sóng "Ồ, cái đó dễ triển khai mà..." và mọi người vội vã dùng các công cụ cồng kềnh để hoàn thành, tôi nghĩ điều đó càng trở nên quan trọng hơn bao giờ hết.

Đây là thời điểm tuyệt vời để theo dõi những người viết, nói và chia sẻ về nghề phần mềm, cũng như cách chúng ta có thể trở thành những người thợ thủ công giỏi hơn. Hy vọng điều này là hiển nhiên, nhưng không bao giờ có một câu trả lời duy nhất — một liều thuốc vạn năng. Mọi thứ luôn là sự đánh đổi, lựa chọn những gì hợp lý cho vấn đề đang gặp phải. Với sự giúp đỡ của rất nhiều bộ óc tuyệt vời đang chia sẻ suy nghĩ của họ — cả hiện tại và từ nhiều thập kỷ trước — chúng ta có một kho công cụ tuyệt vời cho công việc này. Vấn đề là chọn lựa, hoặc làm lại để chuyển sang một lựa chọn tốt hơn, những sự trừu tượng hóa phù hợp. Cốt lõi của nó là quản lý tải nhận thức, học cách xác định những phần nào cần ổn định, và nơi nào chúng ta muốn công việc của mình linh hoạt, uyển chuyển (và bằng cách nào).

Và vâng, chính tôi đã viết những dấu gạch ngang (em-dashes) đó. Tôi quá yêu thích việc chèn các câu chú thích đệ quy vào bài viết của mình, và tôi thích một khoảng nghỉ thay vì dùng dấu phẩy hay dấu ngoặc đơn.