Claude ทำให้บั๊กของ rsync เพิ่มขึ้นหรือไม่?

• รีลีสที่มี Claude ช่วย มีเพียงสองรายการคือ rsync v3.4.2 และ v3.4.3 และไม่มีหลักฐานว่ามีบั๊กมากผิดปกติเมื่อเทียบกับรีลีสในอดีต โดยวัดจากบั๊กถ่วงน้ำหนักตามความรุนแรงต่อ 10 คอมมิต
• sev/10c เป็นตัวชี้วัดหลักที่นำคะแนนความรุนแรงของบั๊กมาปรับให้อยู่ในช่วง 0~1 รวมตามรีลีส แล้วหารด้วยจำนวนคอมมิต ก่อนแปลงเป็นค่าต่อ 10 คอมมิต
• v3.4.2 มี 50 คอมมิต·คอมมิตจาก Claude 9 รายการ·บั๊ก 0 รายการ·0.00 sev/10c ส่วน v3.4.3 มี 34 คอมมิต·คอมมิตจาก Claude 28 รายการ·บั๊ก 17 รายการ·3.29 sev/10c โดยทั้งสองอยู่คนละด้านของ IQR และไม่มีรีลีสใดเป็น ค่าผิดปกติ
• ค่า p ของ exact permutation test อยู่ที่ 46%, ค่า p ของ Fisher's exact test อยู่ที่ 74% และอัตราส่วนออดส์เท่ากับ 1.06 จึงแทบไม่มีสัญญาณว่ารีลีสของ Claude แย่กว่าสองรีลีสแบบสุ่มหรือมีโอกาสเกินค่ามัธยฐานมากกว่าอย่างมีนัยสำคัญ
• v3.4.1 เป็นรีลีสก่อนมี Claude แต่กลับมี 59 บั๊ก·9 คอมมิต·39.39 sev/10c ซึ่งเป็นค่าที่แย่ที่สุดในข้อมูลทั้งหมด และประเด็นหลักของข้อถกเถียง rsync คือการโยง regression เพียงรายการเดียวเข้ากับ Claude โดยไม่มี การกระจายเชิงประวัติศาสตร์

---

ที่มาและคำถาม

• ช่วงปลายเดือนพฤษภาคม 2026 ประเด็นถกเถียงเรื่อง rsync เริ่มจากโพสต์บน Mastodon ที่เชื่อม regression ใน v3.4.3 กับคอมมิตของ Claude ก่อนลุกลามไปยัง Hacker News และ GitHub issue "Please Do Not Vibe Fuck Up This Software" ซึ่งมีคอมเมนต์สะสมเกิน 300 รายการ
• ข้อกล่าวอ้างหลักที่ถูกพูดซ้ำคือการพัฒนาแบบมี Claude ช่วยได้นำบั๊กเข้าสู่เครื่องมือที่เดิมมีเสถียรภาพ และคำถามเชิงข้อมูลคือรีลีสที่มี Claude ช่วยมีบั๊กมากผิดปกติเมื่อเทียบกับรีลีสในอดีตหรือไม่
• บน Lobsters มีการเสนอให้ดูจำนวน regression ต่อรีลีสในรูปกราฟตามเวลา และการวิเคราะห์นี้โฟกัสเพียงคำถามเดียวว่า “รีลีสที่มี Claude ช่วยมีบั๊กมากผิดปกติหรือไม่”

ขอบเขตข้อมูลและการทำซ้ำได้

• ข้อมูลครอบคลุม 36 รีลีสของ RsyncProject/rsync ตั้งแต่ v2.4.6 ถึง v3.4.3 ที่มีข้อมูลบั๊ก โดยมีเพียงสองรีลีสที่มีคอมมิตจาก Claude คือ v3.4.2 และ v3.4.3
• ตัวชี้วัด ระเบียบวิธี และการเลือกแหล่งข้อมูลถูกกำหนดโดยมนุษย์ทั้งหมด และสะท้อนคำแนะนำจากคู่สมรสของผู้เขียนที่จบปริญญาโทด้านสถิติ
• การเก็บข้อมูล การโหลดเข้า DuckDB การสร้าง view และสคริปต์วิเคราะห์สถิติถูกเขียนโดย GLM 5.1 แต่ตัวเลข สถิติ การ์ด และกราฟทั้งหมดถูกแทรกผ่านเทมเพลตอัตโนมัติโดยสคริปต์ Python ที่รันวิเคราะห์สถิติ
• รีโพซิทอรีสำหรับทำซ้ำ alexispurslane/rsync-analysis สามารถรันทั้งกระบวนการได้ครบตั้งแต่ต้นจนจบ

ตัวชี้วัดและวิธีระบุที่มาของบั๊ก

• ตัวชี้วัดหลักคือจำนวนบั๊กถ่วงน้ำหนักตามความรุนแรงต่อ 10 คอมมิต หรือ sev/10c โดยมีสูตรคำนวณ sev/10c = (Σ severity/100 ÷ total_commits) × 10
• คอมมิตถูกเรียงตาม committer date ของสาขาหลัก และช่วงของแต่ละรีลีสถูกกำหนดจากแท็กก่อนหน้าไปจนถึงแท็กนั้น โดยแท็ก pre และ rc จะไม่ถูกใช้เป็นขอบเขต แต่ถูกรวมเข้ารีลีสสุดท้าย
• แหล่งที่มาของบั๊กมีสามแหล่งคือ GitHub issues, rsync Bugzilla และเมลลิงลิสต์ของ rsync โดยบั๊กจาก GitHub issues และเมลลิงลิสต์จะถูกนับให้กับรีลีสล่าสุดที่ถูกปล่อยก่อนเวลาที่รายงานบั๊กนั้น
• รายการใน Bugzilla ใช้ฟิลด์ “Version” เพื่อระบุรีลีสที่รายงานบั๊กไว้โดยตรง จึงนับให้กับรีลีสนั้น
• เหตุผลที่เลือกวิเคราะห์ในระดับรีลีสคือคำวิจารณ์ตั้งต้นเองก็อยู่ในรูป “รีลีสทั้งหมดที่มีคอมมิตของ Claude มีบั๊กมากขึ้น” และบั๊กส่วนใหญ่ไม่ได้ระบุชัดว่าเกิดจากคอมมิตใดโดยตรง

วิธีประเมินความรุนแรง

• รายงานบั๊กทั้งหมดถูกให้คะแนนความรุนแรง 0~100 โดย Qwen 3 35B ด้วยพรอมป์ตที่กำหนดบทบาทเป็นวิศวกรความเชื่อถือได้ระดับอาวุโสที่ประเมินจากผลกระทบต่อผู้ใช้จริง
• คะแนน 90~100 หมายถึงข้อมูลเสียหายแบบเงียบ ๆ, การสูญหายของข้อมูล, การรันโค้ดจากระยะไกล หรือช่องโหว่ความปลอดภัยที่เข้าถึงได้โดยไม่ได้รับอนุญาต; 70~89 คือการแครช, การค้าง, การสำรองข้อมูลล้มเหลว หรือการ build ล้มเหลว; 50~69 คือ regression ของฟังก์ชันที่ยังมีทางเลี่ยงได้
• รายการจาก Bugzilla และเมลลิงลิสต์มีเพียงชื่อเรื่องไม่มีเนื้อหา ดังนั้นโมเดลจึงประเมินจากชื่อเรื่องอย่างเดียว และถูกสั่งให้เอนเอียงไปทางช่วงกลาง 40~60 หากข้อมูลไม่เพียงพอ
• เอาต์พุตใช้ structured output แบบ JSON schema ที่ยอมรับเฉพาะค่าความรุนแรงจำนวนเต็ม และตั้ง temperature เป็น 0 เพื่อให้ข้อมูลนำเข้าเดียวกันได้คะแนนเดิมเสมอ
• issue ที่ได้ 0 คะแนน เช่น feature request, สแปม, การประท้วงเรื่อง AI ที่ไม่ใช่เชิงเทคนิค หรือการส่งเปล่า จะไม่ถูกนับรวมในจำนวนบั๊กพื้นฐาน

ผลลัพธ์ทางสถิติของรีลีสที่มี Claude

• v3.4.2 มีคอมมิตจาก Claude 9 รายการจากทั้งหมด 50 คอมมิต, มีบั๊กจริง 0 รายการ, ได้ 0.00 sev/10c และอยู่ที่เปอร์เซ็นไทล์ 0
• v3.4.3 มีคอมมิตจาก Claude 28 รายการจากทั้งหมด 34 คอมมิต, มีบั๊ก 17 รายการ, ได้ 3.29 sev/10c และอยู่ที่เปอร์เซ็นไทล์ 77
• IQR ในอดีตอยู่ที่ 0.29~2.59 sev/10c โดย v3.4.2 อยู่ต่ำกว่า IQR เล็กน้อย ส่วน v3.4.3 อยู่สูงกว่า IQR เล็กน้อย ทำให้สองรีลีสนี้ประกบการกระจายช่วงกลางจากคนละด้าน
• exact permutation test ให้ผลว่าจากชุดจับคู่รีลีส 2 รายการที่เป็นไปได้ทั้งหมด 595 ชุด มี 272 ชุดที่มีค่าเฉลี่ยอย่างน้อย 1.65 sev/10c เท่ากับกลุ่ม Claude จึงได้ค่า p เท่ากับ 46%
• Fisher's exact test ตรวจว่าระดับ sev/10c ของรีลีส Claude อยู่เหนือค่ามัธยฐาน 0.74 sev/10c บ่อยกว่าหรือไม่ และได้ผลเป็นค่า p 74% กับอัตราส่วนออดส์ 1.06

จำนวนคอมมิตและขนาดการเปลี่ยนแปลง

• รีลีสของ Claude มีค่าเฉลี่ย 42 คอมมิต ขณะที่รีลีสที่ไม่มี Claude มีค่าเฉลี่ย 185 คอมมิต และความน่าจะเป็นที่รีลีสสุ่ม 2 รายการจะมีคอมมิตมากเท่านี้หรือมากกว่าคือ 88%
• ตาม GitHub compare API จำนวนบรรทัดที่เปลี่ยนในรีลีสของ Claude เฉลี่ย 3,756 บรรทัด ส่วนรีลีสที่ไม่มี Claude เฉลี่ย 696 บรรทัด และความน่าจะเป็นที่รีลีสสุ่ม 2 รายการจะมีจำนวนบรรทัดเปลี่ยนมากเท่านี้หรือมากกว่าคือ 5%
• จำนวนบั๊กถ่วงน้ำหนักตามความรุนแรงในรีลีสของ Claude เฉลี่ย 5.6 รายการ ส่วนรีลีสที่ไม่มี Claude เฉลี่ย 14.9 รายการ และความน่าจะเป็นที่รีลีสสุ่ม 2 รายการจะมีบั๊กถ่วงน้ำหนักมากเท่านี้หรือมากกว่าคือ 77%
• สรุปคือรีลีสของ Claude มีจำนวนบรรทัดที่เปลี่ยนมากกว่ามาก แต่ไม่ได้มีจำนวนคอมมิตหรือจำนวนบั๊กถ่วงน้ำหนักตามความรุนแรงมากกว่า

ระบบเวอร์ชันและค่าผิดปกติก่อนหน้า

• ค่าเฉลี่ยของรีลีส v2.x คือ 1.11 sev/10c ส่วนค่าเฉลี่ยของรีลีส v3.x คือ 4.23 sev/10c แสดงว่า v3.x มีอัตราบั๊กสูงกว่า
• แม้จะเปรียบเทียบเฉพาะ v3.x รีลีสของ Claude ก็ยังอยู่ในระดับกลางหรือดีกว่านั้น และหากจะทำให้ Claude ดูเหมือนค่าผิดปกติ ก็ต้องนำไปเทียบกับยุคก่อนหน้าที่สงบกว่าพร้อมโยนความเปลี่ยนแปลงที่เกิดก่อน Claude ไปให้ Claude รับผิด
• Wald–Wolfowitz runs test ให้ผลกับรีลีส 35 รายการที่ไม่มี Claude ว่าพบ run จริง 13 ครั้ง, ค่าคาดหมายแบบสุ่ม 18.5 ครั้ง, z=-1.88, p=0.060 ซึ่งยังไม่แรงพอจะปฏิเสธความเป็นการสุ่มที่เกณฑ์ 0.05
• v3.4.1 เป็นรีลีสก่อนมี Claude แต่กลับทำสถิติอัตราบั๊กสูงสุดในข้อมูลทั้งหมดด้วย 59 บั๊ก·9 คอมมิต·39.39 sev/10c
• v3.4.1 เป็น hotfix รีลีสที่ออกในวันถัดจาก v3.4.0 และมีอัตราบั๊กสูงกว่าทุกรีลีสอื่นแบบทิ้งห่างอย่างน้อยเลขหลักเดียว แต่เป็นช่วงเวลาที่ไม่มี AI ให้กล่าวโทษ

การตีความและข้อจำกัด

• การตีความที่สอดคล้องกับข้อมูลคือ “รีลีสของ Claude ทั้งสองรายการในปัจจุบันไม่แตกต่างจากรีลีสในอดีตอย่างมีนัยสำคัญทางสถิติ”
• v3.4.3 มีค่า 3.29 sev/10c ซึ่งอยู่ที่เปอร์เซ็นไทล์ 77 จึงถือว่าสูง แต่ไม่ใช่ค่ารุนแรงสุดโต่ง และมีรีลีสในอดีต 8 รายการที่ได้คะแนนสูงกว่านี้
• ข้อกล่าวอ้างว่า “Claude ทำให้แย่ลงอย่างชัดเจน” ไม่ได้รับการสนับสนุนจากทั้งการกระจายของรีลีส, permutation test หรือ Fisher test
• ในทางกลับกัน ข้อสรุปว่า “คอมมิตจาก Claude โดยทั่วไปจะไม่ทำให้แย่ลงต่อไปในอนาคต” ก็สรุปจากข้อมูลนี้ไม่ได้เช่นกัน เพราะสิ่งที่บอกได้ตอนนี้มีเพียงสองรีลีสนี้อยู่ในช่วงปกติ
• ตัวชี้วัดนี้มีข้อจำกัดตรงที่เป็นเครื่องมือหยาบ ซึ่งไม่สามารถควบคุมความซับซ้อนของคอมมิตหรือความเข้มข้นของงานด้านความปลอดภัยได้

ปัจจัยกวนที่ถูกหยิบยกขึ้นมา

• ผู้ใช้คนหนึ่งบน Hacker News มองว่าการแก้ไขด้านความปลอดภัยเพื่อตอบสนอง CVE ทำให้เห็นความผิดพลาดในการเขียนโค้ดที่อยู่ในโค้ดมาตั้งแต่ปี 2007
• ผู้ใช้คนหนึ่งบน Lobsters เสนอห่วงโซ่เหตุและผลว่า “LLM → ปัญหาความปลอดภัยที่รู้จักเพิ่มขึ้น → ต้องเปลี่ยนแปลงมากกว่าปกติ → regression มากกว่าปกติ”
• Andrew Tridgell อธิบายว่าคลื่นรายงาน CVE ที่สร้างโดย AI ทำให้ rsync ต้องปรับเปลี่ยนพื้นผิวการโจมตีอย่างรวดเร็วและกว้างขวาง
• หากรวมปัจจัยกวนเหล่านี้เข้าไป ปัญหาก็ดูจะใกล้เคียงกับการมีงานด้านความปลอดภัยมากขึ้นและปริมาณการเปลี่ยนแปลงที่เพิ่มขึ้นตามมา มากกว่าจะเป็นตัว Claude เอง

[GN⁺]

ความเห็นจาก Lobste.rs

• ผมคิดว่าแต่ละคนตัดสินใจเองได้ว่าจะยังใช้โปรเจกต์ FOSS ที่ต่อจากนี้จะพัฒนาแบบ vibe coding หรือไม่ อย่างไรก็ตาม ความโกรธที่ชุมชนแสดงออกมาหลังจากผู้ดูแลเปลี่ยนไปใช้เครื่องมือ vibe coding นั้นค่อนข้างน่าตกใจ และข้อมูลเชิงประจักษ์ในบทความนี้ก็ช่วยให้เห็นบริบทของผลกระทบจากการเปลี่ยนแนวปฏิบัตินั้นได้ดีขึ้นอย่างน้อยก็ในระดับหนึ่ง
  คงต้องรอดูเมื่อเวลาผ่านไปว่าความเชื่อใจจะยังคงอยู่หรือจะยิ่งพังลง หลังจากผู้ดูแลรับแนวทางการเขียนโค้ดแบบนี้มาใช้

  • ผมสงสัยว่าคนที่โกรธกับการเปลี่ยนแปลงครั้งนี้ มีสักกี่คนที่ มีส่วนร่วมกับ rsync อย่างมีนัยสำคัญ หรือเคยลงเงินจริง ๆ

• การวิเคราะห์นี้เป็น exactly สิ่งที่ผมอยากเห็น และมากกว่านั้นด้วย โดยเฉพาะตรงที่บอกว่า “ตัวชี้วัด วิธีวิทยา และแหล่งข้อมูลทั้งหมด ผมเลือกเองหลังจากปรึกษาภรรยาซึ่งจบปริญญาโทสถิติจาก Penn State University” ผมชอบมาก ทั้งการดึง ผู้เชี่ยวชาญด้านสถิติจริง ๆ มามีส่วนร่วม และการเขียนให้อ่านง่ายก็ยอดเยี่ยม
  เขาใช้ตัวชี้วัดเดียวคือ “จำนวนบั๊กต่อ 10 commit” ซึ่งน่าเสียดายที่พลาดโอกาสจะใช้คำนำหน้า SI แล้วเรียกมันว่า decibugs ต่อ commit

  • เห็นด้วย นี่ไม่ใช่บทความของผม แต่ผมชอบที่มีคนก้าวข้ามการเถียงแบบเดือด ๆ ทั้งสองฝั่ง แล้วใช้ข้อมูลแสดง ผลกระทบต่อคุณภาพโค้ด

• ความสำเร็จของโปรเจกต์โอเพนซอร์สขึ้นอยู่กับการรับรู้มากเกินไป จนคนยอมจ่ายเงินซื้อ GitHub stars กันเลยทีเดียว น่าเสียดายที่ปัญหาด้านการรับรู้ครั้งนี้หลุดการควบคุมไปแล้วและกลายเป็นประเด็นหนึ่งขึ้นมา ซึ่งข้อมูลใด ๆ ก็คงเปลี่ยนมันได้ยาก
  ต่อจากนี้คำพูดอย่าง “ผู้ดูแล rsync ใช้ LLM แล้วมันพัง” จะกลายเป็นประเด็นที่คนสายสงสัย AI หยิบขึ้นมาคู่กับเรื่องอย่าง “ดาต้าเซ็นเตอร์สิ้นเปลืองน้ำสะอาดวันละ 500,000 แกลลอน” หรือ “งานวิจัยของ METR บอกว่า LLM ทำให้ผลิตภาพลดลง”
  ไม่ได้จะบอกว่าผมเป็นคนสายสงสัย AI หรือไม่ แค่จะบอกว่าการถกเถียงเรื่องนี้มักไหลไปในทางแบบนี้

  • ทำไมสิ่งนั้นถึงเป็น “ประเด็น” ล่ะ มันไม่ใช่แค่ ข้อเท็จจริง หรอกหรือ?
  • ผมไม่แน่ใจว่าผู้เขียนตั้งใจใช้ข้อมูลไปโน้มน้าวใครหรือเปล่า ผมมองว่าบทความนี้เป็นการใส่ บริบทจากข้อมูล ให้กับข้อถกเถียงอันดุเดือดเรื่องการนำเครื่องมือมาใช้ใน rsync
    แต่ก็จริงที่บทความตัดปัจจัยที่ไม่ใช่เชิงปริมาณอื่น ๆ ออกไปทั้งหมด และน่าจะตั้งใจทำแบบนั้นเพราะเสียงรบกวนจากทั้งฝั่งผู้เผยแพร่และฝั่งผู้สงสัยก็มากพออยู่แล้ว

• ข้อสรุปที่สำคัญมากและก็พอคาดเดาได้ คือรีลีสที่แย่ที่สุดในประวัติศาสตร์ของ rsync เกิดขึ้นก่อนนำ Claude มาใช้ และมีบั๊ก 39.39 ตัว ต่อ 10 commit
  ถ้ากระบวนการอย่างการทดสอบและการประกันคุณภาพระหว่างผู้ใช้กับนักพัฒนาไม่สามารถรับประกันความถูกต้องของซอฟต์แวร์ได้ สุดท้ายก็จะปล่อยบั๊กออกมาไม่ว่าจะมี LLM หรือไม่ก็ตาม LLM อาจเป็นโทษหรืออาจเป็นประโยชน์ต่อกระบวนการนี้ก็ได้

  • เห็นด้วย บทความล่าสุดของ cURL ดูเหมือนจะเป็นตัวอย่างจากอีกด้านหนึ่ง
    ด้วย แนวปฏิบัติทางวิศวกรรมซอฟต์แวร์ ที่แข็งแรงและฝังรากมานานหลายปี คุณค่าของการใช้เครื่องมือ AI คล้าย ๆ กันเพื่อหาบั๊กจึงลดลงโดยรวม
  • ผมมีความกังวลอยู่บ้างเกี่ยวกับอนาคตของ rsync ปัญหาใหญ่ที่สุดคือจริง ๆ แล้ว rsync เป็นโปรเจกต์ที่แทบจะเสร็จสมบูรณ์มาหลายปีแล้ว แต่เมื่อเริ่มใช้ AI กลับไปรื้อโค้ดทดสอบเดิมออกแล้วเปลี่ยนเป็น Python test suite และ ไม่ได้รันชุดทดสอบเดิมควบคู่กันเป็นเวลานานพอสมควรเพื่อยืนยันความถูกต้อง
    สำหรับผม นี่คือความไม่รับผิดชอบ โดยเฉพาะเมื่อหน้าที่หลักของ rsync คือการย้ายข้อมูลสำคัญ และความสมบูรณ์ของข้อมูลนั้นสำคัญอย่างยิ่ง

• ผมอยากให้หลีกเลี่ยงถ้อยคำอย่าง “ตามแบบฉบับของผู้ใช้ที่ต่อต้าน AI สุดท้ายเรื่องก็ escalated ไปเป็นจินตนาการเรื่องความรุนแรง” มันไม่เพียงเหมารวมคนบางส่วนที่ผู้เขียนไม่เห็นด้วย แต่ยังชวนให้ผู้อ่านที่เดิมก็ไม่เห็นด้วยอยู่แล้วรู้สึกต่อต้าน จนคนที่ควรอ่านบทความนี้ที่สุดกลับไม่อ่าน
  แยกอีกประเด็นหนึ่ง ต่อให้เวอร์ชันนี้มีบั๊กมากหรือน้อยกว่าเวอร์ชันก่อน ผมก็ไม่ได้สนใจนัก สิ่งที่ผมให้ความสำคัญคือมันถูกพัฒนาด้วยวิธีที่ไม่สอดคล้องกับแนวคิดของผมเกี่ยวกับการพัฒนาซอฟต์แวร์ ถ้าไม่มีความเข้าใจพื้นฐานว่ามันมีปัญหานอกเหนือจากเรื่องประสิทธิภาพด้วย ก็คงไม่อาจคาดหวังว่าจะโน้มน้าวให้เห็นว่าจุดยืนนี้สมเหตุสมผล
  โชคดีที่ถ้าไม่ต้องการ ก็ไม่จำเป็นต้องใช้ rsync เวอร์ชันนี้ และผมจะเลือกทางเลือกที่แยกออกมาก่อนมีการใช้ LLM

  • บทความนี้เต็มไปด้วยความโกรธมากเกินไปจนผมอ่านต่อได้ไม่นานก็เลิก ถ้ามันพยายามยุติธรรมหรืออย่างน้อยดูเหมือนพยายามจะยุติธรรม ก็น่าจะดีกว่านี้
    การพูดซ้ำมีมที่ถูกหักล้างไปนานแล้ว อย่างเรื่องที่ว่ารายงานบั๊กฉบับแรกคือ issue ที่คนแห่กันเข้าไป ก็ไม่ช่วยอะไร เพราะจริง ๆ แล้วรายงานบั๊กฉบับแรกเป็นอีกอันหนึ่ง

• ตอนนี้ผมว่าบทความนี้ดีขึ้นกว่าเดิมตามตรง แค่ตรงที่บอกว่า “ตัวชี้วัดนี้ควบคุมความซับซ้อนของคอมมิต ความอ่อนไหวด้านความปลอดภัย และความร้ายแรงของบั๊กไม่ได้ มันเป็นเครื่องมือทื่อ ๆ ที่แยกไม่ออกระหว่างการแก้ typo แค่บรรทัดเดียวกับการแพตช์ CVE” นั้น จากจุดยืนของผมที่อยู่ฝั่ง LLM แย่ ถือว่าพลาดคำวิจารณ์แกนหลักไป
  คำวิจารณ์ที่ผมและคนอื่น ๆ ยกขึ้นมาคือ AI ทำให้มีคอมมิตที่ใหญ่ขึ้น เข้าใจได้ยากขึ้น และเพิ่มความซับซ้อนทะลักออกมา ผู้สนับสนุน LLM เองก็มักพูดทำนองเดียวกัน ก่อนจะย้ายเสาประตูจากแนวปฏิบัติที่ผ่านการพิสูจน์มาหลายสิบปีอย่าง “อ่าน PR” ไปเป็น “LLM ควรจะทดสอบทุกอย่างได้” แต่ปัญหาว่าความซับซ้อนของโค้ดคือหนี้ทางเทคนิคก็ไม่ได้หายไป
  ในกรณีนี้ความร้ายแรงของบั๊กสูงมาก เพราะ เวิร์กโฟลว์การสำรองข้อมูล พังไปจริง ๆ rsync ถูกใช้อย่างแพร่หลายในการสำรองข้อมูล และผู้คนก็เชื่อถือมันในฐานะเครื่องมือที่ “ผ่านสนามรบมาแล้ว” มากจนแทบจินตนาการไม่ออกเลยว่าการอัปเดตแพตช์จะทำให้สคริปต์แบ็กอัพพังได้
  จะบอกว่าเป็นเรื่องบังเอิญที่ LLM สร้างซอฟต์แวร์มีบั๊กขึ้นมา หรือจะบอกว่าผู้ดูแลควรเปลี่ยนเวิร์กโฟลว์การใช้ LLM และเพิ่ม test coverage ก็ได้ ซึ่งจริง ๆ ผู้ดูแลก็พูดแบบนั้นแล้ว แต่แก่นของความโกรธคือเครื่องมือนี้ทำลายความไว้วางใจนั้น
  ทุกวันนี้จริง ๆ มีโปรแกรมเมอร์สาย LLM กลุ่มใหม่ที่พูดกันตรง ๆ ว่า “ไม่อ่านโค้ดเลย” เพราะการอ่านใช้เวลานานเกินไป และซับซ้อนกว่าจะทำความเข้าใจเมื่อเทียบกับโค้ดของโปรแกรมเมอร์ทั่วไป การอ่านโค้ดคือการเรียนรู้ mental model ของคนอื่น แต่เครื่องมือ LLM ไม่ได้ให้ mental model ที่สอดคล้องเป็นอันหนึ่งอันเดียวกัน
  อีกเรื่องหนึ่งคือควรเช็กการเข้าถึงของเว็บไซต์ด้วย ถึงผมจะสายตาค่อนข้างดีและยังอยู่ช่วงปลายวัย 20 แต่ตัวอักษรสีเทาอ่อนบนพื้นครีม/เหลืองนี่อ่านทรมานมากจริง ๆ

  • ผมงงกับส่วนที่อ้างมา เพราะตัวชี้วัดที่ใช้ในบทความดูเหมือนจะให้น้ำหนัก ตามความร้ายแรง กับจำนวนบั๊กต่อ 10 คอมมิต แบบนี้ผู้เขียนกำลังขัดแย้งกับตัวเองหรือเปล่า หรือผมอ่านผิด?
  • สำหรับคนที่บอกว่าเวิร์กโฟลว์พัง ผมว่ามันเป็นโอกาสดีที่จะได้เรียนรู้ว่าโอเพนซอร์สซอฟต์แวร์กับ สัญญาอนุญาต GPL คืออะไร และมันรับประกันอะไรให้บ้าง
    ผมไม่คิดว่าคนทั่วไปจะเจอบั๊กนั้นด้วยตัวเองหรอก เดาว่าผู้ใช้ rsync มากกว่า 90% ยังใช้เวอร์ชันก่อนหน้าที่ไม่มีบั๊กนั้นอยู่ และผมก็เป็นหนึ่งในนั้น

    $ 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)  
    [...]  
    

    ถ้าจะถามว่าทำไมเรื่องนี้ถึงดึงความสนใจได้มาก ข้อเท็จจริงที่ว่าตอนนี้ชุมชนส่วนใหญ่กำลังสับสนก็ไม่ใช่เรื่องที่ต้องเป็น Steven Pinker ถึงจะเข้าใจได้ การยอมรับว่า LLM เขียนโปรแกรมได้ดีกว่ามนุษย์นั้นไม่ใช่เรื่องง่าย
    คนที่ผูกอัตลักษณ์และความภาคภูมิใจในตนเองไว้กับความสามารถด้านการเขียนโปรแกรมหรืออาชีพนี้ กำลังเผชิญวิกฤตสองชั้น คือความไม่แน่นอนเรื่องปากท้อง/มูลค่าในตลาดในอนาคต และวิกฤตอัตลักษณ์
    ความกลัว ความไม่แน่นอน และความสงสัยเป็นสิ่งที่รับมือยาก และบริษัท LLM ก็พยายามเต็มที่ที่จะขยายผลนั้นเพื่อดันราคาหุ้นของตัวเอง ผมคิดว่าถ้าตลาดปรับฐานแรงหลังเดือนตุลาคม ตัวขยายผลแบบนี้ก็น่าจะอ่อนแรงลงได้
    ในบรรดาโปรแกรมเมอร์ทั่วโลก คนสัดส่วนเล็กมาก ๆ ที่มองโค้ดเป็น ศิลปะรูปแบบหนึ่ง ก็คงจะใช้ LLM เพื่อฝึกฝนและพัฒนาฝีมือตัวเอง

• บทความนี้อ้างคอมเมนต์ที่พูดถึง regression เยอะมาก แต่ตัวการวิเคราะห์เองไม่ได้วัด regression เลย วัดแค่บั๊กรายงานเท่านั้น มันผูกบั๊กเข้ากับรีลีสที่มีการรายงาน ไม่ใช่รีลีสที่เป็นจุดนำบั๊กเข้ามา และวัดความร้ายแรงของรีลีสด้วยจำนวนคอมมิต โดยตัดปัจจัยชัด ๆ อย่างช่วงเวลาของรีลีสหรือการยอมรับของดิสโทรออกไป
  ผมไม่เข้าใจเลยว่ามันสมเหตุสมผลยังไง

• ส่วนตัวแล้วผมหลีกเลี่ยงโปรเจกต์ที่ใช้ LLM ไม่ใช่เพราะมีเหตุผลเชิงปฏิบัติอะไรนัก แค่รู้สึกขยะแขยงมาก ๆ เฉย ๆ คล้ายกับเวลามีใครพูดคำอย่าง “kek” หรือ “fren” แล้วผมก็รับมันเป็นสัญญาณว่าไม่อยากมีปฏิสัมพันธ์ต่อโดยแทบไม่ต้องมีเหตุผล
  คำอธิบายที่ถูกยกขึ้นมาตอนนี้ว่าไม่ชอบการใช้ LLM เพราะอะไร สำหรับผมมันให้ความรู้สึกเหมือนการหาเหตุผลมารองรับทีหลัง ความกังวลปัจจุบันอย่างเรื่องจริยธรรมหรือคุณภาพก็จริงอยู่ แต่ถึงปัญหาเหล่านั้นจะถูกแก้ คนอย่างผมที่มี แนวโน้มต่อต้าน AI ก็คงไม่ได้จู่ ๆ รู้สึกโอเคขึ้นมา
  เพราะงั้นผมเลยเลี่ยงโปรเจกต์ที่มี “AGENTS.md” หรือคอมมิตที่ร่วมเขียนกับ Claude โดยไม่ได้มีเหตุผลเฉพาะอะไร แค่รู้สึกไม่ชอบและไม่ถูกจริต จะมีบั๊กหรือไม่ก็ไม่เกี่ยว คิดว่าคนอื่นก็คงมีความรู้สึกคล้าย ๆ กันบ้าง

• จะบอกกับผู้เขียนว่า อย่างแรก fantasy ก็คือคำพูด ในทางปฏิบัติคุณกำลังอ้างว่ามันหยุดอยู่แค่คำพูด หรืออย่างน้อยก็ไม่ได้อ้างว่ามีการขยายไปเป็นสิ่งที่ไม่ใช่ภาษาด้วย
  อย่างที่สอง ถ้าจะอ้างแบบนี้ก็ควรถามคนใกล้ตัวที่เป็นผู้เชี่ยวชาญสถิติว่าควรรองรับมันอย่างไร การที่มีคนไม่กี่คนโพสต์อะไรแบบนั้นไม่ได้ช่วยรองรับข้ออ้างว่ามันเป็น “เรื่องปกติ” อย่างมีนัยสำคัญ
  จากการสังเกตเชิงเกร็ดที่ผมเองก็ไม่ได้รองรับด้วยสถิติ ผู้ใช้สาย “ต่อต้าน AI” มักจะรู้สึกเศร้ามากกว่าจะรู้สึกว่าถูกคุกคามอย่างรุนแรง เวลาที่ LLM เข้ามาแทรกในที่ที่มันไม่ได้ช่วยอะไร

  • บางทีก็เห็นบทความยาวมากและละเอียดมากที่ออกมาโต้คนต่อต้าน LLM บางส่วน ซึ่งโดยมากคือบางส่วนที่ตอบสนองต่อ LLM ในเชิงอารมณ์และสังคม ผมอธิบายชัด ๆ ไม่ค่อยได้ว่าทำไม แต่บทความแบบนั้นให้ความรู้สึกไม่จริงใจมาก และเหมือนกำลังรังแกคนที่อ่อนแอกว่า
    มันละเอียดเกินไปจนโต้แย้งจากมุมอารมณ์ได้ยาก และสุดท้ายก็ดูเหมือนจะลงเอยที่ “LLM ไม่ใช่ปัญหา ถ้าใช้ให้ถูกมันเป็นตัวขยายพลัง คนต่อต้าน AI แค่ไม่รู้เรื่องและกลัวว่าจะตามไม่ทัน”
    ผมก็ไม่อยากลดทอนงานของผู้ดูแล rsync ให้กลายเป็นแค่ประเด็นถกเถียง เลยไม่รู้ว่าจะสร้างข้อโต้แย้งกลับที่น่าเชื่อถือได้ยังไง
    สถิติตรงนี้อาจน่าสนใจจากมุมมองการบำรุงรักษาโอเพนซอร์ส แต่ข้อสรุปกลับเอนเอียงไปข้างหนึ่งอย่างแปลก ๆ และทิ้งความรู้สึกว่าโอเพนซอร์สแบบ GitHub ไม่ใช่รูปแบบที่ผมอยากเข้าไปมีส่วนร่วม
    ถึงอย่างนั้น ผมก็คิดว่าการที่คนไปรุมผู้ดูแลในรีโพ rsync เป็นกลุ่มนั้นไม่ดีเลย
  • การบอกว่า fantasy ความรุนแรง ที่เปิดเผยต่อสาธารณะไม่โอเคนั้นถูกแล้ว นั่นไม่ใช่สิ่งที่ควรเป็นเป้าหมายของสังคมอารยะ แค่ส่วนที่ผู้เขียนเรียกมันว่า “เรื่องปกติ” นั้นดูเหมารวมจนขัดใจ
    ส่วนเรื่องการสังเกตเชิงเกร็ด ผมว่าการ์ตูนนี้ พูดถูก ผมชอบเห็นข้ออ้างที่เฉพาะเจาะจงและวัดผลได้ ส่วนหนึ่งเพราะชอบตัวเลข และอีกส่วนเพราะมันช่วยให้การถกเถียงออนไลน์เข้าใกล้โลกอุดมคติในช่องสุดท้ายของการ์ตูนได้อีกนิด

• ขอบคุณสำหรับการวิเคราะห์ แต่ยังไม่ค่อยมั่นใจในวิธีวิทยา อยากเห็นตัวชี้วัดอย่าง จำนวนบั๊กต่อหน่วยของความต่าง ซึ่งคำนวณโดยนำจำนวนบรรทัดที่เปลี่ยนแปลงในโค้ดหลักของแต่ละคอมมิต—คือโค้ดที่ไม่ใช่เทสต์หรือเอกสาร—มาคูณกัน และการวิเคราะห์เวลาที่ใช้กว่าจะมีบั๊กถึงจำนวนหนึ่งหลังรีลีส
  อย่างไรก็ตาม รีลีสครั้งนี้น่าจะได้รับความสนใจมากกว่ารีลีสอื่นมาก จึงมีความเป็นไปได้สูงว่ามีการรายงานบั๊กมากกว่า ทำให้ดูยากที่จะสร้างตัวชี้วัดที่น่าโน้มน้าวได้มากจริง ๆ คำถามอย่าง “เมื่อวัดจากไม่กี่สัปดาห์หลังรีลีสแล้ว ถือว่าเป็นแบบทั่วไปหรือไม่?” ก็อาจไม่ได้มีประโยชน์นัก