Contents
Chào mừng bạn đến với Fx Studio. Khi bạn thôi “sai vặt” AI từng câu lệnh và bắt đầu thiết kế hệ thống tự lặp – bốn kiểu vòng lặp, giải thích bằng nồi cơm điện, GPS và robot hút bụi. Và chủ đề hôm nay là Bắt đầu với Loop Engineering.
Bắt đầu thôi!
Mở đầu: nồi cơm điện và bếp củi
Hãy bắt đầu bằng một câu hỏi tưởng như chẳng liên quan: nồi cơm điện khác bếp củi ở chỗ nào?
- Với bếp củi, bạn phải ngồi canh. Lửa to quá thì bớt củi, nước cạn thì hạ lửa, ngửi thấy mùi khê thì nhấc xuống ngay. Bạn là người ra quyết định ở từng bước.
- Với nồi cơm điện, bạn chỉ làm một việc: vo gạo, đổ nước, bấm nút. Cái nồi tự biết khi nào cơm chín — nhiệt độ vượt 100°C nghĩa là nước đã cạn — và tự chuyển sang chế độ giữ ấm.
Điều thú vị là: nồi cơm điện không “thông minh” hơn bạn. Nó chỉ được thiết kế sẵn một điều kiện dừng mà ai đó đã nghĩ hộ bạn từ trước.
Làm việc với AI coding agent cũng đang đi qua đúng bước chuyển đó. Giai đoạn đầu, chúng ta prompt từng câu — “sửa cái này”, “chạy test đi”, “chưa đúng, làm lại” — tức là ngồi canh bếp củi. Giai đoạn tiếp theo, thứ mà cộng đồng đang gọi là loop engineering, là lúc bạn ngừng canh lửa và bắt đầu thiết kế cái nồi: định nghĩa trước mục tiêu, cách kiểm tra và điều kiện dừng, rồi để agent tự lặp cho đến khi đạt.
Nghe thì hoành tráng, nhưng “loop” thực ra không phải một thứ duy nhất. Có nhiều kiểu loop khác nhau, mỗi kiểu hợp một loại việc, và sai lầm phổ biến nhất là dùng loop phức tạp cho việc đơn giản. Bài này đi qua bốn kiểu loop từ đơn giản đến phức tạp, kèm sơ đồ để bạn hình dung mỗi kiểu “sống” thế nào trong công việc thật.
- Màu da cam : con người
- Màu xanh: Agent hoặc hệ thống
Loop Engineering (Loop) là gì, nói cho dễ hiểu?
Một loop, ở dạng trần trụi nhất, là: lặp lại việc làm và kiểm tra, cho đến khi đạt điều kiện dừng.
Cái làm nên sự khác biệt giữa các kiểu loop nằm ở ba câu hỏi:
- Ai/cái gì khởi động vòng lặp? Bạn gõ prompt? Đồng hồ? Một sự kiện bên ngoài?
- Điều kiện dừng là gì và ai kiểm tra nó? Bạn nhìn bằng mắt? Một bộ test? Một model khác?
- Bạn đã “bàn giao” phần nào cho hệ thống?
Câu hỏi thứ ba là chìa khóa của cả bài. Mỗi kiểu loop tương ứng với việc bạn giao bớt một mảnh trách nhiệm cho máy. Giao càng nhiều, bạn càng rảnh tay — nhưng cũng càng cần thiết kế cẩn thận, vì máy sẽ làm đúng cái bạn định nghĩa, chứ không phải cái bạn mong trong đầu.
Kiểu 1: Turn-based loop – vòng lặp bạn đang dùng mà không để ý
bàn giao: bước kiểm tra (khi có skill) · bạn giữ: prompt + quyết định dừng
Đây chính là thứ xảy ra mỗi lần bạn gõ một prompt cho coding agent. Đằng sau một câu lệnh, agent chạy một chu trình nhỏ: đọc ngữ cảnh → sửa code → tự kiểm sơ bộ → báo “xong”. Vòng lặp tồn tại, nhưng bạn chính là điều kiện dừng: agent nói xong, còn xong thật hay không thì bạn phải mở app lên bấm thử.
Ví dụ minh họa
Bạn nhờ agent: “Thêm nút Quên mật khẩu vào màn hình đăng nhập.” Agent báo xong. Bạn build app, bấm thử — nút có đấy, nhưng crash vì thiếu route. Bạn gõ tiếp: “Bấm vào bị crash, sửa đi.” Lần này chạy, nhưng nút lệch trên iPhone SE. Bạn lại gõ… Ba vòng như vậy, và ở cả ba vòng, người ngồi bấm thử là bạn.
Cách nâng cấp: bàn giao bước kiểm tra
Nâng cấp quan trọng nhất ở tầng này không phải prompt hay hơn, mà là viết quy trình kiểm tra của bạn ra thành văn bản để agent tự làm thay. Trong Claude Code, chỗ để làm việc này là các file skill (SKILL.md) — về bản chất là một tờ checklist agent bắt buộc làm theo trước khi được phép báo “xong”:
# Skill: kiểm tra thay đổi giao diện Trước khi báo hoàn thành bất kỳ thay đổi UI nào: 1. Build và mở app lên (simulator / browser). 2. Tương tác trực tiếp với control vừa thêm — bấm thử, nhập thử, không chỉ nhìn. 3. Kiểm tra console: không được xuất hiện lỗi MỚI nào. 4. Chụp screenshot ở màn hình nhỏ nhất và lớn nhất. Chỉ khi cả 4 bước xanh mới được kết luận "hoàn thành".
Mẹo: check càng định lượng, agent càng tự kiểm được. “Giao diện phải đẹp” là check mà máy chịu chết. “Console không có lỗi mới”, “test pass 100%”, “load < 2 giây” … là những check máy tự xác nhận được.
Kiểu 2: Goal-based loop – bàn giao điều kiện dừng
bàn giao: điều kiện dừng · bạn giữ: định nghĩa goal + trần ngân sách
Vấn đề của kiểu 1: agent tự chấm bài của chính nó, và nó chấm khá… rộng lượng — giống sinh viên tự chấm bài thi của mình. Goal-based loop giải quyết bằng cách tách đôi:
- Bạn định nghĩa trước “xong” trông như thế nào, và một evaluator riêng biệt (model khác, ngữ cảnh sạch) kiểm tra điều kiện đó mỗi khi agent định dừng.
- Chưa đạt — evaluator đẩy agent quay lại làm tiếp, cho đến khi đạt goal hoặc chạm trần số lần thử. Trong Claude Code, cơ chế này là lệnh
/goal.
Hãy nghĩ về nó như GPS trên ô tô. Bạn không chỉ đường từng ngã rẽ — bạn nhập đích đến một lần. Đi sai đường? GPS không bỏ cuộc, nó “recalculating” và tìm lối khác, lặp cho đến khi bạn tới nơi. Cái bạn bàn giao cho GPS là việc liên tục đối chiếu vị trí hiện tại với đích.
Ví dụ minh họa
Module thanh toán có coverage 60%, bạn muốn nâng lên 90%:
// Cách yếu — bạn phải tự lặp thủ công: "Viết thêm test cho module thanh toán." // Cách mạnh — bàn giao điều kiện dừng: /goal Coverage của src/payment đạt ≥ 90%, toàn bộ test suite pass, không xóa hay skip test cũ. Tối đa 6 lần thử.
Ba thành phần trong goal trên đều có chủ đích:
- Điều kiện đo được (≥ 90%): evaluator xác nhận bằng con số, không cảm tính.
- Ràng buộc (không xóa test cũ): chặn “gian lận” — cách nhanh nhất để tăng coverage là… xóa bớt code hoặc test khó. Máy sẽ tìm đường tắt nếu bạn không cấm.
- Ngân sách (tối đa 6 lần): chặn vòng lặp vô hạn khi goal hóa ra bất khả thi.
Stop condition phải là hợp đồng, không phải lời ước. “Cải thiện chất lượng code” là lời ước. “Lighthouse score trang chủ ≥ 90, đo bằng lệnh X, tối đa 5 lần thử” là hợp đồng — có con số, có cách đo, có trọng tài.
Kiểu 3: Time-based loop – bàn giao cái cò súng
bàn giao: trigger (cò súng) · bạn giữ: nội dung việc + quyết định sau báo cáo
Hai kiểu trên có chung một điểm: bạn vẫn là người khởi động. Nhưng có cả một lớp công việc mà phần khó chịu nhất không phải là làm, mà là nhớ để làm: tóm tắt tin nhắn mỗi sáng, kiểm tra CI có fail trong đêm không, xem có PR nào chờ review quá 24 giờ không. Time-based loop bàn giao cái “cò súng” đó cho đồng hồ:
/loop— chạy lại một prompt theo chu kỳ, ngay trên máy bạn. Tắt máy là dừng. Hợp với theo dõi ngắn hạn kiểu “canh cho đến khi CI xanh thì báo mình”./schedule— đẩy routine lên cloud, chạy theo lịch kể cả khi laptop đang ngủ trong balo. Hợp với routine hằng ngày.
Nó giống robot hút bụi đặt lịch 7 giờ sáng: không thông minh hơn máy hút bụi cầm tay, nhưng nó tự nhớ phải chạy — và thứ hay bị bỏ quên nhất trong công việc chính là những việc nhỏ, lặp lại, không gấp.
Ví dụ minh họa: loop buổi sáng kinh điển
/schedule mỗi ngày 07:30: Đọc CI run fail trong 24h qua + issue mới gắn nhãn "bug". Gom lỗi theo NGUYÊN NHÂN GỐC (không liệt kê từng test lẻ). Ghi vào TODO.md, mục mới nhất trên cùng. Gắn nhãn "quick-win" cho lỗi sửa được trong 1 file. → KHÔNG sửa bất kỳ dòng code nào.
Kiểu 4: Proactive loop – bàn giao cả cái prompt
bàn giao: chính cái prompt · bạn giữ: luật chơi + cửa approve cuối
Đây là tầng cao nhất, nơi các mảnh ghép trên kết hợp thành một dây chuyền: lịch trigger việc, goal định nghĩa “xong”, skills mô tả cách kiểm, nhiều agent chia vai phối hợp, và chế độ auto để dây chuyền không dừng giữa chừng xin phép từng bước. Ở tầng này, bạn không viết prompt cho từng việc nữa — hệ thống tự sinh ra việc và tự xử lý, theo luật chơi bạn thiết kế từ trước.
Hình ảnh phù hợp nhất là nhạc trưởng: không chơi nhạc cụ nào, nhưng chọn bản nhạc, phân bè, và định nghĩa thế nào là “chơi đúng”. Dàn nhạc tự chơi.
Ví dụ minh họa: dây chuyền xử lý bug report
Ba chi tiết thiết kế đáng chú ý trong sơ đồ:
- Agent phản biện có ngữ cảnh sạch. Nếu checker đọc toàn bộ dòng suy luận của maker, nó dễ bị “cuốn theo” và gật đầu. Cho nó nhìn kết quả với con mắt tươi mới — như một reviewer thật sự chưa nghe ai giải thích gì — nó sẽ khó tính hơn nhiều.
- Chia model theo độ khó của quyết định. Việc routine (đọc log, phân loại) giao model nhỏ, nhanh, rẻ. Việc cần phán đoán mới dùng model mạnh nhất. Giống phòng khám: y tá đo huyết áp, bác sĩ mới là người đọc kết quả và ra phác đồ.
- Con người vẫn đứng ở cửa cuối. Cái được tự động hóa là mọi thứ trước quyết định merge — không phải chính quyết định đó.
Đừng bắt đầu ở đây. Nhảy thẳng vào proactive loop khi chưa từng vận hành loop nhỏ giống như học lái xe bằng cách đăng ký đua công thức 1. Chạy vững kiểu 1–3, có cách verify tự động đáng tin, rồi hẵng ghép dây chuyền.
Bí quyết giữ chất lượng: loop chỉ tốt bằng hệ thống quanh nó
Một sự thật hơi phũ: loop không làm code của bạn tốt lên. Nó làm code được sinh ra nhanh hơn — tốt hay tệ là do hệ thống xung quanh. Ba đòn bẩy quan trọng:
- Codebase sạch là “tấm gương” của agent. Agent học pattern từ chính code có sẵn. Codebase nhất quán → agent bắt chước cái nhất quán. Codebase bừa → agent nhân bản cái bừa, với tốc độ công nghiệp.
- Reviewer phải có con mắt tươi. Agent thứ hai, ngữ cảnh sạch, không đọc lý luận của agent thứ nhất — và cho nó chạy test trước khi cho phát biểu ý kiến.
- Sửa hệ thống, đừng chỉ sửa lỗi. Khi một vòng lặp cho ra kết quả tệ, phản xạ bản năng là sửa cái kết quả đó rồi thôi. Phản xạ đúng là hỏi: “Thiếu tín hiệu gì trong skill / goal / tài liệu khiến nó làm sai?” — rồi bổ sung tín hiệu đó vào hệ thống. Sửa lỗi cứu được một vòng; sửa hệ thống thì mọi vòng sau đều tốt lên. Đây chính là điểm khiến loop engineering là engineering chứ không phải automation mù.
Chuyện tiền nong: loop đốt token nhanh hơn bạn nghĩ
Loop chạy không người trực nghĩa là token cũng cháy không người trực. Vài nguyên tắc tự vệ:
- Pilot nhỏ trước khi chạy lớn. Định cho loop xử lý 200 bug report? Cho chạy 5 cái trước, xem chất lượng và hóa đơn, rồi mới scale. Các workflow động có thể sinh hàng chục, hàng trăm agent con — hóa đơn nhân lên tương ứng.
- Việc deterministic thì dùng script, đừng dùng model. Đổi tên biến hàng loạt, format file, parse log theo quy tắc cố định — script chạy một lần rẻ hơn nhiều so với bắt model “suy luận lại” cùng logic ở mỗi vòng.
- Đặt trần rõ ràng. Số lần thử tối đa, ngân sách tối đa — cái nào chạm trước thì dừng. Không có trần, một goal bất khả thi sẽ lặp đến khi… thẻ của bạn hết hạn mức.
- Review định kỳ. Loop nào đang chạy? Tần suất có dày hơn mức cần không (check mỗi giờ trong khi báo cáo chỉ về mỗi sáng)? Tắt những loop đã hết lý do tồn tại.
Bảng tổng kết: bạn đang bàn giao mảnh nào?
| Kiểu loop | Bạn bàn giao… | Bạn còn giữ… |
|---|---|---|
| Turn-based + skill | Bước kiểm tra | Prompt, quyết định dừng |
| Goal-based | Điều kiện dừng | Định nghĩa goal, trần ngân sách |
| Time-based | Cái cò súng (trigger) | Nội dung việc, quyết định sau báo cáo |
| Proactive | Chính cái prompt | Luật chơi, cửa approve cuối |
Chưa viết được check verify? Chưa giao được bước kiểm. Goal chưa đo được? Chưa giao được điều kiện dừng.
Bắt đầu từ đâu? Ba câu hỏi cho tuần này
Đừng bắt đầu bằng việc chọn công cụ. Bắt đầu bằng việc soi lại lịch làm việc tuần vừa rồi và tìm một việc mà bạn là nút thắt cổ chai — việc mà agent làm xong từ lâu nhưng phải nằm chờ bạn ngó tới. Rồi tự hỏi ba câu:
- Bước kiểm tra của mình có viết ra thành checklist được không? → Nếu có, đó là một skill. Bạn vừa tìm thấy turn-based loop nâng cấp đầu tiên.
- “Xong” có diễn đạt được bằng con số hoặc điều kiện máy xác nhận được không? → Nếu có, đó là một
/goal. - Việc này có đến theo lịch, hoặc mình từng đặt reminder cho nó không? → Nếu có, đó là một
/schedule.
Chỉ cần một trong ba câu trả lời là “có”, bạn đã có loop đầu tiên để dựng trong tuần này. Bắt đầu nhỏ, cho nó quyền quan sát trước quyền hành động, và nâng dần niềm tin qua từng bậc thang.
Nguyên tắc cuối, quan trọng hơn mọi công cụ: xây loop như một người định ở lại làm engineer, chứ không phải người chỉ đến bấm nút “go”. Loop giải phóng bạn khỏi việc lặp lại — nhưng phán đoán, trách nhiệm với code đã merge, và sự hiểu biết về thứ hệ thống của mình đang sinh ra, ba thứ đó không bàn giao được cho ai.
Tham khảo: Getting started with loops – blog Claude by Anthropic.
Cảm ơn bạn đã đọc bài viết này!
Related Posts:
