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

• 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

[GN⁺]

Ý kiến trên Hacker News

• Khi xem các commit, tôi thấy commit gốc và cả commit hoàn tác: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
  Ngay cả những đường lẽ ra phải dùng malloc cũng bị đổi sang calloc, như thể ép mọi cấp phát phải coi calloc tương thích ngược nghiêm ngặt ở mức siêu tập. Với các cấp phát lớn hoặc cấp phát đệ quy, chi phí này khá đáng kể. Đây có vẻ là một ví dụ điển hình về kiểu vấn đề lọt qua khâu rà soát trong mã do Claude viết. Bản hoàn tác nằm ở https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721..., và chỉ cần đọc lướt phần mô tả hoàn tác cũng thấy đậm mùi LLM. Tôi hiểu cảm giác của người đăng bài gốc

  • Ngay cả số lượng commit cũng đáng ngờ. Trong hai tháng gần đây, số commit vào rsync gần bằng 2 năm trước đó cộng lại, và phần lớn là commit được viết bằng Claude. Nhìn cả những thay đổi kiểu này được đưa vào thì trông rất giống một trường hợp điển hình: quá hào hứng dùng AI rồi dần trở nên bất cẩn
  • Nói là “được viết bằng Claude” thì không đúng. Commit hoàn tác có tham chiếu tới https://github.com/RsyncProject/rsync/issues/959, và trong issue đó tác giả trực tiếp giải thích rằng “thay đổi đưa bộ nhớ về 0 là ý tưởng của tôi và là thay đổi do tôi thực hiện”
    Báo cáo bảo mật nêu ra việc dùng phần tử vượt quá cuối mảng, và ông cho rằng nếu khởi tạo 0 cho vùng cấp phát thì kể cả sau này có lỗi tương tự phát sinh, nhiều khả năng nó sẽ kết thúc bằng dereference null pointer thay vì dereference một con trỏ hợp lệ. Claude chỉ được dùng để sắp xếp lại chùm commit, và cơ chế gắn thẻ co-authored sẽ xuất hiện chỉ với một chút chỉnh sửa, nên không có nghĩa là Claude đã viết thay đổi đó. Ông nói rõ là mã thực tế do chính mình viết
  • Tôi sẽ không khẳng định Claude đã đưa ra quyết định đó. Đây cũng không phải một thay đổi phụ lén chèn vào giữa commit lớn; ngay từ thông điệp commit đã mở đầu bằng “khởi tạo 0 cho toàn bộ vùng nhớ mới cấp phát” và thực sự làm đúng việc đó. Tôi cũng không biết mọi người đang hình dung prompt ban đầu là gì
    Hoàn toàn có thể là một con người lúc đầu nghĩ đây là cải tiến, rồi sau khi thấy RSS regression mới suy nghĩ lại. Và cũng không có định luật tự nhiên nào nói rằng thay đổi này nhất thiết phải làm RSS tăng. calloc có thể được xử lý đặc biệt nhờ biết rằng ánh xạ bộ nhớ mới nhận từ hệ điều hành vốn đã được khởi tạo 0. Nếu muốn đổ lỗi cho AI ở đây thì có lẽ đúng hơn là theo nghĩa: AI làm bùng nổ số lượng báo cáo lỗ hổng, kéo theo bùng nổ các bản vá gấp, và các bản vá gấp thì đôi khi lại tạo ra vấn đề khác
  • Một thời đại tuyệt vời khi AI còn được nhân thêm với Linux overcommit. Cá nhân tôi thấy 10.8GB giờ chẳng là gì, và bộ đệm sprintf có khi còn lớn hơn thế. Nếu chưa thì nên như vậy, còn không thì đã đến lúc bắt đầu dùng snprintf

• Trước khi bình luận, tôi khuyên nên đọc bài mà tác giả rsync đã liên kết: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
  Nói rõ thì tôi không liên lạc với Tridge đã vài năm, nhưng ông ấy từng là đồng nghiệp và người cố vấn của tôi trong thời gian dài. Trước khi gia nhập cuộc thập tự chinh này, đáng để cân nhắc góc nhìn của ông ấy

  • Đây đáng ra phải là bình luận đứng đầu. Khá buồn khi ông ấy còn phải viết cả một bài như vậy. Những người chẳng phải trả hóa đơn cho ông ấy lại phán xét quá nhiều
  • Tôi không hoàn toàn hiểu đoạn “tôi nghĩ nên công khai xây dựng trước cấu trúc cốt lõi của bộ test suite mới trên master”. Nếu ông ấy chỉ cập nhật test hoặc chỉ push lên master thì có lẽ mọi người đã không nổi giận
    Nhưng ông ấy lại push cả thay đổi gây hỏng lên nhánh phát hành. Phá vỡ một workflow đã chạy ổn nhiều năm là cách chắc chắn nhất để làm người khác tức giận, và nếu trong commit còn thấy cả chữ “Claude” thì đúng là đổ thêm dầu vào lửa
  • Tôi cho rằng phản hồi của ông ấy thực sự là một câu trả lời rất tốt

• Tôi không trực tiếp dính dáng đến cuộc tranh cãi này, nhưng có vài điểm trông khá đáng ngờ. Bản phát hành bị quy nhiều lỗi nhất lại là bản phát hành tháng 1, ngay trước bản phát hành đầu tiên có commit đồng tác giả với Claude, nên tôi tự hỏi liệu có khả năng commit do LLM viết nhưng không có nhãn quy thuộc đã được đưa vào bản phát hành này hay không
  Phương pháp quy lỗi theo bản phát hành cũng không ổn lắm. Các lỗi được đưa vào ở một bản cập nhật minor có xu hướng bị quy về bản phát hành patch tồn tại lâu nhất trong minor đó. Khó mà nói 3.4.1 thực sự đã đưa vào nhiều lỗi như vậy; vì nó được phát hành ngay ngày hôm sau 3.4.0, rất có thể các lỗi phát sinh ở bản phát hành đó đã bị tính vào 3.4.1. Ngoài ra, các bản phát hành gần đây có ít thời gian hơn để lỗi được báo cáo, nên cũng có thể có thiên lệch khiến chúng bị đánh giá là ít lỗi hơn

  • Đồng ý. Câu trong bài viết rằng “bản phát hành tệ nhất trong lịch sử rsync là trước khi Claude được đưa vào, và không ai nhận ra” khiến tôi cảm thấy tác giả bọc ý kiến trong những thuật ngữ thống kê hoa mỹ hơn là thật sự không có lợi ích trong cuộc tranh cãi này
    “Rõ ràng đến chói mắt” à? Chỉ cần vẽ một cái biểu đồ là được. Và v3.4.1 là ngày 2025-01-16, về mặt kỹ thuật thì vẫn thuộc thời kỳ lập trình có AI hỗ trợ, chỉ là trước khi việc gắn nhãn quy thuộc trở thành thông lệ tiêu chuẩn
  • Vì các bản phát hành khá thưa, tôi cũng bắt đầu xem xét cùng điểm đó. Để tránh vấn đề các commit do LLM viết nhưng không có nhãn quy thuộc, tôi cho rằng phân tích nên bao gồm so sánh mức độ nghiêm trọng của lỗi trước và sau v3.3.0. Mốc ngày là 2024-04-06
  • LLM có thể được dùng theo nhiều cách. Có thể từ kiểu con người can thiệp rất trực tiếp và chỉ tạo thay đổi cục bộ, cho đến kiểu giao phó hoàn toàn
    Tôi đã thấy nhiều đoạn mã do LLM tạo ra nhưng không có đồng tác giả trong commit message. Có vẻ thường chỉ khi toàn bộ giao diện với codebase được thực hiện hoàn toàn qua các công cụ như Claude/Codex thì mới có gắn các thẻ đó, và những commit như vậy thường rất dài dòng nhưng hầu như không nói vì sao thay đổi, chỉ tóm tắt thay đổi mã. Ngược lại, tôi cũng đã thấy các lập trình viên dùng Claude như một công cụ: qua lại giữa VSCode và terminal Claude, tự kiểm tra mã cho đúng và chỉ giao phần việc đường ống cho Claude. Có lẽ tác giả cũng bắt đầu nhỏ rồi dần tăng lên theo thời gian
  • Điểm thứ nhất và thứ hai có vẻ mâu thuẫn với nhau. Nếu mọi lỗi của 3.4.1 đều phải được quy về 3.4.0, thì thời điểm các commit LLM không được quy thuộc lọt vào dự án phải còn sớm hơn nữa, và như vậy giả thuyết lại càng vô lý hơn
    Vấn đề lớn hơn là hoàn toàn không có bằng chứng nào ủng hộ giả thuyết rằng các commit LLM đã lén được đưa vào các bản phát hành trước đó và vì vậy làm tăng tỷ lệ lỗi. Nếu không mặc định rằng số lỗi cao tự động đồng nghĩa có AI can thiệp, thì không có cơ sở nào cả, và như vậy là lập luận vòng tròn. Điểm thứ ba thì hợp lý. Tôi đã phân tích mất bao lâu để thường phát hiện ra lỗi và mỗi phiên bản nằm ở đâu trong chu kỳ phát hành; nếu muốn tôi có thể đăng lên
  • Nếu nói đến lỗi gây sốc một cách trơ trẽn nhất, thì thống kê về Claude được rút ra từ tổng cộng 2 điểm dữ liệu

• Ở đây có một sự mỉa mai quan trọng ở tầng meta. Bài gốc bảo vệ việc dùng AI, nhưng có vẻ cũng đã rõ ràng dùng AI để phân tích dữ liệu và trình bày kết quả
  Trong quá trình đó, tác giả đã sử dụng thống kê theo cách mà chính họ không hiểu rõ, và đi tới nhiều kết luận sai. Có thể xem thảo luận liên quan tại https://news.ycombinator.com/item?id=48417626. Tóm lại, nghiên cứu này không có đủ sức mạnh thống kê và đang đưa ra khẳng định “không có khác biệt” mà không được biện minh. Cuối cùng, trong lúc dùng LLM để diễn giải dữ liệu, nghiên cứu này lại mắc đúng kiểu sai lầm mà nó định khảo sát: tự tin khẳng định điều sai

  • AI giống tôn giáo quá mức. Với người tin, bạn nói gì cũng không thể khiến họ nghi ngờ niềm tin. Nói rộng hơn, bạn không thể dùng lý trí để thuyết phục ai đó từ bỏ điều mà họ muốn tin

• Tôi nghĩ điều mà những người đang giận dữ về chuyện này đạt được khi gây sức ép lên người bảo trì rsync chỉ là khiến người khác bớt công khai có trách nhiệm về việc dùng AI. Để tránh tranh cãi, họ sẽ chỉ tắt nhãn quy thuộc Claude trong commit

  • Tôi không quá quan tâm tới việc công khai dùng AI. Nếu không phải người mà tôi trực tiếp biết, tôi không tin rằng mã do con người viết nhất định tốt hơn mã do AI tạo ra
    Dù sao thì trách nhiệm với đoạn mã được commit và push vẫn thuộc về con người. Điều này chưa bao giờ thay đổi. Nó được viết bằng tay, do con mèo đi trên bàn phím tạo ra, hay do AI tạo ra thì tôi đều không quan tâm. Chất lượng mã của dự án có thể giảm vì vô số lý do, và ám ảnh riêng việc có phải AI tạo ra hay không thì không mang tính xây dựng. Ai đó muốn tìm cớ để chỉ trích AI, người khác muốn bảo vệ AI, thì cứ vậy thôi, nhưng đó không phải là cách phù hợp để đánh giá chất lượng mã của một dự án
  • Bất kể tranh cãi ra sao, tắt các nhãn như vậy là điều đúng đắn. Không có lý do gì phải làm quảng cáo miễn phí cho các công ty nghìn tỷ. Các trailer như Generated-by chỉ có ý nghĩa khi đóng góp cho dự án của bên thứ ba, và lúc đó thì công khai là phép lịch sự
  • Nghe giống kiểu “đừng tức giận vì ai đó làm điều phi đạo đức hay vô đạo đức, nếu không họ sẽ làm điều còn phi đạo đức hoặc vô đạo đức hơn!”
    Tắt nhãn quy thuộc của mã do LLM tạo ra là gian dối. Vì như vậy tức là nói rằng chính mình đã viết đoạn mã đó. Tất nhiên, điều đó cũng khá hợp với việc ngay từ đầu đã tạo mã bằng LLM. Rốt cuộc, nó chỉ là nhắc lại đầu vào mà không giữ lại giấy phép và thông báo bản quyền
  • Tôi không chắc đó có phải điều xấu hay không. Từ góc nhìn bộ phận marketing của Anthropic thì có lẽ là vậy, nhưng nếu agent chỉ là thêm một công cụ nữa trong hộp đồ nghề của lập trình viên, thì nhãn quy thuộc lại hơi kỳ. Suy cho cùng, trách nhiệm commit vẫn thuộc về lập trình viên
  • Lập luận này lần nào cũng xuất hiện nhưng không thuyết phục. Đúng là khi chỉ ra vấn đề công khai thì sẽ tạo động cơ để che giấu, nhưng rồi sao nữa thì tôi không hiểu
    Tạm gác tranh cãi AI có xấu hay không, nếu ví von thì trốn thuế là xấu và phi đạo đức, thấy thì phải chỉ ra. Nhưng việc điều đó tạo động cơ để che giấu không dẫn tới kết luận rằng ta không nên lên tiếng và cứ im lặng

• Tôi biết ơn những gì Andrew đã làm để tạo ra và duy trì rsync, nhưng vì tôi phụ thuộc khá nhiều vào rsync để sao lưu tệp giữa các máy trong mạng gia đình, nên tôi đã bỏ thời gian tìm cách ghim phiên bản rsync của Homebrew ở 3.4.1
  Hai phiên bản sau đó thực sự đáng sợ về mặt lỗi, và cả báo cáo gốc đã khơi mào toàn bộ chuyện này cũng vậy. Tôi đã ghi lại quy trình này ở đây, vốn phức tạp hơn nhiều so với tưởng tượng: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

• Bài này để lại nhiều câu hỏi hơn là câu trả lời nên khó mà đưa ra kết luận. Tôi không hiểu vì sao v3.4.1 ngay trước commit của Claude lại có nhiều lỗi nhất, và vì sao “không ai nhận ra”. Quá kỳ lạ để chỉ gạt đi như lỗi con người thuần túy
  Cũng khó hiểu không kém là vì sao v3.4.2 lại có 0 lỗi hoặc điểm lỗi bằng 0. Thật lạ khi những ngoại lệ như vậy, dường như không xuất hiện ở các commit khác, lại được phép trộn vào thống kê tổng hợp để làm giảm điểm “Claude tạo lỗi?”. Thành thật mà nói, tôi không hiểu sao đây lại không phải dấu hiệu cảnh báo trong phân tích của tác giả. Có cảm giác như một phân tích nửa vời được trình bày như một thành phẩm rất phức tạp chỉ vì có chạy thống kê cao cấp

  • Tôi không rõ có lý do gì để cho rằng v3.4.1 không phải lỗi con người, ngoài giả định tiên nghiệm rằng nó không thể như vậy
    v3.4.2 trong thước đo ban đầu cũng có 4 lỗi trước khi lọc bỏ các yêu cầu tính năng và câu hỏi, và trước đó còn cao hơn, nhưng không tạo khác biệt lớn cho toàn bộ phân tích. Nó vẫn nằm gọn trong khoảng tứ phân vị, lại còn ở phía thấp. Trong bối cảnh chỉ có đúng hai bản phát hành Claude, tôi cho rằng việc loại bỏ một ngoại lệ chỉ vì trông buồn cười còn tệ hơn và tùy tiện hơn

• Nếu lập luận là kiểu “Không kiểm soát độ phức tạp của commit, mức độ tập trung vào bảo mật, hay mức độ nghiêm trọng của lỗi. Đây là một công cụ thô, không phân biệt được sửa lỗi đánh máy một dòng với bản vá CVE. Nhưng lời chỉ trích của bên phản đối rằng ‘Claude làm mọi thứ tệ hơn’ cũng là công cụ thô, nên đáp trả công bằng nhất là dùng một công cụ thô”, thì tôi khó mà đồng ý
  Từ góc nhìn người dùng, cần hiểu bản chất của lỗi có tệ hơn hay không. Dù tỷ lệ giữ nguyên, nếu chất lượng phần mềm mà người dùng cảm nhận được giảm đi thì, nhất là với người bảo trì dự án, họ sẽ xem đó là tệ hơn. Tôi không định bác bỏ hoàn toàn phân tích này, nhưng tôi nghĩ những câu hỏi như vậy khó mà được trả lời đầy đủ chỉ bằng phân tích định lượng

  • Dù vậy tôi vẫn thấy là công bằng. Đến giờ tôi chưa thấy ai phân tích mã rồi nói có bao nhiêu hồi quy ở mức độ nghiêm trọng nào. Người ta chỉ nói “LLM làm tăng lỗi”
    Phân tích này có thể tự kiểm chứng nếu muốn, và nó nói rằng “ngay cả khi có LLM thì số lỗi vẫn khá trung bình”. Như vậy là đã phản hồi trực tiếp vào tuyên bố đó rồi. Nếu muốn một phân tích tinh tế hơn thì cứ tự làm và chia sẻ kết quả
  • Một khẳng định được đưa ra không có bằng chứng thì cũng có thể bị bác bỏ mà không cần bằng chứng. Phân tích này có nhiều bằng chứng hơn và độ chặt chẽ cao hơn so với những gì dùng để đưa ra khẳng định ban đầu. Với tôi như thế là đủ. Nếu ai đó thực sự làm công việc hậu thuẫn cho tuyên bố ban đầu bằng bằng chứng tốt hơn thì rất hay, tôi muốn xem. Cho đến lúc đó tôi sẽ không lo về vấn đề này
  • Gánh nặng chứng minh chẳng phải thuộc về người đưa ra khẳng định sao?

• Tôi đã lập trình hơn 20 năm, đã yêu việc viết code và có lẽ vẫn sẽ tiếp tục như vậy. Mới vài tháng trước tôi còn là người hoài nghi AI, nhưng Claude và Codex đã thay đổi cách tôi phát triển phần mềm và tốc độ của tôi theo những cách tôi chưa từng tưởng tượng
  Kết quả là tôi tạo ra nhiều mã hơn và cũng tìm ra nhiều lỗi hơn. Vì vậy tôi khá ngạc nhiên khi thấy sự thù ghét cực đoan trên HN đối với bất cứ thứ gì được AI tạo ra. Việc một dự án được AI hỗ trợ hoặc thậm chí được tạo hoàn toàn không khiến nó đột nhiên thành vibe coding, và cụm từ đó cũng không nên là một sự xúc phạm ném vào người dùng LLM. Nó làm tôi nhớ nhiều đến những cách nói miệt thị từng đổ lên đầu “lập trình viên Ấn Độ” khi outsourcing ra nước ngoài bùng lên từ giữa thập niên 90. Giờ đây vào giữa thập niên 2020, những lời tương tự lại hướng về AI. Tôi không hiểu. Điều chắc chắn là bất kể phe phản đối nghĩ gì, ngày càng sẽ có nhiều mã được AI tạo ra hơn

  • Tôi cũng từng hoài nghi AI theo cách tương tự cách đây 3 năm. Khi GPT-4 còn là đỉnh cao, tôi nghĩ nó sớm muộn cũng chững lại vì giới hạn kích thước ngữ cảnh. Tôi còn nhớ thời muốn dùng ngữ cảnh 32K thì phải trả số tiền vô lý
    Năm ngoái là lần đầu tôi thấy một tác nhân AI debug và sửa được một lỗi không hề tầm thường theo cách đủ thỏa đáng. Ngay cả lúc đó cũng rõ là nếu đem dùng cho việc lớn thì nó chưa tới mức có thể nuốt trọn cả issue tracker. Hiện tại vài tháng qua tôi đang làm một dự án không hề tầm thường với Codex. Tôi làm nguyên mẫu bằng C++ vì lý do thư viện, viết phiên bản đầu bằng Haskell, rồi gần đây chuyển sang Rust để kiềm chế mức dùng bộ nhớ trên di động. Đây không phải công cụ không có vấn đề, nhưng tốc độ tiến bộ chỉ trong 1 năm qua thật đáng kinh ngạc. Hoài nghi là tốt, nhưng hoài nghi lành mạnh thì phải lùi bước trước bằng chứng cụ thể
  • Trong bất kỳ chủ đề nào liên quan đến công cụ, luôn có những người thích bản thân công cụ đó và những người thích dùng công cụ để làm ra thứ khác. Trong lập trình, tôi thuộc vế sau. Lập trình là công cụ giúp tôi làm điều mình thật sự thích: giải quyết vấn đề, tư duy ở cấp hệ thống, và cung cấp những lời giải hay ho thông qua phần mềm
    Vì thế việc AI giúp phần nhàm chán khiến tôi thực sự vui, và cũng rất thú vị khi thấy các đồng nghiệp không phải lập trình viên hào hứng vì những ý tưởng vibe coded của họ trở thành hiện thực. Tôi thực lòng tò mò về góc nhìn phản AI của những người làm trong ngành phần mềm. Có phải vì cái chết cận kề của nghề nghiệp, hay vì sự dịch chuyển công nghệ?
  • Nếu đúng là đã có những cách nói miệt thị nhắm vào “lập trình viên Ấn Độ” khi outsourcing bùng lên vào giữa thập niên 90, thì tác nhân khởi phát là gì?
  • Tôi thường xuyên phải xử lý code thuê ngoài, và không ngoại lệ, nó giống như một đám cháy lốp xe. Ngay tuần rồi tôi còn phải dọn dẹp suốt một tuần một codebase nơi có developer không biết cách thiết lập môi trường làm việc cục bộ nên đã commit với một cờ bỏ qua kiểm tra xác thực được bật mặc định
    Trong AI vibe coding cũng có cùng kiểu vấn đề “đi đường tắt” như vậy, và bản thân tôi, kể cả khi dùng model tuyến đầu nâng mức suy luận lên 11, vẫn phải viết lại gần như toàn bộ mã do AI sinh ra. Tuy vậy AI lại cực kỳ hữu ích cho những việc khác như review PR, phân tích lỗ hổng bảo mật, tìm lỗi đánh máy, hay dịch ngược. Có lẽ tôi còn phải nâng gói thuê bao lên bậc cao hơn, nhưng đồng thời mã do AI tạo ra vẫn chưa dùng được. Nếu trong cùng một con người mà “rất hữu ích nên phải trả thêm tiền” và “chất lượng mã đầu ra vô dụng” vẫn có thể cùng đúng, thì việc toàn bộ tập người dùng có nhiều ý kiến khác nhau là điều đương nhiên
  • LLM rất tốt cho truy xuất ngữ cảnh và xuất mẫu. Nhưng thứ được đảm bảo chỉ là câu trả lời nổi bật theo mẫu số chung thấp nhất, đầu ra không có bảo hộ bản quyền, và còn có rủi ro pháp lý tiềm ẩn do rò rỉ bản quyền
    Hiện giờ đúng là thời hoàng kim Napster của hành vi đạo văn đồng hình

• Tôi thật sự không hiểu đây là cái gì. Thứ thực sự quan trọng chỉ là sau khi mã do AI viết được chấp nhận vào codebase thì lỗi có tăng lên hay không. Ai cũng biết câu trả lời. Dù vậy, lúc nào cũng thú vị khi thấy “dữ liệu” có thể bị dùng để tạo ra một kết luận cần đến nó

[GN⁺]

Ý 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.