Claude có làm tăng số lỗi của rsync không?

 (alexispurslane.github.io)
2 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Các bản phát hành có Claude hỗ trợ chỉ gồm hai bản rsync v3.4.2 và v3.4.3, và không có bằng chứng cho thấy chúng có nhiều lỗi bất thường hơn các bản phát hành trước đó khi tính theo lỗi có trọng số mức độ nghiêm trọng/10 commit
  • sev/10c là chỉ số cốt lõi chuẩn hóa điểm mức độ nghiêm trọng của lỗi về thang 0~1, cộng theo từng bản phát hành, rồi chia cho số commit và quy đổi thành giá trị trên mỗi 10 commit
  • v3.4.2 có 50 commit, 9 commit của Claude, 0 lỗi, 0.00 sev/10c; còn v3.4.3 có 34 commit, 28 commit của Claude, 17 lỗi, 3.29 sev/10c, nằm kẹp hai phía của IQR và không bên nào là ngoại lệ
  • Giá trị p của kiểm định hoán vị chính xác là 46%, giá trị p của kiểm định chính xác Fisher là 74%, và odds ratio là 1.06, gần như không có tín hiệu cho thấy các bản phát hành có Claude tệ hơn hai bản phát hành ngẫu nhiên hoặc dễ vượt trung vị hơn
  • v3.4.1 là bản phát hành trước khi đưa Claude vào, nhưng vẫn là giá trị tệ nhất toàn bộ dữ liệu với 59 lỗi, 9 commit, 39.39 sev/10c; trọng tâm của tranh cãi rsync nằm ở việc gắn một hồi quy đơn lẻ với Claude mà không xét phân bố lịch sử

Bối cảnh và câu hỏi

  • Cuối tháng 5/2026, tranh cãi rsync bắt đầu từ một bài đăng trên Mastodon liên hệ giữa hồi quy ở v3.4.3 với các commit của Claude trong bản phát hành đó, rồi lan sang Hacker News và issue GitHub "Please Do Not Vibe Fuck Up This Software"; issue này đã tích lũy hơn 300 bình luận
  • Luận điểm cốt lõi lặp đi lặp lại là phát triển có Claude hỗ trợ đã đưa lỗi vào một công cụ vốn ổn định, và câu hỏi dữ liệu là liệu các bản phát hành có Claude hỗ trợ có nhiều lỗi bất thường hơn các bản phát hành lịch sử hay không
  • Trên Lobsters có đề nghị xem biểu đồ thời gian số hồi quy theo từng bản phát hành, và trọng tâm phân tích là một câu hỏi duy nhất: “Các bản phát hành có Claude hỗ trợ có nhiều lỗi bất thường không?”

Phạm vi dữ liệu và khả năng tái lập

  • Dữ liệu gồm 36 bản phát hành từ v2.4.6 đến v3.4.3 của RsyncProject/rsync có dữ liệu lỗi; chỉ có hai bản phát hành có commit của Claude là v3.4.2 và v3.4.3
  • Việc chọn chỉ số, phương pháp luận và nguồn dữ liệu do con người trực tiếp quyết định, có tham khảo ý kiến từ người phối ngẫu có bằng thạc sĩ thống kê
  • Việc thu thập dữ liệu, nạp vào DuckDB, tạo view và viết script phân tích thống kê do GLM 5.1 thực hiện, nhưng mọi con số, thống kê, bảng và biểu đồ đều được script Python chạy phân tích thống kê chèn vào bằng template tự động
  • Kho lưu trữ tái lập alexispurslane/rsync-analysis có thể chạy toàn bộ pipeline từ đầu đến cuối

Chỉ số và cách quy thuộc lỗi

  • Chỉ số cốt lõi là số lỗi có trọng số mức độ nghiêm trọng trên mỗi 10 commit, sev/10c, với công thức sev/10c = (Σ severity/100 ÷ total_commits) × 10
  • Các commit được sắp theo committer date trên nhánh mặc định, và phạm vi mỗi bản phát hành được lấy từ tag trước đó đến tag hiện tại; các tag pre và rc bị loại khỏi ranh giới và được gộp vào bản phát hành cuối cùng
  • Nguồn lỗi gồm issue GitHub, rsync Bugzilla và mailing list của rsync; lỗi từ issue GitHub và mailing list được quy về bản phát hành mới nhất đã phát hành ngay trước thời điểm báo cáo
  • Các mục Bugzilla có trường “Version” chỉ rõ bản phát hành nơi lỗi được báo cáo, nên được quy về đúng bản phát hành đó
  • Lý do chọn phân tích ở cấp bản phát hành là vì chính lời chỉ trích cũng có dạng “toàn bộ bản phát hành có commit của Claude trở nên nhiều lỗi hơn”, và phần lớn lỗi không nêu rõ chính xác bắt nguồn từ commit nào

Cách chấm mức độ nghiêm trọng

  • Tất cả báo cáo lỗi đều được Qwen 3 35B chấm điểm mức độ nghiêm trọng từ 0 đến 100, với prompt giao vai trò kỹ sư độ tin cậy cấp cao nhìn từ góc độ tác động thực tế đến người dùng
  • Mức 90~100 là hỏng dữ liệu âm thầm, mất dữ liệu, thực thi mã từ xa hoặc lỗ hổng bảo mật cho phép truy cập trái phép; 70~89 là crash, treo, sao lưu thất bại hoặc build thất bại; 50~69 là hồi quy chức năng có thể workaround
  • Với Bugzilla và mailing list, chỉ có tiêu đề mà không có nội dung thân bài, nên mô hình chỉ đánh giá dựa trên tiêu đề; nếu thiếu thông tin thì được hướng nghiêng về khoảng trung bình 40~60
  • Đầu ra dùng structured output với JSON schema chỉ cho phép số nguyên mức độ nghiêm trọng, và temperature được cố định ở 0 để cùng một đầu vào cho cùng một điểm số
  • Các issue được chấm 0 điểm như yêu cầu tính năng, spam, phản đối phi kỹ thuật liên quan đến AI, hoặc bản gửi trống sẽ bị loại khỏi tổng số lỗi cơ bản

Kết quả thống kê của các bản phát hành Claude

  • v3.4.2 có 9 commit của Claude trên tổng 50 commit, 0 lỗi thực tế, 0.00 sev/10c, ở phân vị 0
  • v3.4.3 có 28 commit của Claude trên tổng 34 commit, 17 lỗi, 3.29 sev/10c, ở phân vị 77
  • IQR lịch sử là 0.29~2.59 sev/10c; v3.4.2 nằm ngay dưới IQR còn v3.4.3 nằm ngay trên IQR, nên hai bản phát hành này kẹp phần phân bố trung tâm ở hai phía đối nhau
  • Kiểm định hoán vị chính xác cho thấy trong 595 tổ hợp có thể có của 2 bản phát hành, có 272 tổ hợp có trung bình nhóm Claude từ 1.65 sev/10c trở lên, cho ra giá trị p là 46%
  • Kiểm định chính xác Fisher xem liệu các bản phát hành Claude có nằm trên trung vị 0.74 sev/10c thường xuyên hơn không, và cho kết quả giá trị p 74% cùng odds ratio 1.06

Số lượng commit và quy mô thay đổi

  • Các bản phát hành Claude có trung bình 42 commit, trong khi các bản không có Claude có trung bình 185 commit; xác suất để hai bản phát hành ngẫu nhiên có số commit bằng hoặc nhiều hơn như vậy là 88%
  • Theo GitHub compare API, số dòng thay đổi trung bình của các bản phát hành Claude là 3.756 dòng, còn các bản không có Claude là 696 dòng; xác suất để hai bản phát hành ngẫu nhiên có số dòng thay đổi bằng hoặc nhiều hơn như vậy là 5%
  • Số lỗi có trọng số mức độ nghiêm trọng trung bình của các bản phát hành Claude là 5.6, còn các bản không có Claude là 14.9; xác suất để hai bản phát hành ngẫu nhiên có số lỗi có trọng số bằng hoặc nhiều hơn như vậy là 77%
  • Kết luận là các bản phát hành Claude có nhiều dòng thay đổi hơn hẳn, nhưng không có nhiều commit hơn cũng không có nhiều lỗi có trọng số mức độ nghiêm trọng hơn

Hệ phiên bản và các ngoại lệ có từ trước

  • Trung bình các bản phát hành v2.x là 1.11 sev/10c, còn v3.x là 4.23 sev/10c, cho thấy phía v3.x có tỷ lệ lỗi cao hơn
  • Ngay cả khi chỉ so trong v3.x, các bản phát hành Claude vẫn nằm ở nhóm giữa hoặc tốt hơn; để khiến Claude trông như một ngoại lệ thì phải so với một giai đoạn quá khứ yên ắng hơn và quy trách nhiệm cho Claude về sự thay đổi đã xảy ra trước khi Claude xuất hiện
  • Wald–Wolfowitz runs test cho 35 bản phát hành không có Claude cho kết quả 13 run quan sát được, kỳ vọng ngẫu nhiên 18.5, z=-1.88, p=0.060; theo ngưỡng 0.05 thì chưa đủ mạnh để bác bỏ tính ngẫu nhiên
  • v3.4.1 là bản phát hành trước khi có Claude nhưng lại ghi nhận tỷ lệ lỗi cao nhất toàn bộ dữ liệu với 59 lỗi, 9 commit, 39.39 sev/10c
  • v3.4.1 là bản hotfix phát hành ngay ngày hôm sau v3.4.0, có tỷ lệ lỗi cao nhất vượt xa tất cả các bản phát hành khác ít nhất một bậc chữ số, nhưng khi đó chưa có AI nào để bị đổ lỗi

Diễn giải và giới hạn

  • Cách diễn giải phù hợp với dữ liệu là “hai bản phát hành Claude hiện tại không khác biệt có ý nghĩa thống kê so với các bản phát hành lịch sử”
  • v3.4.3 có 3.29 sev/10c và ở phân vị 77 nên là mức cao, nhưng không phải cực trị; có 8 bản phát hành lịch sử đạt điểm cao hơn thế
  • Mệnh đề “Claude rõ ràng đã làm mọi thứ tệ hơn” không được hậu thuẫn bởi phân bố bản phát hành, kiểm định hoán vị hay kiểm định Fisher
  • Ngược lại, cũng không thể rút ra từ dữ liệu này kết luận rằng “commit của Claude nói chung sẽ không làm mọi thứ tệ hơn về sau”; dữ liệu hiện tại chỉ cho thấy hai bản phát hành này nằm trong phạm vi bình thường
  • Chỉ số này có giới hạn là một công cụ khá thô, không kiểm soát được độ phức tạp của commit hay cường độ công việc bảo mật

Các yếu tố gây nhiễu được thảo luận

  • Một người dùng trên Hacker News cho rằng các bản sửa bảo mật để xử lý CVE dường như đã làm lộ ra những lỗi lập trình tồn tại trong mã từ năm 2007
  • Một người dùng trên Lobsters đưa ra chuỗi nhân quả “LLM → tăng các issue bảo mật đã biết → cần nhiều thay đổi hơn bình thường → nhiều hồi quy hơn bình thường”
  • Andrew Tridgell giải thích rằng làn sóng báo cáo CVE do AI tạo ra đã buộc rsync phải thực hiện các thay đổi nhanh và rộng trên bề mặt tấn công của mình
  • Nếu tính cả yếu tố gây nhiễu này, thì vấn đề có vẻ gần với việc phải làm nhiều công việc bảo mật hơn và kéo theo khối lượng thay đổi tăng lên, hơn là do bản thân Claude

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Lobste.rs

  • Tôi nghĩ mỗi người đều có thể tự quyết định có tiếp tục dùng các dự án FOSS được phát triển theo kiểu vibe coding trong tương lai hay không. Tuy vậy, sự phẫn nộ mà cộng đồng thể hiện sau khi maintainer chuyển sang công cụ vibe coding thực sự khá đáng ngạc nhiên, và dữ liệu thực chứng trong bài ít nhất cũng giúp đặt tác động của thay đổi thực hành đó vào bối cảnh rõ ràng hơn
    Còn việc niềm tin sẽ được duy trì hay tiếp tục sụp đổ sau khi maintainer áp dụng cách lập trình này thì phải chờ thời gian trả lời

    • Tôi khá tò mò có bao nhiêu người trong số những người nổi giận vì sự chuyển đổi này thực sự đóng góp đáng kể cho rsync hoặc đã bỏ tiền ra cho nó

  • Phân tích này đúng chính xác điều tôi muốn thấy, và còn hơn thế nữa. Tôi đặc biệt thích đoạn “mọi chỉ số, phương pháp luận và nguồn dữ liệu đều do tôi tự chọn sau khi trao đổi với vợ tôi, người có bằng thạc sĩ thống kê của Penn State University”, và việc có một chuyên gia thống kê thực thụ tham gia cùng cách trình bày dễ đọc là rất xuất sắc
    Họ dùng một chỉ số duy nhất là “số lỗi trên mỗi 10 commit”, nhưng có vẻ đã bỏ lỡ cơ hội dùng tiền tố SI để gọi đó là decibugs trên mỗi commit

    • Đồng ý. Đây không phải bài của tôi, nhưng tôi thích việc có người vượt qua cuộc tranh cãi quá nhiệt theo kiểu ủng hộ/chống đối để cho thấy tác động lên chất lượng mã bằng dữ liệu

  • Thành công của một dự án mã nguồn mở bị chi phối quá nhiều bởi nhận thức, đến mức người ta còn bỏ tiền mua GitHub stars. Đáng tiếc là vấn đề nhận thức lần này đã vượt khỏi tầm kiểm soát và trở thành một talking point, và rất khó để bất kỳ dữ liệu nào thay đổi được điều đó
    Từ giờ, câu kiểu “maintainer của rsync dùng LLM rồi làm hỏng mọi thứ” sẽ được những người hoài nghi AI đem ra cùng với các talking point như “datacenter lãng phí 500.000 gallon nước sạch mỗi ngày” hay “nghiên cứu của METR nói LLM làm giảm năng suất”
    Tôi không định nói mình có phải người hoài nghi AI hay không, chỉ là tranh cãi quanh chủ đề này thường diễn ra theo kiểu như vậy

    • Tại sao đó lại là một “talking point”, chẳng phải chỉ là sự thật thôi sao?
    • Tôi không rõ tác giả có đang cố dùng dữ liệu để thuyết phục ai đó hay không. Tôi xem bài này như việc thêm bối cảnh dữ liệu vào cuộc tranh cãi gay gắt quanh việc rsync áp dụng công cụ mới
      Dù vậy, đúng là bài viết đã bỏ qua hoàn toàn các yếu tố phi định lượng khác, và có lẽ là cố ý vì tiếng ồn từ cả hai phía, phía truyền giáo lẫn phía hoài nghi, đã quá nhiều rồi

  • Chi tiết rằng bản phát hành tệ nhất trong lịch sử rsync là từ trước khi đưa Claude vào, với 39,39 lỗi trên mỗi 10 commit, là một kết luận rất quan trọng và hoàn toàn có thể đoán trước
    Nếu các quy trình như kiểm thử, đảm bảo chất lượng giữa người dùng và nhà phát triển không thể bảo đảm độ chính xác của phần mềm, thì dù có LLM hay không, lỗi vẫn sẽ được phát hành. LLM có thể gây hại cho quá trình này hoặc cũng có thể giúp ích

    • Đồng ý. Bài viết gần đây của cURL dường như cho thấy ví dụ ở phía ngược lại
      Nhờ các thực hành kỹ nghệ phần mềm mạnh mẽ đã được thiết lập suốt nhiều năm, giá trị của việc dùng các công cụ AI tương tự để tìm lỗi nhìn chung đã giảm đi
    • Tôi có vài lo ngại về tương lai của rsync. Vấn đề lớn nhất là rsync trên thực tế đã là một dự án gần như hoàn thiện trong nhiều năm, nhưng khi dùng AI thì họ lại gỡ bỏ mã kiểm thử cũ và thay bằng bộ test Python, đồng thời trong một khoảng thời gian đáng kể đã không chạy song song với bộ test cũ để xác minh tính chính xác
      Theo tiêu chuẩn của tôi thì đó là vô trách nhiệm. Đặc biệt khi mục đích chính của rsync là chuyển dữ liệu quý giá, và tính toàn vẹn của dữ liệu đó là điều tối quan trọng

  • Tôi mong họ tránh kiểu tu từ như “đúng kiểu người dùng chống AI thì cuối cùng lại leo thang thành fantasy bạo lực”. Cách nói đó không chỉ khái quát hóa một số người mà tác giả không đồng tình, mà còn dễ gây phản cảm với cả những độc giả vốn đã không đồng ý, khiến chính những người cần đọc nhất lại không đọc bài
    Tách riêng chuyện đó ra, dù phiên bản này nhiều hay ít lỗi hơn phiên bản trước thì tôi cũng không quá quan tâm. Điều tôi thấy quan trọng là nó được phát triển theo một cách không phù hợp với quan niệm của tôi về cách phần mềm nên được làm ra. Nếu không có hiểu biết nền tảng rằng ngoài hiệu suất còn có những vấn đề khác, thì tôi cũng không kỳ vọng thuyết phục được ai rằng lập trường này là hợp lý
    May là nếu không muốn thì tôi không cần dùng phiên bản rsync này, và tôi sẽ chọn một nhánh thay thế được tách ra từ trước khi dùng LLM

    • Bài này quá đầy giận dữ nên tôi đọc không lâu nổi rồi bỏ dở. Sẽ tốt hơn nếu nó cố công bằng hơn, hoặc ít nhất trông có vẻ như vậy
      Việc lặp lại một meme đã bị bác bỏ từ lâu, rằng báo cáo lỗi đầu tiên là issue do mọi người ào vào tạo, cũng không giúp ích gì. Báo cáo lỗi đầu tiên thực sự là một báo cáo khác

  • Tôi thấy bài viết hiện tại thành thật mà nói là tốt hơn. Tuy vậy, đoạn “chỉ số này không kiểm soát được độ phức tạp của commit, mức độ nhạy cảm về bảo mật, hay mức độ nghiêm trọng của lỗi. Nó là một công cụ thô, không phân biệt được giữa một bản sửa lỗi chính tả một dòng và một bản vá CVE” lại bỏ lỡ điểm phê phán cốt lõi, ít nhất từ lập trường của tôi ở phía LLM là thứ tệ hại
    Điều tôi và những người khác đang phê phán là AI khiến người ta tuôn ra những commit lớn hơn, khó hiểu hơn và làm tăng độ phức tạp. Những người ủng hộ LLM cũng hay nói điều tương tự, rồi sau đó lại dời khung tranh luận từ thực hành “đọc PR” đã được kiểm chứng hàng chục năm sang “LLM phải có khả năng kiểm thử mọi thứ”. Nhưng vấn đề độ phức tạp của mã là nợ kỹ thuật thì vẫn không biến mất
    Trong trường hợp này mức độ nghiêm trọng của lỗi là rất cao, vì quy trình sao lưu thực sự đã bị phá vỡ. rsync được dùng rộng rãi cho sao lưu, và mọi người đã tin nó là một công cụ “đã được thử lửa trong thực chiến” đến mức gần như không thể tưởng tượng việc một bản cập nhật vá lỗi lại có thể làm hỏng script sao lưu
    Có thể nói việc LLM tạo ra phần mềm có lỗi chỉ là ngẫu nhiên, hoặc quản trị viên cần thay đổi quy trình làm việc với LLM và tăng độ bao phủ kiểm thử. Thực tế quản trị viên cũng đã nói như vậy. Nhưng cốt lõi của cơn giận là công cụ này đã phá vỡ niềm tin đó
    Thực sự là dạo này có một kiểu lập trình viên LLM mới nói rằng họ “không hề đọc mã nữa”. Lý do là đọc quá tốn thời gian, và mã đó còn phức tạp hơn để hiểu so với mã do lập trình viên bình thường viết. Việc đọc mã là học mô hình tư duy của người khác, còn công cụ LLM thì không cung cấp được một mô hình tư duy nhất quán
    Ngoài ra cũng nên kiểm tra khả năng truy cập của trang. Tôi thị lực khá tốt và mới cuối tuổi 20 mà vẫn thấy chữ xám nhạt trên nền kem/vàng thật sự rất đau mắt

    • Tôi thấy đoạn được trích hơi khó hiểu. Chỉ số dùng trong bài có vẻ đã gán trọng số theo mức độ nghiêm trọng cho số lỗi trên mỗi 10 commit, vậy là tác giả đang tự mâu thuẫn hay sao? Hay là tôi đọc sai?
    • Với những người nói quy trình làm việc đã bị phá vỡ, tôi nghĩ đây là dịp tốt để họ tìm hiểu phần mềm mã nguồn mở và giấy phép GPL là gì, và nó bảo đảm những gì
      Tôi không nghĩ chính những người đó đã tự phát hiện ra lỗi. Tôi đoán hơn 90% người dùng rsync vẫn đang dùng phiên bản cũ hơn không có lỗi đó. Tôi cũng là một trong số đó 
      $ uname -a  
Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64

$ port info rsync  
rsync @3.4.1 (net)  
[...]
      Nếu có lý do gì khiến chuyện này thu hút chú ý, thì việc một phần đáng kể cộng đồng đang rơi vào hỗn loạn là điều không cần Steven Pinker cũng hiểu được. Việc LLM lập trình giỏi hơn con người là điều không dễ chấp nhận
      Những người đặt bản sắc và lòng tự trọng của mình vào năng lực lập trình hay nghề nghiệp của họ đang phải đối mặt với hai cuộc khủng hoảng: bất định về sinh kế/giá trị thị trường trong tương lai, và khủng hoảng bản sắc
      Sợ hãi, bất định và nghi ngờ đều rất khó xử lý, còn các công ty LLM thì đang cố hết sức khuếch đại những hiệu ứng đó để đẩy giá cổ phiếu. Nếu thị trường điều chỉnh mạnh sau tháng 10, tôi nghĩ các cơ chế khuếch đại này cũng có thể suy yếu
      Một tỷ lệ rất nhỏ trong số lập trình viên toàn cầu, tức những người xem mã như một loại hình nghệ thuật, có lẽ sẽ dùng LLM để rèn luyện và nâng cao tay nghề

  • Bài này trích dẫn rất nhiều bình luận nhắc đến hồi quy, nhưng bản thân phân tích lại không đo hồi quy mà chỉ đo các báo cáo lỗi. Nó gắn lỗi với bản phát hành nơi lỗi được báo cáo, chứ không phải bản phát hành nơi lỗi được đưa vào, và đo mức độ nghiêm trọng của bản phát hành bằng số lượng commit trong khi bỏ qua các yếu tố rõ ràng như thời gian giữa các bản phát hành hay mức độ được các bản phân phối tiếp nhận
    Tôi không hiểu như vậy thì có ý nghĩa gì

  • Cá nhân tôi tránh các dự án dùng LLM. Không hẳn vì có lý do thực chất nào, mà chỉ vì tôi thấy rất khó chịu, kiểu giống như khi ai đó dùng những từ như “kek” hay “fren” thì tôi xem đó là tín hiệu rằng mình không còn muốn tương tác nữa dù không có lý do gì đặc biệt
    Những lời giải thích hiện được đưa ra cho việc ghét dùng LLM với tôi giống như các lý lẽ hợp thức hóa được gắn vào sau. Các lo ngại hiện tại như đạo đức, chất lượng là có thật, nhưng kể cả khi những vấn đề đó được giải quyết thì tôi cũng không nghĩ những người có xu hướng phản AI như tôi sẽ đột nhiên thấy ổn
    Vì vậy tôi tránh các dự án có “AGENTS.md”, commit đồng tác giả với Claude, v.v., dù không có lý do cụ thể nào. Đơn giản là tôi thấy khó chịu, không hợp gu, và có lỗi hay không cũng không quan trọng. Tôi nghĩ có lẽ những người khác cũng cảm thấy tương tự

  • Nói với tác giả thì, thứ nhất, fantasy là lời nói. Trên thực tế bạn đang khẳng định rằng nó đã dừng lại ở lời nói, hoặc ít nhất là không khẳng định rằng đã có sự leo thang phi ngôn ngữ
    Thứ hai, nếu muốn đưa ra kiểu khẳng định này thì nên hỏi một chuyên gia thống kê gần bạn xem phải hậu thuẫn nó như thế nào. Chỉ vì vài người đăng những bài như vậy không có nghĩa là có thể dùng nó để hậu thuẫn một cách có ý nghĩa cho tuyên bố rằng đó là điều “điển hình”
    Theo quan sát mang tính giai thoại của tôi, vốn không được hậu thuẫn bằng thống kê, thì những người dùng “phản AI” nhìn chung giống như đang buồn vì LLM chen vào những chỗ nó không giúp ích gì hơn là cảm thấy bạo lực

    • Đôi khi tôi thấy những bài rất dài dòng và chi tiết phản bác một bộ phận người phản đối LLM, thường là những người phản ứng với LLM ở mức cảm xúc và xã hội. Tôi khó giải thích rõ lý do, nhưng những bài đó cho tôi cảm giác rất thiếu thiện chí và giống như đang đánh vào kẻ yếu
      Nó quá chi tiết nên rất khó phản bác từ góc độ cảm xúc, và cuối cùng dường như luôn kết lại ở chỗ “LLM không phải vấn đề, nếu dùng đúng thì nó là công cụ khuếch đại. Những người phản AI chỉ là không hiểu gì và đang sợ bị tụt lại phía sau”
      Tôi cũng không muốn hạ thấp công việc của các quản trị viên rsync thành một cuộc tranh cãi, nên tôi không biết mình có thể xây dựng một phản biện thuyết phục như thế nào
      Các thống kê ở đây có thể thú vị từ góc nhìn bảo trì mã nguồn mở, nhưng kết luận lại nghiêng về một phía một cách kỳ lạ, và để lại cảm giác rằng mã nguồn mở kiểu GitHub không phải là hình thức tôi muốn đóng góp vào
      Dù vậy, tôi hoàn toàn không thấy việc mọi người kéo thành đám đông đến kho rsync để dồn ép quản trị viên là điều tốt
    • Việc nói rằng ảo tưởng bạo lực công khai là không ổn là đúng. Đó không phải kiểu hành vi mà một nền văn minh nên hướng tới. Tuy vậy, chỗ tác giả gọi điều đó là “điển hình” làm tôi khó chịu vì đó là một sự khái quát hóa
      Còn về quan sát giai thoại thì tôi thấy tranh này nói đúng. Tôi thích nhìn thấy những khẳng định cụ thể và có thể đo lường, một phần vì tôi thích con số, và một phần vì điều đó giúp các cuộc tranh luận trực tuyến tiến gần hơn dù chỉ một chút tới thế giới lý tưởng ở khung cuối cùng

  • Cảm ơn vì phần phân tích, nhưng tôi không chắc về phương pháp luận. Tôi muốn biết các chỉ số như số lỗi trên mỗi đơn vị chênh lệch, tức lấy số dòng thay đổi trong phần mã cốt lõi của từng commit — nghĩa là mã không phải test hay tài liệu — nhân với số lỗi, và phân tích thời gian cần để đạt đến một số lượng lỗi nhất định sau khi phát hành
    Tuy vậy, có vẻ lần phát hành này đã thu hút sự chú ý nhiều hơn hẳn các lần khác nên khả năng cao là có nhiều lỗi được báo cáo hơn, vì thế sẽ khó tạo ra một chỉ số thật sự thuyết phục. Những câu hỏi như “xét theo số tuần sau phát hành thì có điển hình không?” cũng có thể không hữu ích lắm.