Love AI
New member
Các bài kiểm tra AI thường chỉ đo xem mã có vượt qua bộ test hiện tại hay không, nhưng điều đó không phản ánh chất lượng dài hạn của code. Một nghiên cứu mới chỉ ra AI có thể tạo ra mã ngày càng khó bảo trì dù vẫn 'xanh' trên CI.
Nhiều bộ benchmark đánh giá AI lập trình chỉ hỏi một câu: agent có tạo ra mã vượt qua các test hiện tại hay không? Đây là câu hỏi hữu ích nhưng quá hẹp. Phát triển phần mềm là một quá trình lặp: yêu cầu thay đổi, các trường hợp biên xuất hiện, và các quyết định thiết kế cũ trở thành rào cản cho công việc mới. Mã vượt test hôm nay có thể làm thay đổi tiếp theo chậm và tốn kém hơn, đồng thời tăng rủi ro.
Một bài báo gần đây, SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks (Orlanski et al.), tiến gần hơn tới vấn đề này. Thay vì chấm điểm giải pháp một lần, thử nghiệm buộc agent mở rộng mã do chính nó viết qua 20 bài toán và 93 mốc kiểm tra, mỗi mốc thay đổi yêu cầu. Agent không được bắt đầu lại và không có thiết kế nội bộ để theo, nên nó phải sống chung với các lựa chọn ban đầu.
Bộ test theo dõi hai tín hiệu chất lượng đi kèm với độ chính xác. "Verbosity" đo lượng mã thừa hoặc trùng lặp. "Structural erosion" đo mức độ phức tạp bị dồn vào các hàm đã quá cồng kềnh. Đó là những cách hỏng mà mọi quản lý kỹ thuật đều quen thuộc: hệ thống vẫn vượt test nhưng càng ngày càng nhiều logic bị nhét vào các hàm lớn, càng nhiều trường hợp riêng lẻ bị thêm vào, và để làm tính năng mới cần chỉnh nhiều file hơn.
Kết quả rất rõ ràng. Không agent nào giải quyết được bất kỳ bài toán nào từ đầu đến cuối. Tỷ lệ "strict solve" tốt nhất là 17,2% và tới mốc cuối cùng giảm xuống 0,5%. Trên các luồng thay đổi, "verbosity" tăng trong 89,8% các lần chạy và "structural erosion" tăng trong 80%.
So sánh với mã do con người duy trì càng đáng chú ý hơn. Trên 48 kho mã Python được duy trì, mã do agent sinh ra verbose hơn và bị xói mòn cấu trúc nhiều gấp 2,2 lần. Khi theo dõi 20 kho qua thời gian, mã do con người giữ tương đối ổn định trong khi mã agent ngày càng tệ hơn sau mỗi vòng lặp.
Một ví dụ minh họa là bài toán tìm mã (code-search). Ban đầu hệ thống chỉ cần tìm mã Python bằng tìm chuỗi chính xác hoặc regex. Về sau nó phải hỗ trợ nhiều ngôn ngữ, hiểu cấu trúc mã (ghép AST) và tự sửa lỗi. Nếu thiết kế ban đầu quá chặt và dựa trên giả định hẹp, nó có thể qua được các test ban đầu nhưng rất khó đáp ứng yêu cầu phức tạp hơn sau này.
Với các nhà lãnh đạo QA có hai bài học chính. Thứ nhất: mã sản phẩm do AI tạo có thể xuống cấp sau nhiều thay đổi dù test vẫn xanh. Đội ngũ có thể lầm tưởng kết quả liên tục là dấu hiệu hệ thống khỏe mạnh, trong khi thực tế họ đang tích tụ chi phí lỗi trong tương lai.
Thứ hai: QA giờ đang dùng AI để viết và duy trì test—như tự động hóa UI bằng Playwright—và mô hình suy giảm tương tự vẫn xảy ra. Test suite có thể trở nên verbose và yếu về cấu trúc khi bị chỉnh sửa lặp đi lặp lại bởi công cụ AI. Một test suite xuống cấp còn khó nhận ra hơn mã sản phẩm: pipeline vẫn có thể xanh, coverage trên giấy có vẻ tăng, nhưng các selector kém, kiểm tra yếu, bước test bị sao chép, hàm helper quá lớn hay test chạy chậm sẽ khiến tài sản này ngày càng ít giá trị.
Kết luận và khuyến nghị ngắn: đừng chỉ tin vào việc test có còn xanh hay không. Bổ sung các chỉ số chất lượng dài hạn như độ trùng lặp mã, kích thước và độ phức tạp hàm, số file bị tác động cho mỗi thay đổi. Theo dõi sức khỏe của cả mã sản phẩm lẫn bộ test. Và lưu ý: cải tiến prompt giúp ở giai đoạn đầu nhưng không giải quyết được xu hướng suy thoái lâu dài.
Nguồn: Techradar
Nhiều bộ benchmark đánh giá AI lập trình chỉ hỏi một câu: agent có tạo ra mã vượt qua các test hiện tại hay không? Đây là câu hỏi hữu ích nhưng quá hẹp. Phát triển phần mềm là một quá trình lặp: yêu cầu thay đổi, các trường hợp biên xuất hiện, và các quyết định thiết kế cũ trở thành rào cản cho công việc mới. Mã vượt test hôm nay có thể làm thay đổi tiếp theo chậm và tốn kém hơn, đồng thời tăng rủi ro.
Một bài báo gần đây, SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks (Orlanski et al.), tiến gần hơn tới vấn đề này. Thay vì chấm điểm giải pháp một lần, thử nghiệm buộc agent mở rộng mã do chính nó viết qua 20 bài toán và 93 mốc kiểm tra, mỗi mốc thay đổi yêu cầu. Agent không được bắt đầu lại và không có thiết kế nội bộ để theo, nên nó phải sống chung với các lựa chọn ban đầu.
Bộ test theo dõi hai tín hiệu chất lượng đi kèm với độ chính xác. "Verbosity" đo lượng mã thừa hoặc trùng lặp. "Structural erosion" đo mức độ phức tạp bị dồn vào các hàm đã quá cồng kềnh. Đó là những cách hỏng mà mọi quản lý kỹ thuật đều quen thuộc: hệ thống vẫn vượt test nhưng càng ngày càng nhiều logic bị nhét vào các hàm lớn, càng nhiều trường hợp riêng lẻ bị thêm vào, và để làm tính năng mới cần chỉnh nhiều file hơn.
Kết quả rất rõ ràng. Không agent nào giải quyết được bất kỳ bài toán nào từ đầu đến cuối. Tỷ lệ "strict solve" tốt nhất là 17,2% và tới mốc cuối cùng giảm xuống 0,5%. Trên các luồng thay đổi, "verbosity" tăng trong 89,8% các lần chạy và "structural erosion" tăng trong 80%.
So sánh với mã do con người duy trì càng đáng chú ý hơn. Trên 48 kho mã Python được duy trì, mã do agent sinh ra verbose hơn và bị xói mòn cấu trúc nhiều gấp 2,2 lần. Khi theo dõi 20 kho qua thời gian, mã do con người giữ tương đối ổn định trong khi mã agent ngày càng tệ hơn sau mỗi vòng lặp.
Một ví dụ minh họa là bài toán tìm mã (code-search). Ban đầu hệ thống chỉ cần tìm mã Python bằng tìm chuỗi chính xác hoặc regex. Về sau nó phải hỗ trợ nhiều ngôn ngữ, hiểu cấu trúc mã (ghép AST) và tự sửa lỗi. Nếu thiết kế ban đầu quá chặt và dựa trên giả định hẹp, nó có thể qua được các test ban đầu nhưng rất khó đáp ứng yêu cầu phức tạp hơn sau này.
Với các nhà lãnh đạo QA có hai bài học chính. Thứ nhất: mã sản phẩm do AI tạo có thể xuống cấp sau nhiều thay đổi dù test vẫn xanh. Đội ngũ có thể lầm tưởng kết quả liên tục là dấu hiệu hệ thống khỏe mạnh, trong khi thực tế họ đang tích tụ chi phí lỗi trong tương lai.
Thứ hai: QA giờ đang dùng AI để viết và duy trì test—như tự động hóa UI bằng Playwright—và mô hình suy giảm tương tự vẫn xảy ra. Test suite có thể trở nên verbose và yếu về cấu trúc khi bị chỉnh sửa lặp đi lặp lại bởi công cụ AI. Một test suite xuống cấp còn khó nhận ra hơn mã sản phẩm: pipeline vẫn có thể xanh, coverage trên giấy có vẻ tăng, nhưng các selector kém, kiểm tra yếu, bước test bị sao chép, hàm helper quá lớn hay test chạy chậm sẽ khiến tài sản này ngày càng ít giá trị.
Kết luận và khuyến nghị ngắn: đừng chỉ tin vào việc test có còn xanh hay không. Bổ sung các chỉ số chất lượng dài hạn như độ trùng lặp mã, kích thước và độ phức tạp hàm, số file bị tác động cho mỗi thay đổi. Theo dõi sức khỏe của cả mã sản phẩm lẫn bộ test. Và lưu ý: cải tiến prompt giúp ở giai đoạn đầu nhưng không giải quyết được xu hướng suy thoái lâu dài.
Nguồn: Techradar
Bài viết liên quan
