Sau bữa trưa, cửa sổ chat trả về một câu trả lời gọn đến dễ chịu. Nó gọi đúng triệu chứng trên production, nêu nguyên nhân có vẻ hợp lý, đề xuất bản vá rồi còn nói luôn trade-off. Giọng văn chắc và điềm đạm, gần giống một nhận định đã được người có kinh nghiệm cân nhắc. Trong vài phút, vấn đề bỗng có vẻ nhỏ hẳn.
Cảm giác nhẹ đi ấy hữu ích, nhưng cũng chính là cái bẫy. Câu chữ trôi chảy làm sự mơ hồ lắng xuống đúng lúc ta đang sốt ruột muốn có đáp án. Khi công việc bận, chỉ cần vậy là người đọc có thể chuyển sang làm theo trước khi kịp hỏi: ngoài chính câu trả lời này, bằng chứng nào cho thấy nó đúng?
Cái giá không phải lúc nào cũng là một outage lớn. Có khi cả buổi chiều bị mất vì sửa nhầm tầng. Có khi một bug kín đáo đi vào nhánh chính bởi lời giải thích nghe rất có lý. Có khi quyết định sản phẩm dựa trên bản tóm tắt đã bỏ qua những ví dụ khách hàng khó chịu nhất. Câu trả lời không nhất thiết vô dụng hay có ý xấu; nó chỉ chưa được kiểm chứng trong một việc mà sai thì phải trả giá.
AI càng dùng đúng tiếng nghề càng dễ thuyết phục. Những từ như idempotency, rollback, eventual consistency hay security boundary xuất hiện đúng chỗ khiến ta có cảm giác phần suy luận phía sau cũng đã đầy đủ. Nhưng mô hình có thể tạo ra bề mặt của chuyên môn mà không mang trách nhiệm của người làm chuyên môn. Thuật ngữ đúng không tự biến một phỏng đoán thành kết luận.
Câu trả lời mượt làm việc đọc dễ hơn, không làm trách nhiệm nhẹ hơn. Nó càng thuyết phục, càng nên tách từng khẳng định ra và chỉ rõ cách kiểm tra.
Cách dùng thực tế là coi đầu ra của AI như bản nháp, không phải quyết định. Hãy để nó đề xuất giả thuyết, danh sách kiểm tra, cách so sánh hay một hướng sửa. Sau đó đưa từng ý quan trọng ra thế giới thật. Nó nói nguyên nhân gốc nằm ở đâu thì tái hiện lỗi và đọc log. Nó đề xuất thêm index thì xem query plan lẫn chi phí ghi. Nó tóm tắt chính sách thì mở nguồn gốc. Nó sửa code thì chạy test và đọc các trường hợp biên. AI có thể giúp thiết kế phép kiểm tra, nhưng không thể là trọng tài duy nhất cho câu trả lời của chính mình.
Mức kiểm tra phải đi theo mức rủi ro. Sửa một câu văn có thể chỉ cần đọc kỹ. Khuyến nghị triển khai cần nhiều bằng chứng hơn. Thay đổi liên quan bảo mật cần review, thử nghiệm và thêm một người độc lập xem lại. Một tính năng AI chạm tới khách hàng còn cần bộ ví dụ đánh giá, cách từ chối và khả năng lần về nguồn. Kiểm chứng không phải một nghi thức dùng như nhau cho mọi việc; nó là sự cẩn trọng đúng liều.
Đội ngũ có thể biến việc này thành thói quen chung thay vì để mỗi người tự nhớ. Trong pull request, ghi ngắn phần nào có AI hỗ trợ, giả định nào đã được kiểm tra, test nào đã chạy và vùng nào reviewer cần nhìn kỹ. Trong tài liệu sản phẩm, tách lựa chọn do AI gợi ý khỏi bằng chứng khách hàng đã xác nhận. Trong quy trình hỗ trợ, đặt đoạn nguồn ngay cạnh câu trả lời đề xuất. Những dấu vết nhỏ ấy giữ trách nhiệm ở ngoài một cuộc chat riêng.
Việc kiểm tra còn đem lại một món lợi dễ bỏ sót: hiểu biết thật. Giả thuyết sai cho biết ranh giới hệ thống nằm chỗ khác. Một test vượt qua cho thấy giả định nào mới là then chốt. Lần mở tài liệu gốc có thể làm lộ một trang đã cũ. Nếu bỏ qua những bước này, AI có thể làm ta nhanh hơn trong hôm nay nhưng khiến mô hình hiểu biết trong đầu mỏng dần.
Không cần nghi ngờ AI như một phản xạ. Chỉ cần áp dụng kỷ luật kỹ thuật quen thuộc cho một loại bản nháp mới: dùng tốc độ của nó, tận dụng cấu trúc của nó, nhưng vẫn giữ quyền sở hữu quyết định. Một câu trả lời trôi chảy thường là khởi đầu tốt; rất hiếm khi nó đã là bằng chứng cuối cùng.
Ngay trước lúc làm theo một đáp án nghe quá đúng, hãy xác định thứ gì sẽ trở nên đắt đỏ nếu đáp án ấy sai. Cái giá vừa gọi tên sẽ cho biết cần mở nguồn, chạy test hay mời thêm người xem lại đến mức nào. Sự tỉnh táo nhỏ đó giữ được cả lợi ích của AI lẫn trách nhiệm của người dùng nó.