Hola, I’m Hieu, a Software Engineer

Kịch bản hỏng lúc nào cũng giống nhau. Thứ Hai có người cắm một con AI reviewer vào CI. Nó để lại ba mươi comment trên pull request đầu tiên: hai mươi bảy cái là đặt tên biến, “cân nhắc tách đoạn này ra helper”, và một gợi ý thêm test mà cái test đó đã nằm sẵn ở file cách đó hai bậc. Ba cái là thật, và một trong ba là bug mất dữ liệu thật sự nằm trong nhánh retry. Không ai thấy ba cái đó. Đến thứ Tư mọi người lướt qua phần review của bot để xuống phần review của người. Đến thứ Hai tuần sau nó thành một check không chặn merge với thông báo đã tắt — một tích hợp chết nhưng vẫn đốt token mỗi lần push. Con bot không dở trong việc tìm bug. Nó tìm ra bug rồi. Nó dở ở chỗ không biết im lặng , mà trong code review thì đó chính là toàn bộ công việc. Ngân sách của một reviewer không phải là compute, mà là mức độ sẵn lòng đọc tiếp của đồng đội — và niềm tin đó cập nhật rất nhanh. Nếu trong mười comment đầu tiên một developer đọc chỉ có một cái hữu ích, họ đã học được một quy tắc — lướt qua thôi...

The failure mode is always the same. Someone wires an AI reviewer into CI on a Monday. It posts thirty comments on the first pull request: twenty-seven are variable naming, “consider extracting this into a helper”, and a suggestion to add a test that already exists two files over. Three are real, and one of those is a genuine data-loss bug in a retry path. Nobody finds the three. By Wednesday people scroll past the bot’s review to reach the human one. By the following Monday it is a non-blocking check with notifications muted — a dead integration that still burns tokens on every push. The bot was not bad at finding bugs. It found the bug. It was bad at not saying things , and in code review that is the entire job. A reviewer’s budget is not compute, it is your teammates’ willingness to keep reading, and that belief updates fast. If the first ten comments a developer reads contain one useful one, they have learned a rule — skim it, it is usually nothing — and that rule is applied to ...