Mệt mỏi kiểu 'human-in-the-loop' trong AI coding là gì?

Đó là sự kiệt sức đến từ việc liên tục review, phê duyệt và sửa output do AI sinh ra. Khi agent tạo ra nhiều code nhanh hơn, vai trò của con người chuyển từ viết sang giám sát — và việc giám sát không giới hạn những output nhìn hợp lý nhưng sai lại vắt kiệt tinh thần theo cách mà viết code không gây ra.

Tắt các lời nhắc phê duyệt có khiến agent mất an toàn không?

Không, nếu bạn thay phê duyệt từng hành động bằng rào chắn mang tính cấu trúc: chạy việc rủi ro trong một branch hoặc sandbox, chặn merge sau test và review, và dành sự chú ý của con người cho kế hoạch và diff thay vì từng câu lệnh riêng lẻ. Bạn dời điểm kiểm tra, chứ không bỏ nó.

Làm sao để ngừng review đi review lại cùng một lỗi?

Hãy chắt lọc các phản hồi review lặp lại vào một file hướng dẫn (CLAUDE.md, AGENTS.md, hoặc file rules) để agent áp dụng ngay từ đầu. Cách này biến một lần sửa thủ công lặp đi lặp lại thành một quy tắc viết một lần — đúng nơi mà công sức giám sát nên được đầu tư.

Human-in-the-Loop Đã Mệt: Những Rào Chắn Thực Tế Để Review Công Việc Của AI Agent

17 tháng 7, 2026

ai-codingagentsworkflow

Một bài viết được chia sẻ rộng rãi từ Pydantic, “The human-in-the-loop is tired” của Laura Summers, gọi tên đúng điều mà nhiều lập trình viên đã cảm nhận nhưng chưa diễn đạt được: code với AI agent thường vừa năng suất hơn vừa kém thỏa mãn hơn cùng lúc. Lý do không nằm ở code — mà ở việc giám sát.

Nút thắt đã dịch chuyển, nhưng không ai điều chỉnh theo

Suốt nhiều thập kỷ, nguồn lực khan hiếm trong phần mềm là viết code đúng. Agent đã tự động hóa phần lớn việc đó. Thứ chúng không tự động hóa là sự chú ý và phán đoán — quyết định output có đúng, mạch lạc và đáng giữ lại hay không.

Bài viết mô tả một đồng nghiệp nhận 30 PR do AI sinh ra mỗi đêm, mỗi cái cần một phán đoán chớp nhoáng. Một người khác thức đến 2 giờ sáng, ám ảnh prompt đi prompt lại để có được một spec “đúng”. Chế độ thất bại không phải là model tạo ra rác; mà là model tạo ra output nhìn hợp lý với những “lỗi mạch lạc” tinh vi — code trông đúng và compile được nhưng âm thầm làm sai. Review loại code đó mệt hơn nhiều so với review rác lộ liễu, vì bạn không thể đọc lướt.

Đó chính là cái bẫy: khối lượng output tăng lên, nên khối lượng thứ đòi hỏi con người review cũng tăng theo, trong khi phần thỏa mãn — tự mình giải quyết vấn đề — lại co lại.

Cách khắc phục nằm ở cấu trúc, không phải ở việc gắng sức hơn

Phản xạ tự nhiên là review mọi thứ kỹ hơn. Điều đó không mở rộng được, và chính nó khiến người ta kiệt sức. Nước đi tốt hơn là thay đổi vị trí điểm kiểm tra của con người, chứ không phải dồn sức mạnh hơn vào nó.

Dời điểm kiểm tra từ hành động sang kết quả. Phê duyệt từng lệnh Bash hay Edit riêng lẻ là vòng lặp mệt mỏi nhất có thể. Thay vào đó, hãy để agent làm việc tự chủ bên trong một ranh giới khiến sai lầm trở nên rẻ — một git branch riêng, một worktree, hoặc một sandbox — và đặt sự chú ý thật sự của bạn vào hai thứ: kế hoạch trước khi bắt đầu, và diff khi đã xong. Nếu bạn liên tục bấm approve/deny, bạn đang giám sát ở sai độ cao.

Chặn merge bằng máy móc, không phải bằng mắt. Test, type check và linter là những người review không biết mệt. Càng diễn đạt được nhiều tiêu chí đúng đắn của bạn thành cổng kiểm tra tự động, bạn càng ít phải giữ chúng trong đầu khi review. Review của con người nên tập trung vào ý định và kiến trúc — những thứ mà bộ test không đánh giá được.

Chắt lọc phản hồi lặp lại thành quy tắc. Nếu bạn sửa cùng một loại lỗi hai lần, đó là tín hiệu để viết nó ra, chứ không phải tiếp tục bắt lỗi thủ công. Đưa nó vào file CLAUDE.md / AGENTS.md / rules sẽ biến một lần sửa thủ công vô tận thành một khoản đầu tư một lần. (Đây cũng là lý do các file hướng dẫn phình to đáng được cắt gọn — xem bài của chúng tôi về token overhead của Claude Code.)

Gộp lô, đừng phản ứng theo dòng. Phản ứng với output ngay khoảnh khắc nó xuất hiện chính là kiểu Skinner-box mà bài viết cảnh báo — “chỉ thêm một prompt nữa thôi”. Hãy để một tác vụ chạy đến điểm dừng tự nhiên rồi review toàn bộ kết quả, thay vì trông chừng từng bước. Ít lần review nhưng lớn hơn sẽ đỡ mệt hơn một dòng chảy liên tục.

Biết khi nào nên đóng vòng lặp hoàn toàn

Không phải tác vụ nào cũng cần agent. Khuyến nghị lành mạnh nhất của bài viết là sự trưởng thành trong workflow: đủ tự tin để chuyển qua lại giữa code có AI hỗ trợ và tự gõ tay mà không thấy áy náy. Những thay đổi nhỏ, đã hiểu rõ thường tự viết còn nhanh hơn. Hãy để dành agent cho những việc mà tốc độ của nó thực sự bù lại được chi phí review mà nó tạo ra.

Nếu bạn muốn một thiết lập chạy hoàn toàn cục bộ, nơi bài toán review-so-với-chi-phí khác đi — không có áp lực tính theo token thúc bạn “thêm một prompt nữa” — chúng tôi đã hướng dẫn chạy một coding agent cục bộ miễn phí trong một bài riêng.

Kết luận

Lợi ích năng suất từ coding agent là có thật, nhưng chi phí giám sát cũng vậy, và giả vờ rằng nó miễn phí chính là cách khiến người ta kiệt sức. Đừng cố review gắng hơn. Hãy dời điểm kiểm tra về kế hoạch và diff, để test và branch hấp thụ rủi ro, và viết phản hồi ra thay vì lặp lại nó. Phán đoán của con người giờ là nguồn lực khan hiếm — hãy chi tiêu nó một cách có chủ đích, đừng dùng nó để phê duyệt từng câu lệnh một.

Nguồn: The human-in-the-loop is tired của Laura Summers (Pydantic), thảo luận trên Hacker News.