Loop Engineering

Phần 1: Lý thuyết. Loop Engineering là gì

1.1. Từ một câu nói gây bão

Giữa năm 2026, một câu nói của Boris Cherny, người đứng đầu Claude Code tại Anthropic, lan truyền khắp cộng đồng lập trình:

“Tôi không còn prompt cho Claude nữa. Tôi có các loop đang chạy, chúng tự prompt cho Claude và tự quyết định việc cần làm. Công việc của tôi là viết loop.”

Peter Steinberger, người sáng lập OpenClaw, nói gọn hơn nhưng cùng ý: “Bạn không nên prompt coding agent nữa. Bạn nên thiết kế các loop để prompt agent của mình.”

Chỉ trong một tuần, “loop engineering” đi từ một cụm từ chưa ai dùng thành chủ đề nóng nhất trong giới AI coding. Nhưng nó thực sự là gì?

1.2. Định nghĩa

Loop engineering là việc thiết kế một hệ thống tự vận hành AI agent theo vòng lặp khép kín, thay vì con người ngồi gõ prompt cho từng lượt tương tác.

Cơ chế cốt lõi rất đơn giản: nhận mục tiêu, thực thi, tự kiểm chứng, chưa đạt thì lặp lại, đạt rồi thì dừng và báo cáo.

Ẩn dụ dễ hình dung nhất: nếu prompt engineering là bạn ngồi lái xe, thì loop engineering là bạn thiết kế hệ thống autopilot. Bạn không còn điều khiển từng khúc cua. Bạn định nghĩa điểm đến, đặt luật giao thông, rồi xây cơ chế để hệ thống tự điều chỉnh khi lệch hướng.

1.3. Phả hệ khái niệm. Đây không phải bước nhảy đột ngột

Loop engineering là điểm đến mới nhất của một chuỗi tiến hóa kỹ năng làm việc với AI:

Mỗi tầng không xóa bỏ tầng trước, nó xây trên nền tầng trước. Loop engineering vẫn cần prompt tốt, context tốt, harness tốt. Cái mới là lớp tự động hóa bọc bên ngoài: loop có thể tự chạy theo lịch, tự tìm việc để làm, và tự quyết định khi nào xong mà không cần con người bấm nút ở mỗi bước.

1.4. Vì sao bùng nổ đúng vào lúc này

Hai điều kiện phải cùng xảy ra thì loop engineering mới khả thi, và cả hai vừa mới chín muồi.

Thứ nhất, model đủ mạnh để chạy dài mà không lạc hướng. Một năm trước, để agent tự chạy quá vài phút mà không giám sát gần như chắc chắn dẫn đến việc nó đi lệch mục tiêu. Các model thế hệ mới có thể duy trì một phiên làm việc 30 đến 60 phút, tự kiểm tra lại công việc nhiều lần, mà vẫn bám sát yêu cầu ban đầu.

Thứ hai, chi phí xây dựng loop sụp đổ. Trước đây, muốn có một loop tự động, người ta phải tự viết và bảo trì cả một đống script bash, công cụ “của riêng ai nấy dùng”. Nay các khối xây dựng cơ bản (lịch chạy, điều kiện dừng, agent con, môi trường làm việc cách ly) đã được tích hợp sẵn trong các công cụ như Claude Code và Codex. Ý tưởng về vòng lặp tự động không mới, kỹ thuật này đã tồn tại trong ngành phần mềm hàng chục năm dưới dạng cron job và CI/CD pipeline. Cái thực sự mới là chi phí thực hiện nó đã giảm mạnh, và quan trọng hơn: worker bên trong loop giờ đây xử lý được sự mơ hồ, thứ mà một script cron truyền thống không bao giờ làm được.

1.5. Giải phẫu một loop hoàn chỉnh

Một loop được thiết kế đúng cách gồm các thành phần sau.

Mục tiêu định lượng được. Đây là điều kiện tiên quyết quan trọng nhất. “Hãy cải thiện tính năng giỏ hàng” không phải là mục tiêu dùng được cho loop. “15 test case trong cart.spec.ts phải pass” mới là mục tiêu loop có thể tự kiểm tra được.

Công cụ thực thi được cấp quyền. Agent cần quyền đọc code, chạy lệnh, gọi API, nhưng chỉ trong phạm vi cần thiết (nguyên tắc least privilege).

Cơ chế kiểm chứng (verification). Đây là khối quan trọng nhất, và cũng là chủ đề chính của bài viết này. Một nguyên tắc vàng trong thiết kế loop là không để model tự chấm bài của chính nó, điểm số sẽ bị thổi phồng một cách hệ thống. Loop tốt tách vai trò “người viết” (maker) và “người kiểm tra” (checker) thành hai tiến trình độc lập.

Điều kiện dừng chặt chẽ. Gồm giới hạn số vòng lặp tối đa, ngân sách token hoặc chi phí cứng cho mỗi lần chạy, và cơ chế phát hiện “không tiến triển”: nếu qua vài vòng mà output không đổi, dừng lại và báo cáo thay vì lặp vô hạn.

Cổng phê duyệt của con người (human gate). Việc nằm trong phạm vi an toàn thì agent có thể tự commit; việc rủi ro cao hoặc mơ hồ thì phải dừng lại, báo cáo đầy đủ ngữ cảnh, và chờ người quyết định.

1.6. Hai tầng vòng lặp cần phân biệt

Andrew Ng, trong một bức thư gửi cộng đồng vào cuối tháng 6/2026, mở rộng khái niệm loop engineering thành các tầng có chu kỳ khác nhau. Ở đây ta tập trung vào hai tầng gần với công việc kỹ thuật hằng ngày.

Vòng lặp lập trình (agentic coding loop), chu kỳ vài phút. Cho trước một đặc tả và một bộ evals (tức một tập dữ liệu dùng để đo hiệu năng, đây chính xác là từ Ng dùng), agent viết code, tự kiểm tra, và tiếp tục lặp lại đến khi không còn lỗi và đạt đặc tả. Đây là tầng lặp nhanh nhất, chạy nhiều lần trong một phiên làm việc.

Cần lưu ý một điểm để tránh nhầm lẫn khi đọc tiếp Phần 2: đây không phải một khái niệm “evals khác” so với phần sẽ trình bày sau. Nó vẫn là evals, chỉ khác về quy mô áp dụng. Ở đây, bộ evals gắn với một đặc tả cụ thể đang được xây trong một loop, có thể chỉ gồm vài ca. Ở Phần 2 và Phần 3, evals được dùng ở quy mô rộng hơn: một bộ theo dõi lâu dài, chạy định kỳ, dùng để so sánh model hoặc quy trình qua thời gian. Bản chất khái niệm là một, không phải hai.

Vòng lặp phản hồi của người phát triển, chu kỳ hàng giờ. Con người xem xét sản phẩm hiện tại và điều hướng agent cải thiện tiếp. Một quan sát đáng chú ý: trước đây, nhiều lập trình viên phải tự đóng vai kiểm thử viên cho chính agent của họ, tự tay tìm lỗi rồi yêu cầu agent sửa. Nhưng khi agent có khả năng tự kiểm tra công việc của mình tốt hơn, gánh nặng đó giảm đi đáng kể, giải phóng con người để tập trung vào các quyết định cấp cao hơn: tính năng nào nên có, trải nghiệm người dùng ra sao.

Điểm cốt lõi cần giữ lại: chừng nào con người còn biết điều gì đó về bối cảnh sử dụng mà AI không biết (gọi là “lợi thế ngữ cảnh”) thì con người vẫn cần hiện diện trong vòng lặp để bơm tri thức đó vào hệ thống. Loop engineering không loại bỏ con người, nó dịch chuyển con người lên tầng quyết định cao hơn.

1.7. Hai giới hạn không thể bỏ qua

Chi phí token tăng phi tuyến. Vì mỗi vòng lặp gửi lại toàn bộ lịch sử hội thoại tích lũy, chi phí tăng theo cấp số nhân so với số vòng, không phải cộng dồn tuyến tính. Các phép đo từ nhiều nguồn độc lập cho thấy agent đơn tiêu tốn khoảng 4 lần token so với một cuộc trò chuyện thông thường, và hệ thống nhiều agent phối hợp có thể lên tới 15 lần. Một chi tiết đáng lưu ý: những người truyền bá mạnh nhất cho loop engineering đều làm việc trong môi trường ngân sách token gần như không giới hạn, điều đó không đúng với phần lớn tổ chức.

Chất lượng bị giới hạn bởi bộ kiểm chứng, không phải bởi model. Nhận định sắc bén nhất về giới hạn của loop engineering là: cái quyết định loop có dùng được cho một loại công việc hay không, không phải là model mạnh đến đâu, mà là có viết được một bộ tiêu chí kiểm chứng đáng tin cậy cho công việc đó hay không. Công việc nào có tiêu chí đúng sai rõ ràng (test tự động, benchmark) thì loop hoạt động tốt. Công việc nào phụ thuộc vào phán đoán chủ quan (thẩm mỹ giao diện, “đúng ý khách hàng”) thì loop dễ thất bại hoặc nguy hiểm vì không ai kiểm tra được nó đã “xong” thật hay chưa.

Đây chính là lý do phần tiếp theo của bài viết dành trọn vẹn cho khái niệm evals, công cụ duy nhất giải quyết được giới hạn thứ hai này.

Phần 2: Evals là gì, và vì sao nó không phải là test case (nhưng cũng không hoàn toàn khác)

2.1. Vì sao cần một khái niệm riêng ngoài “test case”

Câu hỏi tự nhiên của bất kỳ ai làm QA khi nghe về loop engineering là: “Tôi đã có test case rồi, sao còn cần evals?”

Câu trả lời nằm ở đối tượng bị đo lường. Test case truyền thống trả lời câu hỏi: “Đoạn code này chạy đúng không?” Evals trả lời một câu hỏi khác hẳn: “Cách tôi đang dùng AI để tạo ra đoạn code này có đang tạo ra kết quả tốt một cách ổn định không?”

Nghe qua có vẻ giống nhau, nhưng khác biệt then chốt nằm ở chỗ: code là deterministic (chạy lại vẫn ra kết quả y hệt), còn AI thì không. Cùng một prompt, chạy hai lần, agent có thể đưa ra hai cách giải khác nhau, một cách đúng hoàn toàn, một cách đúng chức năng nhưng vi phạm quy tắc khác. Test case đơn lẻ không đo được sự bất định này. Evals sinh ra chính để đo lường một hệ thống có tính bất định.

2.2. Bảng so sánh trực tiếp

2.3. Evals giống test case ở điểm nào

Mối quan hệ đúng nhất không phải là “hai thứ tách biệt” mà là: test case là một loại nguyên liệu có thể nằm bên trong evals.

Lấy một ví dụ cụ thể: có một test case “đơn hàng dưới 3.000¥ thì phí ship là 500¥”. Test case này đóng hai vai trò khác nhau tùy ngữ cảnh sử dụng.

Trong một quy trình TDD thông thường, nó là hợp đồng để chấm điểm code: agent phải viết code làm test này chạy pass. Pass là xong việc.

Khi được đưa vào một bộ evals, chính test case đó trở thành một ca trong bộ đề thi để chấm agent: agent giải ca này mất bao nhiêu vòng lặp để đạt pass? Nó có tự ý sửa file nằm ngoài phạm vi được giao không? Nếu đổi sang một model rẻ hơn, agent có còn giải được ca này không?

Nói theo cách dễ hình dung: nếu test case giống một câu hỏi thi, thì evals giống toàn bộ kỳ thi cộng với bảng điểm được theo dõi qua nhiều kỳ, bao gồm đề thi (bộ ca mẫu, trong đó có cả các test case quen thuộc), ba-rem chấm điểm (không chỉ đúng sai chức năng mà cả tuân thủ quy tắc, chi phí, có “lách” đề bài hay không), và bảng so sánh kết quả giữa các “thí sinh”: model A so với model B, prompt cũ so với prompt mới.

Đây không phải suy luận riêng của bài viết. Chính đội ngũ kỹ thuật của Anthropic, trong tài liệu hướng dẫn nội bộ về xây evals cho AI agent, mô tả một eval nhiều lượt cho agent lập trình như sau: agent nhận công cụ, một nhiệm vụ và một môi trường, thực thi vòng lặp gồm gọi công cụ và suy luận, rồi cập nhật môi trường bằng phần triển khai của nó, sau đó việc chấm điểm chính là chạy các unit test để xác nhận sản phẩm hoạt động đúng. Nói cách khác, unit test không đứng ngoài evals, nó thường chính là công cụ chấm điểm nằm bên trong.

2.4. Ba điều evals bao quát mà test case đơn lẻ không có

Chấm cả những thứ nằm ngoài đúng/sai chức năng. Một agent có thể làm test pass hoàn toàn nhưng đồng thời tự ý sửa lây sang file không được giao, vi phạm quy ước code, hoặc tệ hơn: “lách” qua được tiêu chí thay vì thực sự giải quyết vấn đề (ví dụ hard-code giá trị mong đợi thay vì viết logic thật). Test case không bắt được các lỗi này; một bộ chấm điểm evals thiết kế đúng thì có.

Kết quả dạng tỷ lệ và xu hướng, không phải một lần pass/fail. Vì AI không cho kết quả giống hệt nhau mỗi lần chạy, phải chạy cùng một ca nhiều lần để có một con số đủ tin cậy, ví dụ “70% số lần chạy agent giải trọn vẹn ca này” thay vì một kết luận pass/fail duy nhất.

Mục đích cuối cùng là ra quyết định quản trị, không phải chặn một lần merge. Test case trả lời “code này có được merge không”. Evals trả lời những câu hỏi lớn hơn: model nào nên dùng cho loại việc nào, quy trình nào đang hiệu quả hơn, module nào an toàn để giao cho AI và module nào bắt buộc phải có người review toàn phần.

2.5. Chu trình vận hành evals trong thực tế

Kỷ luật vận hành evals, theo quan sát của Andrew Ng, là yếu tố dự báo thành công lớn nhất khi một tổ chức triển khai AI agent, quan trọng hơn cả kỹ thuật viết prompt. Chu trình này rất đời thường:

1. Nhìn output thật: xem lại một loạt ca agent đã xử lý gần đây, không chỉ tin vào cảm giác “nó chạy được rồi”.
2. Phát hiện lỗi lặp lại: ví dụ agent hay quên cập nhật test khi đổi interface, hay dùng thư viện ngoài danh sách được duyệt.
3. Biến lỗi lặp lại thành một tiêu chí đo được. Có hai cách chấm: khách quan (một script tự động đếm được, ví dụ kiểm tra xem có dùng thư viện bị cấm không) và chủ quan (dùng một mô hình khác đóng vai giám khảo chấm chất lượng, chính là nguyên tắc tách vai người viết và người kiểm tra).
4. Đưa phát hiện ngược trở lại hệ thống: cập nhật tài liệu quy ước, sửa prompt, rồi chạy lại đúng bộ ca cũ để xác nhận điểm số có cải thiện hay không.

Sai lầm phổ biến nhất khi bắt đầu là cố xây một bộ evals quá lớn và quá đẹp ngay từ đầu, rồi bỏ dở vì nặng. Cách làm đúng là bắt đầu nhỏ, vài chục ca, chấm bán thủ công cũng được, miễn là chạy đều đặn và có người thật sự nhìn vào kết quả.

Phần 3: Hướng đi cho một QA. Xây bộ evals và phát triển một tính năng

3.1. Vì sao đây là bước chuyển tự nhiên, không phải một cú nhảy nghề nghiệp

Nhìn lại phần giải phẫu loop ở Phần 1: khối quan trọng nhất quyết định một loop có an toàn và hiệu quả hay không là verification, cơ chế kiểm chứng. Và toàn bộ tư duy đằng sau khối này chính là tư duy của một người làm kiểm thử phần mềm lâu năm.

Nói cách khác: xây bộ evals không phải là học một kỹ năng hoàn toàn mới đối với một QA giàu kinh nghiệm. Nó là việc nâng đối tượng áp dụng của những kỹ năng đã có, từ chấm phần mềm sang chấm AI, cộng thêm thói quen ghi nhận và so sánh kết quả một cách có hệ thống qua thời gian.

3.2. Bài tập cụ thể: xây evals cho tính năng “Áp dụng coupon khi thanh toán”

Để một QA hình dung được công việc thật, dưới đây là một tính năng điển hình cho dự án offshore, với đủ business logic, edge case và cả góc bảo mật.

Quy tắc nghiệp vụ của tính năng: coupon giảm 10% hoặc số tiền cố định, có ngày hết hạn, có đơn tối thiểu. Mỗi coupon dùng được một lần cho mỗi khách hàng. Không được cộng dồn hai coupon trong cùng một đơn.

Bước 1. Thiết kế bộ ca mẫu theo bốn nhóm rủi ro

Đây chính là bước một QA đóng góp giá trị lớn nhất, vì nó đòi hỏi tư duy “nghĩ ra được những cách hệ thống có thể sai”, kỹ năng cốt lõi của nghề kiểm thử.

Bước 2. Viết một ca mẫu cụ thể, kèm ba-rem chấm điểm

Lấy ca “coupon hết hạn đúng hôm nay” làm ví dụ. Đề bài giao cho agent: coupon “SUMMER26” hết hạn vào 22/07/2026. Khách hàng áp coupon lúc 23:59 ngày 22/07/2026. Xác nhận theo quy tắc nghiệp vụ, coupon còn hiệu lực trong suốt ngày hết hạn hay không (quy tắc: hết hạn nghĩa là không dùng được từ ngày hôm sau trở đi). Sửa lại logic trong module coupon nếu cần. Chạy bộ test để xác nhận.

Ba-rem chấm điểm ca này không chỉ dừng ở “test có pass hay không”, đây chính là điểm phân biệt evals với test case đơn thuần:

1. Test tự động có chạy pass hay không.
2. Agent có tự viết thêm một test case biên mới để phòng ngừa lỗi tái diễn, hay chỉ sửa code cho vừa đủ qua bài kiểm tra hiện có. Tiêu chí này phân biệt agent thực sự hiểu vấn đề với agent chỉ “vá tạm”.
3. Agent có tuân thủ đúng phạm vi được giao (chỉ sửa trong module coupon) hay không.

Bước 3. Chạy nhiều lần, trên nhiều lựa chọn model, và đọc bảng kết quả

Chạy bộ mười ca như trên với hai lựa chọn model (một rẻ, một đắt), mỗi ca lặp lại vài lần để loại trừ yếu tố ngẫu nhiên. Kết quả tổng hợp có thể cho một bức tranh như sau (số liệu minh họa):

Bước 4. Biến bảng điểm thành quyết định

Đây là phần khác biệt lớn nhất so với việc chỉ “chạy test cho vui”: bảng điểm này cho phép ra quyết định vận hành có căn cứ. Model rẻ đủ dùng cho các tác vụ đơn giản, nhưng tỷ lệ hỏng cao ở nhóm bảo mật cho thấy các module chạm đến logic thanh toán, coupon, xác thực nên bắt buộc review toàn phần của con người, không được giao hoàn toàn cho AI với model rẻ. Đây là loại kết luận có số liệu đứng sau, thay vì một quy định chung chung không ai giải thích được vì sao.

3.3. Con đường phát triển nghề nghiệp gợi ý

Từ bài tập trên, có thể hình dung một lộ trình phát triển hai giai đoạn cho một QA muốn dịch chuyển sang làm việc cùng AI agent.

Giai đoạn đầu là người thiết kế ca mẫu và ba-rem: áp dụng đúng kỹ năng đã có, nghĩ ra các tình huống edge case và bảo mật, viết tiêu chí chấm điểm rõ ràng cho từng ca. Đây là công việc không đòi hỏi biết lập trình sâu, chỉ cần hiểu rõ nghiệp vụ và có tư duy “tìm cách phá hệ thống” quen thuộc của nghề QA.

Giai đoạn sau là người vận hành chu trình evals liên tục: không chỉ xây một lần rồi thôi, mà duy trì việc chạy định kỳ, đọc bảng điểm, phát hiện lỗi lặp lại, và đề xuất cập nhật vào tài liệu quy ước hoặc thay đổi cách phân công công việc giữa người và AI. Đây chính là vai trò kết nối trực tiếp giữa chất lượng sản phẩm và hiệu quả sử dụng AI, một vị trí có giá trị ngày càng tăng khi tổ chức mở rộng việc dùng agent.

Điểm mấu chốt cần nhớ: trong một thế giới nơi ai cũng có thể yêu cầu AI viết code, người biết thiết kế được bộ tiêu chí đáng tin để đánh giá code đó mới là người tạo ra lợi thế cạnh tranh thực sự. Đó chính xác là kỹ năng một QA giỏi đã rèn luyện từ trước, chỉ cần áp dụng đúng đối tượng.

Phần 4: Kết luận. Chúng ta có nên áp dụng Loop Engineering không?

Chưa nên áp dụng Loop Engineering đầy đủ (loop tự chạy theo lịch, tự hành động mà không cần người giám sát từng bước). Nên áp dụng ngay phần nền của nó: TDD-first kết hợp context tốt và evals. Chỉ nên pilot loop ở phạm vi rất hẹp, và chỉ chạy ở chế độ báo cáo (không tự hành động).

Nói ngắn gọn: chưa nên dùng loop, nhưng nên dùng ngay những thứ làm nên một loop tốt.

Vì sao chưa nên dùng loop đầy đủ

Có ba lý do đủ để chặn quyết định này lại, ít nhất ở thời điểm hiện tại.

Thứ nhất, công ty không có “đặc quyền token” như những người đang truyền bá loop. Cherny (Anthropic) và Steinberger (OpenAI) xây dựng và tinh chỉnh cách làm này trong môi trường ngân sách token gần như vô hạn. Với một công ty quy mô trăm người, chi phí tăng phi tuyến của loop (tăng theo cấp số nhân so với số vòng lặp) là rủi ro tài chính thật, không phải chuyện lý thuyết, nhất là khi mô hình offshore vốn đã nhạy cảm với chi phí vận hành.

Thứ hai, điều kiện quan trọng nhất chưa có: một bộ verifier đáng tin. Nút thắt thực sự của loop không nằm ở model mạnh hay yếu, mà ở việc có viết được tiêu chí kiểm chứng đủ tin cậy để “bỏ đó cho nó tự chạy” hay không. Công ty chưa có bộ evals trưởng thành, chưa có kinh nghiệm vận hành chu trình đo lường liên tục. Chạy loop khi chưa có verifier tốt nghĩa là nhân bản lỗi nhanh hơn, không phải làm việc nhanh hơn.

Thứ ba, rủi ro an toàn thông tin chưa có bộ kiểm soát tương xứng. Loop nghĩa là agent có quyền đọc source code, chạy lệnh, tự commit, trong lúc không ai giám sát trực tiếp.

Vì sao nên dùng ngay phần nền

TDD-first kết hợp context tốt và evals tạo ra phần lớn giá trị năng suất mà loop hứa hẹn, nhưng an toàn hơn nhiều, vì ba lý do.

Verifier chạy miễn phí: test tự động không tốn token cho mỗi lần “chấm bài”, khác với sub-agent verifier trong loop luôn tốn thêm chi phí model. Con người vẫn có mặt trong mỗi phiên làm việc, nên không có chuyện agent chạy một mình không ai biết, và vì vậy gần như không cần xây thêm bộ kiểm soát an toàn thông tin mới. Và quan trọng nhất: chính bộ test và bộ evals xây ở giai đoạn này là tài sản mà dự án có thể tái sử dụng.