Claude có thực sự làm gia tăng lỗi trong phần mềm rsync?

Vào cuối tháng 5 năm 2026, cộng đồng công nghệ đã chứng kiến một làn sóng phẫn nộ nhắm vào công cụ đồng bộ hóa dữ liệu nổi tiếng rsync. Mọi chuyện bắt đầu từ một bài đăng trên Mastodon đưa ra mối tương quan giả tạo giữa việc rsync gặp lỗi sau khi nâng cấp và việc phiên bản đó chứa các commit được viết bởi Claude (mô hình AI của Anthropic). Bài đăng này nhanh chóng lan truyền, thu hút hàng nghìn lượt thích và chia sẻ, dù không hề có bằng chứng xác thực.

Từ mạng xã hội, sự giận dữ chuyển sang GitHub dưới dạng một issue mang tên "Please Do Not Vibe Fuck Up This Software" (Xin đừng làm hỏng phần mềm này theo kiểu vibe). Issue này không chứa báo cáo lỗi kỹ thuật nào, chỉ kèm theo ảnh chụp màn hình bài đăng Mastodon và hơn 350 bình luận. Cuộc tranh luận nhanh chóng leo thang từ lo ngại hợp lý thành quấy rối và đe dọa bạo lực đối với người bảo trì dự án.

Vấn đề trên GitHub về việc sử dụng Claude

Để đi đến tận cùng vấn đề thay vì tranh cãi dựa trên cảm tính, một phân tích dữ liệu chi tiết đã được thực hiện. Mục tiêu là trả lời câu hỏi: Liệu việc sử dụng Claude có thực sự làm tăng số lượng lỗi (bugs) trong rsync hay không?

Phương pháp phân tích

Để đánh giá khách quan, phân tích này sử dụng chỉ số "số lỗi trên 10 commit" (bugs/10c). Cách tính này giúp chuẩn hóa dữ liệu, loại bỏ sự chênh lệch về quy mô giữa các bản phát hành (release). Mỗi lỗi được ghi nhận trên GitHub, mailing-list hoặc Bugzilla sẽ được gán cho bản phát hành gần nhất trước thời điểm lỗi đó được báo cáo.

Các bản phát hành có chứa code của Claude (được gọi là "Claude releases") sẽ được so sánh với toàn bộ lịch sử phát hành của rsync để xem liệu chúng có phải là những điểm bất thường (outliers) hay không.

Kết quả thống kê

Khi nhìn vào dữ liệu, hai bản phát hành có sự tham gia của Claude không hề nằm trong nhóm có tỷ lệ lỗi cao nhất. Thực tế, chúng nằm ngay trong khoảng trung bình của lịch sử dự án.

Để kiểm chứng tính ngẫu nhiên, các bài kiểm định thống kê như Exact Permutation Test và Fisher's exact test đã được áp dụng. Kết quả cho thấy giả thuyết "Claude làm cho bản phát hành tồi tệ hơn" không có cơ sở thống kê. Nếu bạn chọn ngẫu nhiên hai bản phát hành bất kỳ từ lịch sử, khả năng bạn chọn được một cặp bản có tỷ lệ lỗi tệ bằng hoặc tệ hơn nhóm Claude là gần 50%.

Biểu đồ phân phối tỷ lệ lỗi của các bản phát hành rsync

Trên biểu đồ phân phối, các bản phát hành của Claude (được đánh dấu màu xanh) đều nằm trong phạm vi tứ phân vị (IQR) — tức là mức độ lỗi hoàn toàn bình thường so với lịch sử.

Giải thích sự thay đổi

Một lập luận thường gặp là các bản phát hành gần đây (v3.x) vốn dĩ đã ổn định hơn so với thời kỳ đầu (v2.x), nên việc so sánh với toàn bộ lịch sử là không công bằng. Tuy nhiên, dữ liệu cho thấy điều ngược lại.

Thực tế, phiên bản v3.x có tỷ lệ lỗi trung bình cao hơn v2.x do bản chất bảo trì và thay đổi mã nguồn phức tạp hơn. Ngay cả khi chỉ so sánh trong kỷ nguyên v3.x, các bản có Claude vẫn nằm ở mức trung bình hoặc tốt hơn. Bản phát hành tồi tệ nhất trong lịch sử rsync thực tế lại xảy ra lâu trước khi Claude được đưa vào sử dụng, nhưng khi đó không có ai gây áp lực hay đe dọa "fork" dự án cả.

Nguyên nhân thực sự của sự thay đổi

Vậy tại sao cộng đồng lại cảm thấy rsync đang đi xuống? Một yếu tố gây nhiễu quan trọng đã bị bỏ qua: sự gia tăng của các báo cáo bảo mật.

Các bình luận đe dọa bạo lực trên GitHub

Chuỗi nguyên nhân thực sự được mô tả như sau: Sự xuất hiện của các công cụ AI đã dẫn đến việc phát hiện ra hàng loạt lỗ hổng bảo mật (CVE) trong rsync. Điều này buộc các nhà phát triển phải thực hiện hàng loạt thay đổi mã nguồn lớn và nhanh chóng để vá lỗi, làm thay đổi bề mặt tấn công của phần mềm. Chính sự thay đổi nhanh chóng để đáp ứng các vấn đề bảo mật mới này đã dẫn đến việc gia tăng các lỗi phát sinh (regressions), chứ không phải do Claude viết code sai.

Như chính người bảo trì dự án (Tridge) đã chia sẻ, bối cảnh bảo mật phần mềm đã thay đổi hoàn toàn trong vài tuần qua. Ông khẳng định mình hiểu rõ cách LLM hoạt động và vẫn sử dụng chúng một cách thận trọng như một công cụ hữu ích trong bối cảnh mới, thay vì từ chối chúng dựa trên những định kiến lỗi thời.

Kết luận, làn sóng tẩy chay rsync không dựa trên thực tế kỹ thuật mà xuất phát từ định kiến chống AI. Dữ liệu chứng minh rằng Claude không làm rsync trở nên tồi tệ hơn; nó chỉ là một công cụ trong tay các nhà phát triển đang phải đối mặt với áp lực bảo mật chưa từng có.