เหตุผลเบื้องหลังนโยบาย anti-AI สำหรับการมีส่วนร่วมในโปรเจกต์ Zig
(simonwillison.net)- หนึ่งในโปรเจกต์ภาษาโอเพนซอร์สหลักกำลังใช้นโยบายเข้มงวดที่ห้าม การใช้ LLM ใน issue, Pull Request, ความคิดเห็นใน bug tracker และงานแปล
- การใช้ภาษาอังกฤษเป็นเพียงคำแนะนำ ไม่ใช่ข้อบังคับ และผู้มีส่วนร่วมสามารถ เขียนด้วยภาษาแม่ ได้ ขณะที่ผู้อื่นสามารถใช้เครื่องมือแปลที่ตนเลือกเพื่อตีความเนื้อหา
- Bun ได้เพิ่ม parallel semantic analysis และ multiple codegen units เข้าไปใน Zig fork ของตนเองบน LLVM backend จนทำให้การคอมไพล์ Bun เร็วขึ้น 4 เท่า แต่ขณะนี้ยังไม่มีแผนส่งกลับ upstream เพราะมีกฎห้ามการมีส่วนร่วมที่เขียนด้วย LLM
- วิธีรีวิวของ Zig ให้ความสำคัญกับการช่วยผู้มีส่วนร่วมหน้าใหม่ไปให้ถึงงานที่สามารถ merge ได้ มากกว่าการปฏิเสธ PR ที่ยังไม่สมบูรณ์ และให้ความสำคัญกับ การเติบโตของผู้มีส่วนร่วม มากกว่าชิ้นงานรายชิ้น
- PR ที่ LLM เขียนเป็นส่วนใหญ่ทำให้เวลารีวิวไม่ได้ถูกใช้ไปกับการเพิ่มจำนวนผู้มีส่วนร่วมหน้าใหม่ที่ไว้ใจได้ และยังทำให้ maintainer มีทางเลือกที่จะรัน LLM เองเพื่อแก้ปัญหาเดียวกันโดยตรง
ความขัดแย้งระหว่างนโยบายกับ Bun fork
- Zig ระบุชัดใน Code of Conduct ว่าห้าม การใช้ LLM ใน issue, Pull Request, ความคิดเห็นใน bug tracker และงานแปล
- การใช้ภาษาอังกฤษเป็นเพียงคำแนะนำ และผู้มีส่วนร่วมสามารถเขียนด้วยภาษาแม่ได้
- ผู้อื่นสามารถใช้เครื่องมือแปลที่ตนเลือกเพื่อตีความเนื้อหาได้
- โปรเจกต์เด่นที่เขียนด้วย Zig ได้แก่ JavaScript runtime อย่าง Bun และ Bun ถูก Anthropic เข้าซื้อกิจการในเดือนธันวาคม 2025
- Bun ดูแล Zig fork ของตนเอง และได้เพิ่ม “parallel semantic analysis and multiple codegen units” ลงใน LLVM backend จนทำให้การคอมไพล์ Bun เร็วขึ้น 4 เท่า
- โค้ดที่เกี่ยวข้องเปิดเผยไว้ที่ ลิงก์เปรียบเทียบ oven-sh/zig
- Bun ยังไม่มีแผนส่งขึ้น upstream ในตอนนี้ เพราะ Zig ห้าม การมีส่วนร่วมที่เขียนด้วย LLM อย่างเข้มงวด
- ตามความเห็นของ Zig core contributor แพตช์ดังกล่าวก็รับเข้าได้ยากอยู่แล้วแม้ไม่เกี่ยวกับประเด็น LLM
- parallel semantic analysis เป็นฟีเจอร์ที่วางแผนมานาน แต่ส่งผลต่อ ตัวภาษา Zig เอง
Contributor Poker และการรีวิวที่ยึดผู้มีส่วนร่วมเป็นศูนย์กลาง
- Contributor Poker and Zig's AI Ban ใช้คำเปรียบเปรย contributor poker ซึ่งเป็นกุญแจสำคัญในการทำความเข้าใจนโยบายห้ามอย่างเข้มงวดของ Zig
- โปรเจกต์โอเพนซอร์สที่ประสบความสำเร็จจะไปถึงจุดที่ได้รับ PR มากเกินกว่าปริมาณที่จัดการได้
- เพื่อเพิ่ม ROI ให้สูงสุด Zig เลือกช่วยผู้มีส่วนร่วมหน้าใหม่ให้ทำงานไปถึงจุดที่ merge ได้ แทนที่จะปฏิเสธ PR ที่ยังไม่สมบูรณ์
- วิธีนี้ไม่ใช่แค่ “สิ่งที่ถูกต้อง” แต่ยังเป็น “สิ่งที่ฉลาด” ด้วย
- Zig ให้ความสำคัญกับ ผู้มีส่วนร่วม มากกว่าผลงานรายชิ้น
- เป้าหมายลำดับแรกของการรีวิวและรับ PR ไม่ใช่การเพิ่มโค้ดใหม่ แต่คือการช่วยคนที่เมื่อเวลาผ่านไปจะเติบโตเป็นผู้มีส่วนร่วมที่เชื่อถือได้และมีประสิทธิภาพ
- ผู้มีส่วนร่วมแต่ละคนจึงเป็นเสมือนเป้าหมายการลงทุนของ Zig core team
- การสนับสนุนด้วย LLM ทำให้โครงสร้างนี้พังลง
- ต่อให้ LLM ช่วยเขียน PR ที่สมบูรณ์แบบ เวลารีวิวที่ทีม Zig ใช้ก็ไม่ได้ช่วยเพิ่มจำนวนผู้มีส่วนร่วมหน้าใหม่ที่มีความมั่นใจและเชื่อถือได้
- “contributor poker” เป็นสำนวนเปรียบเทียบว่ากำลังเล่นเกมโดยดูที่คน ไม่ใช่ที่ไพ่
- ความหมายจึงใกล้กับการ เดิมพันกับตัวผู้มีส่วนร่วม มากกว่าดูจากเนื้อหาของ PR แรก
- หาก PR นั้นถูกเขียนโดย LLM เป็นส่วนใหญ่ maintainer ของโปรเจกต์ก็อาจเลือกที่จะรัน LLM เองเพื่อแก้ปัญหาเดียวกัน แทนการรีวิวและถกเถียงกับ PR นั้น
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
ตาม https://kristoff.it/blog/contributor-poker-and-ai/ ระบุว่าการมีส่วนร่วมที่อิง LLM โดยรวมให้ผลในทางลบ
PR แบบ drive-by ที่ไร้คุณค่าได้เพิ่มสัญญาณรบกวนด้วย โค้ดหลอน ซึ่งคอมไพล์ไม่ผ่านหรือไม่ผ่าน CI และยังมีกรณีที่ผู้มีส่วนร่วมครั้งแรกส่ง PR 10,000 บรรทัด มาด้วย
ยังมี PR ที่ดูเผินๆ เหมือนใช้ได้และระบุชัดว่าไม่ได้ใช้ LLM แต่ในการพูดคุยต่อมาก็เห็นได้ทันทีว่าผู้เขียนแอบอ้างอิง LLM และคอยตอบซ้ำๆ แบบมีข้อผิดพลาดจำนวนมาก
hooks ไม่มีวิธีที่สะอาดในการบังคับให้ติดตั้งตอน clone แต่ GHA Workflows หรือความสามารถเทียบเท่าบน forge อื่นๆ น่าจะมี
ถ้าเป็นโปรเจกต์ที่มีทั้งขนาดและความนิยมระดับหนึ่ง ผมมองว่านี่ควรเป็นข้อกำหนดพื้นฐาน
ปัญหาจำนวนมากของเรื่อง “AI มีส่วนร่วมไม่ได้” น่าจะลดลงได้พอสมควรด้วยการตรวจอัตโนมัติและมาตรการคัดกรองที่ดีกว่านี้
นอกจากประเด็นที่ AI ทำให้สแปมรูปแบบใหม่นี้เกิดขึ้นได้ แก่นแท้ของเรื่องก็ไม่ใช่ AI
ต่อให้ไม่มี AI ถ้าคนไปจ้างกองทัพนักพัฒนาราคาถูกจากต่างประเทศมาผลิต PR แบบ drive-by คุณภาพกลางๆ จำนวนมาก ผลก็จะเหมือนกัน
จะใช้ AI ทำโค้ดดีๆ ก็ได้ แต่เหมือนเครื่องมืออื่นๆ คือต้องใช้อย่างรอบคอบ
นี่ไม่ใช่การมีส่วนร่วมที่คนซึ่งเข้าใจโปรเจกต์และเป้าหมายใช้เครื่องมืออย่างดีและทำอย่างระมัดระวัง แต่มันคือสแปม
เสียงรบกวนรอบนโยบาย AI ดูเหมือนจะเกิดขึ้นเพราะนักพัฒนา Bun บอกว่านโยบายดังกล่าวทำให้พวกเขา upstream PR ด้านประสิทธิภาพไม่ได้
แต่เหตุผลจริงดูจะเป็นเพราะตัวโค้ดใน PR นั้นเองมีสภาพไม่ดีและนำความซับซ้อนที่ไม่ดีต่อสุขภาพเข้ามา https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
ตามคำอธิบายที่ถูกอ้างถึง parallel semantic analysis เป็นแผนที่ชัดเจนของคอมไพเลอร์ Zig มาตั้งนานแล้ว และยังมีอิทธิพลอย่างมากต่อการออกแบบ self-hosted Zig compiler แต่ถ้าจะทำให้ถูกต้องไม่ใช่แค่ตัวคอมไพเลอร์เท่านั้นที่ต้องเปลี่ยน แม้แต่ ภาษา Zig เอง ก็ต้องเปลี่ยนด้วย
เพราะมันขัดกับโรดแมปของ Zig เองที่มุ่งไปสู่ผลลัพธ์ที่ดีกว่า และยังขัดขวางทิศทางการปรับปรุงภาษาทั้งระบบอย่างต่อเนื่อง
เมื่อนโยบายห้าม โค้ดจาก LLM ทั้งหมดอย่างชัดเจน แบบนั้นนโยบายก็ย่อมเป็น “เหตุผลที่แท้จริง” อยู่แล้ว
ฝั่ง Zig ดูเหมือนกำลังเดินตามแนวทางของ ZeroMQ https://zguide.zeromq.org/docs/chapter6
เป็นแนวทางแบบ “บังคับให้เกิดความเป็นเจ้าของร่วมของโปรเจกต์ เพื่อเพิ่มแรงจูงใจทางเศรษฐกิจของผู้มีส่วนร่วม และลดความเสี่ยงที่โปรเจกต์จะถูก hijack โดยผู้ไม่หวังดี”
ชุมชนผู้มีส่วนร่วม ที่แข็งแรงสำคัญกว่าประสิทธิภาพของโค้ด จำนวนฟีเจอร์ หรือจำนวนบรรทัดของโค้ดเสียอีก
ทุกวันนี้ “ชุมชน” zeromq ค่อนข้างเบาบาง แม้ยังมีคนเก่งๆ บางคนที่ยังทำงานอยู่ แต่กระบวนการและช่องทางสื่อสารในระดับมนุษย์กลับไม่ได้ถูกนิยามไว้อย่างดีและก็ไม่ได้ถูกดูแลอย่างเพียงพอ
libzmq กับ binding ส่วนใหญ่ค่อนข้างเสถียร ดังนั้นการขาดกิจกรรมและปฏิสัมพันธ์ของมนุษย์แบบนี้อาจพอยอมรับได้หรืออาจพอมีเหตุผลรองรับ แต่ก็ให้ความรู้สึกว่าวิสัยทัศน์อันยอดเยี่ยมของ Hintjens พา zeromq มาถึงจุดนี้ และหลังจากเสียเขาไป โปรเจกต์ก็เหมือนลอยไปเรื่อยๆ
น่าแดกดันอยู่บ้างสำหรับวิสัยทัศน์ที่เน้นชุมชน เพราะดูเหมือนว่าการสร้างและรักษาชุมชนต้องอาศัย ผู้นำที่มีเสน่ห์และกระตือรือร้น ซึ่งพูดถึงธรรมชาติมนุษย์มากกว่าการพัฒนาซอฟต์แวร์เสียอีก
ถ้าจะโยงกลับมาที่เรื่อง Zig ก็คือ Zig ไม่ได้ขาด PR ดังนั้นจึงมีข้อสมมติฐานว่าพวกเขาสามารถคัดกรองการมีส่วนร่วมแบบ no-LLM ได้ล่วงหน้า
นั่นเป็นทางเลือกที่ดีสำหรับพวกเขา และแนวคิด “contributor poker” ก็พอเข้าใจได้
แต่ถ้าการไหลเข้าของคนใหม่ลดลง เกมก็จะเปลี่ยน และถ้าถึงตอนนั้นคนของ Zig ยังต้องการผู้มีส่วนร่วมหน้าใหม่ พวกเขาอาจต้องขยายตาข่ายให้กว้างขึ้น
เพียงแต่ว่าถ้าถึงจุดนั้น การเปิดรับการมีส่วนร่วมแบบมี LLM ช่วยก็อาจสายเกินไปที่จะฟื้นกลับมาแล้ว
สิ่งที่ผมสงสัยเกี่ยวกับการมีส่วนร่วมใน OSS ที่สร้างด้วย AI คือเรื่องนี้
ถ้า AI เพิ่มผลิตภาพของนักพัฒนาได้มากขนาดนั้น ทำไม maintainer ของ OSS ถึงจะอยากมีผู้มีส่วนร่วมที่ไม่รู้จักมาคั่นกลางระหว่างตัวเองกับ LLM ด้วยล่ะ?
maintainer ถาม Claude Code โดยตรงเองก็ได้
ยืมคำพูดเพื่อนร่วมงานมาคือ “เราไม่ต้องการ คนกลาง มาคุยกับโมเดล AI และการเขียนโค้ดก็ไม่ใช่คอขวดด้วย”
ใช้ AI ทำเวอร์ชันแรกที่แย่ๆ ออกมาก่อน จากนั้นค่อยปรับพรอมป์ต์ แก้ด้วยมือ สั่งให้มันแก้ส่วนอื่น ค้นพบฟีเจอร์ที่เกี่ยวข้องแล้วเพิ่มเข้าไป รัน benchmark แล้วตัดฟีเจอร์เล็กๆ บางอย่างออก หรือเลือกหนึ่งในสอง implementation ที่คล้ายกัน
แล้วก็แก้ด้วยมือตรงนั้นตรงนี้เพิ่ม รันชุดทดสอบอัตโนมัติที่ขยายเพิ่มเพื่อหา bug แปลกๆ ในการตั้งค่าพิสดาร แล้วใช้ทั้ง AI และการแก้มือช่วยกันแก้
พอผ่านไป 20 ชั่วโมง เวอร์ชันสุดท้ายอาจเหลือแค่ 50 บรรทัด และแต่ละบรรทัดอาจถูกเขียนใหม่ถึง 5 ครั้ง
maintainer จึงใช้เวลารีวิวแค่ประมาณ 1 ชั่วโมงกับเวอร์ชันสุดท้ายก็พอ
มันต่างกันโดยสิ้นเชิงกับการปล่อยให้ AI เขียนแพตช์ 5 นาทีแล้วส่งโค้ด 1,000 บรรทัดที่คอมไพล์ไม่ผ่านมาให้ maintainer โดยไม่แม้แต่จะอ่าน
“มันง่ายมากจนฉันก็ทำได้”
ใช่ แต่คุณไม่ได้ทำจริงๆ
แต่ไม่ใช่เครื่องมือประเภทที่คุณจะโยนคำสั่งระดับสูงแบบที่สั่งคนแล้วมันจะทำได้
คนที่อ้างว่า AI ทำงานได้ด้วยคำสั่งระดับสูงอย่างเดียว ส่วนใหญ่ผมสงสัยว่ากำลังทำโปรเจกต์แบบ “ไม่ต้องคิดมาก” ที่นักพัฒนาไม่จำเป็นต้องลงลึกในรายละเอียดมากนักหรือเปล่า
และหวังว่าไม่ได้หมายความว่าข้อดีอย่างเดียวของ LLM คือช่วยสร้างโค้ดที่ขี้เกียจพิมพ์เองโดยตรง
คำอธิบายที่ว่า “Zig ให้ความสำคัญกับ ผู้มีส่วนร่วม มากกว่าการมีส่วนร่วม เป้าหมายหลักของการรีวิวและรับ PR ไม่ใช่เพื่อเอาโค้ดใหม่เข้าโปรเจกต์ แต่เพื่อช่วยให้คนคนนั้นเติบโตเป็นผู้มีส่วนร่วมที่เชื่อถือได้และมีผลิตภาพในระยะยาว การมี LLM ช่วยทำลายสิ่งนี้ไปอย่างสิ้นเชิง ต่อให้ LLM ช่วยให้ส่ง PR ที่สมบูรณ์แบบได้ก็เหมือนกัน” เป็นเหตุผลที่ดีที่สุดเท่าที่ผมเคยเห็นมา
ผมสนับสนุนการตัดสินใจของ Zig อย่างเต็มที่ และชื่นชมวิสัยทัศน์ระยะยาวที่มีต่อทั้งชุมชนและตัวโปรเจกต์จริงๆ
พูดตามตรงผมไม่คิดว่า LLM จะเหมาะกับงานที่ต้องร่วมมือกันมากนัก
ต่อไปจะเปลี่ยนไปอย่างไรคงต้องรอดู แต่เวลารับ PR ที่สร้างด้วย AI สุดท้ายมักจบลงที่ผมต้องทำมันใหม่เองอยู่ดี และที่น่าขันคือผมกลับใช้ LLM ช่วยทำใหม่ เลยยิ่งรู้สึกขัดแย้งขึ้นเรื่อยๆ
ถึงอย่างนั้นก็ยังคิดว่านโยบายของ Zig เป็นความคิดที่ดี อย่างน้อยในช่วง 5 ปีข้างหน้า
ผมคิดว่านี่เป็นถ้อยคำที่ไม่เป็นปฏิปักษ์ที่สุดเท่าที่พวกเขาจะพูดได้แล้ว และก็เคารพว่าเป็นการตัดสินใจเกี่ยวกับโปรเจกต์ของพวกเขาเอง
แต่ก็ยังรู้สึกว่ามันมัดโปรเจกต์ไว้โดยไม่จำเป็น
LLM เป็นเครื่องมือ และมันช่วยในการคิด ค้นคว้า และเขียนโค้ดได้
อาจใช้มากเกินไปได้ แต่ก็ควรยอมรับมันในจุดที่มันช่วยได้
การไม่รับ PR ของ Bun ด้วยเหตุผลอื่นนั้นโอเคมาก แต่การแบน PR ที่เขียนด้วย LLM ทั้งหมดไปเลยเป็นข้อจำกัดที่เกินจำเป็น
แค่โฟกัสที่คุณภาพของงานก็พอ
ถ้า maintainer ใช้ LLM เองทำงานเดียวกัน ก็น่าจะทำได้ด้วยการออกแบบที่ดีกว่าและแนวทางที่รอบคอบกว่า
maintainer ไม่ได้มีเวลาไว้แค่รีวิว PR แบบใช้แรงน้อย แต่ต้องเอาเวลาไปพัฒนาด้วย
กระแสโค้ดจาก LLM กำลังทำให้สมดุลเอียงไปในทางเสียเปรียบสำหรับ maintainer และผมก็เข้าใจมากพอว่าทำไมพวกเขาถึงอยากแบนมันไปเลย
ภาพรวมจากการลองใช้ LLM กับ coding agent อยู่พักหนึ่งของผมคือ มันเป็น เครื่องมือไฟฟ้า หรือเครน ไม่ใช่เครื่องมือในการตัดสินใจ
คนที่มีความเข้าใจแนวคิดและความเข้าใจเชิงวิศวกรรมอย่างลึกซึ้งอยู่แล้วในองค์กร จะมีผลิตภาพพุ่งขึ้นแบบมหาศาล
ในทางกลับกัน คนที่ความเข้าใจน้อยกว่า หรือเป็นมือใหม่ junior กำลังสร้างโค้ดนรกเพียงเพราะมันรันได้แล้วก็คิดว่าจบ
LLM สร้าง ช่องว่างทางสติปัญญา ภายในองค์กร และยิ่งใช้มาก ช่องว่างนั้นก็ยิ่งกว้างขึ้น
สุดท้ายเราอาจไปถึงจุดที่ไม่สามารถเชื่อถือผลลัพธ์ที่ผลิตภายในองค์กรได้อีก เพราะโค้ดที่ถูกสร้างขึ้นมาภายหลัง
AI โดยรวมทำหน้าที่ขยายสกิลเซ็ต ทั้งด้านดีและด้านเสีย
กรณีใช้งานที่ยอดเยี่ยมล่าสุดคือการเขียน concept ของ authentication daemon
ผมคุยกับ Codex เพื่อเลือกข้อเสนอ จากนั้นตรวจทานไขว้ด้วยการค้นเว็บทั่วไป กำหนดร่างสุดท้าย แล้วนำไปคุยกับเพื่อนร่วมงาน
การวางแผนแบบสนทนา ที่มีการค้นเว็บรวมอยู่ด้วยแบบนี้มีประโยชน์มาก และการใช้ AI รีวิวโค้ดที่เขียนไว้แล้วก็ถือว่ามีแต่ข้อดีล้วนๆ ในมุมมองผม
เพียงแต่ caveat หลักของ AI คือท้ายที่สุดคุณต้องฉลาดกว่าเครื่องมือ
ถ้า Codex แนะนำให้ใช้ tech stack X คุณต้องไปค้นว่าทำไมมันถึงดีจริง ต้องเข้าใจมันอย่างถ่องแท้ และเปรียบเทียบกับทางแก้อื่นๆ
หลายคนข้ามขั้นตอนนี้ไป จึงเกิดปัญหามากมาย และมันร้ายแรงมาก
หลังจบบทสนทนา คุณควรจะฉลาดกว่า AI และต้องสามารถเข้าใจและวิจารณ์สิ่งที่ AI พูดได้ทั้งหมด
เมื่อกำหนดสถาปัตยกรรมแล้ว LLM ก็ทำงานด้าน implementation ได้ค่อนข้างดี
โดยทั่วไปสามารถทำให้มันสร้างโค้ดที่ยอดเยี่ยมและทดสอบมาดีได้ และบางทีก็ดีกว่าทำคนเดียวในเวลาเท่ากันมาก
แต่การพยายามตามความรู้ให้ทันทุกอย่างที่ AI สร้างขึ้นก็ยังเป็นความท้าทาย
ตรรกะที่ว่า “ถ้า PR ส่วนใหญ่เขียนโดย LLM ทำไม maintainer ไม่เอาเวลาที่ใช้รีวิวและคุยเรื่อง PR ไปเปิด LLM ของตัวเองแล้วแก้ปัญหาเดียวกันซะเลยล่ะ?” นั้นใช้กับ โอเพนซอร์สโดยรวม ได้ด้วย
ถ้าหุ่นยนต์เขียนให้เองได้ แล้วทำไมต้องใช้โปรเจกต์ของคนอื่นด้วย?
โดยเฉพาะถ้าโปรเจกต์โอเพนซอร์สนั้นเป็น vibe coded ยิ่งแล้วใหญ่
AI และเทคโนโลยีโดยรวมกำลังทำให้การทำของเฉพาะบุคคลมีต้นทุนต่ำและง่ายขึ้น
แต่ก่อนเราต้องใช้สินค้าผลิตจำนวนมากที่พอถูไถสำหรับทุกคน แต่ตอนนี้เริ่มมีความหวังว่าจะได้อะไรบางอย่างที่ยอดเยี่ยมสำหรับฉันคนเดียว
และมันยังกระตุ้นเศรษฐศาสตร์แรงงาน เพราะหลายคนจะเอา LLM ไปสร้างโปรเจกต์โอเพนซอร์สขึ้นมาใหม่ตามที่ต่างๆ
LLM ทำสิ่งเหล่านั้นออกมาได้ในไม่กี่นาที
สิ่งที่ผมต้องการที่สุดคือ ประวัติการใช้งานจริง
ผมอยากใช้ซอฟต์แวร์ที่มีคนอื่นใช้มาก่อนผม และหวังว่าพวกเขาได้เจอบั๊กและขอบคมต่างๆ แล้วขัดเกลามันมาให้แล้ว
ทำนองว่าถ้าดาวน์โหลดโมเดลมาพิมพ์ที่บ้านและปรับแต่งได้ไม่จำกัด แล้วใครจะซื้อของอีกล่ะ
เหตุผลที่เรามีอารยธรรม ก็เพราะเราส่งต่อปัญหาส่วนใหญ่ในชีวิตให้คนอื่นรับไปจัดการ แล้วตัวเองไปโฟกัสกับสิ่งเดียวที่เราทำได้ดี
ถ้าคุณเป็นหมอฟันหรือเปิด muffler shop เวลาต่อวันก็มีจำกัด และคุณก็คงอยากจ่ายเงินให้ SaaS vendor มากกว่าจะไปเรียน vibecoding แล้วคุมลูกน้องประหลาดที่ต้องดูแลเยอะ
แน่นอนว่ามีข้อยกเว้น แต่ก็เป็นแค่ข้อยกเว้น
ถ้า vendor ทำผลิตภัณฑ์ที่มีเหตุผลและมีความสามารถ ผมก็ยินดีจ่าย
โอเพนซอร์สก็เหมือนกัน
ต่อให้ LLM สามารถสร้างระบบปฏิบัติการใหม่ที่เสถียรได้ตั้งแต่ศูนย์ ผมจะอยากได้มันจริงหรือ?
ผมไม่อยากบำรุงรักษา OS ไม่อยากจัดการคนที่มาบำรุงรักษา OS ให้ และก็ไม่เชื่อด้วยว่าตัวเองมีวิสัยทัศน์ที่สอดคล้องกันพอเกี่ยวกับ OS ตั้งแต่แรก
เมื่อเกินระดับ ความซับซ้อน บางจุดไปแล้ว ก็ยากที่จะคาดหวังว่าหุ่นยนต์จะอ่านใจผมได้ดีพอจนให้ผลลัพธ์คุณภาพสูงแบบ “ยอดเยี่ยมสำหรับฉันคนเดียว”
โปรเจกต์ Zig ชัดเจนว่าอยู่นอกขอบเขตความสามารถนั้นไปมาก
มีคนที่แบกรับค่าใช้จ่ายไม่ไหว และแม้มีสิทธิ์เข้าถึงก็ยังมีปัญหาอย่าง Claude ล่มหรือประสิทธิภาพโดยรวมที่ดูเหมือนลดลงเรื่อยๆ เป็นครั้งคราวหรืออย่างต่อเนื่อง
เมื่อหลายเดือนก่อนตอนเพิ่งเริ่มใช้ Claude ใหม่ๆ ผมขยับหลายโปรเจกต์ได้ง่ายในสัปดาห์เดียว แต่เดี๋ยวนี้เหมือนเห็นแต่ spinner และคุณภาพโค้ดก็ตกฮวบจนแทบทำอะไรไม่ได้
ผมมี repo อยู่ไม่กี่ตัวที่มีดาวราวๆ 100 ดวง ไม่ใช่อะไรใหญ่โต แต่จนถึงปีที่แล้วก็ยังได้ PR บ้างเป็นครั้งคราว ส่วนปีนี้จนถึงตอนนี้แทบไม่มีเลย
สมมติฐานของผมคือ LLM ชอบไปเกาะโปรเจกต์กระแสหลัก
ตอนนี้นักพัฒนาหลายคนพึ่งพา LLM อย่างหนัก จึงเกิดอคติไปในทางมองข้ามสิ่งส่วนใหญ่ที่ผมมีให้
สาเหตุหนึ่งที่มี การประดิษฐ์วงล้อใหม่ มากขึ้นด้วย LLM ก็เพราะต้นทุนในการสร้างใหม่ถูกลง
ดังนั้นแทนที่จะไปใช้ของแปลกๆ บน GitHub เช่นของผม มันกลับง่ายกว่าที่จะสร้างสิ่งที่ต้องการขึ้นมาเอง
ผมเห็นปรากฏการณ์เดียวกันนี้ตอนเลือก dependency ด้วย
ถ้าไม่มีเหตุผลที่ดีมากพอ ก็มักจะเลือกสิ่งที่ LLM แนะนำมาเลย
ผมเห็นด้วยระดับหนึ่ง แต่ไม่ถึงกับเห็นด้วยทั้งหมด
การบ่มเพาะผู้มีส่วนร่วมเป็นลำดับความสำคัญที่ถูกต้องนั้นจริง
แต่ผมมอง AI เป็น เทคโนโลยีช่วยเหลือ
คล้าย screen reader หรือ magnifying glass แม้แน่นอนว่าจะมีจุดต่างหลายอย่าง
จะมองมันเป็น โครงกระดูกภายนอกแบบหุ่นยนต์ ก็ได้
มันจะถูกใช้กับเรื่องแย่ๆ และเรื่องโง่ๆ แน่นอน แต่เดิมทีแล้วมันก็จะถูกใช้เพื่อช่วยให้คนที่ไม่เคยทำได้มาก่อนทำสิ่งดีๆ ได้ หรือช่วยให้มีความสามารถมากขึ้นด้วย
สำหรับบางคน AI ทำให้เขียนโค้ดในแบบที่เมื่อก่อนไม่อาจทำได้ สำหรับหลายคน AI เป็นวิธีเรียนรู้การเขียนโค้ดจากการดูสิ่งที่มันทำ และสำหรับอีกหลายคน AI ทำให้เขียนโค้ดได้เร็วขึ้นหรือดีขึ้นมาก
สำหรับบางคน ทักษะบางอย่างอาจเสื่อมลง ขณะที่ทักษะอื่นพัฒนาขึ้นแทน
ถ้ามี exoskeleton ที่ใช้ได้ดีออกสู่ตลาดจริง ก็คงเกิดปัญหาแบบเดียวกัน แต่โดยรวมมันก็จะเป็นเครื่องมือที่ทำให้สิ่งต่างๆ เป็นไปได้
ผมไม่เห็นว่าทำไมการบ่มเพาะผู้มีส่วนร่วมที่ใช้เทคโนโลยีช่วยเหลือ ถึงจะแย่กว่าการบ่มเพาะผู้มีส่วนร่วมที่ไม่ใช้
แน่นอนว่ามันอาจยากกว่า
LLM ไม่ได้ฉลาด อย่างที่ vendor ของ LLM กล่าวอ้าง
ถ้ามันฉลาดขนาดนั้นจริง มันคงเป็นอิสระเต็มตัวไปแล้ว และเราคงไม่ต้องมาคุยกันแบบนี้
คนที่ส่งหรือใช้โค้ดที่ LLM สร้างแบบไม่ลืมหูลืมตา หรือไม่เปิดเผยว่าใช้มัน ควรหยุดได้แล้วจริงๆ
ปัญหาที่เหลือคือมันยังคงเป็นเครื่องมืออยู่ดี
ต่อให้บอกนักพัฒนาคนไหนก็ได้ว่า “ทำ Zig ให้เร็วขึ้นด้วย one-shot PR” ผลลัพธ์ก็คงไม่ดี
โปรเจกต์ OSS ในอดีตมีการคัดกรองตัวเอง เพราะคุณต้องทำ working code ได้ก่อน และเมื่อถึงระดับนั้น ปกติคุณก็ได้เรียนรู้มาหลายปีแล้วจึงมักทำสิ่งที่ถูกต้องและมีเหตุผลของตัวเองเกี่ยวกับฟีเจอร์หรือความจำเป็น
ทุกวันนี้ ต่อให้ LLM สมบูรณ์แบบและมี reasoning ดี มันก็ยังแค่ทำตามคำสั่งของคนพรอมป์ต์อยู่ดี
การคัดกรองตัวเองจึงหายไปแล้ว
นักพัฒนา Zig เองก็คงแยกได้ยากว่าโค้ดไหน LLM ทำ โค้ดไหนคนทำ
เป็นไปได้ด้วยซ้ำว่าโค้ดที่สร้างด้วย LLM ได้เข้าไปแล้ว แต่ อย่างน้อย ผู้ส่งที่เป็นมนุษย์ แบบนั้นก็ยังต้องรับมือกับโค้ดได้เก่งพอสมควร
สุดท้ายผมสงสัยว่าเราจะไปจบที่ “มีแต่มนุษย์ที่มี trusted badge of honor เท่านั้นที่ commit ได้” หรือไปจบที่ “LLM มี reasoning ดีพอที่จะบอกว่า ‘ไม่ เอาออกไป ฟีเจอร์/แผน/ไอเดียนี้ห่วย ฉันจะไม่สร้างมัน’” กันแน่
ถ้าไม่มีวิธีทำให้เจ็บจริงเมื่อทำแบบนั้น ผมก็ไม่รู้ว่าอะไรจะหยุดพวกเขาได้