AWS Hydro: dùng compiler làm lưới chắn cho lỗi của AI coding agent

Khi agent viết phần lớn code, review của con người không theo kịp

Hydro là một framework Rust mã nguồn mở cho hệ phân tán, do nhóm Hydro của AWS phát triển cùng UC Berkeley. Điều đáng chú ý trong câu chuyện mà nhóm kể tại hội nghị AGNTCon + MCPCon ở San Jose (Mỹ) không phải là một tính năng mới, mà là cách nhóm làm việc đã thay đổi: theo bài gốc của The New Stack đăng ngày 29/10/2026, coding agent hiện viết phần lớn code của Hydro, với con người đóng vai trò dẫn dắt.

Hệ quả trực tiếp là các pull request (PR) đến nhanh hơn và lớn hơn nhiều so với trước. Shadaj Laddad, research lead của nhóm Hydro tại AWS, mô tả một thay đổi gần đây là "giống như một PR 5000 dòng". Thay đổi đó liên quan tới một cơ chế mới để kiểm tra rằng hệ phân tán vẫn hoạt động đúng khi nó gửi lại message sau một lần thất bại.

Với một công cụ mà lập trình viên dựa vào để bắt bug, một PR 5000 dòng là bài toán review không nhỏ. Và theo lập luận của Laddad trong keynote, code review của con người đơn giản là không thể bắt kịp tốc độ agent viết code.

Compiler như một vùng tin cậy tách khỏi agent

Vấn đề mà nhóm Hydro đặt ra khá cụ thể: nếu agent vừa viết code vừa viết unit test, thì test không còn là bằng chứng độc lập rằng code đúng. Trong phần lớn workflow dùng agent hiện nay, chính agent sinh ra cả hai thứ đó. Laddad nói: "Agent rất giỏi, nhưng chúng khó đoán định" — sự khó đoán đó nuôi dưỡng tính sáng tạo, nhưng đồng thời khiến con người khó kiểm chứng test do agent viết.

Đề xuất của ông là đặt các kiểm tra tính đúng đắn ở một nơi nằm ngoài "vùng tin cậy" của agent, ví dụ ở tầng compiler. Ông lấy borrow checker của Rust làm ví dụ quen thuộc: nó bắt được race condition trước khi code chạy. Hydro làm điều tương tự cho hệ phân tán, phát hiện một số loại bug ngay ở thời điểm biên dịch để agent nhận phản hồi tức thì.

Điểm mấu chốt về mặt kỹ thuật: khi lỗi bị bắt ở compile time, agent có một tín hiệu rõ ràng, máy đọc được, để sửa — thay vì phải chờ tới runtime hoặc chờ người review phát hiện. Đây cũng là lý do nhóm chọn hướng này thay vì chỉ tăng cường test.

Laddad cũng đặt vấn đề trong bối cảnh rộng hơn: liệu có thể xây dựng những guardrail theo từng domain mà nhiều agent có thể dùng chung. Nhóm đang nghiên cứu các dự án lịch sử để tìm những pattern lặp lại. Một ví dụ là idempotency — đảm bảo một request bị gửi lại không được thực thi hai lần — vốn xuất hiện thường xuyên trong các buổi design review. Câu hỏi nhóm đặt ra là liệu nó có thể trở thành một guardrail tổng quát hay không.

Cách Laddad đóng khung vấn đề mang tính lịch sử: compiler từng giúp lập trình viên khỏi tự làm hỏng lời gọi hàm khi viết assembly (C), rồi giúp bỏ bớt gánh nặng cấp phát bộ nhớ (Java). Theo ông, đây là nấc tiếp theo trên cùng một cái thang đó.

Infinity: runtime cho agent, và một con số đáng chú ý

Bên cạnh Hydro, nhóm còn xây dựng Infinity, một agent runtime mã nguồn mở mà AWS công bố ngày 23/10. Infinity có thể tạm dừng (suspend) một agent trong lúc nó chờ một tool call hoặc một job CI. Cơ chế này hướng tới các hệ chạy nhiều agent đồng thời, nơi phần lớn thời gian agent chỉ ngồi chờ.

Laddad dẫn một benchmark với 75.000 agent chạy đồng thời trên một chiếc Raspberry Pi duy nhất. Con số này được ngoại suy từ một bài test trên server, trong đó mỗi agent ở trạng thái idle dùng khoảng 100 KB. Cần nhấn mạnh đây là kết quả benchmark do nhóm công bố, không phải một phép đo độc lập trên workload thực tế.

Vì sao đáng quan tâm với người làm DevOps & Cloud

Với người làm hạ tầng và vận hành hệ phân tán, câu chuyện của Hydro chạm đúng một nỗi đau quen thuộc: bug trong hệ phân tán thường không lộ ra khi test từng thành phần, mà lộ khi các thành phần được ghép lại với nhau. Laddad diễn đạt điều này khá gọn: "Bạn có thể làm cho tính năng chạy tốt khi đứng một mình, rồi trộn nó với thứ khác, và đột nhiên các đảm bảo bị phá vỡ."

Đây cũng là lý do PR 5000 dòng kia khó chia nhỏ: các thành phần của nó phụ thuộc lẫn nhau, nên tách ra thì mất chính cái tính chất cần kiểm tra. Với các team đang đưa agent vào pipeline phát triển, bài học rút ra không phải "đừng dùng agent", mà là cần thiết kế điểm kiểm tra ở nơi agent không tự sinh ra và tự chấm.

Ở góc độ vận hành, Infinity đáng để theo dõi nếu bạn đang cân nhắc chạy nhiều agent song song cho các tác vụ CI/CD hoặc automation hạ tầng. Việc suspend agent khi chờ I/O là hướng tối ưu hợp lý về mặt tài nguyên, và con số 100 KB mỗi agent idle cho thấy tiềm năng mật độ khá cao — nhưng hãy coi đó là điểm khởi đầu để tự đo trên workload của mình.

Với các team viết service độ trễ thấp, thông lượng cao bằng Rust, Hydro là một lựa chọn đáng thử nếu nỗi lo chính là bug phân tán. Cần lưu ý đây là bản phát hành sớm: bài gốc nói rõ nên kỳ vọng còn rough edge và có learning curve.

Ai nên thử, và thử thế nào

Hydro phù hợp nhất với các nhóm đang xây service phân tán bằng Rust, đặc biệt khi họ muốn các đảm bảo về tính đúng đắn được kiểm tra ở compile time thay vì phát hiện muộn trên production. Nhóm chưa sẵn sàng chuyển sang Rust, hoặc hệ thống nhỏ chưa gặp vấn đề phân tán, có thể chưa thấy nhiều lợi ích ngay.

Cả Hydro và Infinity đều là mã nguồn mở, được giới thiệu tại hydro.run. Bài gốc không nêu lệnh cài đặt cụ thể hay yêu cầu phiên bản Rust, nên bước đầu tiên hợp lý là đọc tài liệu trên trang chính thức và xem repo trước khi đưa vào thử nghiệm. Với Infinity, hãy bắt đầu bằng một pipeline nhỏ, đo mức tiêu thụ bộ nhớ khi agent chờ tool call hoặc job CI, rồi mới mở rộng độ song song.

Giới hạn cần nhớ

Compiler không phải viên đạn bạc. Theo bài gốc, code Rust do AI sinh ra có thể biên dịch hoàn hảo mà vẫn sai — The New Stack từng đề cập điều này trong một bài hồi tháng 8. Nói cách khác, guardrail ở compile time bắt được một lớp lỗi, không bắt được tất cả. Các đảm bảo mà Hydro cung cấp cũng chỉ bao phủ những loại bug mà framework mô hình hóa được.

Ý tưởng về guardrail dùng chung theo domain vẫn đang trong giai đoạn nghiên cứu, chưa phải sản phẩm hoàn chỉnh. Còn với Hydro, đây là bản phát hành sớm, nên kỳ vọng về độ chín và tài liệu cần đặt ở mức thực tế.

Điều đáng giữ lại từ câu chuyện này khá đơn giản: khi agent viết ngày càng nhiều code, giá trị của những kiểm tra mà agent không thể tự tạo ra và tự đánh giá sẽ tăng lên. Phần thưởng mà Laddad mô tả là sự tự tin để thay đổi một hệ thống mà không sợ nó vỡ vài tháng sau đó — với người vận hành hệ phân tán, đó là mục tiêu đáng theo đuổi.

Nguồn: The New Stack