Máy pha cà phê vẫn phát ra âm thanh mệt mỏi quen thuộc, còn người ngồi bàn bên đang mở một câu trả lời AI cạnh bug ticket. Câu trả lời nhìn rất gọn. Nó gọi tên nguyên nhân có thể xảy ra, gợi ý cách sửa, và còn giải thích ngắn vì sao cách sửa đó nên hoạt động. Trong một khoảnh khắc, căn phòng nhẹ đi. Giữa một buổi sáng đã đầy việc, một câu trả lời trôi chảy luôn có sức làm mình yên tâm.
Rồi thói quen engineering cũ quay lại: làm sao mình biết điều này đúng? Không phải vì câu trả lời đáng nghi. Không phải vì AI cần bị xem như đối thủ. Chỉ đơn giản vì một lời giải thích tự tin vẫn chưa phải là evidence. Một câu trả lời AI có thể hữu ích, có suy nghĩ và đi đúng hướng, nhưng trong một codebase thật, nó vẫn là một claim cho đến khi có thứ gì đó bên ngoài model kiểm chứng nó.
Đây là một trong những dịch chuyển nhỏ về trách nhiệm khi AI bước vào công việc hằng ngày. Trước AI, mình đã kiểm chứng rất nhiều thứ. Mình chạy unit test, đọc log, xem docs, reproduce bug, so sánh query result, hỏi người hiểu domain, và quan sát metric sau release. AI không xoá bỏ kỷ luật đó. Nó chỉ chuyển thêm nhiều việc vào khoảng giữa câu trả lời đầu tiên và câu trả lời đủ đáng tin.
Sai lầm là xem verification như biểu hiện của thiếu tin tưởng. Trong engineering, verification không phải là distrust. Nó là cách trust được xây lên. Mình không merge code chỉ vì người viết giỏi; mình merge vì thay đổi đó dễ hiểu, có test, được review, và đủ nhỏ để suy luận. Mình không tin một migration chỉ vì SQL nhìn đẹp; mình tin sau khi có dry run, backup plan và rollback path. Câu trả lời AI cũng xứng đáng với sự nghiêm túc bình thường như vậy.
Một cách nghĩ hữu ích là: mỗi câu trả lời AI có một testing budget. Câu trả lời ít rủi ro có thể chỉ cần đọc lại nhanh. Nếu bạn nhờ AI viết lại meeting note cho rõ hơn, bạn có thể đối chiếu với bản gốc rồi dùng. Nhưng nếu bạn hỏi liệu một database index có sửa được bottleneck production không, ngân sách kiểm chứng phải lớn hơn. Bạn cần query plan, hình dạng dữ liệu thật, chi phí ghi, và có thể cần đo ở staging. Độ lớn của bài test nên đi theo cái giá của việc sai.
Đó là nơi trách nhiệm của con người vẫn hiện rõ. Con người không cần tự viết từng câu hay từng dòng code. Nhưng con người cần quyết định AI vừa đưa ra loại claim nào. Nó đang claim một fact? Hãy kiểm tra nguồn. Nó đang claim một chẩn đoán? Hãy reproduce symptom. Nó đang claim một code change là an toàn? Hãy chạy test liên quan và xem edge case. Nó đang claim một hướng product? Hãy so với user context, business constraint và những người sẽ sống cùng quyết định đó.
Tôi thích một workflow nhỏ cho việc này. Trước hết, gọi tên claim bằng ngôn ngữ rất thường. Ví dụ: bug đăng nhập xảy ra vì refresh token hết hạn trước khi client kịp cập nhật. Tiếp theo, gọi tên điều sẽ tốn kém nếu claim đó sai. Có thể user vẫn bị logout, có thể security boundary yếu đi, có thể team mất nửa ngày sửa nhầm layer. Sau đó, chọn bài test nhỏ nhất có thể thách thức câu trả lời. Trong ví dụ này, hãy kiểm tra token timestamp, reproduce session flow, và thêm một failing test quanh expiry behavior trước khi đổi implementation.
Phần quan trọng là bài test phải xảy ra bên ngoài model. Nhờ AI xác nhận lại chính câu trả lời của nó có thể hữu ích để tìm assumption, nhưng chưa đủ. Model có thể diễn đạt lại cùng một pattern hợp lý với giọng tự tin hơn. Evidence phải đến từ hệ thống, tài liệu, dữ liệu, cuộc trò chuyện với khách hàng, hoặc domain rule mà team thật sự sở hữu.
Điều này càng quan trọng khi câu trả lời nghe rất senior. AI giỏi tạo ra hình dáng của expertise: giọng điệu cẩn thận, ngôn ngữ trade-off, một danh sách risk gọn gàng, và kết luận bình tĩnh. Hình dáng đó có thể giúp mình suy nghĩ, nhưng cũng có thể làm mình dừng sớm một bước. Một câu trả lời bóng bẩy về payment retry policy vẫn cần kiểm tra idempotency. Một lời giải thích gọn về điều khoản pháp lý vẫn cần người có chuyên môn đọc. Một bản tóm tắt chắc chắn về customer feedback vẫn cần ví dụ từ ticket gốc. Fluency làm giảm ma sát, không làm giảm trách nhiệm.
Kiểm chứng câu trả lời AI cũng bảo vệ việc học. Nếu mình nhận một gợi ý mà không kiểm tra, có thể task vẫn xong, nhưng phần hiểu biết bị bỏ qua. Nếu mình kiểm chứng, mình học được điều bền hơn: assumption nào đúng, edge case nào quan trọng, system boundary thật sự nằm ở đâu. Bài test biến sự tự tin đi mượn thành hiểu biết chung của team.
Team có thể làm thói quen này nhẹ hơn bằng cách đưa verification vào workflow thay vì để nó thành việc tự nhớ của từng người. Một PR có dùng AI có thể nói phần nào được generate, phần nào đã manual check, test nào được thêm, và claim nào còn chưa chắc. Một product note có thể tách option do AI draft khỏi evidence đã được validate từ customer. Một support workflow có thể hiển thị đoạn nguồn đứng sau câu trả lời được gợi ý. Những dấu vết nhỏ này làm trách nhiệm dễ được chia sẻ hơn.
Có một con đường rất bình tĩnh ở giữa. Mình không cần từ chối câu trả lời AI cho đến khi nó hoàn hảo, và cũng không cần chấp nhận nó chỉ vì nó đến nhanh. Mình có thể xem nó như một bản nháp hữu ích cần bài test đúng mức. Đôi khi bài test đó là một lần đọc kỹ. Đôi khi nó là benchmark, source check, unit test, staging run, hoặc một cuộc trao đổi với người gần vấn đề hơn.
Thói quen này đơn giản nhưng không nhỏ: trước khi hành động theo một câu trả lời AI, hãy hỏi điều gì cần đúng để việc này an toàn. Rồi tìm một cách thực tế để kiểm tra điều đó. Qua thời gian, câu hỏi ấy trở thành muscle memory của team. Nó giữ AI hữu ích mà không để AI âm thầm lấy mất phần phải thuộc về engineering con người: chịu trách nhiệm với hệ quả của câu trả lời. Nếu nhìn lại câu trả lời AI gần nhất bạn đã dùng trong công việc, bạn nghĩ nó xứng đáng với kiểu kiểm chứng nào?