Nhận một task điều tra: để AI làm hộ, hay để AI làm cùng?

Từ hồi có AI, mỗi lần nhận task điều tra mình thấy nhẹ người hẳn. Một con bug ai đó vừa report, một đoạn logic cũ rích chẳng rõ nó làm gì, hay kiểu sếp ném qua "check giúp xem chỗ này tính có đúng không"... mở chat lên hỏi vài câu là có cái để bắt đầu.

Nhưng để ý kỹ thì dân dev mình chia làm hai phe.

Phe một để AI làm hộ: copy code quăng vào, "fix giúp tao", nó trả về gì dán nấy. Phe hai coi AI như đứa ngồi cạnh phụ việc, người điều tra vẫn là mình, nó chỉ gánh đỡ mấy phần nặng. Nhìn bề ngoài thì giống y nhau, ai cũng đang "dùng AI". Nhưng tới lúc có người quay sang hỏi "ủa sao nó lỗi vậy em", phe một hay đứng hình, còn phe hai trả lời được. Đơn giản vì phe một có hiểu gì đâu mà trả lời.

Bài này mình kể cách làm theo phe hai.

Đừng mở AI vội

Cái sai mình thấy nhiều nhất (hồi xưa mình cũng y vậy) là vừa đọc xong ticket đã quăng code vào hỏi liền. Khoan.

Trước tiên phải biết rõ mình đang đi tìm cái gì. Nghe sáo chứ "điều tra" mà không có câu hỏi cụ thể thì lạc nhanh lắm. Là bug thì câu hỏi nằm ở chỗ: đáng lẽ phải ra cái gì, mà đang ra cái gì. Còn nếu chỉ là đọc hiểu một đoạn logic, câu hỏi có thể là "cái này quyết định dựa trên gì", "gặp case kia thì nó rẽ nhánh nào", hay thẳng luôn "logic này đúng hay sai, sai ở input nào". Hỏi mù mờ thì đừng trông mong câu trả lời rõ ràng.

Quan trọng hơn cả là phải có một ca cụ thể để bám. Cả mình lẫn AI đều dễ chém gió trên lý thuyết kinh khủng, nên lúc nào cũng cần một thứ thật để đối chiếu. Bug thì reproduce cho ra. Logic thì lấy một bộ input cụ thể rồi tự tay lần theo code, hoặc viết đại cái test xem nó nhả ra gì. Có cái mỏ neo đó rồi mới biết một lời giải thích là đúng thật hay chỉ nghe lọt tai.

Làm xong hai cái đó thì gom đồ nghề về một chỗ: code liên quan, log, stack trace nếu có, lỗi bắt đầu từ bản nào, đang chạy version gì. Lát đưa hết cho AI.

AI chỉ ngon bằng đúng context bạn đưa nó

Đây là chỗ ăn thua. Cái prompt chắc ai cũng từng gõ:

"Đoạn code này bị bug, fix giúp tao: [dán cả function]"

Mà AI có thấy bug đâu, nó chỉ thấy code thôi. Thế là nó đoán đại một cái "bug" nghe cho có lý, thường là mấy thứ vô thưởng vô phạt như thiếu null check, thiếu try-catch. Bạn dán vào, bug thật vẫn nằm im cười khẩy.

Đổi sang một prompt có đầu có đuôi:

"Function này tính phí ship. Expected: đơn nhiều kho thì cộng phí từng kho. Actual: thỉnh thoảng phí đơn này bị cộng nhầm sang đơn khác trong cùng batch. Reproduce: chạy batch 2 đơn, đơn thứ 2 ra số sai. Stack Node 18, input đầu vào tao check rồi, đúng. Code đây [...], log đây [...]. Liệt kê giúp tao mấy giả thuyết về nguyên nhân, xếp theo độ khả nghi."

Vẫn con AI đó mà kết quả một trời một vực. Nên nói thật, cái gọi là "biết xài AI" phần lớn là chịu khó dọn context cho tử tế, chứ chẳng phải đi lùng mấy câu prompt thần thánh.

Đọc hiểu logic cũng y vậy. Đưa code, hỏi câu cụ thể, kèm một ca ví dụ: "Đoạn này quyết định user có được giảm giá không. Với một user hạng bạc, mua 3 món, cầm 1 voucher, lần giúp tao xem nó đi qua những nhánh nào và chốt dựa trên điều kiện gì." Hỏi vậy nó bám code mà giải thích, chứ không phun ra một bài chung chung chỗ nào đọc cũng thấy đúng.

Bảo nó điều tra, đừng xin nó cái fix

Chuyện nhỏ mà khác biệt lớn. Đừng "fix giúp tao", hãy lôi nó vào điều tra chung:

• Liệt kê mấy khả năng có thể gây ra cái này coi.

• Dữ liệu chạy qua function này thế nào khi input là X?

• Đoạn logic này thật ra đang quyết định dựa trên những điều kiện nào?

• Nếu giả thuyết của tao đúng thì tới dòng kia biến này phải bằng mấy?

• Nên log chỗ nào để xác nhận hoặc loại được cái nghi ngờ này?

Hỏi cỡ đó thì người cầm trịch vẫn là bạn, AI chỉ phụ. Còn cứ xin sẵn một câu chốt, cái fix để dán hay câu "logic này ổn rồi" để yên tâm, rồi tin luôn, thì bạn đang đặt cược vào thứ mình không hiểu. Mà mấy vụ cược kiểu đó hay nổ đúng lúc xui nhất.

Điều tra là vòng lặp, không phải một câu hỏi

Cái này nhiều người bỏ qua: hỏi AI một phát rồi tin sái cổ là cách đi trật nhanh nhất. Điều tra ngon là một vòng lặp ngắn, quay đi quay lại với dữ liệu thật.

Mấu chốt ở chỗ feed kết quả thật ngược lại cho nó. AI lý luận trên giả định thì giỏi, nhưng nó không chạy được code của bạn. Mỗi lần bạn ném vào một con số thật, giá trị biến lúc chạy, một dòng log thật, là chặt bớt được cả mảng phỏng đoán của nó. Vài vòng như vậy là khoanh đúng chỗ, thay vì ôm về một đống giả thuyết nghe hay mà chẳng dẫn tới đâu.

Mấy việc lặt vặt tốn thời cứ giao thẳng cho AI

Có những việc AI nó làm nhanh hơn mình rất nhiều, không xài thì phí:

• Cày cái log mấy trăm dòng rồi lọc ra chỗ bất thường.

• Giải thích đoạn legacy hay cái thư viện lạ mình chưa đụng bao giờ.

• Viết test để chốt behavior, tái hiện bug hoặc xác nhận đoạn logic chạy đúng/sai như mình nghĩ.

• Lần luồng dữ liệu chạy lòng vòng qua mấy file.

• Soi lại cái fix của mình: sửa vầy có làm ảnh hưởng các logic nào khác không.

Verify — đừng tin cái giọng tự tin

Điều này phải khắc cốt: AI nói sai với giọng tự tin y hệt lúc nói đúng. Nó có thể bịa tên API, đoán nhầm hành vi thư viện, sửa nhầm chỗ. Nên mọi thứ nó khẳng định, bạn verify lại bằng chính codebase và bằng kết quả chạy thật.

Và mục tiêu cuối luôn là root cause, không phải triệu chứng. Trước khi kết thúc investigate, tự hỏi: mình có giải thích được tại sao bug xảy ra không, hay chỉ thấy nó biến mất? Nếu chỉ là biến mất mà không hiểu vì sao, khả năng cao nó sẽ trở lại.

Chốt lại cho gọn để người khác hiểu

Một cái chốt tử tế, dù là mô tả PR, comment trong ticket, xuất ra file markdown summary thông tin, nên gói được: vấn đề (hoặc câu hỏi) là gì, mình tìm ra cái gì và vì sao chắc, đã làm hoặc đề xuất gì, kiểm bằng cách nào, có đụng tới chỗ nào khác không.

Khâu này AI gánh hộ được luôn. Hiểu rồi thì nhờ nó viết lại cho mượt là chuyện dễ dàng. Nhưng để ý thứ tự: hiểu trước đã, rồi mới nhờ viết. Làm ngược lại, bắt AI viết kết luận cho thứ mình còn mù tịt, thì đọc trơn tru thật đấy mà rỗng, và bể ngay khi có ai hỏi sâu một câu.

Nói cho cùng, làm hộ hay làm cùng không nằm ở chỗ bạn gõ prompt khéo cỡ nào, mà ở chỗ bạn có chịu ôm lấy phần khó hay không. Phần cày nhiều, đọc nhiều, phần tốc độ thì cứ đẩy cho AI. Phần phán đoán, kiểm chứng, quyết định thì giữ lại cho mình. Giữ được vậy thì task điều tra nào cũng nhẹ đi, và quan trọng là lúc bị hỏi, bạn nói được vì sao, chứ không lí nhí "dạ nó hết lỗi rồi anh".