Gợi ý của AI trông rất tự tin. Nó gọi tên bug, đề xuất một patch nhỏ, và còn giải thích vì sao code cũ sai. Trong vài giây, câu trả lời có vẻ đã xong. Rồi kỹ sư làm việc kém hấp dẫn hơn: mở source file, chạy test, kiểm tra log line, và so lời giải thích với điều hệ thống thật sự làm.
Đây là nơi AI tool hữu ích và rủi ro cùng lúc. Chúng làm việc bắt đầu dễ hơn. Chúng có thể summarize một code path, gợi ý test case, biến bug report mơ hồ thành vài hypothesis, và nhận ra pattern mà ta có thể bỏ lỡ khi mệt. Nhưng sự trôi chảy của câu trả lời cũng làm ta quên rằng trôi chảy không đồng nghĩa với đúng.
Dùng AI tốt bắt đầu bằng việc đổi vai trò ta giao cho nó. Nếu coi nó là oracle, ta sẽ hỏi kết luận rồi dùng năng lượng để bảo vệ kết luận đó. Nếu coi nó là review partner, ta có thể hỏi option, assumption, evidence còn thiếu, và failure mode có thể xảy ra. Mode thứ hai ban đầu chậm hơn, nhưng nó giữ judgment trong tay người chịu trách nhiệm cho thay đổi.
Một thói quen đơn giản rất có ích: luôn hỏi điều gì sẽ chứng minh câu trả lời sai. Nếu tool nói một condition là impossible, hãy tìm call site có thể làm nó possible. Nếu nó nói migration an toàn, hỏi data shape nào sẽ làm vỡ. Nếu nó giải thích symptom production, so giải thích đó với timestamp, metric, và user report. Mục tiêu không phải nghi ngờ mọi câu trả lời. Mục tiêu là giữ câu trả lời nối với evidence.
AI cũng rất giỏi tạo language che bớt uncertainty. Nó có thể biến một guess yếu thành một đoạn văn polished. Engineer cần kỹ năng ngược lại: biến polished guess thành claim có thể inspect. File nào đã được đọc? Test nào sẽ fail? Input nào quan trọng? Behavior nào là product truth, và behavior nào chỉ là implementation detail? Những câu hỏi này làm công việc bớt ma thuật và dễ review hơn.
Kết quả tốt thường đến từ một vòng lặp nhỏ. Nhờ AI map code path. Tự mình verify path đó. Nhờ nó nghĩ edge case. Chuyển edge case hữu ích thành test. Nhờ nó đề xuất patch. Đọc patch như thể một teammate viết trong lúc áp lực. Rồi chạy hệ thống. Tool giúp di chuyển nhanh hơn, nhưng mỗi bước vẫn có checkpoint của con người.
Điều này quan trọng không chỉ vì correctness. Khi outsource judgment, ta cũng outsource learning. Có thể ta ship được fix, nhưng không xây mental model giúp xử lý issue tiếp theo. Khi dùng AI như partner, explanation, code, và evidence trở thành vật liệu cho chính hiểu biết của mình. Team có cả speed lẫn shared knowledge mạnh hơn.
Không có gì xấu hổ khi nhận trợ giúp từ tool. Câu hỏi là tool làm ta chú ý hơn hay ít chú ý hơn. Một AI workflow tốt nên để lại dấu vết: đã assume gì, đã check gì, đã đổi gì, và vì sao quyết định cuối thuộc về team. Nếu bạn có một thói quen nhỏ giúp AI-assisted work grounded hơn, mình rất muốn học từ nó.