Bài 7 — Dùng tool, test và log làm context phản hồi (feedback loop)

Context không chỉ là code tĩnh

Mạnh nhất của một coding agent hiện đại là vòng lặp hành động: chạy lệnh, đọc kết quả, tự điều chỉnh. Output của test, lint, type-check, git diff, log runtime — tất cả là context phản hồi giúp agent sửa dựa trên sự thật thay vì phỏng đoán. Thiết kế feedback loop tốt = agent tự đi từ sai tới đúng mà bạn ít can thiệp.

Vòng lặp agent kinh điển

1. Đọc yêu cầu + code liên quan
2. Viết/sửa code
3. Chạy test/lint/build   <-- sinh context phản hồi
4. Đọc kết quả:
     pass -> báo xong (kèm bằng chứng)
     fail -> phân tích lỗi -> quay lại bước 2

Công việc của bạn là đảm bảo bước 3 tồn tại và chạy được.

Ví dụ cụ thể

Tác vụ: sửa hàm parse ngày. Agent sửa, chạy:

$ pytest tests/test_date.py -q
FAILED test_parse_iso - ValueError: unconverted data '+07:00'

Lỗi này chính là context vàng. Agent đọc, hiểu chưa xử lý timezone, sửa tiếp, chạy lại → pass. Không có bước chạy test, agent sẽ "báo xong" với bug còn nguyên.

Thiết kế feedback loop tốt

• Test nhanh, phạm vi hẹp — chạy pytest tests/test_date.py thay vì cả suite; vòng lặp nhanh, ít nhiễu.
• Lỗi rõ ràng — bật thông báo lỗi/traceback đầy đủ để agent có tín hiệu tốt.
• Một tiêu chí xanh/đỏ — lint pass? test pass? build ok? để agent biết chắc trạng thái.
• Cho agent quyền chạy an toàn — cho phép lệnh đọc/test tự động; giữ lệnh nguy hiểm (deploy, xóa DB) cần bạn duyệt.
• Đưa log runtime khi cần — với bug lúc chạy, dán log/stack trace thật vào context.

Các bước dựng feedback loop cho một dự án

• Đảm bảo có lệnh test/lint chạy được, ghi vào CLAUDE.md.
• Trong prompt, yêu cầu agent chạy test sau mỗi thay đổi và dán kết quả.
• Khi fail, yêu cầu agent phân tích một nguyên nhân rồi sửa, chạy lại.
• Giới hạn số vòng lặp (ví dụ: sau 3 lần fail liên tiếp thì dừng, báo cáo cho người).
• Với lệnh rủi ro, đặt chế độ cần xác nhận thủ công.

Khung phân loại quyền tool

Đọc (ls, grep, cat)          -> tự động, an toàn
Test/lint/build              -> tự động, khuyến khích
Sửa file trong repo          -> tự động, nhưng review diff
Lệnh phá hủy (rm -rf, drop)  -> LUÔN cần người duyệt
Deploy / gọi API tính phí    -> LUÔN cần người duyệt

Checklist feedback loop

• [ ] Có lệnh test/lint phạm vi hẹp, chạy nhanh
• [ ] Agent chạy verify sau mỗi thay đổi và dán output
• [ ] Traceback/lỗi đầy đủ, không bị nuốt
• [ ] Có giới hạn số vòng lặp để tránh loop vô tận
• [ ] Lệnh nguy hiểm cần xác nhận thủ công

Không chỉ test: các nguồn phản hồi khác

Test là nguồn phản hồi phổ biến nhất, nhưng không phải duy nhất. Tùy tình huống, hãy tận dụng:

• Type checker (mypy, tsc): bắt lỗi kiểu trước cả khi chạy — phản hồi cực nhanh, rất hợp để chống ảo giác về chữ ký hàm.
• Linter/formatter: bắt vi phạm quy ước, biến bất định, import thừa.
• git diff: cho agent (và bạn) thấy chính xác nó đã đổi gì — phát hiện thay đổi ngoài ý muốn.
• Log runtime / stack trace: với bug chỉ xuất hiện lúc chạy thật, dán nguyên văn log vào context là tín hiệu quý nhất.
• Kết quả build: một lỗi compile là bằng chứng không thể chối cãi rằng code chưa đúng.

Một feedback loop mạnh thường ghép nhiều nguồn: type-check + lint (nhanh, chạy trước) rồi mới test (chậm hơn). Càng nhiều "máy nói sự thật", agent càng ít cơ hội đoán mò.

Sai lầm thường gặp

• Không cho agent chạy test — mất trụ cột tự sửa; agent chỉ đoán.
• Chạy cả suite mỗi lần — chậm, ngốn context, che tín hiệu bằng hàng trăm dòng output.
• Nuốt lỗi (ẩn traceback) — agent thiếu tín hiệu để sửa đúng.
• Cho quyền lệnh phá hủy tự động — rủi ro nghiêm trọng; luôn gate lại.
• Vòng lặp vô tận — agent sửa-fail-sửa mãi; đặt trần số lần và bắt nó dừng báo cáo.
• Bỏ qua type-check/lint — mất lớp phản hồi nhanh và rẻ nhất trước khi chạy test.

Feedback loop biến agent từ "máy đoán" thành "kỹ sư tự kiểm chứng". Bài cuối: ghép tất cả vào quy trình thực chiến.