Câu trả lời của AI trông rất trọn vẹn. Nó gọi tên bug, đề xuất một patch nhỏ, rồi giải thích mạch lạc vì sao đoạn code cũ sai. Chỉ mất vài giây để có cảm giác việc đã xong. Sau đó mới tới phần kém hấp dẫn hơn: mở đúng source file, lần theo call site, chạy test, đối chiếu log và xem hệ thống thật có làm điều AI vừa kể hay không.
AI hữu ích và nguy hiểm ở cùng một điểm: nó làm cho việc bắt đầu quá dễ. Nó có thể tóm tắt một luồng mã, đề nghị ca kiểm thử, tách một báo cáo lỗi mơ hồ thành vài giả thuyết và nhắc những điều kiện biên ta bỏ sót lúc mệt. Nhưng câu văn trôi chảy không phải bằng chứng. Một giải thích nghe hợp lý vẫn có thể dựa trên file cũ, hiểu sai contract hoặc lấp chỗ trống bằng một mẫu quen thuộc không thuộc hệ thống này.
Cách dùng thay đổi khi ta đổi vai cho công cụ. Xem AI như nơi ban kết luận, ta dễ hỏi “đáp án là gì?” rồi vô thức bảo vệ đáp án vừa nhận. Xem nó như một người cùng phản biện, ta sẽ hỏi “còn phương án nào?”, “giả định nào đang bị giấu?”, “bằng chứng nào còn thiếu?” và “trường hợp nào làm lời giải này vỡ?”. Nhịp thứ hai có vẻ chậm hơn lúc đầu, nhưng quyền phán đoán vẫn nằm ở người phải chịu trách nhiệm cho thay đổi.
Một câu hỏi đặc biệt hữu ích là: điều gì sẽ chứng minh nhận định này sai? Nếu AI bảo một nhánh code không thể chạy tới, hãy tìm call site có thể đưa dữ liệu vào đó. Nếu nó nói migration an toàn, hãy kiểm tra shape dữ liệu cũ, khóa ngoại, rollback và cách chạy lại khi dở dang. Nếu nó giải thích một triệu chứng production, hãy đặt giả thuyết cạnh timestamp, metric, log và báo cáo của người dùng. Không cần nghi ngờ mọi thứ; chỉ cần buộc mỗi khẳng định quan trọng có đường quay về bằng chứng.
AI còn rất giỏi phủ lớp sơn đẹp lên sự không chắc chắn. Một phỏng đoán yếu có thể được viết thành ba đoạn chắc nịch. Việc của kỹ sư là bóc nó trở lại thành các mệnh đề kiểm tra được: đã đọc file nào, chưa đọc file nào, test nào phải fail nếu giả thuyết đúng, input nào làm hành vi đổi, đâu là sự thật của sản phẩm và đâu chỉ là chi tiết triển khai. Khi câu trả lời đứng được ở mức đó, người khác mới review được thay vì chỉ chọn tin hay không tin.
Một vòng làm việc nhỏ thường đã đủ. Nhờ AI phác luồng mã, rồi tự lần lại luồng ấy. Nhờ nó nghĩ trường hợp biên, rồi biến trường hợp hữu ích thành test. Nhờ nó đề xuất patch, rồi đọc diff như đọc code của một đồng đội đang làm dưới áp lực. Cuối cùng chạy hệ thống và nhìn đầu ra. AI giúp rút ngắn quãng đường giữa các điểm kiểm tra; nó không xóa các điểm kiểm tra.
Phần này quan trọng không chỉ vì tính đúng đắn. Nếu giao luôn việc phán đoán, ta cũng dễ giao mất việc học. Có thể bug được sửa, nhưng trong đầu không hình thành mô hình đủ chắc để xử lý lần hỏng tiếp theo. Ngược lại, khi giải thích của AI phải va vào code, test và dữ liệu thật, chính sự va chạm ấy làm hiểu biết của người và của cả nhóm dày lên.
Một quy trình dùng AI tử tế nên để lại dấu vết rất đời thường: đã giả định gì, đã kiểm tra gì, kết quả nào làm đổi ý, và vì sao nhóm chọn phương án cuối. AI có thể viết nhanh bản nháp; quyền nói “đủ bằng chứng để đưa vào hệ thống” vẫn phải thuộc về người biết mình đang ký tên dưới hậu quả nào.