Kỹ thuật vòng lặp (loop engineering) đang trở thành một xu hướng nổi bật. Lướt qua bất kỳ diễn đàn kỹ thuật nào, bạn cũng sẽ thấy những ý kiến tranh luận rằng chúng ta nên ngừng coi các tác nhân AI như những chatbot cần được huấn luyện bằng các câu lệnh (prompt) khéo léo. Thay vào đó, họ cho rằng chúng ta nên thiết kế các vòng lặp: những chu kỳ tự trị cho phép một tác nhân lập kế hoạch, thực thi, tự kiểm tra công việc và lặp lại trong khi chúng ta đang ngủ. Lời đề nghị này nghe rất hấp dẫn. Nếu vòng lặp được xây dựng tốt, tác nhân sẽ đi đúng hướng mà không cần sự giám sát liên tục của con người, biến ý định ban đầu thành kết quả hoàn chỉnh chỉ sau một đêm.
Lời hứa đó hoạt động rất tuyệt vời trên lý thuyết. Trong thực tế, hầu hết các tác nhân đã đang chạy vòng lặp rồi. Chúng tạo mã, kiểm tra lỗi trình biên dịch hoặc lỗi kiểm thử, vá mã và chạy lại bộ kiểm thử. Chu kỳ phản hồi cơ bản đó không có gì mới. Những gì những người ủng hộ đang kêu gọi hiện nay là một thứ tham vọng hơn: một vòng lặp bên ngoài (outer loop) quản lý toàn bộ tác vụ, chứ không chỉ là các lỗi cú pháp. Xây dựng vòng lặp bên ngoài đó là nơi mọi thứ trở nên khó khăn, bởi vì kỹ thuật phần mềm hiếm khi là một hệ thống đóng với các quy tắc cố định.
Vấn đề thiết kế vòng lặp
Các mục tiêu sản phẩm thường rất hỗn loạn. Bạn hiếm khi bắt đầu với một định nghĩa hoàn hảo về trạng thái hoàn thành (definition of done). Thông thường, bạn sẽ khám phá ra mục tiêu thực sự khi đang dấn thân sâu vào quá trình xây dựng. Một yêu cầu nghe có vẻ đơn giản trên bảng trắng hóa ra lại có những trường hợp biên (edge cases) làm thay đổi hoàn toàn hình thái của giải pháp. Khi bạn bao bọc một tác nhân bên trong một vòng lặp cứng nhắc, sự cứng nhắc đó sẽ trở thành một điểm yếu. Vòng lặp cứ tiếp tục đập vào một mục tiêu có thể là sai lầm. Tệ hơn, một vòng lặp linh hoạt đôi khi giải quyết sự bế tắc bằng cách âm thầm thay đổi mục tiêu để khớp với bất kỳ kết quả nào mà nó tạo ra được. Cả hai kết quả đều không hữu ích. Một cái gây lãng phí tài nguyên tính toán; cái còn lại thì tự tin bàn giao những thứ rác rưởi.
Vấn đề sâu xa hơn là chi phí đặc tả (specification cost). Nếu bạn muốn một vòng lặp chạy mà không cần giám sát, bạn phải viết một bản đặc tả dự đoán được gần như mọi thứ. Chính xác thì tác nhân nên thay đổi điều gì? Hành vi hiện tại nào là bất biến và phải được giữ nguyên? Trong những điều kiện chính xác nào thì tác nhân nên ngừng lặp lại? Những rủi ro nào là có thể chấp nhận được, và những tác dụng phụ nào sẽ kích hoạt việc dừng lại ngay lập tức? Việc viết tài liệu đó có thể mất nhiều thời gian hơn là việc ngồi cùng tác nhân và điều hướng nó thực hiện tác vụ trong thời gian thực. Bạn đang phải trả một khoản "thuế" trả trước rất lớn để đổi lấy sự tự động hóa mà chỉ thực sự có lợi nếu việc xác minh rẻ hơn đáng kể so với việc thực hiện.
Nơi các vòng lặp thực sự phát huy giá trị
Điều đó không có nghĩa là kỹ thuật vòng lặp là vô dụng. Nó có nghĩa là đây là một công cụ chuyên dụng, không phải là một chiến lược vạn năng. Các vòng lặp tỏa sáng khi chi phí xác minh tăng lên theo cấp số nhân và các tiêu chí thành công là rõ ràng. Có ba trường hợp mà điều này thường đúng.
Các công việc cơ học lặp đi lặp lại. Hãy nghĩ về những tác vụ khiến các kỹ sư dày dạn kinh nghiệm muốn nghỉ hưu: khởi động các ứng dụng theo một trình tự cụ thể, nhấp qua giao diện triển khai để xác nhận từng giai đoạn, grep nhật ký để tìm các chuỗi lỗi đã biết sau khi phát hành, hoặc xác nhận rằng một tệp cấu hình đã được ghi vào tất cả các nút (nodes) chính xác. Những bước này rất tẻ nhạt đối với con người nhưng lại cực kỳ dễ xác minh. Một vòng lặp có thể "trông nom" quá trình này, kiểm tra các điểm cuối sức khỏe (health endpoints) sau mỗi lần khởi động lại và thực hiện hoàn tác (rollback) ngay khi có dấu hiệu bất thường đầu tiên. Con người vẫn là bên xác định kế hoạch triển khai. Vòng lặp chỉ đơn giản là thực hiện nó với sự kiên nhẫn của một cỗ máy vào lúc hai giờ sáng.
Các mục tiêu tối ưu hóa có thể đo lường được. Khi thành công được định nghĩa bằng một con số, các vòng lặp tỏ ra hiệu quả một cách đáng kinh ngạc. Giảm độ trễ p99 xuống dưới 150 mili giây. Giảm mức chiếm dụng bộ nhớ xuống 20%. Chuyển đổi một luồng xử lý quan trọng (hot path) từ Python sang Rust và đảm bảo tất cả các bài kiểm thử đơn vị hiện có vẫn vượt qua. Vòng lặp có thể tạo ra một thay đổi, đo lường hiệu năng (benchmark), giữ lại biến thể mang lại kết quả tốt nhất và loại bỏ phần còn lại. Vì việc xác minh đã được tự động hóa và không gian tìm kiếm là rất lớn, nên chi phí tích lũy của việc xem xét thủ công sẽ khiến công việc này trở nên bất khả thi nếu không có vòng lặp. Mục tiêu là cố định. Con đường là chưa biết. Đó chính là điểm giao thoa lý tưởng.
Các kịch bản vận hành (playbooks). Việc ứng phó sự cố và các phiếu hỗ trợ (support tickets) thường tuân theo các mô hình mà con người đã nắm rõ. Một loại lỗi sản xuất cụ thể luôn yêu cầu xoay vòng thông tin xác thực và xóa bộ nhớ đệm. Một danh mục yêu cầu hỗ trợ có thể được giải quyết bằng cách hoàn tiền khi đáp ứng đủ ba điều kiện cụ thể. Một vòng lặp có thể theo dõi các tác nhân kích hoạt đó và thực hiện kịch bản, chỉ leo thang (escalate) khi mô hình bị phá vỡ. Nó không quyết định rằng kịch bản đó là đúng; nó chỉ đơn thuần thực thi sự nhất quán với quy mô và tốc độ mà các kỹ sư trực chiến (on-call) không thể sánh kịp.
Những người điều tiết, không phải người thiết lập tham chiếu
Có một sự phân biệt quan trọng đang bị bỏ qua trong phần lớn các cuộc thảo luận hiện nay. Các vòng lặp là những bộ điều tiết. Chúng giữ cho một hệ thống luôn bám sát một mục tiêu đã định trước, giống như cách máy điều nhiệt giữ cho căn phòng ở mức 72 độ. Nhưng máy điều nhiệt không tự chọn con số 72 đó. Trước đó, phải có ai đó quyết định rằng đó mới là nhiệt độ phù hợp.
Áp dụng vào phần mềm, điều này có nghĩa là một agent bên trong một vòng lặp có thể sửa lỗi, tái cấu trúc các hàm, hoặc tinh chỉnh các tham số suốt cả ngày. Tuy nhiên, nó không thể quyết định tính năng nào thực sự giúp ích cho khách hàng hoặc liệu một lỗi có đáng để sửa trước bản phát hành tiếp theo hay không. Những lựa chọn đó đòi hỏi sự phán đoán về ngữ cảnh kinh doanh, những khó khăn của người dùng và các ưu tiên chiến lược. Agent thực thi. Con người quyết định. Việc nhầm lẫn giữa hai điều này chính là lý do khiến các đội ngũ cuối cùng lại sở hữu những hệ thống được tối ưu hóa một cách tuyệt vời nhưng lại giải quyết sai vấn đề.
Kỹ thuật vòng lặp (loop engineering) rất hữu ích, nhưng phạm vi của nó khá hẹp. Nó giúp bạn vận hành cỗ máy một cách kỷ luật và tốc độ. Nó không quyết định xem nên xây dựng cỗ máy nào, cỗ máy đó dành cho ai, hay thành công trông như thế nào dưới góc độ con người. Việc phán đoán xem tính năng nào là quan trọng, rủi ro nào là có thể chấp nhận được, và khi nào bản thân mục tiêu cần phải thay đổi sẽ nằm ở chính bạn. Hãy xây dựng các vòng lặp cho những công việc mà bạn đã hiểu rõ đến mức có thể xác minh chúng một cách tự động. Hãy giữ quyền kiểm soát đối với tất cả những việc còn lại.
Bài viết này dựa trên những ý tưởng được thảo luận ban đầu bởi Isaac Hagoel trong “Loop Engineering Minus The Hype.” Để tham gia thêm các thảo luận về kỹ thuật, hãy gia nhập cộng đồng học tập của chúng tôi trên Telegram.