- เอนจินเกมโอเพนซอร์ส Godot ตัดสินใจห้าม โค้ดที่เขียนโดย AI และการส่งงานโดย AI agent ใน policy การมีส่วนร่วม หลัง Pull Request ที่สร้างโดย AI เพิ่มภาระการรีวิว
- เหล่า maintainer มองว่าการตรวจ PR ที่สร้างโดย AI ทำให้งานรีวิวที่น่าเบื่ออยู่แล้วสิ้นเปลืองแรงมากขึ้น และยังลดผลในการปั้นผู้มีส่วนร่วมหน้าใหม่ให้เป็น maintainer ในอนาคต
- policy ใหม่จะปฏิเสธอย่างชัดเจนทั้งโค้ดที่ AI เขียน, Pull Request ที่ AI agent ส่ง และ ข้อความที่สร้างโดย AI ในการสื่อสารระหว่างคน
- ผู้มีส่วนร่วมสามารถใช้ AI เป็นตัวช่วยได้เฉพาะกับงาน “menial things” เท่านั้น และต้องเปิดเผยว่าใช้ AI โดย การแปลด้วยเครื่อง ที่อิงจากต้นฉบับที่มนุษย์เขียนยังคงอนุญาต
- Godot Foundation จะดำเนินการแบบระมัดระวังไว้ก่อน เนื่องจากเครื่องมือ AI เปลี่ยนแปลงรวดเร็ว และมีแผนจะประเมิน policy ใหม่ตามสถานการณ์ที่เปลี่ยนไป
การเปลี่ยนแปลง policy การมีส่วนร่วมของ Godot
- Godot Foundation และเหล่า maintainer หารือกันมาหลายเดือน ก่อนตัดสินใจปรับปรุง แนวทางสำหรับผู้มีส่วนร่วม เพื่อจำกัดการส่งงานที่เกี่ยวข้องกับ AI
- สิ่งที่ถูกจำกัดคือโค้ดที่ AI เขียน, Pull Request ที่ AI agent ส่ง และข้อความที่สร้างโดย AI ในการสื่อสารระหว่างคน
- Godot เป็นเอนจินเกมโอเพนซอร์สที่ใช้ในเกมอย่าง Slay the Spire 2 และ The Case of the Golden Idol
ภาระดูแลรักษาที่ Pull Request จาก AI สร้างขึ้น
- เหล่า maintainer ได้หารือกันมาตั้งแต่เดือนกุมภาพันธ์ว่าจะรับมือกับ AI slop Pull Request ที่เพิ่มขึ้นอย่างไร
- กระแส PR เหล่านี้ทำให้ผู้รีวิวโค้ดของโปรเจกต์อยู่ในสภาพ “increasingly draining and demoralizing”
- Godot Foundation มองว่าปัญหานี้ไม่ใช่เรื่องชั่วคราว และต้องการลดภาระของ maintainer ขณะยังคงรักษาเส้นทางในการปั้นผู้มีส่วนร่วมหน้าใหม่ให้เป็น maintainer ในอนาคต
ปัญหาที่การรีวิวไม่ต่อยอดไปสู่การ mentorship
- สถานการณ์ที่มี PR รอการตรวจจำนวนมากนั้น อาจมองได้ว่าเป็นสัญญาณของความสนใจที่เพิ่มขึ้นต่อการใช้งานและการมีส่วนร่วมกับ Godot
- แต่เมื่อการมีส่วนร่วมที่ AI เขียนหรือส่งเพิ่มขึ้น maintainer ก็มีความเต็มใจที่จะใช้เวลากับการรีวิว PR น้อยลง
- หาก feedback ของ PR ไม่ได้ช่วย mentor ผู้ที่อาจเป็น maintainer ในอนาคต แต่กลับถูก “เครื่องจักรดูดซับ” ไป ก็ยากที่จะให้เหตุผลรองรับการใช้เวลาว่างไปกับการรีวิว
ข้อจำกัดเฉพาะของ policy ใหม่
- policy การมีส่วนร่วมของ Godot จะเพิ่มข้อความที่ปฏิเสธ AI-authored code อย่างชัดเจนในเร็ว ๆ นี้
- ผู้มีส่วนร่วมต้องใช้ความช่วยเหลือจาก AI เฉพาะกับงาน “menial things” เท่านั้น และต้องเปิดเผยว่าใช้งาน
- Foundation ระบุว่า “AI ไม่สามารถรับผิดชอบได้ และเราไม่อาจเชื่อถือได้ว่าคนที่ใช้ AI อย่างหนักจะเข้าใจโค้ดของตนเองมากพอที่จะแก้ไขมันได้”
- ในการสื่อสารระหว่างคน ข้อความที่สร้างโดย AI ก็จะถูกปฏิเสธเช่นกัน
- Foundation อธิบายสิ่งนี้ว่าเป็น “a basic principle of respect”
- การแปลด้วยเครื่อง ที่อิงจากต้นฉบับที่มนุษย์เขียนยังคงได้รับอนุญาตต่อไป
แนวทางการดำเนิน policy
- Godot Foundation มุ่งเน้นการเพิ่มกำแพงกั้นต่อการมีส่วนร่วมแบบ “slop” ที่ใช้ความพยายามต่ำ
- การทำให้ maintainer ยังคงรีวิวโค้ดต่อไปได้ และการช่วยให้ผู้มีส่วนร่วมหน้าใหม่เติบโตเป็น maintainer ในอนาคต ก็เป็นเป้าหมายของ policy นี้ด้วย
- การมีส่วนร่วมทั้งหมดต้องมาจาก มนุษย์ ที่รับผิดชอบต่อโค้ดของตนเอง และสามารถแก้ไขได้ด้วยตนเองหากเกิดความล้มเหลว
- Foundation ระบุว่าเครื่องมือ AI ในปัจจุบันเปลี่ยนแปลงทุกวัน จึงจะรักษา policy แบบระมัดระวังไว้ก่อน แต่จะประเมินใหม่ตามความเปลี่ยนแปลง
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
นโยบายนี้ยุติธรรมดี การถูกส่ง กำแพงข้อความที่ AI เขียน ยืดยาวมาให้ตรวจอย่างละเอียดนี่น่าหงุดหงิดจริง ๆ และเหมือนเป็นการโจมตีแบบปฏิเสธการให้บริการต่อจิตใจมนุษย์
แต่คงกันการเขียนโค้ดที่อาศัย AI เองไม่ได้ ในแง่ลบ ผู้ส่งอาจเติมลักษณะสำนวนให้ดูเหมือนคนเขียน ทำให้สาระสำคัญและขนาดของ contribution ยังเหมือนเดิม แต่สไตล์กลับประหลาดขึ้น
ในแง่บวก อาจทำให้คนส่ง commit และคอมเมนต์แบบไม่เยิ่นเย้อ เช่น “นี่คือโค้ด เหตุผลที่แก้คือแบบนี้ และผลกระทบเป็นแบบนี้” แม้ AI จะเป็นคนสร้าง contribution เล็ก ๆ แบบนี้ก็ตรวจสอบได้ง่ายกว่ามาก และอาจเกิดมาตรฐานเรื่องขนาด contribution ที่เหมาะสม หรือการเปลี่ยนแปลงแบบไหนที่ต้องรีวิวเข้มขึ้น
ส่วนตัวแล้วถ้าเนื้อหาเข้ากับแบบหลัง ผมก็ไม่ได้สนใจมากนักว่ามันสร้างโดย AI หรือไม่
ถ้ามี “commit และคอมเมนต์แบบไม่เยิ่นเย้อ” มาจริง ๆ คงเหมือนฝันเลย
ในบริบทแบบนี้ การผลัก contribution จาก AI ออกไปจึงสมเหตุสมผล และยิ่งเป็นซอฟต์แวร์อย่าง Godot ที่พิสูจน์คุณค่ามหาศาลมาแล้วก็ยิ่งใช่
ถ้า commit ที่ AI เขียนไม่ได้แตกต่างโดยเนื้อแท้ ก็ไม่มีเหตุผลจะปฏิเสธ ดังนั้นผมคิดว่าเป้าหมายไม่ใช่การกันการเขียนโค้ดที่อาศัย AI
น่าสนใจที่ด้านหนึ่ง มูลค่าบริษัทของผู้เล่น AI ตั้งอยู่บนสมมติฐานว่าในอนาคตอันใกล้ โค้ดและผลงานดิจิทัลทั้งหมดจะ ถูกเขียนโดย AI แต่อีกด้านหนึ่ง โปรเจกต์โอเพนซอร์สยอดนิยมแทบทั้งหมดกลับพยายามกัน contribution จาก AI สองอย่างนี้เข้ากันได้ยาก
ส่วนตัวหลังจากลองใช้กับโปรเจกต์โอเพนซอร์สของตัวเองมากพอ ก็เหมือนเจอ อาการเมาค้างจาก AI ตอนใช้รู้สึกเหมือนได้พลังมหาศาล สร้างฟีเจอร์ที่ปกติใช้เวลาหลายสัปดาห์ได้ในไม่กี่ชั่วโมง แต่พอเวลาผ่านไปกลับมาดูโค้ด ก็เห็นรอยร้าวและความไม่สอดคล้องเล็ก ๆ ที่เครื่องมือทิ้งไว้ ทำให้ลำบากใจ
ตอนนี้เลยพยายามใช้มันน้อยลงในงานที่วาง guardrail เข้ม ๆ ได้ เช่น การวางแผน ดีบัก และ refactor ในขอบเขตแคบ มากกว่าการพัฒนาฟีเจอร์ใหญ่ ถึงอย่างนั้นงานก็ยังเร็วขึ้น แต่ใกล้เคียง 1.5–3 เท่า ไม่ใช่ 10 เท่า
สมาธิทางจิตที่ต้องใช้ในการเขียนโค้ดลดลงก็จริง แต่เกิดความเหนื่อยแบบใหม่จากการต้องแชตกับเครื่องตลอดเวลา และไม่รู้ว่าคำสั่งภาษาธรรมชาติจะถูกตีความอย่างไร มันให้ความรู้สึกเหมือนควบคุมเครื่องที่สายไฟภายในเปลี่ยนอยู่เรื่อย ๆ ด้วยชุดปุ่มกด เลยไม่น่าพอใจ
สิ่งที่ AI ทำให้เป็นไปได้คือ contribution จากคนที่ไม่ได้มีส่วนเกี่ยวข้องกับโปรเจกต์เลย ตอนนี้แค่มีคนทำ PR มา ก็ไม่อาจถือได้อีกแล้วว่า “คนนี้สนใจความสำเร็จของโปรเจกต์อยู่บ้าง” ผ่านเกณฑ์ขั้นต่ำแล้ว
ถ้าใช้ให้ถูก AI คือเครื่องขยายพลัง แต่ในมุมของผู้ดูแลโอเพนซอร์ส ก็อาจถูกกลบได้ง่ายด้วย “contribution” มูลค่าต่ำจำนวนมากจากคนที่ไม่ได้สนใจโปรเจกต์
โดยเฉพาะเพราะ แนวโน้มชอบประจบ ของ AI ที่เอาแต่บอกว่า “เป็นไอเดียที่ดีครับ!” ทั้งที่ผมรู้ดีว่าไอเดียส่วนใหญ่ของผมไม่ได้ยอดเยี่ยมอะไร
เวลาเห็นเรื่องเล่าว่าอยู่กับลูก ๆ แต่ก็ vibe coding บนมือถือไปด้วย ฟังแล้วแทบเหมือนเป็นพฤติกรรมย้ำคิดย้ำทำ
แรกเริ่มเดิมที ในโอเพนซอร์ส ความเร็วก็ไม่ได้มีความหมายมากนัก และมันก็มีเหตุผลของมัน
โครงสร้างโดปามีน ที่ทำให้เอื้อมไปหา AI ง่ายเกินไปเวลาเริ่มทำงานหรือเริ่มโปรเจกต์ใหม่ก็เป็นปัญหา
ตอนนี้ผมพยายามฝึกสมองใหม่ให้กลับไปชอบเขียนโค้ดส่วนใหญ่ด้วยมือ มากกว่าจะเริ่มจากการมองหา Claude ก่อน เรื่องนี้จะเป็นแค่ระยะชั่วคราว หรือเราจะต้องมีอะไรอย่างกลุ่มนิรนามสำหรับผู้ติด LLM หรือไม่นั้น เวลาคงบอกเอง
มีรายการที่รวบรวม ซอฟต์แวร์ปลอด AI อยู่ ถ้าได้เห็นเป็นดัชนีหรือกราฟว่ามันเปลี่ยนไปอย่างไรเมื่อเวลาผ่านไปก็คงดี
https://codeberg.org/brib/slopfree-software-index
https://noai.starlightnet.work/list.html
https://hcker.news/?ai=exclude&include_domains=github.com
ถ้ามองในเชิงฟังก์ชัน ผมนึกเหตุผลของนโยบาย no-AI ไม่ค่อยออก ไม่ว่าใครหรืออะไรสร้าง ถ้ามันรันได้ก็คือรันได้
ต่อให้หลีกเลี่ยงขยะที่สร้างโดย AI ได้ ก็ยังหลีกเลี่ยงขยะที่สร้างโดยคน หรือคน+AI ที่ผ่านตัวกรองเข้ามาไม่ได้
แต่ก็พอนึก เหตุผลที่ไม่ใช่เชิงฟังก์ชัน ได้มากมาย เช่น แหล่งที่มา ความรับผิดชอบ หลักฐานของการลงแรง การส่งเสริมให้คนเขียนโค้ดเอง และการติดตามเชิงประจักษ์ว่ามนุษย์พัฒนา codebase กันอย่างไร
คำพูดของ Foundation ที่ว่า “หากฟีดแบ็กต่อ PR ไม่ได้ถูกใช้เพื่อเมนเทอร์คนที่อาจกลายเป็นผู้ดูแลในอนาคต แต่เพียงถูกเครื่องดูดซึมไป ก็ยิ่งยากขึ้นมากที่จะหาเหตุผลรองรับการใช้เวลาว่างไปกับการรีวิว PR” นั้นแทงใจประเด็นพอดี
ถ้าไม่เข้าใจ ลองดูสิ่งเหล่านี้
https://github.com/godotengine/godot/pull/115280
https://github.com/godotengine/godot/pull/116410
สำหรับโปรเจกต์ที่ก่อนยุค AI ก็ลำบากอยู่แล้วเพราะมี PR ให้รีวิวมากเกินไป การบอกให้ผู้ดูแลต้องคอยจัดการเรื่องแบบนี้ต่อไปด้วยนั้นไม่ยุติธรรม
ดังนั้นการเปลี่ยนแปลงใหญ่จริง ๆ ของนโยบายนี้คือส่วนที่ทำให้ ผู้มีส่วนร่วมรายใหม่ ไม่สามารถรับงานฟีเจอร์ใหญ่หรือรีแฟกเตอร์ครั้งใหญ่ได้
จากข้อมูลที่เหลืออยู่ใน repository ก็สามารถตามเจอนามแฝงและบัญชีโซเชียลได้ และเป็นเด็กที่ยังไม่ถึงวัยต้นวัยรุ่นด้วยซ้ำ ดูเหมือนว่ายังไม่มีความรู้พื้นฐานพอจะเข้าใจปัญหาหรือโครงสร้างทางสังคมที่เกี่ยวข้อง
นี่เป็นกรณีที่ กฎของ Brandolini ทำงานตรง ๆ
การหักล้างเรื่องไร้สาระต้องใช้ความพยายามมากกว่าการสร้างมันขึ้นมา 10 เท่า การรีวิวโค้ดก็คือการหักล้าง และการตรวจสอบความถูกต้องของข้อเสนอก็เช่นกัน
การสร้างข้อเสนอนั้นง่าย แต่การหักล้างต้องพิสูจน์ว่าจริงหรือเท็จ หรือหาความขัดแย้งให้เจอ พลังงานของผู้ดูแลโอเพนซอร์สที่มีเวลาจำกัดถูกสิ้นเปลืองโดยไม่จำเป็น จึงเห็นด้วยเต็มที่กับการประหยัดพลังงานไว้ใช้ให้เกิดประโยชน์
AI บังเอิญค้นพบหนึ่งในทรัพยากรที่แพงที่สุดของอุตสาหกรรม นั่นคือ เวลาว่าง ของคนที่ดูแลโอเพนซอร์สในตอนเย็นหลังเลิกงานประจำ
Foundation ชี้ให้เห็นสิ่งที่เป็นจริงมาโดยตลอด แต่ AI ทำให้เด่นชัดขึ้น นั่นคือผู้มีส่วนร่วมใด ๆ รวมถึง AI อาจไม่สามารถดูแลแพตช์นั้นต่อไปได้ในอนาคต
แก่นของเรื่องไม่ใช่การใช้ AI เอง แต่เป็นหนึ่งในกลิ่นบ่งชี้ว่าผู้ส่งไม่เข้าใจว่าสิ่งที่ตนส่งมาคืออะไร การทำลายธรรมเนียมการตั้งชื่อตัวแปร การเปลี่ยน API ที่ไม่ควรแตะ หรือการทำพลาดด้านภาษาที่ดูไม่ชำนาญ ล้วนเป็นเหตุผลให้ปฏิเสธได้ แม้แพตช์จะทำงานก็ตาม
วิธีเลี่ยงอย่างหนึ่งคือระบุว่าปฏิเสธ PR เพราะ AI แล้วให้ผู้เขียนชี้ส่วนหนึ่งที่ตนภูมิใจเป็นพิเศษ และอธิบายด้วยคำพูดของตัวเองว่าเขาทำอะไรและทำไมจึงดี ไม่ใช่ส่งกำแพงข้อความจาก AI ผู้เขียนต้องแสดงรสนิยมและความคิดเห็นที่ AI ไม่มี
ตรงนี้รู้สึกว่าหลายคนกำลังตอบสนองต่อหัวข้อ มากกว่าจะอ่านนโยบายจริง ๆ ในนโยบายระบุว่าเหตุผลสำคัญคือการใช้การรีวิว PR เพื่อ ฝึกผู้มีส่วนร่วมรายใหม่ และค้นหาผู้ที่อาจเป็นผู้ดูแลในอนาคต
ไม่ว่าคุณภาพของการมีส่วนร่วมจาก AI จะเป็นอย่างไร ประเด็นนี้ดูหักล้างได้ยาก
เว้นแต่จะเชื่อว่า AI จะทำให้แนวคิดเรื่องการมีส่วนร่วมกับโอเพนซอร์สหรือการดูแลรักษาทั้งหมดไม่จำเป็นอีกต่อไป แต่ถ้าเป็นอย่างนั้น การ fork เอนจินแล้วให้เอเจนต์ทำงานเองน่าจะเหมาะกว่าส่ง PR ไปที่ Godot
ผู้มีส่วนร่วมที่ใช้ AI คิดจริง ๆ หรือว่าตัวเองกำลังช่วยอยู่ พวกเขาไม่รู้หรือว่ากำลังทำลายโปรเจกต์ด้วย “งาน” แบบนั้น
ไม่เข้าใจว่าทำไมถึงจ่ายเงินให้กับสิ่งที่ไม่มีใครต้องการและจะถูกปฏิเสธ ไม่มีงานอดิเรกกันหรือไง หรือเป็น อินสแตนซ์ OpenClaw ที่คนสร้างลืมไว้จนปล่อยให้เดินเพ่นพ่านและทำตามใจตัวเอง
คนแบบนี้กำลังเก็บเกี่ยวการมีส่วนร่วมกับโปรเจกต์ FOSS หลัก ๆ เพื่อ ปั่นเรซูเม่ให้ดูดี เรื่องเดียวกันนี้ก็เกิดขึ้นกับการรายงานช่องโหว่ด้วย
ผู้ผลิตจำนวนมากอาจคิดจริงใจว่าตนกำลังช่วย หรืออาจรู้ว่าการ “มีส่วนร่วม” ของตนทำให้โปรเจกต์เสียมากกว่าได้ แต่เมื่อมีแรงจูงใจทางเศรษฐกิจโดยตรงและสถานะของตัวเองไม่มั่นคง ผลกระทบภายนอกก็ถูกลดลำดับความสำคัญลง
Claude ทำได้ใน 1 ชั่วโมง และผมปรับแก้ 3–4 รอบเพื่อลดกำแพงข้อความและให้เข้ากับสไตล์ของโปรเจกต์ต้นทาง ทางเลือกคือปล่อยทิ้งไว้ หรือแค่เปิด issue แล้วโยนภาระให้ผู้ดูแล
ดังนั้นผมคิดว่าผมได้ช่วยจริง ๆ เคสขอบเขตนี้ก็เจอตอน tinkering กับโฮมแล็บซึ่งเป็นงานอดิเรกของผม
PR ทั้งสองอันเล็ก และไม่ต่างจาก PR ของมนุษย์ ผมยังเชื่อว่าเป็นการเพิ่มที่มีคุณค่า และเห็นได้ชัดว่าผู้ดูแลบางคนก็มองอย่างนั้น
ไม่ใช่ว่าอยากเขียนโค้ดหรือทำให้ผลิตภัณฑ์ดีขึ้น แต่อยากได้ “จำนวนบรรทัดโค้ด”, “คอมมิต” และโปรไฟล์ GitHub สีเขียวสวย ๆ โดยไม่ต้องเข้าใจรายละเอียด