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

 (alexispurslane.github.io)
2 คะแนน โดย GN⁺ 2026-06-06 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • รีลีสที่มี 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 เอง

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2026-06-06
ความคิดเห็นจาก Hacker News

  • ลองไล่ดูคอมมิตแล้วเจอทั้งคอมมิตต้นฉบับและคอมมิตย้อนกลับ: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
    แม้แต่เส้นทางที่ควรเป็น malloc ก็ถูกเปลี่ยนเป็น calloc ทำให้บังคับกับทุกการจัดสรรเหมือนกับว่า calloc เข้ากันได้แบบ superset อย่างเคร่งครัด ซึ่งมีต้นทุนค่อนข้างสูงในกรณีการจัดสรรขนาดใหญ่หรือการจัดสรรแบบเรียกซ้ำ ดูเป็นตัวอย่างที่ดีว่าของแบบนี้หลุดรอดการตรวจทานได้อย่างไรในโค้ดที่เขียนด้วย Claude ส่วนคอมมิตย้อนกลับอยู่ที่ https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721... และแค่อ่านคำอธิบายการย้อนกลับครึ่งเดียวก็ยังให้ความรู้สึกว่าเป็นงานที่ LLM เขียน เข้าใจความรู้สึกของคนที่โพสต์ต้นฉบับได้เลย

    • จำนวนคอมมิตเองก็น่าสงสัย ช่วงสองเดือนล่าสุด จำนวนคอมมิตที่เข้า rsync พอๆ กับของ 2 ปีก่อนหน้านั้นรวมกัน และส่วนใหญ่เป็นคอมมิตที่ทำด้วย Claude พอมีการเปลี่ยนแบบนี้หลุดเข้าไป ก็ยิ่งดูเหมือนอาการคลาสสิกของการตื่นเต้นกับ AI จนค่อยๆ ประมาทมากขึ้น
    • การบอกว่า “เขียนด้วย Claude” ไม่ถูกต้องนัก คอมมิตย้อนกลับอ้างถึง https://github.com/RsyncProject/rsync/issues/959 และใน issue นั้นผู้เขียนอธิบายเองว่า “การเปลี่ยนให้หน่วยความจำถูกทำเป็น 0 เป็นไอเดียของผมและเป็นการเปลี่ยนของผม”
      รายงานด้านความปลอดภัยพบการใช้องค์ประกอบเกินท้ายอาร์เรย์ และเขามองว่าถ้าเริ่มต้นการจัดสรรเป็น 0 ก็มีโอกาสมากกว่าที่บั๊กคล้ายกันในอนาคตจะจบลงที่การ dereference null pointer แทนที่จะเป็น valid pointer ที่ผิดพลาด Claude ถูกใช้แค่ช่วยจัดระเบียบชุดคอมมิต และระบบนี้จะติดแท็ก co-authored หากมีการแก้ไขแม้เพียงเล็กน้อย จึง ไม่ได้หมายความว่า Claude เป็นคนเขียนการเปลี่ยนแปลงนั้น เขาระบุชัดว่าโค้ดจริงเขาเป็นคนเขียน
    • ผมคงไม่ฟันธงว่าการตัดสินใจนั้นมาจาก Claude มันไม่ใช่การเปลี่ยนแปลงยิบย่อยที่แอบสอดเข้ามาระหว่างคอมมิตใหญ่ๆ ด้วยซ้ำ เพราะข้อความคอมมิตเริ่มต้นด้วย “เริ่มต้นหน่วยความจำที่จัดสรรใหม่ทั้งหมดให้เป็น 0” และตัวคอมมิตก็ทำสิ่งนั้นจริงๆ ไม่รู้เหมือนกันว่าคนที่ว่าอย่างนั้นจินตนาการว่าใช้พรอมป์ตแบบไหน
      เป็นไปได้มากว่ามนุษย์คิดว่าเป็นการปรับปรุงในตอนแรก ก่อนจะเห็น RSS regression แล้วกลับมาคิดใหม่ และก็ไม่มีกฎธรรมชาติข้อไหนบอกว่าการเปลี่ยนนี้ต้องทำให้ RSS เพิ่มเสมอไป calloc อาจมีการจัดการพิเศษโดยรู้ว่าการแมปหน่วยความจำใหม่ที่เพิ่งได้จากระบบปฏิบัติการนั้นถูกตั้งค่าเป็น 0 อยู่แล้ว ถ้าจะโทษ AI ในที่นี้ ก็น่าจะหมายถึงว่า AI ทำให้รายงานช่องโหว่พุ่งขึ้น และนั่นนำไปสู่การแก้ไขแบบเร่งด่วนที่พุ่งขึ้น ซึ่งบางครั้งการแก้แบบเร่งด่วนก็สร้างปัญหาอื่นตามมา
    • ช่างเป็นยุคสมัยจริงๆ ที่ AI มาคูณกับ Linux overcommit ส่วนตัวแล้ว 10.8GB ทุกวันนี้ก็ไม่ได้มากอะไรนัก และบัฟเฟอร์ sprintf อาจใหญ่กว่านั้นอีก ถ้าไม่ใช่ก็ควรจะเป็น และถ้าไม่อย่างนั้นก็ควรเริ่มใช้ snprintf

  • แนะนำให้อ่านโพสต์ที่ผู้เขียน rsync ลิงก์ไว้ก่อนจะคอมเมนต์: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
    ขอเปิดเผยไว้ก่อนว่าผมไม่ได้ติดต่อกับ Tridge มาหลายปีแล้ว แต่เขาเคยเป็นทั้งเพื่อนร่วมงานและเมนเทอร์ของผมมานาน ควรพิจารณามุมมองของเขาก่อนจะเข้าร่วมขบวนครูเสด

    • อันนี้ควรเป็นคอมเมนต์บนสุดเลย ค่อนข้างน่าเศร้าที่เขาต้องถึงขั้นเขียนโพสต์แบบนี้ คนที่ไม่ได้เป็นคนจ่ายบิลให้เขากลับตัดสินกันมากเกินไป
    • ผมยังไม่เข้าใจทั้งหมดกับส่วนที่ว่า “ผมคิดว่าควรสร้างโครงสร้างหลักของ test suite ใหม่แบบเปิดเผยบน master ก่อน” ถ้าแค่อัปเดตเฉพาะเทสต์หรือพุชแค่บน master คนคงไม่เดือดกันขนาดนี้
      แต่เขาพุชการเปลี่ยนที่ทำให้พังไปยัง release branch ด้วย การทำลายเวิร์กโฟลว์ที่ใช้งานมาหลายปีเป็นวิธีที่แน่นอนที่สุดในการทำให้คนโกรธ และยิ่งเห็นคำว่า “Claude” ในคอมมิตก็ยิ่งเหมือนราดน้ำมันลงกองไฟ
    • ผมว่าคำตอบของเขาเป็นการรับมือที่เขียนได้ดีมาก

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

    • เห็นด้วย คำพูดในบทความที่ว่า “รีลีสที่แย่ที่สุดในประวัติศาสตร์ของ rsync เกิดขึ้นก่อนนำ Claude มาใช้ และไม่มีใครสังเกตเห็น” ให้ความรู้สึกน้อยกว่าจะเป็นผู้เขียนที่ไม่มีผลประโยชน์กับเรื่องนี้ แต่ให้ความรู้สึกมากกว่าว่าเขา ห่อหุ้มความคิดเห็นด้วยคำศัพท์ทางสถิติที่ดูหวือหวา
      “ชัดเจนจนน่าตื่นตา” เหรอ? แค่วาดกราฟสักอันก็พอแล้ว และ v3.4.1 คือวันที่ 2025-01-16 ดังนั้นในทางเทคนิคมันก็อยู่ในยุคของการเขียนโค้ดแบบมี AI ช่วยแล้ว และเป็นช่วงก่อนที่การติดป้ายระบุที่มาจะกลายเป็นแนวปฏิบัติมาตรฐาน
    • เมื่อคำนึงว่าการออกรุ่นค่อนข้างห่างกัน ผมเลยเริ่มดูประเด็นเดียวกันนี้เหมือนกัน ถ้าจะหลีกเลี่ยงปัญหาคอมมิตที่ LLM เขียนแต่ไม่ได้ติดป้ายระบุที่มา ผมคิดว่าการวิเคราะห์ควรต้องรวมการเปรียบเทียบความรุนแรงของบั๊ก ก่อนและหลัง v3.3.0 ด้วย วันที่คือ 6 เมษายน 2024
    • LLM ถูกใช้งานได้หลายแบบ ตั้งแต่ให้คนควบคุมใกล้ชิดมากและให้เปลี่ยนแค่เฉพาะจุดในเครื่อง ไปจนถึงปล่อยให้จัดการทั้งหมด
      ผมเห็นโค้ดที่ LLM สร้างแต่ในข้อความคอมมิตไม่มีผู้ร่วมเขียนติดอยู่เยอะมาก ปกติดูเหมือนจะมีแท็กแบบนั้นก็ต่อเมื่อการติดต่อกับโค้ดเบสเกิดผ่านเครื่องมืออย่าง Claude/Codex แบบครบวงจร และคอมมิตพวกนั้นก็มักยืดยาวมากแต่แทบไม่บอกเหตุผลที่เปลี่ยน มีแค่สรุปว่าเปลี่ยนโค้ดอะไรบ้าง ในทางกลับกันผมก็เคยเห็นนักพัฒนาที่ใช้ Claude เป็นแค่เครื่องมือ สลับไปมาระหว่าง VSCode กับเทอร์มินัลของ Claude ตรวจสอบโค้ดที่ถูกต้องด้วยตัวเอง และโยนงานจิปาถะให้ Claude ทำ ผู้เขียนเองก็น่าจะเริ่มจากเล็ก ๆ แล้วค่อยเพิ่มขึ้นตามเวลา
    • ประเด็นแรกกับประเด็นที่สองดูเหมือนจะขัดกันเอง ถ้าบั๊กทั้งหมดของ 3.4.1 ควรถูกโยงกลับไปที่ 3.4.0 ช่วงเวลาที่คอมมิต LLM แบบไม่ถูกระบุแหล่งที่มาจะต้องหลุดเข้ามาในโปรเจกต์ก็ยิ่งต้องย้อนกลับไปก่อนหน้านั้นอีก ซึ่งยิ่งทำให้สมมติฐานนี้ไม่น่าเป็นไปได้มากขึ้น
      ปัญหาใหญ่กว่านั้นคือ ไม่มีหลักฐานเลย ที่สนับสนุนสมมติฐานว่ามีคอมมิต LLM แอบหลุดเข้ามาในรีลีสก่อนหน้าและนั่นจึงทำให้อัตราบั๊กสูงขึ้น มันไม่มีมูลเลย เว้นแต่ว่าจะตั้งต้นว่าจำนวนบั๊กที่สูงเท่ากับมี AI เข้ามาเกี่ยวโดยอัตโนมัติ ซึ่งนั่นก็เป็นการให้เหตุผลแบบวนซ้ำ ประเด็นที่สามนั้นใช้ได้ ผมวิเคราะห์ไว้แล้วว่าปกติใช้เวลานานแค่ไหนกว่าจะพบบั๊ก และแต่ละเวอร์ชันอยู่ตรงไหนในรอบการออกรุ่น ถ้าอยากได้เดี๋ยวผมโพสต์ให้
    • ถ้าจะเริ่มจากข้อผิดพลาดที่ชวนตกใจที่สุดแบบตรงไปตรงมาเลย ก็คือสถิติของ Claude มาจาก ข้อมูลทั้งหมด 2 จุด

  • มีความย้อนแย้งเชิงเมตาที่สำคัญอยู่ตรงนี้ บทความต้นฉบับปกป้องการใช้ AI แต่ก็ดูชัดเจนว่าใช้ AI ในการวิเคราะห์ข้อมูลและนำเสนอผลลัพธ์ด้วย
    ระหว่างทางนั้น ผู้เขียนใช้สถิติในแบบที่ตัวเองดูจะไม่เข้าใจดีพอ และลงเอยด้วยข้อสรุปผิด ๆ หลายอย่าง ดูการถกเถียงที่เกี่ยวข้องได้ที่ https://news.ycombinator.com/item?id=48417626 สรุปคือการศึกษานี้มี อำนาจการทดสอบทางสถิติ ไม่เพียงพอ และกำลังอ้างว่า “ไม่มีความแตกต่าง” ทั้งที่ไม่มีเหตุผลรองรับ ท้ายที่สุดก็กลายเป็นว่าตีความข้อมูลด้วย LLM แล้วดันทำผิดพลาดแบบเดียวกับที่งานชิ้นนี้พยายามจะตรวจสอบ นั่นคือการยืนยันเรื่องเท็จอย่างมั่นใจ

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

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

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

  • ผมขอบคุณ Andrew สำหรับงานที่สร้างและดูแล rsync มาโดยตลอด แต่เพราะผมพึ่งพา rsync มากสำหรับการสำรองไฟล์ระหว่างเครื่องในเครือข่ายบ้าน ผมเลยยอมใช้เวลาเพื่อหาวิธีตรึงเวอร์ชัน rsync ของ Homebrew ไว้ที่ 3.4.1
    ตั้งแต่นั้นมาบั๊กในสองเวอร์ชันถัดมาก็น่ากลัวจริง ๆ และรายงานต้นฉบับที่จุดชนวนเรื่องทั้งหมดนี้ก็เช่นกัน ผมสรุปขั้นตอนไว้ที่นี่ ซึ่งซับซ้อนกว่าที่คิดมาก: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

  • บทความนี้ทิ้งคำถามไว้มากกว่าคำตอบ จนตัดสินได้ยาก ฉันไม่เข้าใจว่าทำไม v3.4.1 ก่อนคอมมิตของ Claude ถึงมีบั๊กมากที่สุด และทำไม “ไม่มีใครสังเกตเห็น” มัน แปลกเกินกว่าจะปัดว่าเป็นแค่ความผิดพลาดของมนุษย์
    อีกอย่างก็ยังสงสัยว่าทำไม v3.4.2 ถึงมีบั๊กเป็น 0 หรือคะแนนบั๊กเป็น 0 ด้วย ค่าผิดปกติแบบนี้ที่ดูเหมือนไม่มีในคอมมิตอื่นกลับถูกปล่อยให้ปนอยู่ในสถิติรวม จนช่วยลดคะแนนแนว “Claude สร้างบั๊กหรือเปล่า?” ก็แปลกเหมือนกัน พูดตรง ๆ คือไม่เข้าใจว่าทำไมสิ่งนี้ถึงไม่ใช่สัญญาณอันตรายในงานวิเคราะห์ของผู้เขียน รู้สึกเหมือนเอาการวิเคราะห์ครึ่ง ๆ กลาง ๆ มานำเสนอเป็นงานสำเร็จรูปที่ซับซ้อนมาก เพียงเพราะมีการใช้สถิติขั้นสูง

    • ฉันไม่รู้ว่ามีเหตุผลอะไรที่ทำให้มองว่า v3.4.1 ไม่ใช่ความผิดพลาดของมนุษย์ นอกจากสมมติฐานตั้งต้นว่ามันเป็นไปไม่ได้
      ส่วน v3.4.2 เดิมทีในเมตริกต้นฉบับก็มีบั๊ก 4 ตัวก่อนจะกรองคำขอฟีเจอร์และคำถามออก และก่อนหน้านั้นก็สูงกว่านั้นอีก แต่ไม่ได้สร้างความต่างใหญ่ต่อการวิเคราะห์โดยรวม มันยังอยู่ในช่วง interquartile range และอยู่ฝั่งค่าต่ำเสียด้วยซ้ำ ในเมื่อมี Claude release แค่สองครั้ง การตัดค่าผิดปกติทิ้งเพียงเพราะมันดูตลก น่าจะแย่กว่าและเป็นการเลือกตามอำเภอใจมากกว่า

  • ถ้าแนวคิดคือ “ไม่ได้ควบคุมความซับซ้อนของคอมมิต การเน้นด้านความปลอดภัย หรือความร้ายแรงของบั๊ก มันเป็นเครื่องมือทื่อ ๆ ที่ไม่แยกแยะระหว่างการแก้ typo หนึ่งบรรทัดกับแพตช์ CVE แต่เพราะคำกล่าวหาของฝั่งวิจารณ์ที่ว่า ‘Claude ทำให้สถานการณ์แย่ลง’ ก็เป็นเครื่องมือทื่อ ๆ เหมือนกัน ดังนั้นการตอบโต้ด้วยเครื่องมือทื่อ ๆ จึงยุติธรรมที่สุด” แบบนี้ ฉันเห็นด้วยได้ยาก
    จากมุมมองของผู้ใช้ เราต้องเข้าใจว่าลักษณะของบั๊กแย่ลงหรือไม่ ต่อให้สัดส่วนเท่าเดิม แต่ถ้าคุณภาพซอฟต์แวร์ที่ผู้ใช้รับรู้แย่ลง โดยเฉพาะถ้าคุณเป็นผู้ดูแลโครงการ ก็คงมองว่ามันแย่ลง ฉันไม่ได้จะปัดการวิเคราะห์นี้ทิ้งทั้งหมด แต่คิดว่าคำถามแบบนี้ตอบได้ไม่พอด้วยการวิเคราะห์เชิงปริมาณอย่างเดียว

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

  • ฉันเขียนโค้ดมาเกิน 20 ปี รักการเขียนโค้ดมาตลอด และก็น่าจะยังเป็นแบบนั้นต่อไป ไม่กี่เดือนก่อนฉันยังเป็นพวกสงสัย AI อยู่เลย แต่ Claude กับ Codex เปลี่ยนวิธีพัฒนาและความเร็วในการทำงานของฉันไปในแบบที่ไม่เคยนึกภาพได้มาก่อน
    ผลคือฉันสร้างโค้ดได้มากขึ้น และเจอบั๊กมากขึ้นด้วย เพราะงั้นเวลาเห็นความเกลียดชังรุนแรงต่อของที่สร้างด้วย AI ในคอมเมนต์ HN ก็เลยค่อนข้างแปลกใจ ไม่ใช่ว่าแค่มี AI ช่วยหรือให้มันสร้างทั้งหมดแล้วโครงการจะกลายเป็น vibe coding ไปทันที และคำนั้นก็ไม่ควรเป็นคำดูถูกที่โยนใส่ผู้ใช้ LLM ด้วย มันทำให้นึกถึงคำเหยียดมากมายที่เคยพุ่งไปที่ “นักพัฒนาชาวอินเดีย” ตอนงานเอาต์ซอร์สต่างประเทศเฟื่องฟูตั้งแต่กลางยุค 90 ตอนนี้กลางทศวรรษ 2020 ก็มีคำพูดคล้ายกันโยนใส่ AI อีก ฉันไม่เข้าใจ สิ่งที่แน่ชัดคือไม่ว่าคนคัดค้านจะคิดอย่างไร โค้ดที่สร้างด้วย AI ก็จะมีมากขึ้นเรื่อย ๆ

    • ฉันก็เคยสงสัย AI ในทำนองเดียวกันเมื่อ 3 ปีก่อน ตอน GPT-4 ยังเป็น state of the art ฉันคิดว่ามันคงชนเพดานในไม่ช้าเพราะข้อจำกัดด้านขนาดบริบท ยังจำได้เลยว่าสมัยจะใช้บริบท 32K ต้องจ่ายแพงแบบเหลือเชื่อ
      ปีก่อนฉันเห็น AI agent ดีบักและแก้บั๊กที่ไม่ใช่เรื่องจิ๊บจ๊อยได้อย่างน่าพอใจเป็นครั้งแรก ตอนนั้นก็ยังชัดเจนว่า ถ้าเอาไปใช้กับงานใหญ่ มันยังไม่ถึงระดับที่จะโยน issue tracker ทั้งอันให้มันจัดการได้ ตอนนี้ฉันทำโปรเจกต์ที่ไม่เล็กน้อยด้วย Codex มาไม่กี่เดือนแล้ว เพราะเหตุผลด้านไลบรารีเลยทำต้นแบบด้วย C++ เวอร์ชันแรกเขียนด้วย Haskell และช่วงหลังก็พอร์ตไป Rust เพื่อลดการใช้หน่วยความจำบนมือถือ มันไม่ใช่เครื่องมือที่ไร้ปัญหา แต่ความเร็วของพัฒนาการในปีที่ผ่านมา น่าทึ่งมาก ความสงสัยเป็นเรื่องดี แต่ถ้าเป็นความสงสัยที่ดีต่อสุขภาพ ก็ควรถอยเมื่อเจอหลักฐานที่เป็นรูปธรรม
    • ในทุกหัวข้อที่เกี่ยวกับเครื่องมือ จะมีทั้งคนที่ชอบตัวเครื่องมือเอง และคนที่ชอบใช้เครื่องมือนั้นไปทำอย่างอื่น สำหรับการเขียนโปรแกรม ฉันเป็นอย่างหลัง การเขียนโปรแกรมเป็นเครื่องมือที่ทำให้ฉันได้ทำสิ่งที่ชอบจริง ๆ คือการแก้ปัญหา การคิดระดับระบบ และการส่งมอบทางออกเจ๋ง ๆ ผ่านซอฟต์แวร์
      เพราะงั้น AI ที่มาช่วยส่วนที่น่าเบื่อจึงทำให้ฉันสนุกมาก และก็สนุกมากเช่นกันที่ได้เห็นเพื่อนร่วมงานที่ไม่ใช่โปรแกรมเมอร์ตื่นเต้นเมื่อไอเดียแบบ vibe coded ของพวกเขากลายเป็นจริง ฉันอยากรู้จริง ๆ ว่ามุมมองแบบต่อต้าน AIของคนที่ทำงานในอุตสาหกรรมซอฟต์แวร์เป็นอย่างไร เป็นเพราะกลัวจุดจบของอาชีพที่ใกล้เข้ามา หรือเพราะการเปลี่ยนผ่านทางเทคโนโลยีกันแน่?
    • ถ้าตอนกลางยุค 90 ที่งานเอาต์ซอร์สต่างประเทศเพิ่มขึ้น มีคำเหยียดพุ่งไปที่ “นักพัฒนาชาวอินเดีย” จริง แล้วต้นตอของมันคืออะไร?
    • ฉันต้องรับมือกับโค้ดเอาต์ซอร์สอยู่เสมอ และมันเหมือน ไฟไหม้กองยาง ทุกครั้งไม่มีข้อยกเว้น เมื่อกี้ฉันเพิ่งใช้เวลาหนึ่งสัปดาห์ทำความสะอาดโค้ดเบสที่นักพัฒนาคนหนึ่งคอมมิตแฟลกข้ามการตรวจสอบยืนยันตัวตนให้เปิดเป็นค่าเริ่มต้น เพราะเขาตั้งสภาพแวดล้อมการทำงานในเครื่องตัวเองไม่เป็น
      ใน AI vibe coding ก็มีรายงานปัญหา “ทางลัด” แบบเดียวกัน และต่อให้ฉันใช้โมเดลแนวหน้าพร้อมดันระดับการคิดไปถึง 11 ฉันก็ยังต้องเขียนโค้ดที่ AI สร้างขึ้นใหม่เกือบทั้งหมดอยู่ดี แต่ AI มีประโยชน์มากในกิจกรรมอื่น เช่น รีวิว PR วิเคราะห์ช่องโหว่ความปลอดภัย หา typo และทำ reverse engineering ฉันคงต้องอัปเกรดแพ็กเกจสมาชิกขึ้นอีกระดับด้วยซ้ำ แต่ในขณะเดียวกันโค้ดที่ AI สร้างก็ยังใช้ไม่ได้อยู่ดี ถ้าในคนคนเดียวกันสามารถมีทั้งความเห็นว่า “มันมีประโยชน์มากจนต้องยอมจ่ายเพิ่ม” และ “คุณภาพโค้ดที่มันปล่อยออกมายังใช้การไม่ได้” พร้อมกันได้ ก็ไม่แปลกที่ฐานผู้ใช้โดยรวมจะมีความเห็นหลากหลาย
    • LLM เก่งเรื่องการค้นบริบทและการปล่อยผลลัพธ์แบบเทมเพลต แต่สิ่งที่รับประกันได้คือคำตอบที่เด่นที่สุดในระดับตัวหารร่วมต่ำสุด ผลงานที่ไม่สามารถคุ้มครองลิขสิทธิ์ได้ และยังมีความเสี่ยงทางกฎหมายที่อาจเกิดจากการรั่วไหลของลิขสิทธิ์ด้วย
      ตอนนี้คือยุคทองแบบ Napster ของการลอกเลียนแบบเชิงโครงสร้าง

  • ฉันไม่รู้จริง ๆ ว่านี่คืออะไรกันแน่ สิ่งที่สำคัญจริง ๆ มีแค่ว่า หลังจากอนุญาตให้โค้ดที่ AI เขียนเข้าไปอยู่ในโค้ดเบสแล้ว บั๊กเพิ่มขึ้นหรือไม่ ซึ่งทุกคนก็รู้คำตอบอยู่แล้ว ถึงอย่างนั้นก็ยังน่าสนใจเสมอที่ได้เห็นว่ามันสามารถถูกใช้เพื่อสร้างข้อสรุปที่ต้องการ “ข้อมูล” มารองรับได้
 
GN⁺ 2026-06-06
ความเห็นจาก 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 ความรุนแรง ที่เปิดเผยต่อสาธารณะไม่โอเคนั้นถูกแล้ว นั่นไม่ใช่สิ่งที่ควรเป็นเป้าหมายของสังคมอารยะ แค่ส่วนที่ผู้เขียนเรียกมันว่า “เรื่องปกติ” นั้นดูเหมารวมจนขัดใจ
      ส่วนเรื่องการสังเกตเชิงเกร็ด ผมว่าการ์ตูนนี้ พูดถูก ผมชอบเห็นข้ออ้างที่เฉพาะเจาะจงและวัดผลได้ ส่วนหนึ่งเพราะชอบตัวเลข และอีกส่วนเพราะมันช่วยให้การถกเถียงออนไลน์เข้าใกล้โลกอุดมคติในช่องสุดท้ายของการ์ตูนได้อีกนิด

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