Tuần này timeline của mình bị chiếm bởi đúng một câu. Peter Steinberger viết ngày 7/6: "Bạn không nên prompt coding agent nữa. Bạn nên thiết kế những cái loop tự prompt agent giúp bạn." Câu đó cán mốc 2.2 triệu view, và phần reply biến thành một cái chợ vỡ — nửa số người gật gù như vừa được khai sáng, nửa còn lại bảo đây chỉ là cách gọi màu mè cho một vòng while.
Điều khiến mình dừng lại không phải con số view. Mà là hai ngày trước đó, Boris Cherny — người xây Claude Code — đã nói gần như y hệt trên sân khấu: "Mình không prompt Claude nữa. Mình có những cái loop đang chạy. Chính chúng mới là thứ prompt Claude và quyết định làm gì tiếp theo."
Khi cả người làm tool lẫn người dùng tool đầu bảng cùng nói một thứ trong cùng một tuần, mình thường không bỏ qua. Người ta đang gọi nó là loop engineering. Và mình ngồi nhận ra: mình vẫn đang ở thời "chat".
Cái mình tưởng là "dùng AI giỏi"
Suốt hơn một năm, định nghĩa "giỏi AI" trong đầu mình là: prompt khéo hơn. Context rõ hơn, ví dụ tốt hơn, biết lúc nào chia nhỏ task, biết hỏi lại thay vì ra lệnh. Mình thậm chí viết hẳn một bài về chuyện này.
Nhưng loop engineering nói một điều khó chịu hơn: prompt khéo tới đâu thì bạn vẫn là con người ngồi trong vòng lặp. Bạn gõ, chờ, đọc, gõ tiếp. Mỗi lần như vậy là một lần bạn phải có mặt. Cái trần năng suất của bạn chính là số giờ bạn ngồi trước màn hình.
Prompt khéo tới đâu thì bạn vẫn là con người ngồi trong vòng lặp — và cái trần năng suất chính là số giờ bạn chịu ngồi đó.
Cái dịch chuyển mà loop engineering nói tới không phải "prompt hay hơn". Nó là: thôi làm người prompt agent, trở thành người thiết kế cái hệ thống đi prompt agent. Bạn viết một chương trình nhỏ — nó mới là thứ nói chuyện với model. Model tụt từ vị trí "người cộng sự" xuống thành một hàm được gọi trong một vòng lặp chạy theo lịch, cho tới khi điều kiện dừng được thỏa mãn.
Nghe thì giống chuyện kỹ thuật. Nhưng đọc kỹ thì đây là chuyện về vị trí của mình trong công việc.
Chain không phải là loop
Chỗ này mình thấy nhiều người — gồm cả mình lúc đầu — lẫn lộn. Mình tưởng mình đã "làm loop" từ lâu rồi, vì mình có mấy cái script nối các bước AI lại với nhau. Nhưng cái đó là chain, không phải loop.
Một chain chạy các bước theo trình tự cố định: A → B → C. Bạn vạch sẵn con đường, model chỉ điền vào chỗ trống. Một loop thì động: agent act (làm gì đó), observe (đọc kết quả), reason (so với mục tiêu rồi quyết định), và repeat — quay lại bước trước, đổi cách tiếp cận, hoặc dừng. Nó không đi theo đường thẳng. Nó tự dò đường.
Chain hợp với việc đã biết hình dạng — pipeline rõ ràng, đầu vào đầu ra đoán được. Loop hợp với việc mở, lặp đi lặp lại, không biết trước cần bao nhiêu vòng: sửa cho tới khi test xanh, refactor cho tới khi không còn warning, dò một bug mơ hồ cho tới khi tái hiện được.
Và điều làm mình bất ngờ nhất khi đọc: tới giữa 2026, đây không còn là việc phải tự build từ đầu nữa. Các mảnh ghép đã nằm sẵn trong sản phẩm — trigger theo lịch, cô lập agent bằng git worktree để chúng không ghi đè lên nhau, skills (mấy folder có SKILL.md) để giữ kiến thức giữa các lần chạy, tách agent viết khỏi agent chấm điểm, connector qua MCP để với ra issue tracker hay Slack, và memory ghi xuống markdown/JSON để sống sót qua mỗi lần khởi động lại.
Đọc tới đoạn này mình thấy quen. Hồi mình mổ source bị leak của Claude Code, mình rút ra đúng những mảnh đó — memory, workflow, tools, automation. Hóa ra loop engineering chỉ là cái tên gọn cho việc ghép tất cả chúng lại và để máy tự quay vòng.
Cái khó không phải viết loop — là làm nó dừng
Đây là đoạn mình thích nhất, vì nó đập tan cái hype. Ai cũng nghĩ phần khó của loop engineering là kiến trúc. Không phải. Phần khó là làm sao cho nó dừng.
Một cái loop không có phanh là một tờ hóa đơn để ngỏ. Nó sẽ quay, quay nữa, đốt token trong lúc bạn đi ngủ. Bài viết mình đọc nói thẳng: cần ít nhất ba cái phanh cứng, không phải tùy chọn —
Một, trần số vòng lặp, để nó không quay vô tận. Hai, kiểm tra diff, để dừng khi thay đổi giữa các vòng đã chững lại — agent đang giậm chân tại chỗ thì cho nó nghỉ. Ba, giới hạn token/tiền, một con số cứng, chạm là cắt.
Con số làm mình rùng mình: Uber phải chốt trần chi tiêu AI ở mức 1.500 đô/tháng cho mỗi tool, sau khi vài đội đốt sạch ngân sách cả năm chỉ trong bốn tháng. Loop không làm bạn tốn tiền hơn. Nó chỉ làm cái tốc độ đốt tiền của bạn nhanh lên gấp nhiều lần — theo cả hai chiều.
Nhưng cái phanh mà mình nghĩ nhiều nhất lại không phải tiền. Bài viết gọi nó là comprehension debt — nợ thấu hiểu. Code ra nhanh hơn tốc độ bạn kịp hiểu nó. Khoảng cách đó tích lại thành một món nợ, và loop là cái máy phóng đại món nợ đó ở tốc độ máy.
Mình đã viết về đúng cảm giác này rồi, hồi nhận ra mình dùng AI sai cách: cái trực giác đọc code và biết ngay vấn đề ở đâu — nó mờ dần mà mình không hay. Hồi đó mình ngồi trong vòng lặp, mỗi vòng vài phút, nên ít ra còn kịp thấy. Một cái loop tự chạy qua đêm thì lấy luôn cả những phút đó.
Loop nhân lên cái taste của bạn
Có một câu trong bài làm mình ngồi im một lúc: "Một cái loop nhân lên bất cứ phán đoán nào bạn đặt vào cái rubric."
Nghĩ kỹ thì nó hơi đáng sợ. Khi bạn chat tay, gu thẩm mỹ kém của bạn chỉ làm hỏng một câu trả lời. Khi bạn để một loop chạy với cái rubric phản ánh gu kém đó, bạn đang nhân cái gu kém lên ở tốc độ máy. Loop không sửa được phán đoán tồi. Nó chỉ thực thi phán đoán đó, nhanh hơn, nhiều lần hơn.
Đây cũng là lý do người ta phân biệt open loop và closed loop. Open loop để agent tự chọn đường — linh hoạt tối đa, nhưng chi phí khó đoán và rất khó nhìn ra nó đang làm gì. Closed loop vạch sẵn toàn bộ lộ trình với các bước đánh giá rõ ràng — kém phiêu lưu, nhưng chi phí đoán được và rubric ổn định. Hầu hết thứ chạy được trong production là closed loop. Không phải vì nó thông minh hơn. Vì nó kiểm soát được.
Vài điểm mình không hoàn toàn đồng ý
Cái câu gốc — "đừng prompt nữa" — bán chạy vì nó tuyệt đối. Nhưng tuyệt đối thường là chỗ mình thấy gợn.
Với phần lớn việc mình làm hằng ngày, chat vẫn đúng. Một task mới, hình dạng còn mơ hồ, mình chưa biết mình muốn gì — đó là lúc cần ma sát của việc ngồi nghĩ cùng model, không phải một cái loop quay sẵn. Loop tỏa sáng ở việc lặp lại, có biên rõ, đã biết hình dạng. Đem loop đi giải một bài toán mình còn chưa hiểu thì mình chỉ tự động hóa sự bối rối của chính mình.
Và mình nghĩ cái khẩu hiệu này nguy hiểm với người mới. Nó nghe như: bỏ qua bước học prompt đi, nhảy thẳng lên thiết kế loop. Nhưng cái rubric mà loop chạy trên đó — điều kiện dừng, tiêu chí "đủ tốt", lúc nào thì retry — toàn bộ là kết tinh của taste. Mà taste thì chỉ đến từ những giờ ngồi trong vòng lặp, tay làm, mắt nhìn cái gì hỏng. Bạn không thể tự động hóa cái gu mà bạn chưa từng có.
Loop engineering không phải là bước nhảy qua giai đoạn ngồi chat. Nó là thứ bạn được phép làm sau khi đã ngồi đủ lâu để biết mình đang chấm điểm cái gì.
Nói vậy không phải để dìm. Mình thật sự nghĩ đây là hướng đúng, và tuần sau mình sẽ thử dựng một closed loop nhỏ cho cái việc nhàm nhất trong tuần của mình — dọn và gắn nhãn issue. Có ba cái phanh đầy đủ. Mình chỉ muốn nhắc bản thân: cái mình đang tự động hóa không phải là việc suy nghĩ. Mà là việc gõ.
Câu hỏi không phải bạn prompt hay bạn loop. Mà là bạn đã đủ taste để viết cái rubric mà loop sẽ chạy trên đó hay chưa.
Đọc thêm
- nguồn Loop Engineering: Should You Stop Prompting Agents and Start Designing Loopsfirecrawl.dev — bài phân tích mình dựa vào nhiều nhất
- nguồn What Hacker News Gets Right About AI Coding Agents in 2026developersdigest.tech — workflow & verification là nút thắt
- trên blog Tôi đọc source code bị leak của Claude Code12 patterns: memory · workflow · tools · automation
- trên blog RAG thông thường đang nói dối bạnkhi một vòng lặp có kiểm soát đổi cả kiến trúc
- trên blog Tôi đã dùng AI sai cách suốt gần một nămvề cái trực giác mờ dần — gốc của comprehension debt