“LOOP ENGINEERING” LÀ GÌ, VÀ TẠI SAO CÙNG GỌI LÀ LOOP NHƯNG MỖI NGƯỜI LẠI NÓI MỘT THỨ KHÁC NHAU?

 “LOOP ENGINEERING” LÀ GÌ, VÀ TẠI SAO CÙNG GỌI LÀ LOOP NHƯNG MỖI NGƯỜI LẠI NÓI MỘT THỨ KHÁC NHAU?

Dạo gần đây trong giới AI và Software Engineering bắt đầu xuất hiện khá nhiều khái niệm như “Loop Engineering”, “Loopcraft”, “Ralph Loop”. Boris Cherny của Anthropic thậm chí từng chia sẻ đại ý rằng ổng không còn ngồi prompt Claude từng bước nữa, mà viết các loop để chúng tự làm việc.

Nghe thì có vẻ đơn giản, nhưng vấn đề là chữ “Loop” đang được dùng cho nhiều thứ rất khác nhau. Có người nói Loop chỉ việc Claude tự sửa code rồi chạy test. Người khác lại đang nói tới hệ thống AI có thể tự đọc backlog, tìm việc cần làm, code, review rồi tiếp tục xử lý việc tiếp theo.

Laurie Voss, đồng sáng lập npm, đã thử bóc tách Loop Engineering thành nhiều tầng khác nhau (mình để link bài viết gốc dưới comment). Ở bài viết này, mình sẽ lấy 1 ví dụ cụ thể để anh em có thể tiếp cận với các khái niệm được bóc tách dễ hơn: Sửa 1 cái bug log in.

1. Execution Loop: AI tự tìm cách làm task

Ở tầng đơn giản nhất, mình prompt cho AI: “Fix bug login này”. AI có thể tự chạy một vòng:

đọc code → sửa code → chạy test → thấy fail → đọc lỗi → sửa tiếp → test lại

Đây chắc là thứ khá nhiều anh em làm dùng Claude Code, Cursor hay các coding agent hiện nay.

Câu hỏi mà tầng này giải quyết là: “Task này phải làm như thế nào?” Scope vẫn khá nhỏ, chỉ là các bước bên trong một task. Với có 1 vấn đề quen thuộc là agent đôi khi xác nhận xong task, dù code thực tế vẫn chưa chạy được nên phải cần người ngồi QC rồi fix tiếp.

2. Task Loop: không tin AI nói xong, bắt kết quả chứng minh là xong

Zoom ra thêm một tầng, thay vì để một session AI chạy mãi (bị loop liên tục) với context ngày càng dài, hệ thống có thể liên tục đưa cùng một spec cho các agent với context mới:

Spec → Agent → Code → Test

Nếu chưa đạt:

Spec → Agent mới → Code tiếp → Test

Vòng này chỉ dừng khi có điều kiện rõ ràng như:

Unit test pass
Integration test pass
Acceptance criteria đạt
Artifact đúng với spec

Lúc này cái loop giúp giải quyết vấn đề: “Task này đã thực sự hoàn thành chưa?”

Đây cũng là lý do khi dùng coding agent, spec và test/eval ngày càng quan trọng. Nếu muốn AI tự chạy, trước tiên phải định nghĩa được thế nào mới tính là “xong”.

3. Product Loop: AI bắt đầu tham gia vào cả workflow phát triển phần mềm

Khi này bug login đã được AI sửa xong. AI không nhất thiết phải dừng ở đó mà có thể tiếp tục:

đọc backlog/codebase → tìm việc cần làm → lên kế hoạch → code → test → review → tạo PR → tiếp tục

Scope bây giờ đã không còn là một file hay một feature nữa, mà mở rộng ra codebase, backlog và cả SDLC. Câu hỏi loop này trả lời được mở rộng ra từ 1 task thành: “Tiếp theo hệ thống cần làm gì?”

Đây là tầng khá gần với cách Boris Cherny mô tả workflow của mình. Ông từng chia sẻ về các agent chạy liên tục, có agent tìm cách cải thiện architecture, có agent tìm những abstraction bị trùng để hợp nhất rồi tự gửi pull request. AI lúc này không chỉ làm một task được giao, mà có thể chủ động tìm việc trong phạm vi codebase. Đây cũng là chỗ những khái niệm kiểu Software Factory bắt đầu xuất hiện.

4. System Loop: cải thiện chính hệ thống AI đang làm việc

Đây là tầng dễ nhầm với Product Loop nhất. Nếu AI liên tục refactor code, sửa bug hay cải thiện architecture của sản phẩm thì vẫn là Product Loop. System Loop chỉ xuất hiện khi thứ được cải thiện là chính hệ thống agent.

Ví dụ một coding agent đang dùng Claude + system prompt A + một bộ tools nhất định. Một System Loop có thể thử:

Prompt A → benchmark
Prompt B → benchmark
Model khác → benchmark
Tool hoặc agent harness khác → benchmark

Sau đó dựa trên eval để giữ lại configuration tốt hơn.

Nói ngắn gọn: Product Loop tối ưu sản phẩm - System Loop tối ưu “nhà máy AI” đang tạo ra sản phẩm.

Câu hỏi loop sẽ giải quyết ở tầng này là: “Làm sao để chính agent hoạt động tốt hơn?”

5. Oversight Loop: con người quyết định AI nên làm gì

Dù AI có thể sửa code, hoàn thành task, xử lý backlog hay tự cải thiện chính nó, vẫn còn một tầng cao hơn cần con người quyết định - hay còn gọi là Oversight Loop. Giải quyết các vấn đề:

Feature này có đáng làm không?
Nên ưu tiên reliability hay thêm feature?
Cho agent dùng bao nhiêu budget?
Workflow này đang chạy sai hướng thì có nên dừng không?
AI được quyền tự quyết tới đâu?

Có thể tóm lại sơ đồ bên dưới như sau:

Execution Loop: Làm task này thế nào?
Task Loop: Task được giao đã thực sự xong (chạy được) chưa?
Product Loop: Xong task này rồi, tiếp theo làm gì?
System Loop: Làm sao để agent code tốt hơn?
Oversight Loop: Mục tiêu là gì, AI được phép đi xa tới đâu?

Điểm mình thấy thú vị nhất trong cách nhìn này là Loop Engineering không đơn giản là cho AI chạy lặp đi lặp lại 1 tác vụ. Thứ thực sự được thiết kế là feedback, điều kiện dừng và mức độ tự chủ ở từng tầng.

Chiếu với workflow hiện tại của anh em thì mọi người đang ở loại loop nào rồi? Mình đoán đa số các team dự án lớn đã bắt đầu giao spec + test để AI tự chạy tới khi đạt yêu cầu rồi ha.