Nguyen Le PhongNguyen Le Phong

Dùng AI đọc codebase, nhưng đừng giao luôn việc hiểu

AI có thể mở nhanh những cánh cửa đầu tiên trong codebase; hiểu đúng vẫn cần giả thuyết bám vào mã nguồn, kiểm chứng trực tiếp và phán đoán của người đọc.

README kể một câu chuyện khá mạch lạc. Cây thư mục cũng có vẻ ngay ngắn. Nhưng sau một giờ trong codebase lạ, hành vi thật vẫn nằm rải qua route, service, adapter, fixture và những quyết định cũ mà không file nào kể trọn. Ở đúng khoảnh khắc chưa biết nên mở cánh cửa nào trước, AI có thể giúp người đọc bớt mò mẫm.

Một người xem cây thư mục trên laptop và vẽ sơ đồ luồng trên giấy; bên cạnh là một màn hình khác.
Một bản đồ ban đầu giúp việc đọc bớt mông lung, nhưng từng đường nối vẫn cần được kiểm tra trong mã nguồn.

Giá trị rõ nhất của AI nằm ở lượt đọc đầu. Có thể nhờ nó tóm tắt một module, gợi ý entry point, liệt kê các file liên quan hoặc phác lại đường đi của một request. Câu trả lời ấy không phải hiểu biết hoàn chỉnh. Nó chỉ cho ta vài cánh cửa đáng mở trước, thay vì bước vào mọi hành lang cùng lúc.

Rủi ro cũng nằm ngay ở ưu điểm đó: lời tóm tắt trôi chảy thường đến sớm hơn sự hiểu biết. Model có thể gọi tên một mẫu kiến trúc mà code chỉ tuân theo một nửa. Nó có thể bỏ sót feature flag, nhánh fallback hay test helper khiến hành vi production khác với luồng chính. Câu chữ càng ngăn nắp, người đọc càng dễ quên rằng code thật có thể rối hơn nhiều.

Cách dùng an toàn là coi đầu ra của AI như kế hoạch đọc, không phải phán quyết. Nếu công cụ bảo luồng thanh toán đi qua ba service, hãy mở ba service đó. Nếu nó nói queue có tính idempotent, hãy tìm khóa idempotency và logic retry. Nếu một module bị gắn nhãn legacy, hãy yêu cầu chỉ ra căn cứ. Phần đáng giá không chỉ là bản tóm tắt, mà là tốc độ tạo ra những giả thuyết có thể kiểm chứng.

Prompt tốt vì thế phải cụ thể và buộc câu trả lời bám vào mã nguồn. Thay vì “giải thích repo này”, hãy hỏi: “Lần theo một đơn hàng từ HTTP request tới thao tác ghi database, rồi liệt kê file và hàm dùng làm bằng chứng.” Thay vì “thiết kế này có tốt không”, hãy hỏi: “Luật nghiệp vụ được giữ ở đâu, caller nào có thể đi vòng qua?” Câu hỏi càng có đường kiểm tra, câu trả lời càng khó trôi sang nhận xét theo cảm giác.

AI còn hữu ích khi so sánh: đối chiếu hai module gần giống nhau, tìm cách đặt tên không nhất quán, hoặc chỉ ra những test đang diễn tả cùng một hành vi bằng hai cách gọi nội bộ khác nhau. Đọc codebase không chỉ là hiểu từng file riêng lẻ. Nó còn là nhận ra các hình dạng lặp lại và xác định chúng được thiết kế có chủ ý hay tích tụ ngẫu nhiên.

Dù vậy, có những vùng cần con người đọc chậm và đọc tận nơi. Ranh giới bảo mật, dòng tiền, xóa dữ liệu, migration và phân quyền không nên dựa vào một bản tóm tắt dù nghe hợp lý đến đâu. AI có thể gom ngữ cảnh, nhưng mã nguồn, test, log và hành vi production mới là nơi giữ bằng chứng cuối cùng.

Một quy trình lành mạnh cho AI mở rộng vùng tìm kiếm, rồi dùng editor, test và phán đoán để thu hẹp điều ta dám khẳng định. Ghi riêng điều đã kiểm chứng và điều vẫn còn chưa chắc. Khi chia sẻ với đồng đội, nói rõ đâu là gợi ý của công cụ, đâu là kết luận đã được mã nguồn chứng minh.

AI có thể làm giờ đầu trong codebase bớt cô độc, nhất là với người mới. Nhưng mô hình trong đầu vẫn phải được xây bằng việc quay lại mã nguồn, lần theo hành vi và sửa những giả định sai. Công cụ đưa ta tới cánh cửa nhanh hơn; phần hiểu căn phòng phía sau vẫn là việc của người đọc.

Bạn thấy bài viết thế nào?