Tóm tắt
Bài viết của HumanLayer nhắm vào làn sóng “software factory” dùng coding agents để nhồi việc vào queue, sinh PR, tự review, tự test, rồi ship với rất ít can thiệp của con người. Lập luận chính không phải là agent vô dụng. Ngược lại: agent đã làm bước build nhanh hơn rất nhiều, từ ngày/giờ xuống phút/giờ. Nhưng khi build rẻ đi, review và maintainability mới trở thành nút thắt thật.
Tác giả cho rằng cách nghĩ “chỉ cần thêm loop, thêm review bot, thêm test” bỏ sót một vấn đề huấn luyện model. Những benchmark coding phổ biến thường thưởng cho pass/fail ngắn hạn: bug có được sửa không, test có pass không. Chúng không phạt đủ mạnh khi agent làm codebase khó sửa hơn, thêm abstraction lệch, copy logic, hoặc vá bằng try/catch và type cast yếu.
Vì sao lights-off factory dễ hỏng
Một software factory trước AI vốn đã có nhiều vòng lặp: người quyết định sản phẩm, ticket đi vào tracker, kỹ sư build, PR được review, deploy, monitor, rồi feedback quay lại backlog. AI thay đổi mạnh nhất ở bước build: agent có thể tạo patch nhanh hơn nhiều. Từ đó nhiều team thử xóa hoặc nén bước review bằng agentic review, regression testing tự động và monitoring.
Điểm HumanLayer cảnh báo là review không biến mất, nó chỉ đổi hình. Khi không ai đọc code, bạn vẫn phải trả chi phí ở nơi khác: incident, bug khó truy vết, feature sau này sửa lâu hơn, hoặc codebase dần biến thành một khối khó hiểu. Faros AI được trích trong bài ghi nhận review comments tăng 25%, comment dài hơn 22,7%, 31,3% PR bỏ qua review, incidents per PR tăng 242,7% và bugs per developer tăng 54% trong giai đoạn AI coding tool bùng lên đầu 2026. Đây là tín hiệu tương quan, không phải bằng chứng tuyệt đối, nhưng rất khớp với trải nghiệm của nhiều team đang dùng agent thật.
Benchmark chưa đo được maintainability
Bài viết giải thích khá kỹ vì sao benchmark hiện tại chưa đủ. Với một task kiểu SWE-bench, agent nhận bug report, sửa code, test patch của benchmark được áp vào, rồi hệ thống chấm 0 hoặc 1. Nếu test pass, trace thắng. Cách agent đi tới lời giải, code có sạch không, kiến trúc có bị bẻ cong không, và lần sửa sau có khó hơn không gần như không được tính.
Vấn đề là test cho feedback trong vài giây, còn bad architecture có chi phí sau vài tuần hoặc vài tháng. Bạn chỉ thấy nó khi cần sửa một dòng nhưng phải đi qua 11 file, hoặc khi một workaround nhỏ làm vỡ hành vi ở module xa hơn. Không có oracle nhanh và đáng tin cho maintainability thì reinforcement learning cũng khó thưởng/phạt đúng thứ mà team production quan tâm.
HumanLayer có nhắc tới vài hướng tốt hơn như SWE-Marathon, DeepSWE và Frontier Code. Các benchmark này thử mở rộng task dài hơn, giảm contamination, thêm quality rules, hoặc kiểm tra test mới có thật sự fail trên pre-patch code hay không. Dù vậy, model-judge cho chất lượng code vẫn có giới hạn: nếu model luôn biết code nào tốt, có lẽ nó đã viết bản tốt ngay từ đầu.
Nên vận hành agent thế nào
Khuyến nghị thực dụng của bài viết là bật đèn lại. Con người không cần viết từng dòng, nhưng nên đứng ở những điểm quyết định có đòn bẩy cao.
- Product review: chốt vấn đề người dùng, mục tiêu thành công và các màn hình hoặc workflow cụ thể trước khi code.
- System architecture: thống nhất service, endpoint, schema, queue, datastore và ranh giới module.
- Program design: đi xuống tầng type, method signature, call stack, file-tree diff và cách chia code.
- Vertical slices: cho agent build từng lát end-to-end nhỏ, kiểm tra được bằng curl, browser hoặc test thật, thay vì làm kế hoạch ngang kiểu database rồi service rồi API rồi frontend.
Điểm hay ở đây là không cực đoan. Copy tweak, script nhỏ hoặc bug có repro rõ vẫn có thể one-shot. Việc cần kỷ luật là task medium/large, nơi misunderstanding của agent sẽ đắt hơn thời gian bạn bỏ ra để viết plan.
Ý nghĩa với dev
Dev nên quan tâm vì bài này chuyển câu hỏi từ “agent có viết code không” sang “hệ thống của mình có giữ được chất lượng khi agent viết nhiều code hơn không”. Nếu chỉ đo số PR, số dòng code hoặc thời gian từ ticket tới patch, bạn đang tối ưu đúng phần dễ đo nhất và bỏ quên phần dễ làm hỏng nhất.
Metric nên theo dõi gồm: tỷ lệ PR cần rework, số incident sau merge, thời gian review thực tế, số vòng resteer, số patch phải rollback, độ nhỏ của vertical slice, và số quyết định kiến trúc được chốt trước khi agent code. Software factory khỏe không phải factory không có người; nó là factory biết đặt người vào đúng điểm có leverage.