Tech lead nào mình từng nói chuyện cũng đi qua cùng một hành trình adopt AI: bắt đầu bằng việc gõ prompt vào coding agent, rồi copy-paste lại prompt đó với vài chỉnh sửa nhỏ, rồi viết script tự động làm việc copy-paste đó thay mình. Bước cuối này giờ đã có tên gọi — Gergely Orosz gọi nó là loop engineering, và đáng để hiểu rõ trước khi team bạn tự phát minh lại nó theo kiểu vụng về.

Sự Dịch Chuyển, Gói Gọn Trong Một Câu

Boris Cherny ở Anthropic nói rất gọn: engineer đang chuyển từ viết prompt sang viết loop. Addy Osmani mô tả nó là “thay thế chính mình trong vai trò người prompt agent.” Thay vì bạn là con người đứng trong loop quyết định hỏi agent cái gì tiếp theo, bạn viết ra hệ thống tự quyết định điều đó — một goal, một điều kiện thành công, và một cơ chế cứ gọi lại agent cho đến khi điều kiện đó đạt được.

Ý tưởng chỉ có vậy. Nghe có vẻ hiển nhiên khi nói ra thành lời — mà đó thường là dấu hiệu của một dịch chuyển thật sự, chứ không phải buzzword.

Xuất Phát Từ Đâu

Pattern này bắt nguồn từ “Ralph Wiggum loop” của Geoffrey Huntley, công bố năm 2025 — đặt tên theo nhân vật trong Simpsons thành công nhờ sự lì lợm chứ không phải sự tinh vi. Cơ chế rất đơn giản:

1. Giao cho agent một task và một goal được định nghĩa rõ ràng
2. Bắt nó viết một work plan với success criteria tường minh
3. Chạy agent liên tục, sau mỗi lượt kiểm tra xem goal đã đạt chưa
4. Cho phép nó spawn subagent cho từng phần việc khi cần
5. Giữ state giữa các lượt chạy qua log và file plan được cập nhật

Cảnh báo của chính Huntley cũng quan trọng không kém kỹ thuật: “engineer vẫn cần thiết.” Một loop với goal định nghĩa tệ chỉ đơn giản là fail nhanh hơn và tốn kém hơn một prompt định nghĩa tệ.

Từ Hack Thành Tính Năng Native

Điều biến pattern này từ một workaround khéo léo thành một thực hành engineering thật sự là tooling bắt kịp. Trong khoảng sáu tuần mùa xuân năm nay, các coding harness lớn lần lượt ship native support cho đúng pattern này:

• Tháng 4/2026 — Codex ship lệnh /goal: một objective bền vững với điều kiện hoàn thành được định nghĩa rõ
• 2/5 — Hermes ship /goal riêng, dẫn nguồn cảm hứng từ Codex
• 12/5 — Claude Code ship /goal, bổ sung thêm cho lệnh /loop đã có sẵn cho scheduled task

Thứ trước đây phải tự viết bash script wrap quanh agent CLI giờ chỉ còn là một lệnh duy nhất. Đó mới là cái unlock thật sự — không phải một năng lực mới, mà là chi phí setup giảm mạnh — và đó là lý do adoption tăng vọt trong quý này.

Team Đang Thực Sự Dùng Nó Để Làm Gì

Các use case đang bám trụ lại không hề exotic. Chúng vẫn là những nhóm automation mà engineering team luôn muốn có, chỉ khác là giờ đầu bên kia là agent thay vì một script cố định:

• Fix theo trigger — một Sentry error nổ lên, loop mở draft PR trước cả khi engineer kịp nhìn issue (Ivan Pantić)
• Dọn flaky test — một engineer tạo ra 13 PR fix flaky test chỉ bằng một lần chạy /loop (Paul D’Ambra)
• Hỗ trợ incident response — loop triage và soạn sẵn fix trong lúc on-call engineer còn đang bị page (Ivan Abad)
• Chạy cải tiến theo lịch — cron job hàng ngày đọc log 24 giờ gần nhất và ship các fix nhỏ cho product (Jack D)
• Trông coi test qua đêm — E2E test chạy đêm được tự động chẩn đoán và vá lỗi trước giờ standup (Utku K)
• Migration lớn — một migration React sang React Native tiến triển nhờ loop chạy theo cron mỗi 30 phút (Rafel Mendiola)

Để ý pattern chung: không cái nào thay thế judgment. Chúng thay thế cái việc lặp đi lặp lại nhàm chán — nhận ra có việc cần làm và re-prompt agent để làm.

Góc Nhìn Hoài Nghi Đáng Để Lắng Nghe

Không phải ai cũng tin đây là điều mới. Câu phản biện sắc nhất đến từ Director Oded Messer: “nếu workflow chiến lược của tôi automatable được thì hoặc nó trở thành tactical vì AI đủ năng lực, hoặc nó chỉ là automation kiểu cũ ở tầm cao.” Nói cách khác: đây là webhook và cron job gắn thêm LLM — và những team vốn đã có automation tốt sẽ thấy đây không phải bước nhảy vọt gì lớn, so với những team chưa có gì.

Max Kanat-Alexander đi xa hơn, cho rằng loop có thể chỉ là scaffold tạm thời — một workaround cho giới hạn context window, và sẽ phần lớn biến mất khi harness giỏi hơn trong việc xử lý goal dài hạn native. Lúc đó “loop engineering” như một kỹ năng riêng biệt sẽ lặng lẽ không còn là thứ bạn cần biết nữa.

Cả hai lời phê bình đều chỉ vào cùng một rủi ro thật: agent drift. Một loop với điều kiện thành công mơ hồ không fail ồn ào — nó âm thầm đốt token và tạo ra output nghe có vẻ hợp lý nhưng sai, lặp đi lặp lại, không ai giám sát, cho đến khi có người để ý đến hóa đơn hoặc mấy cái PR tệ.

Một Khung Ra Quyết Định, Không Phải Một Mệnh Lệnh

Nếu bạn là tech lead đang cân nhắc đưa loop engineering vào team, câu hỏi không phải “có nên dùng loop không” — mà là “automation nào hiện có của team nên trở thành loop, và phiên prompt thủ công nào nên trở thành automation.” Cụ thể:

1. Điều kiện thành công có kiểm tra được bằng máy không? Test pass, build thành công, lint rule sạch — ứng viên tốt. “Nhìn có ổn không” — chưa phải lúc, vẫn cần giữ con người trong loop.
2. Task này hôm nay đã lặp lại chưa? Nếu bạn đang prompt agent cho cùng một nhóm fix ba lần một tuần, đó là tín hiệu để viết loop, không phải viết thêm prompt mới.
3. Blast radius nếu nó chạy không giám sát qua đêm là gì? Fix flaky test trên feature branch: rủi ro thấp, loop đầu tiên tốt. Bất cứ thứ gì đụng đến production data hay auth: giữ human gate trước khi merge, bất kể loop trông tốt thế nào lúc test.
4. Bạn có visibility về token budget không? Loop nhân số lần gọi agent lên nhiều lần. Nếu bạn chưa track cost theo từng PR hay từng fix, bạn sẽ phát hiện ra theo cách đau ví nhất.

Việc Cần Làm Tuần Này

Đừng bắt đầu loop engineering như một chiến lược. Bắt đầu từ task AI thủ công lặp lại gây khó chịu nhất của team — cái mà ai đó cứ vài ngày lại chạy lại cùng một prompt với chỉnh sửa nhỏ — và biến đúng một task đó thành một lần chạy /goal với điều kiện thành công tường minh, kiểm tra được. Đo kết quả nó tạo ra trong một tuần trước khi tin tưởng để nó chạy không giám sát.

Tooling đã bắt kịp đủ nhanh để chi phí setup không còn là cái cớ nữa. Phần judgment về việc cái gì xứng đáng có một loop vẫn hoàn toàn nằm ở bạn — và đó mới thực sự là công việc của tech lead, y như nó vẫn luôn là vậy.