Khi một rào chắn an toàn hét lên: phân loại trước khi sửa

Rào chắn an toàn chỉ hữu ích nếu bạn phản ứng tốt với chúng, và kiểu thất bại thường thấy là dễ đoán: bản build chuyển đỏ, bạn hơi hoảng, và bạn dán lỗi cho AI kèm câu "sửa đi." Đôi khi cách đó hiệu quả. Nhưng thường thì nó tạo ra một bản sửa khiến chữ đỏ biến mất mà không giải quyết được vấn đề thực sự — AI làm yếu bài kiểm thử đi, nới lỏng một kiểu dữ liệu, hoặc bọc lệnh gọi bị lỗi trong một try/catch để nuốt chửng vấn đề.

Trước khi để nó "sửa" bất cứ thứ gì, hãy dành mười giây để phân loại. Thực sự chỉ có ba loại thất bại của rào chắn an toàn:

• Một lỗi thật mà bạn vừa gây ra. Bước kiểm tra đang làm đúng nhiệm vụ của nó. Sửa đoạn mã, không phải sửa bước kiểm tra.
• Một bài kiểm thử giờ đã lỗi thời. Bạn đã cố ý thay đổi hành vi, và khẳng định (assertion) cũ không còn khớp nữa. Cập nhật bài kiểm thử để khẳng định hành vi mới đúng đắn — một cách có chủ đích, không phải theo phản xạ.
• Một bước kiểm tra không ổn định hoặc sai. Thực sự hiếm gặp. Hãy nghi ngờ chính bản thân mình ở đây; đây là cái thùng rác mà người ta hay đổ những lỗi thật vào vì đó là lựa chọn cho phép họ tiếp tục làm việc khác.

Chỉ dẫn giữ cho AI trung thực là buộc nó phải chẩn đoán trước khi thay đổi bất cứ điều gì:

The test "never discounts below zero" is failing.
First, tell me WHY it fails — what does the code do now vs. what
the test expects. Then tell me which is correct: the code or the
test. Do NOT change anything until I confirm.

Khoảng dừng đó chính là ranh giới giữa một rào chắn an toàn bảo vệ bạn và một rào chắn an toàn mà bạn đã lặng lẽ huấn luyện AI đánh bại. Một dấu kiểm đỏ là thông tin; điều tệ nhất bạn có thể làm là trả giá để biến nó thành xanh mà không đọc xem nó đang nói với bạn điều gì.