Vấn đề "Over-Editing": Tại sao các mô hình AI lập trình lại viết quá nhiều code không cần thiết?

Trong kỷ nguyên lập trình được hỗ trợ bởi AI, các công cụ như Cursor, GitHub Copilot hay Claude Code đã trở thành những trợ thủ đắc lực không thể thiếu. Tuy nhiên, bất kỳ lập trình viên nào sử dụng các công cụ này trong năm qua có lẽ đều từng trải qua một tình huống khó chịu: bạn yêu cầu mô hình sửa một lỗi đơn giản (ví dụ: sai một toán tử hoặc lỗi off-by-one), và dù nó sửa được lỗi đó, nhưng kết quả trả về lại đi kèm với việc viết lại một nửa hàm function.

Ví dụ về Over-editing

Các hàm helper mới xuất hiện, tên biến hợp lý bị đổi, các kiểm tra đầu vào mới được thêm vào, và diff (thay đổi) trở nên khổng lồ. Đây là vấn đề được gọi là Over-Editing (Chỉnh sửa quá mức), nơi các mô hình có xu hướng viết lại những đoạn code không cần thiết. Vấn đề này quan trọng hơn ta tưởng rất nhiều, bởi code review vốn dĩ là một nút thắt cổ chai trong quy trình phát triển phần mềm. Khi một mô hình viết lại toàn bộ hàm function, ngay cả khi đúng, nó cũng khiến công việc review trở nên khó khăn gấp bội vì code trở nên hoàn toàn khác biệt so với bản gốc.

Over-editing là gì?

Over-editing đề cập đến việc mô hình sửa đổi code vượt quá mức cần thiết để giải quyết vấn đề. Cụ thể, một mô hình bị coi là over-editing nếu đầu ra của nó đúng về mặt chức năng nhưng lại khác biệt về cấu trúc so với code gốc nhiều hơn mức sửa đổi tối thiểu yêu cầu.

Kỹ thuật phần mềm broadly chia làm hai chế độ: Green-field (xây dựng mới từ con số 0) và Brown-field (làm việc trên codebase hiện hữu). Trong bối cảnh Brown-field, code hiện hữu đã được đội ngũ hiểu rõ và được viết có chủ đích theo cách nhất định. Nhiệm vụ của mô hình là sửa lỗi và chỉ có vậy thôi. Over-editing là một thất bại trong bối cảnh Brown-field, và không giống như các lỗi chức năng, nó vô hình với các bộ test.

Đo lường mức độ Over-editing

Để nghiên cứu vấn đề này, chúng ta cần một bộ dữ liệu (dataset) nơi "sự thật cơ bản" (ground truth) được xác định rõ ràng. Thay vì sử dụng một LLM khác để tạo ra lỗi bug (như hầu hết các benchmark hiện tại), nghiên cứu này đã lập trình làm hỏng 400 vấn đề từ BigCodeBench. Các lỗi này rất tinh vi như đảo ngược toán tử so sánh, thay đổi giá trị boolean, hoặc xóa một dòng quan trọng.

Để đo lường mức độ thay đổi, nghiên cứu sử dụng hai chỉ số chính:

• Khoảng cách Levenshtein chuẩn hóa: Đo lường số lượng thay đổi ký tự cần thiết để biến code gốc thành code của mô hình.
• Độ phức tạp nhận thức (Cognitive Complexity) được thêm vào: Đo lường độ khó của logic flow control. Vì các lỗi được tạo ra chỉ thay đổi giá trị chứ không thay đổi cấu trúc, bản sửa đúng nên không làm tăng độ phức tạp này.

Các mô hình có Over-editing không?

Câu trả lời là Có, ngay cả với các mô hình tiên phong nhất (frontier models).

So sánh các mô hình

Trong số các mô hình mới nhất, GPT-5.4 over-editing nhiều nhất với khoảng cách Levenshtein là 0.39 (chế độ reasoning) và độ phức tạp nhận thức tăng thêm là 2.31. Ngược lại, Claude Opus 4.6 đạt điểm Pass@1 cao nhất (0.912) đồng thời tạo ra các diff nhỏ nhất với Levenshtein chỉ 0.06. Điều này cho thấy không phải mọi mô hình tiên phong đều mắc phải tật sửa quá nhiều code.

Một phát hiện thú vị là so sánh giữa các Mô hình Reasoning (có khả năng suy luận) và Non-reasoning. Trong cài đặt mặc định, các mô hình reasoning có xu hướng over-editing nhiều hơn đối tác non-reasoning của chúng. Có vẻ như khả năng suy luận mở rộng khiến các mô hình này tìm cách "cải tiến" code theo cách chúng cho là tốt hơn, thay vì chỉ sửa lỗi tối thiểu.

Prompting có giúp ích không?

Nhiều nghiên cứu thường bỏ qua việc kiểm tra xem mô hình có thể thực hiện nhiệm vụ khi được yêu cầu trực tiếp hay không. Khi thêm hướng dẫn rõ ràng vào prompt: "QUAN TRỌNG: Hãy cố gắng giữ nguyên code gốc và logic của code gốc càng nhiều càng tốt", mọi mô hình đều cải thiện và giảm khoảng cách Levenshtein.

Hiệu ứng này đặc biệt rõ rệt ở các mô hình reasoning. Một cách giải thích là ràng buộc về việc sửa đổi tối thiểu vô tình thu hẹp không gian tìm kiếm các giải pháp sửa lỗi, dẫn các mô hình đến những thay đổi chính xác, có mục tiêu hơn và có khả năng đúng hơn.

So sánh Reasoning vs Non-reasoning

Huấn luyện mô hình để sửa lỗi tối thiểu

Câu hỏi tự nhiên tiếp theo là: Liệu chúng ta có thể huấn luyện (train) các mô hình để trở thành những "biên tập viên" trung thực hơn không? Nghiên cứu này đã thử nghiệm các phương pháp như SFT (Supervised Fine-Tuning), DPO (Direct Preference Optimization) và RL (Reinforcement Learning).

Kết quả cho thấy Reinforcement Learning (RL) là phương pháp hiệu quả nhất. RL không chỉ giúp mô hình học được hành vi chỉnh sửa tối thiểu mà còn tổng quát hóa tốt mà không gây ra hiện tượng "Quên lãng thảm khốc" (Catastrophic Forgetting) – tức là không làm giảm khả năng lập trình chung của mô hình. Ngược lại, phương pháp SFT đơn giản lại dẫn đến việc mô hình học vẹt các thay đổi cụ thể và thất bại trong việc tổng quát hóa sang các loại lỗi mới.

Ngoài ra, việc sử dụng LoRA (Low-Rank Adaptation) cũng cho thấy hiệu quả tích cực. Vì nhiệm vụ này ít liên quan đến việc dạy kiến thức mới mà nhiều hơn là điều chỉnh phong cách trên một nhiệm vụ hiện có, LoRA với rank 64 gần như khớp với hiệu suất của full RL nhưng rẻ hơn và nhanh hơn đáng kể.

Kết luận

Over-editing là một vấn đề phổ biến và có thể đo lường được. Tuy nhiên, kết quả từ việc prompting cho thấy đây không phải là một hạn chế về khả năng cốt lõi. Đặc biệt đối với các mô hình reasoning, một hướng dẫn đơn giản để giữ nguyên code gốc dẫn đến các bản chỉnh sửa trung thực hơn nhiều.

Các kết quả huấn luyện cũng cho thấy hành vi này có thể được cải thiện thông qua Reinforcement Learning, tạo ra các biên tập viên AI trung thực hơn mà không làm giảm khả năng lập trình chung. Trong bối cảnh các mô hình lập trình ngày càng tạo ra nhiều code hơn, việc giải quyết vấn đề over-editing là chìa khóa để duy trì chất lượng codebase và giảm bớt gánh nặng cho các lập trình viên trong quá trình review.