Refactor bắt đầu bằng một nhận xét nhỏ trong code review: function này đang làm quá nhiều việc. Ai cũng đồng ý. Rồi có người mở file ra và nhớ vì sao nhiều tháng rồi không ai đụng vào nó. Function đó xử lý validation, mapping, logging, fallback behavior, và một edge case lạ từ lần migration customer cũ. Nó không phải không thể cải thiện. Nó chỉ đủ đặc để bước an toàn đầu tiên khó nhìn thấy.
Đây là một chỗ AI thật sự có ích. Không phải như thứ thay thế engineering judgment, và cũng không phải nút bấm thần kỳ để dọn sạch codebase. AI hữu ích vì refactoring thường bắt đầu bằng hiểu biết. Model có thể giúp tóm tắt function dài, gọi tên responsibility, nhận ra pattern lặp lại, đề xuất seam để extract, và biến cảm giác mơ hồ rằng code đang rối thành vài change set cụ thể để engineer đánh giá.
Prompt tốt hiếm khi là rewrite đoạn này cho sạch hơn. Câu đó mời model tối ưu cho vẻ ngoài. Request tốt hơn sẽ đặt boundary: preserve behavior, không đổi public contract, xác định test trước, tách mechanical change khỏi behavioral change, và giải thích evidence cho từng bước. Refactoring không phải làm code trông ấn tượng hơn. Nó là đổi cấu trúc trong khi giữ lời hứa phần mềm đang có.
AI có thể giúp tạo bản đồ trước khi sửa dòng đầu tiên. Nó có thể liệt kê input và output, side effect, external dependency, assumption ẩn, và nơi error đang bị nuốt. Bản đồ đó có giá trị vì nhiều refactor xấu thất bại trước khi coding bắt đầu. Engineer đổi hình dạng code mà chưa thấy behavior hình dạng đó đang âm thầm bảo vệ.
AI cũng có thể giúp tạo characterization test. Trước khi đổi legacy code, vài test ghi lại behavior hiện tại có thể biến nỗi sợ thành thông tin. Model có thể đọc example, suy ra edge case, và đề xuất scenario: input rỗng, duplicated record, thiếu permission, provider timeout, status bất ngờ, data shape cũ. Engineer vẫn phải verify test có ý nghĩa, nhưng AI giảm chi phí trang trắng khi quyết định bắt đầu từ đâu.
Với mechanical refactor, AI tiết kiệm thời gian khá rõ. Rename một concept nhất quán, extract helper, tách conditional dài, chuyển branch lặp thành table, hoặc đưa code sau một interface nhỏ là những việc model cẩn thận có thể draft phần lớn patch. Từ quan trọng là cẩn thận. Diff vẫn cần human review vì một refactor đổi một comparison, một default value, hoặc một error path thì không còn chỉ là refactor nữa.
Nguy hiểm là AI rất giỏi tạo code trông mạch lạc. Nó có thể xóa một branch vì branch đó có vẻ redundant, không phải vì có evidence. Nó có thể làm đơn giản retry path từng tồn tại vì vendor hành xử xấu vào một tình huống hiếm. Nó có thể rename field ở một layer và bỏ sót serialized contract. Nó có thể tạo abstraction nhìn đẹp nhưng làm lần debug tiếp theo khó hơn. Refactor với AI nên tăng evidence, không thay thế evidence.
Tôi thấy hữu ích khi yêu cầu AI đưa option thay vì một đáp án. Option A extract pure function. Option B tách adapter khỏi business rule. Option C giữ cấu trúc gần như cũ nhưng thêm test và tên rõ hơn. So sánh option làm trade-off hiện ra. Đôi khi refactor tốt nhất không phải refactor lớn nhất. Đôi khi bước tốt nhất là thêm test, đổi tên hai biến, và để redesign sâu hơn cho lúc team có nhiều context hơn.
Verification là đường ranh giữa hỗ trợ hữu ích và trình diễn rủi ro. Chạy test hiện có. Thêm focused test ở nơi behavior trước đó chưa được che. Đọc diff chậm. Kiểm tra public type, API response, analytics event, migration và failure path. Nếu refactor chạm vào behavior quan trọng, hãy test ở level mà user hoặc system khác thật sự phụ thuộc. AI có thể gợi ý verification command, nhưng engineer sở hữu việc command đó có đủ hay không.
Cũng cần bảo vệ team habit. Nếu mọi người dùng AI để refactor riêng và ship diff lớn bóng bẩy, reviewer có thể khó thấy intent. AI-assisted refactor tốt nên dễ review hơn, không khó hơn. Commit nhỏ, commit message rõ, note trước và sau, cùng test giải thích behavior càng quan trọng hơn khi generation làm edit lớn trở nên rẻ.
AI làm refactoring nhanh hơn khi engineer dùng nó như một trợ lý kiên nhẫn: map code, phơi bày risk, draft thay đổi nhỏ, gợi ý test, và challenge assumption. Nó trở nên nguy hiểm khi được dùng như một stylist có quyền commit. Câu hỏi hữu ích không phải AI có dọn code được không. Câu hỏi là AI có giúp team hiểu code đủ tốt để cải thiện mà không làm mất behavior từng khiến code đó có giá trị hay không.