การเปลี่ยนแนวทางการพัฒนาของ Ladybird
(ladybird.org)- Ladybird จะหยุดรับ public pull request เพื่อเตรียมพร้อมสำหรับ alpha release แรกและการเปิดตัวเบราว์เซอร์สำหรับผู้ใช้จริง โดยจะให้เฉพาะผู้ดูแลโครงการเป็นผู้นำการเปลี่ยนแปลงโค้ดเข้ามาเท่านั้น
- เมื่อ เครื่องมือ AI ทำให้การสร้างผลงานที่ดูเหมือนเป็นการมีส่วนร่วมอย่างจริงจังทำได้เร็วขึ้นและถูกลง โมเดลความไว้วางใจเดิมที่มองว่าแพตช์ขนาดใหญ่สะท้อนถึงความหวังดีหรือความพยายามอย่างมากจึงอ่อนแอลง
- เบราว์เซอร์รันอินพุตที่ไม่น่าเชื่อถือจากทั้งอินเทอร์เน็ตบนเครื่องของผู้ใช้ ดังนั้นเพียง ช่องโหว่ ที่ซ่อนมาอย่างแนบเนียนหนึ่งจุดก็เพียงพอสำหรับผู้โจมตีแล้ว
- public PR ที่เปิดอยู่ทั้งหมดจะถูกปิด และจะไม่สร้างขั้นตอนส่งแพตช์แยกผ่าน issues·comments·email·forks หรือสร้าง ระบบการมีส่วนร่วมแบบเงา
- Ladybird จะยังคงเป็นโอเพนซอร์ส และการมีส่วนร่วมจากภายนอกจะมุ่งไปที่การรายงานบั๊กอย่างชัดเจน การทำชุดย่อเพื่อให้เกิดซ้ำได้ การทดสอบเว็บไซต์ การหารือเรื่องมาตรฐาน·การออกแบบ การรายงานความปลอดภัย และฟีดแบ็กทางเทคนิค แทนการส่งโค้ด
แก่นสำคัญของการเปลี่ยนกระบวนการพัฒนา
- จากนี้ไป Ladybird จะไม่รับ public pull request และจะเปลี่ยนไปใช้แนวทางที่ให้เฉพาะผู้ดูแลโครงการเป็นผู้นำการเปลี่ยนแปลงเข้าสู่ codebase
- ในช่วงเตรียม alpha release แรก จำเป็นต้องมีกระบวนการพัฒนาที่เข้มงวดขึ้น โมเดลความปลอดภัยที่ชัดเจนขึ้น และกลุ่มคนที่เล็กลงซึ่งรับผิดชอบต่อโค้ดที่เข้าสู่เบราว์เซอร์
- ในอดีต แพตช์ขนาดใหญ่เป็นสัญญาณตัวแทนที่พอเชื่อได้ว่ามีความพยายามอย่างมากและมีเจตนาดี แต่ด้วยเครื่องมือ AI สมมติฐานนั้นไม่เป็นจริงอีกต่อไป
- เบราว์เซอร์รันอินพุตที่ไม่น่าเชื่อถือจากอินเทอร์เน็ตบนเครื่องของผู้ใช้ และเพียงช่องโหว่ที่ซ่อนมาอย่างแนบเนียนหนึ่งจุดก็เป็นเงื่อนไขที่เพียงพอสำหรับผู้โจมตี
- เคยมีแคมเปญที่อดทนและมีทรัพยากร ซึ่งพยายามสร้างความไว้วางใจจากผู้ดูแลในโอเพนซอร์สแล้วนำไปใช้ในทางที่ผิดอยู่แล้ว สิ่งที่เปลี่ยนไปคือ ตอนนี้สามารถสร้างผลงานที่ดูเหมือนการมีส่วนร่วมอย่างจริงจังได้เร็วขึ้นและถูกลง
- การเปลี่ยนแปลงทุกอย่างที่เข้ามาใน Ladybird ต้องสอดคล้องกับสถาปัตยกรรม ทนต่อการรีแฟกเตอร์ในอนาคต โต้ตอบกับส่วนอื่นของเบราว์เซอร์ได้อย่างถูกต้อง และเป็นสิ่งที่ผู้ดูแลเข้าใจได้
- ประเด็นสำคัญไม่ใช่ว่าโค้ดถูกเขียนด้วยมือหรือไม่ แต่เป็นว่าเมื่อโค้ดเข้าไปอยู่ในเบราว์เซอร์แล้ว ใครเป็นผู้รับผิดชอบ
มาตรการเปลี่ยนผ่านและการมีส่วนร่วมที่ยังทำได้ต่อ
- public pull request ที่เปิดอยู่ทั้งหมดในตอนนี้จะถูกปิด เพราะหากยังคงรักษาคิวเดิมไว้ ก็เท่ากับว่ายังคงเปิดเส้นทางการมีส่วนร่วมแบบสาธารณะอยู่จริง จึงตัดสินใจเปลี่ยนตอนนี้เลย
- ต่อจากนี้ pull request จะมีให้เฉพาะผู้ดูแลโครงการเท่านั้น
- จะไม่สร้างขั้นตอนส่งแพตช์แยกผ่าน issues, comments, email, forks และจะไม่ปฏิบัติต่อ fork หรือ patch dump เสมือนเป็น review queue ของ upstream Ladybird
- โค้ดจากภายนอกยังอาจมีอยู่ได้ภายใต้เงื่อนไขของไลเซนส์
- Ladybird จะยังคงเป็นโอเพนซอร์ส และซอร์สโค้ดจะยังคงเปิดเผยต่อไปภายใต้ไลเซนส์โอเพนซอร์ส
- การมีส่วนร่วมจากภายนอกยังช่วยให้โครงการเดินหน้าได้ผ่าน bug reports, reductions, website testing, standards discussion, design discussion, security reports, technical feedback ที่ชัดเจน
- ในช่วงเตรียมเปิดตัวเบราว์เซอร์ให้ผู้ใช้จริง กระบวนการพัฒนาก็ต้องสอดคล้องกับความรับผิดชอบนั้นด้วย
2 ความคิดเห็น
ความคิดเห็นบน Hacker News
ช่วงนี้เห็น PR จากโปรเจกต์โอเพนซอร์สขนาดใหญ่หลายโปรเจกต์อย่าง Godot แล้วพบว่า PR ที่ทั้งโค้ดและคำอธิบายถูกสร้างโดย AI มีเพิ่มขึ้นมาก
ตามนโยบายของโปรเจกต์มักห้ามไว้ จึงมักแค่เตือนผู้ส่งแบบเบา ๆ โดยหลายคนก็รับได้ดี แต่บางคนกลับโกรธว่าเมนเทนเนอร์ไม่รู้จักขอบคุณ
ดูเหมือนว่าแม้แต่คนที่ขึ้นขบวน AI เต็มตัว ก็ยังไม่ได้ซึมซับว่าการปั่นก้อนโค้ดออกมาได้เองนั้นไม่ได้มีคุณค่าโดยเนื้อแท้
ทั้งที่ความพยายามของตัวเองลดลงไปมาก แต่พอส่ง PR ใหญ่ก็ยังคาดหวังปฏิกิริยาหรือคำขอบคุณแบบเดียวกับยุคก่อน AI
ในบริบทนั้น ฉันไม่คาดหวังว่าคนประเภท นิสัยแย่ ที่มีเยอะอยู่แล้วในวงการนี้จะเปลี่ยนพฤติกรรมหลังยุค AI
อนึ่ง ตอนนี้พนักงานสาย non-technical ที่ที่ทำงานของฉันเริ่มส่ง PR ที่สร้างด้วย AI มายังรีโปภายในที่ฉันดูแลอยู่ ซึ่งคุณภาพดีมาก และก็รับฟังฟีดแบ็กจากรีวิวพร้อมแก้ไขอย่างรวดเร็ว ปัญหาไม่ได้อยู่ที่ว่าเป็นคนสายเทคนิคหรือไม่ แต่เป็นเรื่องของ ทัศนคติ
มันไม่ใช่แค่ในวิธีการมีส่วนร่วม แต่ยังโผล่ออกมาในการพูดทั่ว ๆ ไปด้วย เช่น “ฉันสร้าง X ขึ้นมา”, ยืนกรานว่า “การคัดสรร” ของตัวเองมีผลอย่างมากต่อผลลัพธ์, พูดยากเรื่องบทบาทของ LLM, มีท่าทีแบบ “ฉันโฟกัสที่การสร้าง ส่วนคนอื่นเสียเวลากับรายละเอียด”, และปฏิเสธที่จะเผชิญกับข้อบกพร่องที่อาจมีอยู่
มันต่างอย่างน่าทึ่งจากนักพัฒนาระดับซีเนียร์ที่มักสงสัยอยู่เสมอว่าผลงานที่ตนทำอาจเต็มไปด้วยข้อบกพร่องและทำแบบลวก ๆ ความรู้สึกเหมือน impostor syndrome แบบกลับด้าน
ปัญหาอยู่ที่คนส่ง PR เหล่านี้ 100% ถ้ามีประวัติว่าไม่ลังเลที่จะละเมิดกฎของโปรเจกต์ แถมยังหยิ่งผยองอีก แบบนั้นสำหรับนายจ้างในอนาคตหรือผู้ที่จะร่วมงานด้วยที่เข้ามาดูโปรไฟล์ของคนนั้น ก็ควรเป็น สัญญาณอันตราย ขนาดใหญ่
ฉันไม่เข้าใจว่าทำไมถึงจงใจทำลายชื่อเสียงตัวเอง การไม่มีความเคลื่อนไหวอะไรในโปรไฟล์ยังดีกว่าทิ้งบันทึกพฤติกรรมแย่ ๆ ไว้มาก
เช่นอาจพูดทำนองว่า “นี่ไม่ใช่การปกป้องขอบเขตของโปรเจกต์หรือรับประกันคุณภาพโค้ด แต่มันคือ กลไกกันคน ที่พวกหัวอนุรักษนิยมสร้างขึ้น เพราะพวกเขารู้สึกถูกคุกคามโดยผู้สร้างสายอนาคตอย่างคุณที่เชี่ยวชาญประสิทธิภาพของ AI อย่างแท้จริง”
“แพตช์ขนาดใหญ่เคยหมายถึงความพยายามขนาดใหญ่ และความพยายามนั้นก็เป็นตัวชี้วัดโดยประมาณที่สมเหตุสมผลของเจตนาดี ตอนนี้สมมุติฐานนั้นใช้ไม่ได้อีกต่อไปแล้ว”
ประโยคนี้คือแก่นของบทความ และฉันคิดว่าใช้ได้กับโปรเจกต์ส่วนใหญ่
ถึงอย่างนั้นก็ยังต้องมีวิธีตัดสินว่าใครสามารถทุ่มเทระยะยาวจนกลายเป็นเมนเทนเนอร์ได้ การมีส่วนร่วมกับซอร์สโค้ดตอนนี้เชื่อถือได้ยากในฐานะสัญญาณแบบนั้น และฉันก็ยังไม่รู้ว่าเราจะใช้สัญญาณอะไรแทนในอนาคต มันน่าจะเป็นปัญหาที่ยากพอสมควร
แต่ถ้า AI เพิ่มผลิตภาพของโปรแกรมเมอร์ได้อย่างก้าวกระโดดจริง โปรเจกต์โอเพนซอร์สที่ประสบความสำเร็จก็อาจไม่จำเป็นต้องมีทีมเมนเทนเนอร์ขนาดใหญ่
ในแง่หนึ่ง ถ้าคุณเติบโตมากับ bazaar การย้ายไปสู่ cathedral อาจให้ความรู้สึกเหมือน “ความตายของโอเพนซอร์ส” ทั้งที่จริง ๆ แล้วมันอาจเป็นแค่การกลับไปสู่วิธีทำงานที่เก่ากว่า
แต่อีกแง่หนึ่ง ถ้าไม่รับโค้ดจากภายนอก ท่าทีด้านความปลอดภัยก็คงดีขึ้นแน่ ๆ แต่การหาให้เจอว่าควรเชิญใครเข้าสู่คณะนักบวชก็คงยากขึ้น
ก่อนที่ GitHub จะโด่งดัง โปรเจกต์โอเพนซอร์สจะคล้ายสวนล้อมรั้วแน่นหนามากกว่า เป็นเหมือนคลับเล็ก ๆ ที่ทุกคนจ้องมองคุณทันทีที่คุณเดินเข้าห้อง GitHub ทำให้การติดต่อกลายเป็นสินค้า และลดกำแพงด้านความพยายามหรือความสนใจที่ต้องลงทุนก่อนจะมีส่วนร่วม
ตอนนี้ช่วงเวลานั้นจบแล้ว และก่อนจะไปมีส่วนร่วมกับอะไรก็ตาม เราต้องสร้างความไว้วางใจก่อน
นี่ไม่ใช่ความตายของโอเพนซอร์ส แต่คือความตายของ หมู่บ้านโลก ที่ทุกคนเดินไปมาได้อย่างเสรีและปฏิสัมพันธ์กันได้ง่าย มันคือการคืนชีพของชุมชนขนาดเล็ก เชิงสังคม และอิงความไว้วางใจ และฉันหวังว่ากระแสนี้จะลามไปทั้งอินเทอร์เน็ต
ทุกวันนี้คนยังรู้จักอุปมาอุปไมยนั้นหรือหนังสือของ Raymond กันอยู่ไหม? เราอยู่ในโลกที่ Microsoft เป็นผู้จัดหาโอเพนซอร์สรายใหญ่ และเป็นเจ้าของแพลตฟอร์มที่ทำให้การเขียนโปรแกรมโอเพนซอร์สส่วนใหญ่บนโลกนี้เกิดขึ้น ลองอธิบายสิ่งนี้ให้คนเดินทางข้ามเวลาจากปลายยุค 90 ฟังสิ
และอย่างที่คอมเมนต์ข้างบนบอกเป็นนัย แม้แต่ bazaar ต้นแบบอย่าง Linux kernel ตอนนี้ก็ยังดูเป็น cathedral พอสมควร เมื่อเทียบกับโมเดลความโกลาหลไร้ขีดจำกัดของ GitHub
เพราะงั้นฉันไม่มองว่าการตัดสินใจของ Ladybird เป็นปัญหา ตรงกันข้าม ฉันมองว่ามันช่วยเสริมด้านความเป็นมนุษย์ของการพัฒนาซอฟต์แวร์ และเป็นการเหยียบเบรกพวกที่อาศัย AI เกาะกินผลงานคนอื่น
มันอาจไม่ใช่วิธีที่สมบูรณ์แบบ แต่เดิมทีแล้วการ สั่งสมชื่อเสียง ก็ควรเป็นสิ่งที่ต้องใช้เวลาอยู่แล้ว
พอเห็นแบบนี้ก็ทำให้นึกว่าอยากให้ไม่มี AI ไปเลย
น่าผิดหวังมากที่โปรเจกต์โอเพนซอร์สกำลังสูญเสียความสามารถในการหาผู้ดูแลใหม่และช่วยเมนเทอร์พวกเขา
บอกว่า “จะไม่มีขั้นตอนในการส่งแพตช์ไม่ว่าด้วยวิธีใดก็ตาม” แต่ก็ยังบอกว่า “การมีส่วนร่วมจากภายนอกยังคงสำคัญ: การรายงานบั๊กที่ชัดเจน”
งั้นก็หมายความว่าคุณหาบั๊กและแก้มันได้ แต่ห้ามบอกว่าคุณแก้มันอย่างไรอย่างนั้นหรือ
แล้วทีมก็ต้องไปหาทางออกกันใหม่เอง คงสนุกน่าดูที่ต้องทำสิ่งที่คนอื่นทำสำเร็จไปแล้วซ้ำอีก
ในฐานะผู้ใช้และนักพัฒนา ผมไม่เข้าใจว่าทำไมต้องเสียเวลาให้กับโปรเจกต์ที่ตั้งกำแพงแบบนี้กับซอฟต์แวร์ที่สามารถทำให้ชีวิตผมดีขึ้นได้ ใช้ Firefox หรือ Chromium ที่การแก้ไขของผมอาจถูกรับเข้าไปจริง ๆ ดูจะง่ายกว่ามาก
ก่อนหน้านี้ตอนที่ Chromium เวอร์ชันใหม่ทำให้ผลิตภัณฑ์ของผมแครช ผมเคยเสนอแนวทางแก้ให้ V8 ได้ และมันถูกรวมเข้าไปในรีลีส Chromium ถัดไป ทำให้ผลิตภัณฑ์กลับมาใช้งานได้อีกครั้ง ซึ่งมีประโยชน์มาก(https://github.com/v8/v8/commit/4f8a70adca01c)
ถ้าไม่มีช่องทางแบบนั้น ก็เป็นไปได้ว่านักพัฒนา Chromium จะไม่มีเวลาพอจะหาสาเหตุและแก้ไขมัน
เขาบอกว่า “pull request ไม่ได้บอกอะไรเกี่ยวกับผู้ส่งได้มากเหมือนแต่ก่อนแล้ว” แต่จริง ๆ แล้วไม่ควรมีใครจำเป็นต้องรู้อะไรเกี่ยวกับคนที่ส่ง pull request เลย
ผมหวังว่าการตัดสินใจเรื่องโค้ดที่จะเข้า Firefox หรือ Chromium จะยึดตาม ความถูกต้องของโค้ด ที่ตรวจสอบได้จากการรีวิว ไม่ใช่ตาม “ความพยายาม” หรือ “ความหวังดี” ของผู้ส่ง
การรีวิวโค้ดที่แก้มาแล้วมันง่ายกว่าการคิดขึ้นมาเองอย่างเห็นได้ชัด ถ้าไม่ใช่แบบนั้นก็แค่เขียนโค้ดเองตั้งแต่แรกก็จบ
ในมุมของโปรเจกต์ จะเพิกเฉยหรือปิด PR ที่ไม่ต้องการเมื่อไรก็ได้อยู่แล้ว แต่การปิดกั้นไม่ให้มีแม้แต่ ทางเลือก ที่จะใช้ผลงานจากภายนอก ไม่ว่าจะเพื่อตรวจรีวิวการมีส่วนร่วมหรือเอาไปใช้เป็นข้อมูลสำหรับการเขียนใหม่ของตัวเอง ก็ดูไม่ฉลาดนัก
การแบ่งปันการวิเคราะห์ที่ละเอียดนั้นต่างหากคือวิธีเพิ่มคุณค่าของการมีส่วนร่วมให้สูงสุด ส่วนโค้ดเป็นได้มากสุดก็แค่โบนัสเสริมที่เลือกจะมีหรือไม่มีก็ได้
การแก้บั๊กของคุณอาจมีคุณค่า แต่คุณค่านั้นอาจไม่มากกว่าต้นทุนในการรีวิวและรับมันเข้ามา
คำพูดที่ว่า “การรีวิวโค้ดที่แก้มาแล้วง่ายกว่าการคิดขึ้นมาเองอย่างเห็นได้ชัด” นั้นผิดอย่างสิ้นเชิงในโปรเจกต์ที่ซับซ้อนพอสมควร การแก้อาจมีแค่บรรทัดเดียว แต่ผลกระทบอาจลามไปไกลมาก
ในฐานะผู้ใช้และนักพัฒนา ถ้าคุณไม่อยากเสียเวลาให้กับโปรเจกต์ที่มีกฎแบบนั้น ก็ไม่ต้องเสียก็ได้ คุณไม่ได้ติดหนี้อะไรโปรเจกต์ และโปรเจกต์ก็ไม่ได้ติดหนี้อะไรคุณ มันง่ายแค่นั้น
Firefox และ Chromium มีทีมที่ใหญ่กว่ามาก ยังไม่ต้องพูดถึง Linux kernel เลย พวกเขาอาจมีศักยภาพพอที่จะรับการมีส่วนร่วมของคุณ
ไม่ใช่แค่ประสบการณ์ของผมกับกรณีตัวอย่างในต้นฉบับเท่านั้น แต่ยังรวมถึงประสบการณ์ของผู้ดูแลจำนวนมากที่แชร์บทความคล้ายกันด้วย
คุณช่วยแชร์ลิงก์โปรเจกต์โอเพนซอร์สที่คุณดูแลและรีวิวการมีส่วนร่วมมาหลายปี ซึ่งเป็นพื้นฐานของความเชี่ยวชาญในประเด็นนี้ได้ไหม?
เขียนเป็น คำอธิบายภาษาธรรมชาติ ก็พอ เพื่อให้ผู้ดูแลเข้าใจแนวทางการแก้ปัญหา
แต่ลำดับความสำคัญและความต้องการของพวกเขาต่างออกไป ในกรณีนี้พวกเขาประเมินแล้วและตัดสินว่าไม่คุ้ม หมายความว่าต้นทุนสูงกว่าผลประโยชน์
น่าสนใจว่าอย่างน้อยในแง่มุมสำคัญหนึ่ง Chromium/Gecko/WebKit ตอนนี้ดูเหมือนจะเป็นเอนจินเบราว์เซอร์ที่ “เปิด” กว่า Ladybird เสียอีก
ส่วน Servo ถ้ามองว่าเปิดรับการมีส่วนร่วมจากภายนอกตราบใดที่ไม่ใช้ AI ก็อาจอยู่กึ่งกลาง
พอเข้าใจได้ว่าทีมที่มีเงินทุนไม่มากต้องปิดการรับ contribution เพื่อประหยัดต้นทุนแรงงาน แต่ก็รู้สึกเหมือนผู้คนยังให้การยอมรับไม่มากพอต่อทรัพยากรทางเศรษฐกิจที่ Google/Mozilla/Apple ทุ่มลงไปเพื่อทำให้ความเปิดกว้างแบบนี้เกิดขึ้นได้
เพื่อเปิดเผยอคติและประสบการณ์ส่วนตัว ตอนนี้ผมเกษียณแล้ว แต่เมื่อก่อนเคยสร้าง Chrome ที่ Google ผมเห็นเพื่อนร่วมงานหลายคนช่วยพัฒนาผู้มีส่วนร่วมจากภายนอก และตัวผมเองก็เคยทำบ้างทั้งแบบไม่เป็นทางการและผ่านโปรแกรมอย่างการฝึกงาน
ผมไม่คิดว่าเราควรต้องรู้สึกขอบคุณการสร้างการผูกขาดไปตลอดกาล
เข้าใจได้ว่าทำไมถึงตัดสินใจแบบนั้น ถ้า pull request ส่วนใหญ่เป็นโค้ดที่เขียนด้วย AI ผู้ดูแลก็สามารถใส่พรอมป์ให้ Claude Code โดยตรงได้เหมือนกัน
ไม่ว่าจะเป็นโอเพนซอร์สหรือไม่ก็ตาม ผมมองว่าเกมทั้งหมดของวิศวกรรมซอฟต์แวร์เปลี่ยนไปอย่างสิ้นเชิงแล้ว ก้อนโค้ดไม่ได้มีความหมายหรือสื่อเป็นนัยแบบเดียวกับเมื่อ 2 ปีก่อนอีกต่อไป
เมื่อหลายปีก่อน ถ้าผมส่ง PR ที่ซับซ้อนซึ่งคอมไพล์ได้และผ่านการทดสอบ นั่นหมายความว่าผมได้ลงทุนทั้งเวลาและพลังการรับรู้ไปมากขนาดนั้น ถ้าไม่ได้เข้าใจ codebase, ฟีเจอร์ หรือบั๊ก ก็คงมีโอกาสน้อยมากที่จะลงทุนแบบนั้น
ตอนนี้ต้นทุนในการได้มาซึ่งความเข้าใจนั้น โดยมากก็ยังพอๆ กับเมื่อก่อน แต่ AI ทำให้ต้นทุนในการสร้างโค้ดที่คอมไพล์ได้และผ่านการทดสอบลดลงอย่างมาก
สมาชิกชุมชนที่น่าจะมีเจตนาดีเต็มไปด้วยความยินดีที่จะช่วยในสิ่งที่ราคาถูก นั่นคือโทเคนของ Claude Code แต่เพราะมันถูกเกินไป มันจึงไม่ใช่ตัวชี้วัดที่ดีอีกต่อไปว่าได้มีการมอบสิ่งที่แพงกว่าอย่าง ความเข้าใจของมนุษย์ มาด้วย
ผมกำลังทำ side project ด้วย OpenCode และใช้เวลาไม่น้อยไปกับการเขียนพรอมป์ การตั้งค่าไฟล์ที่เหมาะสม และการอธิบายผลิตภัณฑ์กับโรดแมปที่อยากสร้าง
จากนั้นก็วนซ้ำด้วย ลูปการตรวจสอบ ที่แน่นหนา ซึ่งสามารถรันการตรวจสอบอัตโนมัติได้มากหลังการเปลี่ยนแปลงแต่ละครั้ง และทดสอบ edge case จำนวนมากด้วยมือที่ฟีเจอร์ที่สร้างขึ้นอาจทำพังได้ มันเป็นงานคนละแบบ แต่ก็ทำให้คืบหน้าได้เร็วกว่าการเขียนโค้ดด้วยมือ สิ่งสำคัญคือองค์ประกอบของลูปการตรวจสอบ
จากประสบการณ์ช่วงหลายเดือนที่ผ่านมา การเขียนโค้ดด้วย AI ก็เป็นทักษะอย่างหนึ่งเช่นกัน คุณเรียนรู้เทคนิคใหม่ๆ และเก่งขึ้นได้จากการลองทำ ซึ่งก็หมายความว่าถ้าทำดีพอ มันสามารถสร้างผลลัพธ์ที่มีคุณค่าได้
ดังนั้นผมไม่เห็นด้วยกับประโยคแรก แต่เห็นด้วยเต็มที่กับประโยคที่สอง สิ่งที่เราสูญเสียไปคือความสามารถในการแยกแยะอย่างง่ายระหว่างผลลัพธ์ที่ผ่านการคิดมาอย่างลึกซึ้ง กับผลลัพธ์ที่ถูกสร้างขึ้นมาโดยไม่คิด ในที่นี้การโฟกัสที่ การตรวจสอบต้นทุนต่ำ น่าจะช่วยได้มาก
ผมคิดว่าทุกโปรเจกต์จะค่อยๆ ไปทางนี้ การช่วยกันขัดเกลาแผนร่วมกันดูสมเหตุสมผลกว่า
ตอนที่ AI เพิ่งมาใหม่ๆ ผมกลัวว่าวันหนึ่งจะตกงาน ผมโชคดี แต่หลายคนเสียงานไปจริงๆ และมันเจ็บปวดมาก
เมื่อมีใครบางคนสูญเสียอะไรไปเพราะระบบอัตโนมัติ ไม่ว่าจะมีเหตุผลทางเศรษฐกิจอย่างไร คุณก็อดไม่ได้ที่จะเข้าข้างมนุษย์ หรืออย่างน้อยก็หวังว่าสังคมจะยังยุติธรรมกับคนที่ได้รับผลกระทบหนักที่สุด
ตอนนี้ผมเห็นว่าชุมชนกำลังได้รับผลกระทบ การฆ่า PR ไม่ได้สั่นคลอนแค่การมีส่วนร่วมด้านโค้ด แต่ยังกระทบการมีส่วนร่วมที่มองไม่เห็นอย่างไอเดียหรือสายตาจำนวนมากขึ้นที่ช่วยมองโค้ดด้วย ซึ่งมันให้ความรู้สึกแย่กว่าเดิมมาก
ผมทั้งขัดแย้งในใจ สับสน และหวาดกลัว ถึงอย่างนั้นก็ยังใช้ Claude กับ DeepSeek รวมถึงเทคโนโลยีต่างๆ, harness ที่ซับซ้อน และ MCP อยู่ดี แต่ตอนนี้ทุกอย่างดูเหมือนเป็นช่วงเปลี่ยนผ่าน ผมแค่ไม่รู้ว่ากำลังเปลี่ยนไปสู่อะไร
คำถามมากมายตอบไม่ได้เลยถ้าไม่ให้ความหมายกับชีวิต สัมผัสของความเป็นมนุษย์งั้นหรือ? มันสายไปแล้วหรือยัง? แล้วก็มีเพลงหนึ่งที่ผมชอบ แต่ดันเป็น Suno พอรู้เข้าก็ยกเลิกการกดถูกใจ ผมรู้สึกว่าตัวเองโง่บ่อยเกินไป
ขอโทษที่นอกเรื่องและพูดวกวน ผมชอบ Ladybird และยังติดสติกเกอร์ไว้บนโน้ตบุ๊กด้วย หวังว่ามันจะไปได้ดี
มันเหมือนอยู่กลางพายุทอร์นาโด ถึงอย่างนั้นการปิดหน้าจอ นั่งลงที่โต๊ะ แล้วค่อยๆ คิดอย่างสงบโดยนึกถึง หลักการแรก ก็ช่วยได้
ขอยืมคำพูดของ Obama มาใช้ว่า “ท้ายที่สุดแล้วความจริงจะตามมาทัน”
ถึงจะมีคำพูดมากมาย แต่ iOS ก็ไม่ได้ปล่อยฟีเจอร์และการแก้ไขระดับ 10 ปีในทุกปีอยู่ดี ไม่มีใครทำได้แบบนั้นจริงๆ และกลับกันเรายังเห็นเสียงบ่นว่าฟีเจอร์เดิมพังอีกต่างหาก ดังนั้นคำกล่าวที่ว่าเรามีผลิตภาพเพิ่มขึ้น 10 เท่าจึงไม่อาจเป็นจริงได้ และข้อเท็จจริงนี้สุดท้ายก็จะตามเรามาทัน
เราต้องคิดแบบมนุษย์ และต้องจำไว้ว่าหลายคนมีความผูกพันทางอารมณ์อยู่มาก คนจูเนียร์ต้องการให้สิ่งนี้เป็นโอกาสที่ทำให้พวกเขาโดดเด่นในตลาดที่ปฏิเสธพวกเขา CEO ทั้งหลายเดิมพันกับ AI ไปแล้วและไม่อยากถอยกลับ คนซีเนียร์อยากส่งสัญญาณว่าตัวเองยังไม่หมดความสำคัญ บริษัท AI ก็จะทำให้วาทกรรมปนเปื้อน แต่หมอกควันนี้สุดท้ายจะจางไป
โดยมากมันจบลงที่ความเห็นที่ไม่เป็นที่ต้องการ ความพยายามยึดครองแบบเป็นปฏิปักษ์ การดึงคุณค่าออกไป ดราม่าทั่วไป และโดยรวมคือ ภาระด้านปฏิบัติการ ที่ถูกเพิ่มเข้ามาบนงานเขียนโค้ด
มันไม่ได้เป็นแบบนี้เสมอไป แต่โมเดลการพัฒนาโอเพนซอร์สแบบเสรีสไตล์ GitHub และการขจัดแรงเสียดทานแทบทั้งหมด ได้สร้างค่าตั้งต้นใหม่ขึ้นมาอย่างชัดเจน
โมเดลนั้นเดิมทีก็ยั่งยืนไม่ได้อยู่แล้ว แต่เพราะอัตราการหมดไฟต่ำพอ มันเลยยังพอประคองต่อได้ด้วยการแทนที่คนที่เหนื่อยล้าด้วยมนุษย์เพิ่มอีกจำนวนหนึ่ง
AI ทำให้อัตราการหมดไฟสูงกว่าอัตราการทดแทนไปแล้ว ดังนั้นจึงมีแนวโน้มสูงที่โปรเจกต์ต่างๆ จะเลือกจุดยืนแบบนี้หรือใกล้เคียงกันมากขึ้น
ผมเป็นทั้งคนทำงานสร้างสรรค์และโปรแกรมเมอร์ ไม่ชอบเห็นสิ่งที่เกิดขึ้นในบางชุมชน แต่ก็ยังใช้เอเจนต์ในการพัฒนา เช่นเดียวกับที่ครั้งหนึ่งหลีกเลี่ยง Google และ Stack Overflow ได้ยาก มันดูเหมือนว่า LLM ก็มี ช่วงเวลาก่อนและหลัง ที่ชัดเจนเหมือนกัน
ผมคงไม่มีอะไรที่เป็นประโยชน์มากไปกว่านี้จะเสริมได้ แต่แค่อยากบอกว่าคุณไม่ได้อยู่คนเดียวที่รู้สึกขัดแย้งแบบนี้ ของใหม่มักเป็นแบบนั้นเสมอ ในบางด้านมันให้ประโยชน์มหาศาล แต่ในอีกด้านกลับเหมือนกำลังลอกความเป็นมนุษย์ออกไป บางคนใช้มันสร้างแต่ภาพลักษณ์ลวงกับขยะ แต่บางคนก็ได้ความสามารถใหม่และสร้างสิ่งที่ดีกว่าเดิม น่าเสียดายที่ดูเหมือนไม่มีความจริงสากลที่ใช้ได้กับทุกกรณี
อ่านแล้วรู้สึกค้างคาแปลก ๆ เพราะผู้เขียนมีแนวโน้มจะทำ PR ขนาดใหญ่ที่ไม่ใช่เรื่องเล็กเกิน 1,000 บรรทัดอยู่บ่อย ๆ บางทีก็หลายอันต่อวัน และมัก merge ภายในวันเดียวกันโดยไม่มีรีวิว
ต่อให้ไม่นับประเด็น LLM ก็ยังเป็นแบบนั้นอยู่ดี ไม่รู้ว่ามีกี่เปอร์เซ็นต์ที่ได้ความช่วยเหลือ แต่ถึงจะเป็น 0% ก็ยังไม่ใช่ความเร็วในการพัฒนาที่ทำให้ฉันสบายใจ
“ประเด็นสำคัญไม่ใช่ว่าโค้ดถูกพิมพ์ด้วยมือหรือไม่ สิ่งสำคัญคือหลังจากโค้ดเข้าไปอยู่ในเบราว์เซอร์แล้ว ใครเป็นคนรับผิดชอบมัน Ladybird กำลังกลายเป็นเบราว์เซอร์สำหรับผู้ใช้จริง คนที่นำการเปลี่ยนแปลงเข้ามาต้องเป็นคนตัดสินว่าการเปลี่ยนแปลงนั้นเป็นส่วนหนึ่งของโปรเจ็กต์ และต้องเป็นคนที่รับผิดชอบต่อผลลัพธ์นั้น”
ที่บริษัทมีแพลตฟอร์มโอเพนซอร์สตัวหนึ่งที่ใช้งานมาหลายปี และใช้เวอร์ชัน Enterprise แบบเสียเงินอยู่ด้วย มีช่องโหว่ด้านความปลอดภัยประหลาดมากหลุดเข้าไปในแพลตฟอร์มนั้น พอไปดูแล้วก็เห็นได้ว่า AI เข้ายึดโครงการไปแล้ว
ไม่ว่าจะประกาศไว้ชัดเจนหรือไม่ แค่ดู commit log ก็เห็นชัดจากปริมาณและความถี่ น่าผิดหวังมาก
[1] https://github.com/awesomekling
LLM อาจเป็นหนึ่งในเหตุผลที่ทำให้ Ladybird ตัดสินใจแบบนี้ แต่ไม่ใช่เหตุผลเดียวที่เป็นไปได้ ตัวอย่างเช่น SQLite ก็พัฒนาในลักษณะนี้มาแทบจะตั้งแต่แรก
ดูเหมือนแต่ละโครงการก็มีวิธีของตัวเอง
ใช้ไลเซนส์ MIT และผู้ดูแลก็ขอบคุณสำหรับรายงานบั๊กเสมอ แต่โค้ดทั้งหมดของโปรเจ็กต์นี้เขียนโดยคนเพียง 3 คนเท่านั้น
นี่เป็นการขยับที่สมเหตุสมผลอย่างยิ่งเพื่อปกป้องเวลาและโปรเจ็กต์ของพวกเขา
ความคิดเห็นจาก Lobste.rs
ช่วงนี้การทำ รีวิวคอนทริบิวชัน ใน clang น่าสังเวชมาก มี PR ขยะไหลเข้ามาไม่รู้จบ ผู้คนเก็บร่องรอยที่เห็นได้ชัดเก่งขึ้น แต่ส่วนใหญ่ก็ยังพอดูออกอยู่ดี และต้องเสียเวลาไปกับการคัดกรองพวกนั้น
ต่อให้มีคนยอมรับว่าใช้ AI และเขียนอธิบายว่าใช้ยังไง ก็ยังต้องกลับไปตรวจอีกว่าพูดจริงหรือแค่ลดระดับการใช้งานลงเพื่อให้ PR แย่ ๆ ผ่าน
จนถึงตอนนี้ผมเห็น PR แบบนี้มาเยอะมากแล้ว แต่ไม่คิดว่าเคยเห็น PR สไตล์ vibe coding อันไหนที่ดีจริงเลย บางอันก็พอ “ใช้ได้” และคนเขียนก็ลงมือทำงานเองต่อบ้าง แต่ส่วนใหญ่หายเงียบไป และที่เหลือก็เห็นชัดว่าผิดตั้งแต่แนวคิดการเขียนโค้ดพื้นฐาน โดยไม่ต้องมีความรู้ภายในของ clang ก็ยังดูออก
ที่แย่กว่านั้นคือสคริปต์ที่ทำสายพาน fuzzer→bug→LLM→PR แบบอัตโนมัติ ซึ่งมักเข้าใจบั๊กจริงผิดอย่างหนัก “แก้” แบบพัง ๆ แล้วแนบเทสต์แย่ ๆ มา หรือไม่ก็ไม่ใส่เคสที่เดิมล้มเหลวอยู่แล้วด้วยซ้ำ
สุดท้ายมันทำให้ความอยากทุ่มเวลาเพื่อช่วยให้ผู้มีส่วนร่วมหน้าใหม่พัฒนาความสามารถลดลงไปด้วย เวลาเห็นชื่อที่ไม่คุ้นส่ง PR มาแก้ crash ก็ต้องเริ่มจากสงสัยก่อนว่านี่เป็นการเสียเวลาหรือเป็นคนที่จะกลายมาเป็นผู้มีส่วนร่วมจริง ๆ
คนที่แค่โยนขยะใส่โปรเจ็กต์แบบนี้ไม่ได้สนใจทั้งการมีส่วนร่วมและการเรียนรู้ และส่วนใหญ่ดูเหมือนแค่อยากใส่บรรทัดอย่าง “มีส่วนร่วมกับ clang” ลงในเรซูเม่
หลังจากนั้นก็ยังกลับมาถามเรื่อย ๆ ว่า “ทำไมรายชื่อยังไม่อัปเดต? ทำไมยังไม่มีชื่อฉัน?” แล้วพอเว็บไซต์อัปเดตเสร็จก็หายไป
แต่ก็ว่าไม่ได้ เพราะตอนเด็ก ๆ ผมก็เคยโง่คล้าย ๆ กัน เคยเห็นว่ามีคนบอกว่าสามารถทำ mirror เว็บไซต์ของคนดังในวงการโอเพนซอร์สได้ ผมก็เลยทำ mirror แล้วส่งเมลไปขอให้ใส่ชื่อไว้ในรายชื่อด้วย อีกทั้งยังเคยสมัครเมลลิงลิสต์นักพัฒนา nmap เพราะคิดว่าจะเป็น 1337 hax0r ทั้งที่ไม่เคยส่งแพตช์เลย
การนิยามปัญหานั้นชัดเจนสำหรับทุกคน ตลอดหลายทศวรรษที่ผ่านมาโปรเจกต์โอเพนซอร์สเรียนรู้ว่าจะไว้ใจใครผ่านการมีส่วนร่วมในโค้ด ผู้คนลงมือทำงาน รับผิดชอบต่อการเปลี่ยนแปลง และยังอยู่กับโปรเจกต์ต่อไป ความไว้วางใจจึงเกิดจากตัวงานเอง
แต่ผมมองว่าวิธีแก้นี้เป็นเวอร์ชันที่แย่กว่าอย่างชัดเจนเมื่อเทียบกับการ ห้ามการมีส่วนร่วมจาก LLM ที่โปรเจกต์ Zig เลือกใช้
เมื่อเครื่องมือ AI เปลี่ยนความคุ้มค่าทางเศรษฐกิจอย่างรวดเร็ว ตอนนี้ PR ก็ไม่ได้บอกอะไรเกี่ยวกับผู้ส่งได้มากเท่าเมื่อก่อนอีกแล้ว แพตช์ใหญ่เคยหมายถึงความพยายามมาก และเป็นตัวชี้วัดตัวแทนของเจตนาดีได้พอสมควร แต่ตอนนี้สมมติฐานนั้นใช้ไม่ได้แล้ว
สิ่งที่น่ากังวลคือ โอเพนซอร์สเป็นธุรกิจที่ยาก และควรใช้ประโยชน์จากข้อได้เปรียบที่มีคุณค่าให้มากที่สุด ผู้มีส่วนร่วมสามารถนำคุณค่ามหาศาลมาให้แทบจะฟรีอยู่แล้ว (contributor poker) และยังสำคัญมากในฐานะช่องทางการจ้างงานด้วย แต่การปฏิเสธทั้งหมดนี้ดูเป็นการตัดสินใจที่บ้าบิ่น
คุณอาจเถียงได้ว่า LLM สามารถเติมช่องว่างนั้นได้ แต่ประการแรก คุณสามารถห้ามใช้ LLM ได้เฉพาะกับ PR จากผู้มีส่วนร่วมที่ยังไม่น่าเชื่อถือก็ได้ และประการที่สอง ต่อให้เป็น LLM ที่ดีที่สุดก็มีต้นทุน ราคาโทเคนก็กำลังขึ้น โค้ดก็ยังต้องรีวิวอยู่ดี และท้ายที่สุดมันก็ไม่อาจกลายเป็นผู้มีส่วนร่วมแกนหลักที่ได้รับความไว้วางใจและรับผิดชอบบางส่วนของโค้ดเบสได้
ถ้าตัดการไหลเข้าของโค้ดจาก PR ออกไป เมื่อเวลาผ่านไปผู้มีส่วนร่วมน้อยรายจะกลายเป็นเจ้าของโค้ดทั้งหมด และทำให้โปรเจกต์ทำ license rugpull ได้ง่ายขึ้น ถ้าความเป็นเจ้าของลิขสิทธิ์กระจายตัวดี เรื่องแบบนี้จะทำได้ยากกว่า
โดยรวมแล้วไม่ดีเลย มันทำให้โอเพนซอร์สกลายเป็นโมเดลธุรกิจที่มีปัญหามากขึ้นโดยไม่จำเป็น ทำให้การจ้างผู้มีส่วนร่วมแกนหลักยากขึ้น และรวมศูนย์ความเป็นเจ้าของโค้ดไว้กับคนไม่กี่คน นี่คือสูตรสำเร็จของหายนะอย่างชัดเจน จนทำให้สงสัยว่านี่เป็นแค่ความผิดพลาดธรรมดา หรือมีผู้สนับสนุนบางรายของ Ladybird กำลังเล่นเกมประหลาดอะไรอยู่
ผมสงสัยจริง ๆ ว่าเบื้องหลังการเปลี่ยนแปลงครั้งนี้คืออะไร โปรเจกต์ที่เคยอวดจำนวนผู้มีส่วนร่วมหน้าใหม่ที่หลากหลายในช่วงต้นของรายงานสถานะประจำเดือน กลับหันหัวเรือแบบฉับพลันขนาดนี้ ถือเป็นการเปลี่ยนทิศทางที่รวดเร็วมาก คำอธิบายที่ออกมาตอนนี้อย่างน้อยก็ดูเหมือนยังไม่ครบถ้วน
ทั้ง Zig และ Ladybird ต่างกำลังพยายามหาทางเดินต่อไปจากอนาคตที่เราไม่ต้องการ ตลอดหลายปีที่ผ่านมาเราไม่รู้อะไรเลย และพูดตามตรงก็ไม่คิดว่าอนาคตแบบนี้จะมาถึง ตอนนี้มันไม่ชัดเจนเลยว่า “สิ่งที่ถูกต้อง” คืออะไร
สิ่งที่ผมอยากถาม Zig คือ เราแยก PR จาก LLM กับ PR ที่มนุษย์ทำเอง ไม่ออก คุณคัดงานขยะที่ใช้แรงน้อยออกได้ก็จริง แต่ถ้าจะ “ห้าม AI” ก็ต้องเหมือนผ่านการทดสอบแบบทัวริง ซึ่งถ้าเป็นผมกับไลเซนส์ Claude Pro ก็น่าจะผ่านได้สบาย
สิ่งที่ “ห้าม AI” ทำจริง ๆ คือ เปิดทางให้โจมตีคนและชื่อเสียงของเขาได้ เมื่อมีใครส่งโค้ดจาก LLM มาแล้วอ้างว่าทำเองด้วยมือ แต่ถูกจับได้ คุณอยากเอาเวลาไปลงกับเรื่องแบบนี้จริงหรือ? มันเหมือนจะมีคนแบบ Karl Jobst โผล่มาคอยจับคนที่ใช้ LLM แต่แกล้งทำเป็นเขียนโค้ดเอง
มันไม่ได้หยุด PR จาก LLM ได้จริง แค่เปลี่ยนเกมให้กลายเป็น “จับให้ได้ถ้าจับได้” เท่านั้น ตอนเห็น Andreas ตัดสินใจใน Ladybird แบบที่เกือบจะเป็น rugpull ตอนแรกผมขนลุก แล้วต่อมาก็คิดว่าอย่างน้อยก็ใจถึง ปัญหาเรื่องความช่วยเหลือจาก LLM กับความไว้วางใจนั้นใหญ่มากจริง ๆ และผมอยากเห็นทั้ง Zig และ Ladybird คิดนอกกรอบกับเรื่องนี้
แต่ในความเป็นจริงเขาเป็น Designator และเท่าที่ผมอ่าน สถานะนี้จะอยู่กับเขาตลอดชีวิต เว้นแต่จะลาออกหรืออยู่ในสภาพไร้ความสามารถ Designator ตัดสินใจด้วยเสียงข้างมาก แต่เมื่อมีแค่ 2 คนก็แปลว่าต้องเห็นพ้องกันทั้งคู่ และคนกลุ่มนี้เป็นผู้แต่งตั้งหรือปลด Directors รวมถึงต้องให้ความเห็นชอบกับการแก้ไขข้อบังคับด้วย
นั่นหมายความว่าเขามีสิทธิยับยั้งโดยพฤตินัยต่อองค์กรไม่แสวงหากำไรนี้โดยแทบไม่มีการถ่วงดุล Andreas ก็เช่นกัน แต่ Andreas เป็นคนที่สร้างงานส่วนใหญ่ขึ้นมา มีส่วนร่วมกับโปรเจกต์ และไม่ใช่มหาเศรษฐี ส่วน Wanstrath เป็นมหาเศรษฐี บริจาคเพียงเศษเสี้ยวเล็กน้อยของทรัพย์สิน และไม่ได้มีส่วนร่วมในการดำเนินงาน แต่กลับมีอำนาจเท่ากัน
ถ้าไม่มีเหตุผลทางกฎหมายที่ดีบางอย่างที่ผมมองข้ามไป มันก็ฟังดูไม่ใช่โครงสร้างการกำกับดูแลที่ดีสำหรับโปรเจกต์โอเพนซอร์ส
ผมกังวลว่าในระยะยาวโปรเจกต์ที่ปิดรับการมีส่วนร่วมไปไม่นานนี้จะเป็นอย่างไร สักจุดหนึ่งคนแกนหลักที่ได้รับความไว้วางใจบางส่วนก็จะจากไป และถ้าไม่มีผู้มีส่วนร่วมระยะยาวที่ผ่านการพิสูจน์แล้ว ก็อาจไม่มีผู้สืบทอดที่ชัดเจน
เส้นทางพื้นฐานอาจนำไปสู่ ภาวะหมดไฟและโปรเจกต์ที่ถูกทิ้งร้าง ได้ จึงหวังว่าจะหาวิธีเอาชนะเรื่องนี้ได้
ผมไม่มองว่านี่เป็น ภาวะผู้นำ ไม่ว่าประเภทไหน มันไม่ใช่ก้าวหนึ่งไปในทิศทางที่ถูกต้อง และไม่ใช่ไอเดียเกี่ยวกับวิธีที่เราจะอยู่ร่วมกันได้
ผมเข้าใจว่าแรงกดดันนั้นมีอยู่จริง แต่ก็น่าผิดหวังที่การตอบสนองนี้ให้ความรู้สึกทั้งประชดประชันและยอมแพ้ มากกว่าจะมีชีวิตชีวาและมีความหวัง
ส่วนที่บอกว่า “เพื่อเป็นส่วนหนึ่งของการเปลี่ยนแปลงครั้งนี้ เราจะปิด pull request สาธารณะทั้งหมดที่เปิดอยู่ในปัจจุบัน” นั้นน่าตกใจมาก
หลายปีก่อนเคยมีโปรเจกต์หนึ่งปิด PR ของผมเพราะตัดสินใจว่าไม่มีทรัพยากรพอจะรีวิว PR ซึ่งมันเจ็บพอตัวและไม่ยุติธรรมกับผู้มีส่วนร่วมที่ลงแรงไปกับ PR นั้น
เข้าใจเหตุผลที่เสนอมา แต่ก็กังวลกับการตัดสินใจนี้ ไม่ได้แปลว่ามันต้องแย่แน่ ๆ และถ้าเป็นแค่ชั่วคราวแล้วค่อยหาจุดประนีประนอมแบบอื่นในภายหลังก็อาจจะพอรับได้ แต่ก็ยังน่ากังวลอยู่
นี่ก็ไม่ใช่สัญญาณเตือนครั้งแรกเหมือนกัน การเขียน Rust ใหม่โดยมี LLM ช่วย ก็ให้ความรู้สึกคล้ายกัน แม้จะทำอย่างระมัดระวังกว่า Bun พอสมควร โดยแยกเป็นคอมโพเนนต์ขนาดที่รีวิวได้ มีอินพุตและเอาต์พุตชัดเจน และรันคู่ขนานกับคอมโพเนนต์เดิมเพื่อจับความไม่ตรงกัน ถึงอย่างนั้นก็ยังไม่ใช่วิธีที่อยากเห็นในบราวเซอร์เอนจิน
หวังว่า Ladybird จะไปได้ดี อยากเห็นบราวเซอร์เอนจินตัวใหม่ท้าทายโครงสร้างกึ่งผูกขาด แต่ถ้าคิดถึงกรณีที่ Ladybird หลุดทางไป ก็ยังน่ายินดีที่ Servo ซึ่งหยุดนิ่งมาหลายปี กำลังก้าวหน้าได้ดีเช่นกัน
ใช้ โค้ดขยะจาก AI กับการพัฒนา Rust แล้วก็อยู่ฝั่งที่สนับสนุน DHH ซึ่งดูเป็นไปทางคนขาวเป็นใหญ่และต่อต้าน LGBT แถมยังดูค่อนข้างก้าวร้าวด้วย ไม่คิดว่าโปรเจกต์นี้จะไปได้ไกล
ถ้าไม่มี ช่องทางเข้าสำหรับผู้มีส่วนร่วม จากภายนอก ก็น่าจะพลาดอะไรไปเยอะ ถึงแม้จะต้องการความมุ่งมั่นที่จริงจังกว่าแค่เดินผ่านมาแล้วส่ง PR มาก็ตาม
เพราะแบบนั้นเวลาอยากเพิ่มนักพัฒนา ก็จะมีฐานคนที่รู้จักโค้ดเบสให้เลือกมากขึ้น และองค์กรภายนอกก็อาจเข้ามาแก้ความต้องการที่ทีมแกนหลักไม่ได้จัดเป็นลำดับความสำคัญได้ด้วย เรื่องนี้ช่วยต่อการนำไปใช้และลดภาระงานได้เช่นกัน
ดูเหมือนว่าไม่ควรติด แท็ก vibecoding ให้โพสต์นี้ การเอาเหยื่อของ vibe coding ไปอยู่ใต้แท็กเดียวกับคนที่โปรโมตพฤติกรรมนั้นมันแปลกในระดับพื้นฐาน