- ชุมชน Debian ได้หารือเรื่อง การอนุญาตหรือไม่อนุญาตให้มีการส่งโค้ดที่อิงกับ AI หรือ LLM แต่ยุติการหารือโดยไม่มีข้อสรุป
- ร่างข้อเสนอที่ถูกเสนอมีเนื้อหาให้อนุญาตภายใต้เงื่อนไข เช่น ต้องเปิดเผยอย่างชัดเจนเมื่อใช้เครื่องมือ AI, ระบุความรับผิดชอบให้ชัดเจน, และห้ามใช้ข้อมูลที่อ่อนไหว
- นักพัฒนาเห็นต่างกันในประเด็น ความกำกวมของคำว่า ‘AI’, ขอบเขตการใช้งาน LLM และ ปัญหาด้านคุณภาพ ลิขสิทธิ์ และจริยธรรม
- บางส่วนแสดงจุดยืนคัดค้านด้วยเหตุผล เช่น ขัดขวางการเริ่มต้นของผู้มีส่วนร่วมรายใหม่, พฤติกรรมที่ไร้จริยธรรมของบริษัท, และ ความไม่แน่นอนทางกฎหมาย
- Debian จะยังคง พิจารณาเป็นกรณีไปตามนโยบายเดิม ไปก่อนในระยะนี้ และเปิดทางให้มีการหารือต่อในอนาคต
ภาพรวมการหารือเรื่องการมีส่วนร่วมด้วย AI ของ Debian
- Debian ได้ดำเนินการถกเถียงภายในเกี่ยวกับ การรับโค้ดที่สร้างโดย AI หรือไม่ แต่จบลงโดยไม่มีการเสนอ มติทั่วไป (GR)
- การหารือเริ่มขึ้นเมื่อ Lucas Nussbaum เสนอร่างเพื่อทำให้จุดยืนเกี่ยวกับผลงานที่มี AI ช่วยสร้างมีความชัดเจนขึ้น
- เขาพิจารณาจะยื่นอย่างเป็นทางการหลังจากรวบรวมความเห็น แต่เมื่อการถกเถียงซาลง จึงไม่มีการเสนอญัตติ
- ร่างดังกล่าวรวมถึง ข้อบังคับให้เปิดเผยโค้ดที่สร้างด้วยเครื่องมือ AI, การระบุความรับผิดชอบของผู้ส่งผลงาน, การรับประกันการปฏิบัติตามข้อกำหนดด้านความปลอดภัยและไลเซนส์, และ การห้ามใช้ข้อมูลที่ไม่เปิดเผยต่อสาธารณะ
ข้อถกเถียงเรื่องนิยามคำและการแยกประเภทเทคโนโลยี
- นักพัฒนาหลายคนชี้ให้เห็นถึง ความไม่ชัดเจนของคำว่า ‘AI’ และเน้นถึง ความจำเป็นในการระบุเทคโนโลยีเฉพาะ เช่น LLM
- Russ Allbery ชี้ว่าคำว่า “AI” กว้างเกินไปและไม่เหมาะกับการกำหนดนโยบาย
- Sean Whitton เสนอให้ แยกแยะตามวัตถุประสงค์ของการใช้ LLM (รีวิวโค้ด, ทำต้นแบบ, โค้ดสำหรับใช้งานจริง)
- Andrea Pappacoda กล่าวถึงโปรเจกต์อย่าง Claude’s C Compiler ว่าไม่ควรถูกรวมเข้า Debian
- อย่างไรก็ตาม Nussbaum โต้ว่า ประเด็นสำคัญไม่ใช่ชนิดของเครื่องมือ แต่เป็นการกระทำของการสร้างโค้ดแบบอัตโนมัติเอง
ประเด็นการเริ่มต้นของผู้มีส่วนร่วมรายใหม่และเรื่องต้นทุน
- Simon Richter กังวลว่า AI อาจเข้ามาแทนที่โอกาสในการเรียนรู้ของนักพัฒนามือใหม่
- เขาชี้ว่าแม้ AI จะได้รับการชี้แนะ แต่มันไม่ได้เรียนรู้ และทรัพยากรของโครงการก็ไม่ได้นำไปสู่การถ่ายทอดความรู้ระยะยาว
- ยังมีข้อกังวลว่าการใช้ AI อาจทำให้ ต้องพึ่งพาเครื่องมือแบบเสียเงิน จนลดการเข้าถึงของผู้มีส่วนร่วม
- Nussbaum ยอมรับว่าปัจจุบันยังเข้าถึงได้ฟรี แต่ก็ยอมรับว่า อาจเกิดปัญหาเรื่องค่าใช้จ่ายในอนาคต
- เขาโต้กลับว่า AI อาจช่วย เพิ่มการเข้าถึงงานที่ซับซ้อน ได้ด้วยซ้ำ
- Ted Ts’o คัดค้านว่า การกีดกันผู้ใช้ AI เป็นสิ่งย้อนแย้งในตัวเอง และอาจจำกัดความหลากหลายของผู้มีส่วนร่วม
การหารือด้านจริยธรรม ลิขสิทธิ์ และคุณภาพ
- Matthew Vernon เห็นว่า Debian ควรแสดงจุดยืนคัดค้านอย่างชัดเจน โดยอ้างถึง การเก็บข้อมูลอย่างไร้จริยธรรมของบริษัท AI และผลกระทบต่อสิ่งแวดล้อม
- เขาชี้ถึงผลข้างเคียง เช่น การละเมิดลิขสิทธิ์, การสร้างภาพโดยไม่ได้รับความยินยอม, และรายงานความปลอดภัยปลอม
- Jonathan Dowland เสนอให้ จำกัดการรับผลงานที่สร้างด้วย AI จนกว่าความไม่แน่นอนทางกฎหมายจะคลี่คลาย
- Thorsten Glaser เสนอว่า ควรย้ายโปรเจกต์ที่มีโค้ดจาก LLM ไปไว้ในพื้นที่ ‘non-free’ แต่ไม่ได้รับการสนับสนุน เพราะเสี่ยงต่อการ ตัด Linux kernel, Python และโปรเจกต์หลักอื่น ๆ ออกไป
- Allbery ชี้ว่า ข้อถกเถียงเรื่องคุณภาพของโค้ดจาก AI นั้นไร้ความหมาย เพราะมนุษย์เองก็เขียนโค้ดที่แย่ได้เช่นกัน
- Bdale Garbee เน้นว่า ควรมอง AI เป็นช่วงหนึ่งของวิวัฒนาการและติดตามผลกระทบระยะยาว
การหารือเรื่อง ‘รูปแบบที่ควรเลือกใช้ในการแก้ไข (Preferred form of modification)’
- Nussbaum ตอบว่า อินพุต (prompt) ของ LLM คือรูปแบบที่ควรเลือกใช้ในการแก้ไข แต่ก็เกิดข้อถกเถียงต่อจาก ปัญหาความไม่เป็นเชิงกำหนด
- บางคนมองว่า LLM ไม่เป็นเชิงกำหนด จึงไม่เหมาะกับ reproducible build
- อีกฝ่ายโต้ว่า หากคงค่า PRNG seed และสภาพแวดล้อมเดิมไว้ ก็สามารถทำซ้ำได้
- การหารือขยายไปสู่รายละเอียดทางเทคนิค เช่น determinism, reproducibility และความไม่ประสานกันของการคำนวณบน GPU
บทสรุป: Debian ยังไม่ตัดสินใจ
- ภายใน Debian ยังอยู่ในภาวะที่ แม้แต่นิยามของผลงานที่มีส่วนร่วมซึ่งสร้างด้วย AI ก็ยังไม่สามารถตกลงกันได้
- หลายฝ่ายเห็นว่า ตอนนี้ยังไม่ใช่เวลาสำหรับการลงมติ และ ควรเดินหน้าหารือกันต่อในระดับเมลลิงลิสต์
- Nussbaum กล่าวว่าทางออกที่เป็นจริงน่าจะเป็น “การอนุญาต AI แต่มีมาตรการป้องกัน”
- ณ ตอนนี้ การพิจารณาเป็นรายกรณีตามนโยบายเดิม จะยังคงดำเนินต่อไป และ เกณฑ์การจัดการ AI model, โค้ดจาก LLM และผลงานที่สร้างด้วย AI ยังไม่ได้ข้อยุติ
- ท่ามกลางการเปลี่ยนแปลงทางเทคนิคที่ซับซ้อนและความเห็นที่หลากหลาย การคงสภาพเดิมไว้ถูกมองว่าเป็นทางเลือกที่ใช้งานได้จริงที่สุด
1 ความคิดเห็น
ความเห็นจาก Hacker News
เขียนโค้ดมาตลอดชีวิต แต่หลังจากบาดเจ็บที่ข้อมือจน แทบพิมพ์ไม่ได้ ก็กลับมาสร้างโค้ดคุณภาพสูงได้อีกครั้งด้วย LLM, AI autocomplete และการพัฒนาแบบเอเจนต์
แม้แต่ hallucination ของ AI ก็ยังช่วยให้ปรับแต่งพรอมป์ต์และทำให้เจตนาชัดเจนขึ้นได้
ในแง่การเข้าถึง AI เป็นเครื่องมือที่จำเป็นสำหรับฉัน และฉันคิดว่าสิ่งสำคัญไม่ใช่ “ข้อดีชดเชยข้อเสียได้ไหม” แต่คือ ท่าทีในการยอมรับมันเข้าเป็นส่วนหนึ่งของระบบนิเวศโดยรวม
บางโปรเจกต์เต็มไปด้วย PR คุณภาพต่ำ และผู้มีส่วนร่วมจำนวนมากก็แค่อยากเติม GitHub profile ของตัวเอง
สุดท้ายสิ่งสำคัญคือเขามีส่วนร่วมด้วย “เจตนาดี (good faith)” หรือไม่ และโปรเจกต์ก็ควรกำหนดขอบเขตที่ยอมรับได้ให้ชัดเจน
แบบนี้ช่วยลดความเหนื่อยล้าจากการรีวิว และโฟกัสตรวจเฉพาะส่วนที่ต่างจากที่คาดได้
ตอนนี้ถึงขั้นไม่อยากทำงานกับบริษัทที่ปิดกั้นความสามารถแบบนี้แล้ว
มิติด้านการเข้าถึงสำคัญมาก แต่ ปัญหาเรื่องลิขสิทธิ์และความรับผิดชอบ ก็ยังซับซ้อนอยู่
ฉันคิดว่าการรีวิว PR (pull request) สุดท้ายแล้วคือ เรื่องของความไว้วางใจ คือเชื่อว่าผู้ส่งทำดีที่สุดแล้ว
แก่นสำคัญไม่ใช่ว่าใช้ AI หรือไม่ แต่คือ ใช้มันอย่างมีความรับผิดชอบหรือเปล่า
หลายบัญชีปลอมอาจเป็นผู้โจมตีคนเดียวกันก็ได้ และโค้ดที่ LLM สร้างก็ดูใช้ได้ในสายตา LLM ทำให้ตรวจสอบยากขึ้นอีก
สุดท้ายจึงกลายเป็นสถานการณ์ที่ ประเมิน PR ยากกว่าสร้างมันขึ้นมา
การถกเถียงเรื่องคุณภาพของผลงานจาก AI ดูแปลกดี เพราะคุณภาพเป็น ความรับผิดชอบของผู้ส่ง มาโดยตลอด
การใช้ AI ไม่ได้ทำให้พ้นความรับผิด และยิ่งไปกว่านั้น นโยบายจำกัดการใช้ AI อาจไปทำร้ายผู้มีส่วนร่วมที่มีเจตนาดีเท่านั้น
ฉันดูแล fork ที่มี 300 commits ด้วย AI แต่ฉันตรวจทุกบรรทัดและอธิบายได้ทั้งหมด
สุดท้ายแล้วหัวใจคือ คุณภาพของการมีส่วนร่วม ไม่ใช่ประเภทของเครื่องมือ
ในระยะยาว ถ้า AI พัฒนาต่อไป ก็น่าจะ แยกผลงานของมนุษย์กับ AI ได้ยากขึ้น
สุดท้ายเมื่อมันไปถึงระดับ “ดีพอ” ก็คงดูเหมือนมนุษย์ทำจริง ๆ แล้วตอนนั้นจะเกิดอะไรขึ้นก็น่าสนใจ
ตอนนี้ PR จาก AI ส่วนใหญ่ยังคุณภาพต่ำ แต่ต่อให้คุณภาพสูงขึ้น ก็ยังอาจปฏิเสธได้ด้วย เหตุผลทางกฎหมายหรืออุดมการณ์
มักเจอการนามธรรมที่ย่อยเกินไปหรือการรีแฟกเตอร์ที่ไม่จำเป็น
การที่มนุษย์ใช้ AI เป็นเครื่องมือนั้นไม่เป็นไร แต่ฉันมองว่า ระดับที่ AI จะมาแทนมนุษย์ได้ ยังอีกไกล
เพียงแต่การ ใช้ vibecoding แบบพร่ำเพรื่อ กำลังเพิ่มต้นทุนการรีวิวและการบำรุงรักษาอย่างรวดเร็ว
ฉันอยู่ฝ่าย “ถ้ามันทำงานได้ก็พอ”
ถ้าโค้ดผ่านเกณฑ์ด้าน ฟังก์ชัน เอกสาร การทดสอบ และความถูกต้อง ไม่ว่าจะ AI เขียนหรือมนุษย์เขียนก็ไม่สำคัญ
สิ่งสำคัญคือกำหนดให้ชัดว่า “ทำงานได้” หมายถึงอะไร และมี ระบบรีวิวที่มีความสามารถ
AI อาจสร้างโค้ดหลายพันบรรทัดในครั้งเดียวแล้วเปิด PR ได้ แต่สุดท้ายก็ต้อง จำกัดขนาดให้อยู่ในระดับที่รีวิวได้
ต่อให้ AI ผ่านการทดสอบ หากผู้เขียนไม่เข้าใจเนื้อหาก็ยังอันตราย
จำเป็นต้องมี การจำกัดขอบเขตงาน และ ประวัติการมีส่วนร่วมแบบทำมือก่อนหน้า
นโยบายของ Debian เรียบง่าย — คือ “อย่าทำให้ใครบาดเจ็บ” เป็นหลักการที่ดี
มีคนถามว่า Debian มีกฎห้ามส่งโค้ดของคนอื่นราวกับเป็นของตัวเองหรือไม่
ในทางปฏิบัติมัน ผิดกฎหมายเพราะละเมิดลิขสิทธิ์ อยู่แล้ว จึงมีอยู่โดยนัยแม้ไม่เขียนไว้ชัด
LLM ไม่ใช่มนุษย์ แต่ลิขสิทธิ์ของโค้ดที่มันสร้างขึ้นก็ยังไม่ชัดเจนอยู่ดี
ถ้าเป็น vibecoding สำหรับเว็บแอปหรือแอปมือถือก็อาจไม่เป็นไร แต่การใช้ AI กับ ซอฟต์แวร์โครงสร้างพื้นฐานสำคัญ อย่างเคอร์เนล คอมไพเลอร์ หรือระบบปฏิบัติการนั้นเสี่ยง
ในพื้นที่แบบนี้จำเป็นต้องมี ภาษาเพื่อการตรวจพิสูจน์เชิงรูปแบบอย่าง Ada/SPARK
รู้สึกน่ากลัวเมื่อนึกว่าสักวันอาจต้องนั่งรถที่ใช้ ระบบเบรกที่ AI สร้าง
เมื่อเทียบกับ “การส่งโค้ดแบบ YOLO” แล้ว การบอกว่าใช้ AI แต่เป็น โค้ดที่ตรวจสอบอย่างดีที่สุดแล้ว ย่อมน่าจะยอมรับได้มากกว่า