QGIS ห้ามโค้ดจาก AI: X ถกว่า Review รับไม่ไหว หรือถอยจากอนาคต

ฝั่ง 1 — Review รับไม่ไหว: ทรัพยากรที่หายากคือชั่วโมงของผู้รีวิว

เสียงหลัก: ผู้ดูแล QGIS ในเธรด PR และบัญชีสาย Dev/AI ที่สรุปข่าว

• ในเธรด PR @haubourg อธิบายว่าการใช้ AI ของผู้ร่วมพัฒนาภายนอกสร้าง “massive and unbearable pressure on the shoulders of our maintainers” และ “AI stream is a lot higher than what human review can take seriously” ผลคือ PR ที่รอรีวิวยาวขึ้น หรือโค้ดที่ถูกรีวิวไม่เต็มที่
• @cozybearlog สรุปว่า “the scarce resource in a volunteer project was never code. It was reviewer hours, donated for free.” และ “Companies hit the same wall and just hire more reviewers. Volunteers cannot.”
• @harden_369741 เขียนว่า “The AI didn’t make code free, it moved the cost.”
• บัญชีขนาดเล็กรายหนึ่ง มองว่า “A ban is a pricing decision.” คือย้ายต้นทุนการตรวจกลับไปที่คนสร้างงาน อีกบัญชีหนึ่ง ตอบว่า การแบนเป็นเรื่องเวลามากกว่าการจับผิด เพราะ “It gives maintainers a reason to close a weird PR in ten seconds without a long argument about it.”
• @JustTakeAL987 (โพสต์ภาษาจีน) บอกว่า LLM ใช้ 10 วินาทีก็สร้าง PR ที่ดูไม่มีปัญหาได้ แต่ผู้ดูแลอาจต้องใช้หลายชั่วโมงตรวจขอบเขตและความสัมพันธ์กับโค้ดเดิม (แปลความ)

ฝั่ง 2 — ปิดประตูก่อน แล้วค่อยเปิดทีละบาน

เสียงหลัก: ผู้เสนอ QEP เอง และคนที่มองว่านี่คือเบรกฉุกเฉิน

• Nyall Dawson ตอบในเธรดว่านี่ไม่ใช่นโยบาย “written in stone, forever” แต่เป็น “lets start with a closed door, which we can then selectively open a little if/when it’s safe” และยกตัวอย่างว่าภายหลังอาจมีคนเสนอให้ใช้ AI แทน IDE autocomplete หรือใช้แปลภาษา โดยพิจารณาทีละกรณี
• @elpaso ย้ำว่าไม่ได้แปลว่าจะห้าม AI “forever and in any form” ส่วน Even Rouault (บัญชี @rouault-on-strike) เรียกว่า “a stop gap measure”
• @aka_ssy เรียกว่า “controlled pause” และมองว่า QGIS “betting that precise exceptions are easier to add than lost trust is to rebuild.”
• @ju1fy เห็นว่าเป็น “a reasonable emergency brake” แต่เตือนว่า “a fuzzy ban can punish careful use while missing undisclosed use.”
• @superdoccimo (ภาษาญี่ปุ่น) ชี้ว่าตอนนี้มีทั้งข้อเสนอยกเว้นให้นักพัฒนาที่มีประสบการณ์ และข้อเสนอขยายข้อห้ามไปถึงข้อความที่ AI สร้าง (แปลความ)

ฝั่ง 3 — นิยามกำกวม และบังคับใช้ไม่ได้จริง

เสียงหลัก: ผู้ร่วมพัฒนาในเธรด GitHub และนักพัฒนาที่ใช้ AI ประจำ

• ก่อนโหวต @02JanDal ถามว่าแบบไหนนับว่าโดนห้าม เช่น LLM autocomplete, ML ที่ IDE ของ JetBrains ใช้จัดอันดับ autocomplete, การใช้ ChatGPT ระดมไอเดียออกแบบ, การเห็นคำตอบ AI ใน Google โดยบังเอิญ หรือการใช้ Google Translate หาศัพท์ แล้วเสนอให้เขียนว่า “No code contributions written by LLM or AI-agents”
• Tim Sutton (@timlinux) ตอบว่ามาตรวัดคือ “did you in good conscience write the code yourself” และยอมรับว่า “we are not set up to peer into your computer”
• @kannes เตือนว่าคำว่า “assisted” และ “used” กว้างจนอาจ “throw out the baby with the bathwater” Even Rouault ตอบว่า “yes, we are aware … but the baby might be non-viable”
• @ElliotChen เป็นเสียงวิจารณ์ที่ชัดที่สุดในตัวอย่าง: “a ban can’t tell my AI-written code from my hand-written code. It only tells honest people to stop saying so.” และ “The real problem is unreviewed code, and that existed long before LLMs.”
• @manongfu (ภาษาจีน) สงสัยว่าจะบังคับใช้อย่างไร เพราะทีมเองก็ยอมรับว่าทำได้แค่พึ่งความสมัครใจ บัญชีขนาดเล็กอีกรายใช้สำนวนจีนว่า “กันได้แต่สุภาพชน กันคนร้ายไม่ได้” (แปลความ) และ อีกบัญชี ถามว่า “how you even enforce that”
• @cozybearlog ชี้ช่องว่างอีกแบบว่า “plenty of people now prototype with AI, then write the final code by hand. QGIS declined to draw that line.”

ฝั่ง 4 — เสียคน หรือถอยหลัง? (และคำแย้งว่าเสียคนไปแล้ว)

เสียงหลัก: คนที่กังวลเรื่องประสิทธิภาพและการกีดกัน กับผู้ดูแลที่บอกว่าความเสียหายเกิดก่อนแล้ว

• บัญชีขนาดเล็กรายหนึ่ง ถามว่า “Is this protecting open source or shutting contributors out?” อีกรายเขียนเป็นภาษาจีนว่าการแบน “กันผลประโยชน์ด้าน Productivity ไว้นอกประตูด้วย” (แปลความ)
• @prpatel05 ประชดทั้งสองฝั่ง: “somewhere a maintainer got their weekends back and a contributor found out they can’t write a for loop”
• ฝั่งผู้ดูแลแย้งว่าการเสียคนเกิดขึ้นไปแล้ว แต่เป็นการเสียคนรีวิว Nyall เขียนว่านโยบายเก่า “clearly didn’t work” และ “we’ve already lost at least one extremely high value contributor as a result” ในเธรดไม่ได้ระบุว่าเป็นใคร
• @Amalvir ผู้ร่วมพัฒนามือใหม่ที่เคยส่ง PR แก้บั๊กที่ใช้ AI ช่วย 2 รายการ กลับโหวตสนับสนุน บอกว่า “LLMs give you the illusion that it’s possible” และกังวลว่าคนที่พึ่ง AI จะไม่ได้เรียนรู้มากพอจนกลายเป็นผู้รีวิวในอนาคต
• คำวิจารณ์เรื่องการกีดกันยังพุ่งไปที่ไอเดีย Proof of life ด้วย Célia Buira เขียนในเมลลิสต์ว่าการร่วมพัฒนา QGIS ก็ต้องใช้ฮาร์ดแวร์หลายพันดอลลาร์อยู่แล้ว การบังคับบริจาคจะยิ่งเพิ่มความเหลื่อมล้ำ

ข้อสังเกต: ในตัวอย่างที่เราอ่าน คำวิจารณ์แรง ๆ แบบ “Luddite” หรือ “ต่อต้านความก้าวหน้า” แทบไม่มี คำค้นที่มีคำว่า luddite ไม่พบโพสต์ที่เกี่ยวข้องเลย ส่วนใหญ่เป็นแค่ข้อกังวลว่าจะเสียประโยชน์หรือกันคนออก

ฝั่ง 5 — Human in the loop แบบ LLVM ถูกลองแล้ว แต่ไม่เกิดจริง

เสียงหลัก: คนที่ชี้ว่านโยบายเปิดเผยแล้วให้คนตรวจ ใช้ไม่ได้ในทางปฏิบัติ กับคนที่ยังเชื่อในแนวทางนี้

• @uclaros เขียนในรีวิว PR ว่าป้าย extractive ไม่เคยถูกสร้างจริง “~50 PRs were tagged AI Assisted, ~40 of them were closed without merging” และยังมี PR อีกหลายรายการที่ถูกปิดโดยไม่ได้ติดป้าย
• บัญชีขนาดเล็กรายหนึ่ง สรุปว่า QEP 428 ผ่านเพราะ “tag-and-review failed” และ “Other projects will copy this.” อีกราย เตือนความจำว่า จนถึงสัปดาห์ก่อน กฎยังเป็น “use any tool, keep a human in the loop, tag it Assisted-by.”
• ฝั่งที่ยังเชื่อใน Human in the loop บอกว่าทางแก้คือคุมคุณภาพ ไม่ใช่ห้าม @Av1dlive ตอบ ElliotChen ว่า “we should just have better filter systems for AI slop and non-AI slop, and make code quality a part of CI/CD pipelines.” บัญชีเล็กอีกราย ประกาศหลักของตัวเอง ว่า “If my agent opens a PR on your repo, I read it first.”
• ข้อควรระวัง: QGIS ล้มเหลวกับแนวทางนี้ ไม่ได้แปลว่า LLVM ล้มเหลวด้วย LLVM ยังใช้นโยบาย Human in the loop อยู่ ณ วันที่ตรวจ บริบทของสองโครงการ เช่นจำนวนผู้รีวิว ต่างกัน