Loops thay thế Prompt Engineering — vì sao mọi coder AI đều sẽ phải viết loop, không phải prompt

Prompt engineering không chết — nó chỉ bị đẩy xuống làm tầng nhỏ nhất trong một stack mới: loop engineering. Anthropic vừa publish bài chính thức từ team Claude Code, định nghĩa loop là “agent lặp chu kỳ công việc cho tới khi đạt điều kiện dừng”, và phân loại thành 4 loại theo trigger và stop criteria. Bài viết này không phải review nội dung — mà là phân tích vì sao cách tiếp cận này thay đổi luôn cách một engineer viết code.

Table of contents

Bối cảnh: từ prompt tới loop trong 3 tuần

Tháng 6/2026, ba engineer từ ba công ty khác nhau — Peter Steinberger (OpenClaw, giờ ở OpenAI), Boris Cherny (head of Claude Code tại Anthropic), và Addy Osmani (Google Chrome team) — độc lập đăng cùng một luận điểm trong vòng một tuần:

“Bạn không nên prompt coding agent nữa. Bạn nên thiết kế loop prompt nó.”

Boris Cherny diễn đạt thẳng hơn:

“Tôi không còn prompt Claude. Tôi có loop chạy nền, chúng tự prompt Claude và tự quyết định phải làm gì. Việc của tôi là viết loop.”

Bài từ Anthropic publish ngày 6/7/2026 — đúng một tuần sau khi loop engineering trở thành meme — là lời đáp chính thức: “Loop là gì, theo chúng tôi, và dùng nó như thế nào”. Quan trọng nhất không phải định nghĩa — mà là primitive nào trong Claude Code ship 4 loại loop khác nhau, và cái nào hợp với task nào.

Định nghĩa từ team Claude Code: loop là gì?

Một loop là một agent lặp lại chu kỳ công việc cho tới khi đạt một điều kiện dừng. Loop được phân loại theo 4 chiều: cách trigger, cách dừng, primitive nào của Claude Code được dùng, task type nào phù hợp.

Có 4 loại loop chính thức, xếp theo độ tự chủ tăng dần:

Để ý hai chi tiết kỹ thuật quan trọng:

Một — /goal không phải “Claude tự quyết khi nào xong”. Sau mỗi turn, một evaluator model riêng (mặc định là Haiku — model nhỏ và nhanh) check điều kiện dừng mà user đặt ra. Nếu chưa đạt, evaluator gửi kèm lý do, Claude quay lại làm tiếp. Tách biệt worker và judge là kiến trúc, không phải prompt.

Hai — /schedule chạy trên cloud Anthropic, không phải máy bạn. Tắt laptop vẫn chạy. /loop thì ngược lại — chạy local, session-scope, tắt terminal = chết loop.

Tại sao prompt engineering là tầng nhỏ nhất, không phải tầng cao nhất

Một coder quen prompt sẽ tự hỏi: “Tôi đã viết prompt đủ tốt, sao loop?” Sự thật là loop dùng prompt, không thay thế. Phân tầng từ dưới lên:

Tầng 1 — Prompt: Một câu lệnh đơn gửi tới Claude. Claude làm một thứ, trả lời, dừng. Tốt cho task one-off.

Tầng 2 — Skill: Một file SKILL.md chứa instruction set cố định. Bất kỳ loop nào cũng có thể gọi skill như subroutine. Skill chính là cách “tái sử dụng prompt thông minh”.

Tầng 3 — Loop: Một vòng lặp quanh Claude. Mỗi tick, loop gọi Claude (có thể qua skill), check output, quyết định continue / retry / stop / escalate. Đây là nơi hầu hết giá trị production nằm.

Tầng 4 — Routine: Loop + cloud scheduling + state persistence. Chạy mà không cần bạn. Đây là cấp “tôi đi ngủ, tỉnh dậy PR đã merge”.

Boris Cherny mô tả 3 giai đoạn trong sự nghiệp của anh:

Sự dịch chuyển: từ viết prompt → chạy session → thiết kế hệ thống tự chạy. Cùng một dòng “làm cho AI viết code” nhưng tầng abstraction đã đi lên 3 cấp.

Cú chốt: verifier phải tách khỏi worker

Đây là phần hay nhất của bài Anthropic, và là phần hầu hết người dùng loop bỏ qua.

Khi bạn bảo Claude “viết code rồi tự kiểm tra”, Claude sẽ khen chính nó. Đây không phải vấn đề về model — đó là vấn đề cấu trúc. Một agent không nên làm gà kiêm công việc gà kiểm, vì nó thiếu động lực và góc nhìn tỉnh táo.

Pattern đúng:

Worker model viết code. Một verifier model riêng — thường là model nhỏ, nhanh, prompt-engineered cứng — check output có đạt spec không. Nếu không, verifier trả lý do về cho worker. Loop chỉ dừng khi verifier ra “yes” hoặc hết turn cap.

/goal implement chính xác pattern này. Bạn viết condition, evaluator riêng check nó. Worker không có quyền tự dừng.

Tác giả bài loop engineering paper (Addy Osmani) gọi đây là “the part everyone skips” — và đúng. Loop không có verifier là “token furnace tự tin” — đốt tiền mà ship bug.

Ví dụ cụ thể: build-test-fix loop

Pattern được demo nhiều nhất trong cộng đồng. Hai agent:

• Builder: Viết code, sửa code
• Checker: Chạy test, typecheck, lint. Trả về chính xác cái gì fail.

Hai agent pass work qua lại tới khi mọi check pass. Toàn bộ pitch là giảm đau: agent one-shot ship bug của chính nó mà không biết.

Anthropic từng nói trong buổi chia sẻ nội bộ: “Verification skills — những skill check xem work có thành công không — tạo ra sự khác biệt lớn nhất cho chất lượng output, so với mọi thứ chúng tôi từng thử.”

Một verification skill tốt không phải là “tell Claude to check its work”. Một verification skill tốt là:

• Chạy test cụ thể (pytest, npm test)
• Parse output, biết chính xác khi nào pass
• Trả lời binary: pass/fail + lý do
• Được encode lại thành file SKILL.md để loop nào cũng dùng được

Đây là chỗ “cost shift” mà bài từ O’Reilly ghi nhận: token per call rẻ, nhưng cost của việc quản lý loop runaway thì đắt. Loop không có verification hợp lý sẽ đốt $200-$500 cho một task dở dang.

Token cost: chỗ nhiều người tự bắn vào chân

Có một sự thật mà Anthropic không giấu nhưng cũng không hét to: mỗi turn trong loop đều tốn token, và loop thiết kế để không dừng. Nếu loop chạy qua 200 turn trên một task open-ended, token cost có thể lên tới $26/tasks (theo estimate từ OpenAI researcher Noam Brown, chia sẻ đầu tháng 7).

Boris Cherny thừa nhận thẳng:

“Nếu nghe có vẻ đắt, thì đúng là nó đắt. Nhưng Anthropic bán token, nên calculus của model provider không giống calculus của người dùng.”

Đây không phải disqualifier. Nó là lý do bạn phải thiết kế loop cẩn thận. Bài Anthropic liệt kê 6 cách kiểm soát:

1. Chọn primitive + model phù hợp: task nhỏ không cần Opus 4.8. Dùng Haiku cho routine, Sonnet cho judgment.
2. Define rõ success + stop criteria: cụ thể thay vì “improve this code”.
3. Pilot trước khi scale: dynamic workflows có thể spawn hàng trăm agent. Test trên slice nhỏ trước.
4. Dùng script cho deterministic work: form-filling PDF chạy script rẻ hơn reasoning.
5. Đừng chạy routine thường xuyên quá cần: match interval với tốc độ thay đổi của nguồn.
6. Review usage thường xuyên: /usage breakdown theo skills, subagents, MCPs.

Quên một trong sáu thứ này, loop sẽ đốt tiền không kiểm soát.

Khi nào KHÔNG nên dùng loop

Addy Osmani, người đặt tên “loop engineering”, có một quote rõ ràng:

“Không phải task nào cũng xứng đáng có loop. Trước khi build bất cứ thứ gì, chạy nó qua 4 câu hỏi:

1. Có lặp lại không?
2. Có finish line rõ ràng không?
3. Cost có biết trước không?
4. Tự check được output không?

Nếu thiếu một trong bốn, đừng ép nó vào loop. Làm bằng tay hoặc prompt bình thường vẫn tốt hơn.”

Anthropic đồng tình trong bài chính thức:

“Không phải task nào đều cần loop phức tạp. Hãy bắt đầu với giải pháp đơn giản nhất và dùng các pattern này có chọn lọc.”

Đây là lý do recipe bắt đầu bằng “First-time draft from raw transcript” trong skill authoring mình đang giữ — không phải mọi thứ đều nên loop hoá. Một bài blog một lần, một bug fix nhanh, một experiment research — đều không cần loop.

Áp dụng: nếu bạn đang xài Claude Code, bắt đầu từ đâu?

Bài Anthropic đưa ra một checklist gọn:

Pick một task bạn đang làm bottleneck. Hỏi: phần nào bạn có thể hand off? Có viết được verification check không? Goal đủ rõ không? Work đến theo schedule không?

Sau khi có ý tưởng, chạy loop, quan sát kết quả — nó stall ở đâu, nó over-reach ở đâu? Đừng sợ iterate.

Nếu bạn mới bắt đầu với loop, 3 move tối thiểu:

1. Chạy build-test-fix pair dưới dạng /loop để có thứ gì đó measurably improve trong khi bạn quan sát.
2. Chạy five-minute repository maintainer dưới dạng /loop trong khi bạn làm việc khác.
3. Chạy overnight PR routine dưới dạng /schedule để sáng dậy PR đã xong.

Give mỗi cái một budget và một verifier. Đó là một working loop stack cho ngày mai.

TL;DR

• Loop = agent lặp chu kỳ công việc cho tới khi đạt điều kiện dừng. Anthropic vừa định nghĩa chính thức thành 4 loại: turn-based, goal-based (/goal), time-based (/loop + /schedule), proactive.
• Prompt engineering không chết — nó trở thành tầng nhỏ nhất trong stack: Prompt → Skill → Loop → Routine.
• Verifier phải tách khỏi worker. /goal implement pattern này: evaluator model riêng check stop criteria sau mỗi turn. Worker không có quyền tự dừng.
• Token cost là vấn đề thật — loop thiết kế để không dừng, 200 turn có thể tốn $26/task. Phải có budget, iteration cap, và stop criteria cụ thể.
• Không phải task nào cũng cần loop. Chỉ loop khi: lặp lại, có finish line rõ ràng, cost biết trước, tự check được output. Thiếu một trong bốn → làm tay.
• Bắt đầu với 3 move tối thiểu: build-test-fix loop, five-minute maintainer, overnight PR routine. Mỗi cái cần một budget và một verifier.

Tham khảo

• Nguồn gốc: ClaudeDevs (@ClaudeDevs) — Getting started with loops (X Article, 2026-07-06) https://x.com/ClaudeDevs/status/2074208949205881033
• Official guide: Getting started with loops — https://claude.com/blog/getting-started-with-loops
• Loop Engineering — paper gốc: Addy Osmani — Loop Engineering (2026-06-08) — thuật ngữ + 6 building blocks chính thức
• Quote gốc về shift: Boris Cherny (WorkOS Acquired Unplugged, 2026-06-02): “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”
• Bài liên quan: The Future of Work (Acquire This Skill Stack) — Dan Koe, thedankoe.com — phân tích tại sao meta-skill quan trọng hơn technical skill
• Concept liên quan: Outer Harness — Tại sao Process và Data quan trọng hơn Agent — bài trên blog này về việc tooling xung quanh agent quan trọng hơn chính agent