เหตุผลเบื้องหลังนโยบายต่อต้าน AI contribution ของโปรเจกต์ Zig

(simonwillison.net)

5 คะแนน โดย GN⁺ 2026-05-01 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

Zig ใช้กฎที่เข้มงวดในการ ห้ามใช้ LLM กับ issues, Pull Request, ความเห็นใน bug tracker และงานแปล
การใช้ภาษาอังกฤษเป็นเพียงคำแนะนำ ไม่ใช่ข้อบังคับ และผู้ร่วมพัฒนาสามารถ เขียนด้วยภาษาแม่ ได้ ส่วนผู้อื่นก็สามารถใช้เครื่องมือแปลที่ตนเลือกเพื่อตีความเนื้อหาได้
Bun ได้เพิ่ม parallel semantic analysis และ multiple codegen units เข้าไปใน Zig fork ของตัวเองบน LLVM backend จนทำให้การคอมไพล์ Bun เร็วขึ้น 4 เท่า แต่ขณะนี้ยังไม่มีแผนส่งกลับ upstream เพราะนโยบายห้าม contribution ที่เขียนด้วย LLM
วิธีรีวิวของ Zig ไม่ได้มุ่งปฏิเสธ PR ที่ยังไม่สมบูรณ์ แต่มุ่งช่วยให้ผู้ร่วมพัฒนาใหม่ไปถึงจุดที่สามารถ merge งานได้ และให้ความสำคัญกับ การเติบโตของผู้ร่วมพัฒนา มากกว่าตัว contribution รายชิ้น
PR ที่ส่วนใหญ่เขียนโดย LLM ทำให้เวลาในการรีวิวไม่ถูกใช้ไปกับการเพิ่มจำนวนผู้ร่วมพัฒนาหน้าใหม่ที่ไว้วางใจได้ และ maintainer ก็อาจเลือกแก้ปัญหาเดียวกันด้วยการรัน LLM เองแทนได้

ความขัดแย้งระหว่างนโยบายกับ Bun fork

Zig ระบุอย่างชัดเจนใน Code of Conduct ว่า ห้ามใช้ LLM กับ issues, 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 ห้าม contribution ที่เขียนด้วย LLM อย่างเข้มงวด
ตามความเห็นของ ผู้ร่วมพัฒนาแกนหลักของ Zig แพตช์นี้ก็ยากจะถูกรับเข้าอยู่ดี แม้ไม่เกี่ยวกับประเด็น LLM
- parallel semantic analysis เป็นฟีเจอร์ที่วางแผนมานาน แต่ส่งผลต่อ ตัวภาษา Zig เอง

Contributor Poker และการรีวิวที่ยึดผู้ร่วมพัฒนาเป็นศูนย์กลาง

แนวคิด contributor poker ใน Contributor Poker and Zig's AI Ban เป็นอุปมาสำคัญในการทำความเข้าใจนโยบายแบนอย่างเข้มงวดของ Zig
- โปรเจกต์โอเพนซอร์สที่ประสบความสำเร็จจะไปถึงจุดที่ได้รับ PR มากกว่าปริมาณที่สามารถจัดการได้
- เพื่อเพิ่ม ROI ให้สูงสุด Zig เลือกแนวทางที่ไม่ปฏิเสธ PR ที่ยังไม่สมบูรณ์ แต่ช่วยให้ผู้ร่วมพัฒนาใหม่สามารถพางานของตนไปจน merge ได้
- แนวทางนี้ถูกมองว่าไม่ใช่แค่ “สิ่งที่ถูกต้อง” แต่ยังเป็น “สิ่งที่ฉลาด” ด้วย
Zig ให้ความสำคัญกับ ผู้ร่วมพัฒนา มากกว่าตัว contribution รายชิ้น
- เป้าหมายหลักของการรีวิวและรับ PR ไม่ใช่การนำโค้ดใหม่เข้ามา แต่คือการช่วยคนที่เมื่อเวลาผ่านไปจะเติบโตเป็นผู้ร่วมพัฒนาที่ไว้ใจได้และมีประสิทธิภาพ
- ผู้ร่วมพัฒนาแต่ละคนจึงเป็นเป้าหมายการลงทุนของ Zig core team
การสนับสนุนด้วย LLM ทำลายโครงสร้างนี้
- ต่อให้ LLM ช่วยเขียน PR ที่สมบูรณ์แบบ เวลาที่ทีม Zig ใช้รีวิวก็ไม่ได้ช่วยเพิ่มจำนวนผู้ร่วมพัฒนาหน้าใหม่ที่มีความมั่นใจและเชื่อถือได้
- “contributor poker” มาจากอุปมาที่ว่าเกมนี้เล่นโดยดูคน ไม่ใช่ดูไพ่
- ความหมายจึงใกล้เคียงกับการ เดิมพันกับผู้ร่วมพัฒนา มากกว่าดูจากเนื้อหาของ PR แรก
หากเป็น PR ที่ LLM เขียนเกือบทั้งหมด maintainer ของโปรเจกต์ก็มีทางเลือกที่จะไม่รีวิวและถกเถียง PR นั้น แต่ไปรัน LLM เองเพื่อแก้ปัญหาเดียวกันโดยตรง

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

fantajeon 2026-05-02

เพราะคนคือคอขวด จึงต้องมีนโยบายคัดกรองเบื้องต้นไว้ล่วงหน้า เพราะถ้าต้องมานั่งรีวิว PR ขยะที่ไหลบ่าเข้ามา ก็อาจทำให้การพัฒนา Zig เดินหน้าต่อไม่ได้

GN⁺ 2026-05-01

ความคิดเห็นใน Hacker News

ตาม https://kristoff.it/blog/contributor-poker-and-ai/ ระบุว่าการมีส่วนร่วมที่อิง LLM โดยรวมให้ผลในทางลบ
PR แบบ drive-by ที่ไร้คุณค่าได้เพิ่มสัญญาณรบกวนด้วย โค้ดหลอน ซึ่งคอมไพล์ไม่ผ่านหรือไม่ผ่าน CI และยังมีกรณีที่ผู้มีส่วนร่วมครั้งแรกส่ง PR 10,000 บรรทัด มาด้วย
ยังมี PR ที่ดูเผินๆ เหมือนใช้ได้และระบุชัดว่าไม่ได้ใช้ LLM แต่ในการพูดคุยต่อมาก็เห็นได้ทันทีว่าผู้เขียนแอบอ้างอิง LLM และคอยตอบซ้ำๆ แบบมีข้อผิดพลาดจำนวนมาก
- สรุปกลุ่มแฟน LLM ได้ค่อนข้างดีทีเดียว
- มันเหมือน Fake it till you make it และดูเหมือนว่า LLM ก็ขึ้นขี่กระแสนั้นไปด้วย
- ส่วนตัวแปลกใจที่โปรเจกต์ OSS ขนาดใหญ่ไม่มี ระบบอัตโนมัติ สำหรับกันการส่งงานที่คอมไพล์ไม่ผ่านหรือ linter ไม่ผ่าน
  hooks ไม่มีวิธีที่สะอาดในการบังคับให้ติดตั้งตอน clone แต่ GHA Workflows หรือความสามารถเทียบเท่าบน forge อื่นๆ น่าจะมี
  ถ้าเป็นโปรเจกต์ที่มีทั้งขนาดและความนิยมระดับหนึ่ง ผมมองว่านี่ควรเป็นข้อกำหนดพื้นฐาน
  ปัญหาจำนวนมากของเรื่อง “AI มีส่วนร่วมไม่ได้” น่าจะลดลงได้พอสมควรด้วยการตรวจอัตโนมัติและมาตรการคัดกรองที่ดีกว่านี้
- นี่ใกล้เคียงกับ ปัญหาสแปม มากกว่าจะเป็นปัญหา AI
  นอกจากประเด็นที่ AI ทำให้สแปมรูปแบบใหม่นี้เกิดขึ้นได้ แก่นแท้ของเรื่องก็ไม่ใช่ AI
  ต่อให้ไม่มี AI ถ้าคนไปจ้างกองทัพนักพัฒนาราคาถูกจากต่างประเทศมาผลิต PR แบบ drive-by คุณภาพกลางๆ จำนวนมาก ผลก็จะเหมือนกัน
  จะใช้ AI ทำโค้ดดีๆ ก็ได้ แต่เหมือนเครื่องมืออื่นๆ คือต้องใช้อย่างรอบคอบ
  นี่ไม่ใช่การมีส่วนร่วมที่คนซึ่งเข้าใจโปรเจกต์และเป้าหมายใช้เครื่องมืออย่างดีและทำอย่างระมัดระวัง แต่มันคือสแปม
- เราสามารถชี้นำให้ LLM ทำงานที่ต้องการได้ แต่โชคร้ายที่ผู้คนจำนวนมากขาดทั้ง ความอดทน และทักษะสำหรับสิ่งนั้น
เสียงรบกวนรอบนโยบาย 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 เอง ก็ต้องเปลี่ยนด้วย
- คำตอบนั้นให้เหตุผลที่น่าเชื่อถือในการไม่ merge fork ของ Bun
  เพราะมันขัดกับโรดแมปของ Zig เองที่มุ่งไปสู่ผลลัพธ์ที่ดีกว่า และยังขัดขวางทิศทางการปรับปรุงภาษาทั้งระบบอย่างต่อเนื่อง
- ถ้าส่ง เพิ่มมา 3,000 บรรทัด ใน PR เดียว โอกาสถูกปฏิเสธก็สูงอยู่แล้ว
- ไม่ค่อยเข้าใจว่าการถกเถียงเรื่องคุณภาพ PR จะมีความหมายอะไร
  เมื่อนโยบายห้าม โค้ดจาก 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 แต่พอนึกภาพสถานการณ์ได้ว่าผู้มีส่วนร่วมอาจใช้เวลารวมราว 20 ชั่วโมง
  ใช้ AI ทำเวอร์ชันแรกที่แย่ๆ ออกมาก่อน จากนั้นค่อยปรับพรอมป์ต์ แก้ด้วยมือ สั่งให้มันแก้ส่วนอื่น ค้นพบฟีเจอร์ที่เกี่ยวข้องแล้วเพิ่มเข้าไป รัน benchmark แล้วตัดฟีเจอร์เล็กๆ บางอย่างออก หรือเลือกหนึ่งในสอง implementation ที่คล้ายกัน
  แล้วก็แก้ด้วยมือตรงนั้นตรงนี้เพิ่ม รันชุดทดสอบอัตโนมัติที่ขยายเพิ่มเพื่อหา bug แปลกๆ ในการตั้งค่าพิสดาร แล้วใช้ทั้ง AI และการแก้มือช่วยกันแก้
  พอผ่านไป 20 ชั่วโมง เวอร์ชันสุดท้ายอาจเหลือแค่ 50 บรรทัด และแต่ละบรรทัดอาจถูกเขียนใหม่ถึง 5 ครั้ง
  maintainer จึงใช้เวลารีวิวแค่ประมาณ 1 ชั่วโมงกับเวอร์ชันสุดท้ายก็พอ
  มันต่างกันโดยสิ้นเชิงกับการปล่อยให้ AI เขียนแพตช์ 5 นาทีแล้วส่งโค้ด 1,000 บรรทัดที่คอมไพล์ไม่ผ่านมาให้ maintainer โดยไม่แม้แต่จะอ่าน
- การเขียนโค้ดอาจไม่ใช่คอขวดก็จริง แต่ความเป็นไปได้สูงคือคอขวดจะไปอยู่ที่การตรวจสอบความถูกต้องของ โค้ดที่ LLM สร้าง
- ทำให้นึกถึงคำวิจารณ์ศิลปะแบบหนึ่ง
  “มันง่ายมากจนฉันก็ทำได้”
  ใช่ แต่คุณไม่ได้ทำจริงๆ
- เวลา AI ทำงานได้ผล มันให้ ความเร็วเพิ่ม 2–3 เท่า
  แต่ไม่ใช่เครื่องมือประเภทที่คุณจะโยนคำสั่งระดับสูงแบบที่สั่งคนแล้วมันจะทำได้
  คนที่อ้างว่า AI ทำงานได้ด้วยคำสั่งระดับสูงอย่างเดียว ส่วนใหญ่ผมสงสัยว่ากำลังทำโปรเจกต์แบบ “ไม่ต้องคิดมาก” ที่นักพัฒนาไม่จำเป็นต้องลงลึกในรายละเอียดมากนักหรือเปล่า
- คงไม่ได้จะบอกว่าตัวชี้วัดผลิตภาพมีแค่ จำนวนบรรทัดโค้ด หรอกนะ?
  และหวังว่าไม่ได้หมายความว่าข้อดีอย่างเดียวของ LLM คือช่วยสร้างโค้ดที่ขี้เกียจพิมพ์เองโดยตรง
คำอธิบายที่ว่า “Zig ให้ความสำคัญกับ ผู้มีส่วนร่วม มากกว่าการมีส่วนร่วม เป้าหมายหลักของการรีวิวและรับ PR ไม่ใช่เพื่อเอาโค้ดใหม่เข้าโปรเจกต์ แต่เพื่อช่วยให้คนคนนั้นเติบโตเป็นผู้มีส่วนร่วมที่เชื่อถือได้และมีผลิตภาพในระยะยาว การมี LLM ช่วยทำลายสิ่งนี้ไปอย่างสิ้นเชิง ต่อให้ LLM ช่วยให้ส่ง PR ที่สมบูรณ์แบบได้ก็เหมือนกัน” เป็นเหตุผลที่ดีที่สุดเท่าที่ผมเคยเห็นมา
ผมสนับสนุนการตัดสินใจของ Zig อย่างเต็มที่ และชื่นชมวิสัยทัศน์ระยะยาวที่มีต่อทั้งชุมชนและตัวโปรเจกต์จริงๆ
พูดตามตรงผมไม่คิดว่า LLM จะเหมาะกับงานที่ต้องร่วมมือกันมากนัก
ต่อไปจะเปลี่ยนไปอย่างไรคงต้องรอดู แต่เวลารับ PR ที่สร้างด้วย AI สุดท้ายมักจบลงที่ผมต้องทำมันใหม่เองอยู่ดี และที่น่าขันคือผมกลับใช้ LLM ช่วยทำใหม่ เลยยิ่งรู้สึกขัดแย้งขึ้นเรื่อยๆ
- ผมคิดว่า LLM ยอดเยี่ยม และทำ vibe coding กับ Zig เยอะมากบนอุปกรณ์ locally deployed semi-embedded on-prem
  ถึงอย่างนั้นก็ยังคิดว่านโยบายของ Zig เป็นความคิดที่ดี อย่างน้อยในช่วง 5 ปีข้างหน้า
ผมคิดว่านี่เป็นถ้อยคำที่ไม่เป็นปฏิปักษ์ที่สุดเท่าที่พวกเขาจะพูดได้แล้ว และก็เคารพว่าเป็นการตัดสินใจเกี่ยวกับโปรเจกต์ของพวกเขาเอง
แต่ก็ยังรู้สึกว่ามันมัดโปรเจกต์ไว้โดยไม่จำเป็น
LLM เป็นเครื่องมือ และมันช่วยในการคิด ค้นคว้า และเขียนโค้ดได้
อาจใช้มากเกินไปได้ แต่ก็ควรยอมรับมันในจุดที่มันช่วยได้
การไม่รับ PR ของ Bun ด้วยเหตุผลอื่นนั้นโอเคมาก แต่การแบน PR ที่เขียนด้วย LLM ทั้งหมดไปเลยเป็นข้อจำกัดที่เกินจำเป็น
แค่โฟกัสที่คุณภาพของงานก็พอ
- ทำไมต้องไปรีวิว โค้ดที่ 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 เป็น sounding board สำหรับ การตัดสินใจด้านสถาปัตยกรรม แล้วนำประเด็นไปคุยต่อกับทีมเพื่อทบทวนสมมติฐานและข้อดีข้อเสียร่วมกัน
  เมื่อกำหนดสถาปัตยกรรมแล้ว LLM ก็ทำงานด้าน implementation ได้ค่อนข้างดี
- เห็นด้วยกับการประเมินนี้ แต่แม้แต่ senior ที่มีความรู้สะสมอยู่แล้วก็ยังมีความเสี่ยงจะปล่อยให้โค้ดจำนวนมากที่ตัวเองไม่เข้าใจทั้งหมดงอกออกมานอกการควบคุมเหมือนพื้นหลุดใต้เท้า
  โดยทั่วไปสามารถทำให้มันสร้างโค้ดที่ยอดเยี่ยมและทดสอบมาดีได้ และบางทีก็ดีกว่าทำคนเดียวในเวลาเท่ากันมาก
  แต่การพยายามตามความรู้ให้ทันทุกอย่างที่ AI สร้างขึ้นก็ยังเป็นความท้าทาย
ตรรกะที่ว่า “ถ้า PR ส่วนใหญ่เขียนโดย LLM ทำไม maintainer ไม่เอาเวลาที่ใช้รีวิวและคุยเรื่อง PR ไปเปิด LLM ของตัวเองแล้วแก้ปัญหาเดียวกันซะเลยล่ะ?” นั้นใช้กับ โอเพนซอร์สโดยรวม ได้ด้วย
ถ้าหุ่นยนต์เขียนให้เองได้ แล้วทำไมต้องใช้โปรเจกต์ของคนอื่นด้วย?
โดยเฉพาะถ้าโปรเจกต์โอเพนซอร์สนั้นเป็น vibe coded ยิ่งแล้วใหญ่
AI และเทคโนโลยีโดยรวมกำลังทำให้การทำของเฉพาะบุคคลมีต้นทุนต่ำและง่ายขึ้น
แต่ก่อนเราต้องใช้สินค้าผลิตจำนวนมากที่พอถูไถสำหรับทุกคน แต่ตอนนี้เริ่มมีความหวังว่าจะได้อะไรบางอย่างที่ยอดเยี่ยมสำหรับฉันคนเดียว
และมันยังกระตุ้นเศรษฐศาสตร์แรงงาน เพราะหลายคนจะเอา LLM ไปสร้างโปรเจกต์โอเพนซอร์สขึ้นมาใหม่ตามที่ต่างๆ
- ช่วงนี้ผมคิดเรื่อง “ถ้าหุ่นยนต์เขียนให้เองได้ แล้วทำไมต้องใช้โปรเจกต์ของคนอื่น?” บ่อยมาก และตอนนี้สิ่งที่ผมเห็นว่ามีค่าที่สุดในซอฟต์แวร์ไม่ใช่ชุดทดสอบที่แน่นหนาหรือเอกสารที่ละเอียดถี่ถ้วน
  LLM ทำสิ่งเหล่านั้นออกมาได้ในไม่กี่นาที
  สิ่งที่ผมต้องการที่สุดคือ ประวัติการใช้งานจริง
  ผมอยากใช้ซอฟต์แวร์ที่มีคนอื่นใช้มาก่อนผม และหวังว่าพวกเขาได้เจอบั๊กและขอบคมต่างๆ แล้วขัดเกลามันมาให้แล้ว
- ตอนต้นทศวรรษ 2010 ที่คนพูดกันว่า การปฏิวัติ 3D printing กำลังจะมาถึง ผมก็เคยได้ยินตรรกะแบบเดียวกัน
  ทำนองว่าถ้าดาวน์โหลดโมเดลมาพิมพ์ที่บ้านและปรับแต่งได้ไม่จำกัด แล้วใครจะซื้อของอีกล่ะ
  เหตุผลที่เรามีอารยธรรม ก็เพราะเราส่งต่อปัญหาส่วนใหญ่ในชีวิตให้คนอื่นรับไปจัดการ แล้วตัวเองไปโฟกัสกับสิ่งเดียวที่เราทำได้ดี
  ถ้าคุณเป็นหมอฟันหรือเปิด muffler shop เวลาต่อวันก็มีจำกัด และคุณก็คงอยากจ่ายเงินให้ SaaS vendor มากกว่าจะไปเรียน vibecoding แล้วคุมลูกน้องประหลาดที่ต้องดูแลเยอะ
  แน่นอนว่ามีข้อยกเว้น แต่ก็เป็นแค่ข้อยกเว้น
  ถ้า vendor ทำผลิตภัณฑ์ที่มีเหตุผลและมีความสามารถ ผมก็ยินดีจ่าย
  โอเพนซอร์สก็เหมือนกัน
  ต่อให้ LLM สามารถสร้างระบบปฏิบัติการใหม่ที่เสถียรได้ตั้งแต่ศูนย์ ผมจะอยากได้มันจริงหรือ?
  ผมไม่อยากบำรุงรักษา OS ไม่อยากจัดการคนที่มาบำรุงรักษา OS ให้ และก็ไม่เชื่อด้วยว่าตัวเองมีวิสัยทัศน์ที่สอดคล้องกันพอเกี่ยวกับ OS ตั้งแต่แรก
- ตรรกะนี้ใช้ได้เฉพาะกับโปรเจกต์โอเพนซอร์สที่เล็กที่สุดเท่านั้น
  เมื่อเกินระดับ ความซับซ้อน บางจุดไปแล้ว ก็ยากที่จะคาดหวังว่าหุ่นยนต์จะอ่านใจผมได้ดีพอจนให้ผลลัพธ์คุณภาพสูงแบบ “ยอดเยี่ยมสำหรับฉันคนเดียว”
  โปรเจกต์ Zig ชัดเจนว่าอยู่นอกขอบเขตความสามารถนั้นไปมาก
- การเข้าถึง LLM ยังไม่ใช่เรื่องทั่วไปเสียทีเดียว
  มีคนที่แบกรับค่าใช้จ่ายไม่ไหว และแม้มีสิทธิ์เข้าถึงก็ยังมีปัญหาอย่าง Claude ล่มหรือประสิทธิภาพโดยรวมที่ดูเหมือนลดลงเรื่อยๆ เป็นครั้งคราวหรืออย่างต่อเนื่อง
  เมื่อหลายเดือนก่อนตอนเพิ่งเริ่มใช้ Claude ใหม่ๆ ผมขยับหลายโปรเจกต์ได้ง่ายในสัปดาห์เดียว แต่เดี๋ยวนี้เหมือนเห็นแต่ spinner และคุณภาพโค้ดก็ตกฮวบจนแทบทำอะไรไม่ได้
- ผมเห็น PR ใน repository ของตัวเองลดลง
  ผมมี 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 ดีพอที่จะบอกว่า ‘ไม่ เอาออกไป ฟีเจอร์/แผน/ไอเดียนี้ห่วย ฉันจะไม่สร้างมัน’” กันแน่
- คิดว่าพวกเขาคงไม่หยุด
  ถ้าไม่มีวิธีทำให้เจ็บจริงเมื่อทำแบบนั้น ผมก็ไม่รู้ว่าอะไรจะหยุดพวกเขาได้