Những thông tin từ O'Reilly: Người điều phối bất đắc dĩ

Ngày 22/5/2026 Thông tin từ O'Reilly: Người điều phối bất đắc dĩ Các thử nghiệm trong kỹ thuật tác nhân và phát triển dựa trên AI Tín dụng: Alexandra Francis [Ghi chú của biên tập viên: Chúng tôi mở chuyên mục vào thứ Sáu trên blog để cung cấp cái nhìn sâu sắc thường xuyên từ tiếng nói trong cộng đồng nhà phát triển, dù là ở Stack Overflow hay bên ngoài. Đây là bài viết đầu tiên trong số các chuyên mục đó, một bản tái bản của một trong những bài viết trên blog Radar của O’Reilly Media. Chúng tôi sẽ có một bài đăng lại từ họ hàng tháng.] Bài viết này ban đầu được xuất bản trên O’Reilly Radar và được tái bản tại đây với sự cho phép của tác giả. —————————- Đây là bài viết đầu tiên trong loạt bài về kỹ thuật tác nhân và phát triển dựa trên AI. Hãy tìm bài viết tiếp theo vào ngày 19/3 trên O’Reilly Radar. Đã có rất nhiều sự cường điệu về AI và phát triển phần mềm, và nó xuất hiện dưới hai dạng. Một dạng nói, “Tất cả chúng ta đều gặp nguy hiểm, những công cụ như Claude Code sẽ khiến kỹ thuật phần mềm trở nên lỗi thời trong vòng một năm.” Dạng khác nói, “Đừng lo lắng, mọi thứ đều ổn, AI chỉ là một công cụ khác trong hộp công cụ.” Cả hai đều không trung thực. Tôi đã dành hơn 20 năm viết về phát triển phần mềm cho các chuyên gia, bao gồm mọi thứ từ mã hóa và kiến trúc đến quản lý dự án và động lực nhóm. Trong hai năm qua, tôi đã tập trung vào AI, đào tạo các nhà phát triển sử dụng các công cụ này một cách hiệu quả, viết về những gì hiệu quả và những gì không hiệu quả trong sách, bài báo và báo cáo. Và tôi liên tục gặp phải cùng một vấn đề: Tôi vẫn chưa tìm thấy bất kỳ ai có câu trả lời mạch lạc về cách các nhà phát triển có kinh nghiệm thực sự nên làm việc với các công cụ này. Có rất nhiều lời khuyên và rất nhiều sự cường điệu nhưng rất ít cấu trúc, và rất ít thứ bạn có thể thực hành, giảng dạy, phê bình hoặc cải thiện. Tôi đã quan sát các nhà phát triển làm việc sử dụng AI với các mức độ thành công khác nhau, và tôi nhận ra rằng chúng ta cần bắt đầu coi đây là một lĩnh vực riêng. Andrej Karpathy, cựu trưởng bộ phận AI tại Tesla và là thành viên sáng lập của OpenAI, gần đây đã đề xuất thuật ngữ “kỹ thuật tác nhân” (agentic engineering) cho việc phát triển có kỷ luật với các tác nhân AI, và những người khác như Addy Osmani đang tham gia. Cách diễn đạt của Osmani là các tác nhân AI xử lý việc triển khai nhưng con người sở hữu kiến trúc, xem xét mọi khác biệt và kiểm tra không ngừng. Tôi nghĩ điều đó đúng. Nhưng tôi đã dành nhiều thời gian trong hai năm qua để dạy các nhà phát triển cách sử dụng các công cụ như Claude Code, chế độ tác nhân trong Copilot, Cursor và các công cụ khác, và điều tôi liên tục nghe được là họ đã biết rằng họ nên xem xét đầu ra của AI, duy trì kiến trúc, viết các bài kiểm tra, cập nhật tài liệu và kiểm soát cơ sở mã. Họ biết cách làm điều đó về mặt lý thuyết. Nhưng họ gặp khó khăn khi cố gắng áp dụng nó vào thực tế: Làm thế nào để bạn thực sự xem xét hàng nghìn dòng mã do AI tạo ra? Làm thế nào để bạn giữ cho kiến trúc mạch lạc khi bạn làm việc trên nhiều công cụ AI trong nhiều tuần? Làm thế nào để bạn biết khi nào AI tự tin sai? Và không chỉ các nhà phát triển cấp dưới mới gặp khó khăn với kỹ thuật tác nhân. Tôi đã nói chuyện với các kỹ sư cấp cao gặp khó khăn với sự thay đổi sang các công cụ tác nhân, và các nhà phát triển trung cấp lại tiếp thu một cách tự nhiên. Sự khác biệt không nhất thiết là số năm kinh nghiệm; đó là liệu họ đã tìm ra một cách hiệu quả và có cấu trúc để làm việc với các công cụ mã hóa AI hay chưa. Khoảng cách giữa việc biết những gì các nhà phát triển nên làm với kỹ thuật tác nhân và biết cách tích hợp nó vào công việc hàng ngày của họ là một nguồn lo lắng thực sự cho rất nhiều kỹ sư hiện nay. Đó là khoảng cách mà loạt bài này đang cố gắng giải quyết. Mặc dù những lời cường điệu về kỹ thuật tác nhân (agentic engineering) đang lan truyền, loại hình phát triển này không loại bỏ nhu cầu về chuyên môn của nhà phát triển; mà ngược lại. Làm việc hiệu quả với các tác nhân AI thực sự nâng cao tiêu chuẩn về những gì nhà phát triển cần biết. Tôi đã viết về khoảng cách kinh nghiệm đó trong một bài viết trước đây trên O’Reilly Radar có tên “Nghịch lý lối tắt nhận thức” (The Cognitive Shortcut Paradox). Các nhà phát triển tận dụng tối đa công cụ mã hóa AI là những người đã biết phần mềm tốt trông như thế nào và thường có thể nhận ra liệu AI có phải là tác giả hay không. Ý tưởng rằng các công cụ AI hoạt động tốt nhất khi được các nhà phát triển có kinh nghiệm điều khiển phù hợp với mọi điều tôi đã quan sát. Điều đó nghe có vẻ đúng, và tôi muốn chứng minh nó theo cách mà các nhà phát triển khác sẽ hiểu: bằng cách xây dựng phần mềm. Vì vậy, tôi bắt đầu xây dựng một phương pháp tiếp cận cụ thể, thực tế đối với kỹ thuật tác nhân dành cho các nhà phát triển, và sau đó tôi đã thử nghiệm nó. Tôi đã sử dụng nó để xây dựng một hệ thống sản xuất từ đầu, với quy tắc rằng AI sẽ viết tất cả mã. Tôi cần một dự án đủ phức tạp để kiểm tra căng thẳng phương pháp tiếp cận, và đủ thú vị để giữ tôi gắn bó qua những phần khó khăn. Tôi muốn áp dụng mọi thứ mình đã học và khám phá những gì mình vẫn chưa biết. Đó là lúc tôi quay lại với các mô phỏng Monte Carlo. **Thử nghiệm** Tôi đã bị ám ảnh bởi các mô phỏng Monte Carlo từ khi còn nhỏ. Cha tôi là một nhà dịch tễ học – toàn bộ sự nghiệp của ông là tìm kiếm các mô hình trong dữ liệu dân số lộn xộn, điều đó có nghĩa là thống kê luôn là một phần trong cuộc sống của chúng tôi (và điều đó cũng có nghĩa là tôi đã học SPSS từ rất sớm). Khi tôi khoảng 11 tuổi, ông đã kể cho tôi nghe về bài toán người say rượu: Một thủy thủ rời quán bar trên bến tàu, mỗi lần bước ngẫu nhiên về phía nước hoặc về phía con tàu của mình. Anh ta có ngã xuống nước hay về nhà không? Bạn không thể biết từ bất kỳ lần chạy đơn lẻ nào. Nhưng chạy mô phỏng một nghìn lần, và mô hình sẽ xuất hiện từ nhiễu loạn. Kết quả cá nhân là ngẫu nhiên; tổng hợp là có thể dự đoán được. Tôi nhớ đã viết mô phỏng đó bằng BASIC trên chiếc TRS-80 Color Computer 2 của mình: một thủy thủ nhỏ bé, lảo đảo trên màn hình, hai bước tiến, một bước lùi. Người say rượu là “Hello, world” của các mô phỏng Monte Carlo. Monte Carlo là một kỹ thuật cho các vấn đề mà bạn không thể giải quyết bằng phân tích: Bạn mô phỏng chúng hàng trăm hoặc hàng nghìn lần và đo lường kết quả tổng hợp. Mỗi lần chạy riêng lẻ là ngẫu nhiên, nhưng các thống kê hội tụ về câu trả lời đúng khi kích thước mẫu tăng lên. Đó là một cách chúng ta mô hình hóa mọi thứ từ vật lý hạt nhân.