- GitHub และ Microsoft ประกาศ พับลิกพรีวิวของ GitHub Copilot Agent และมีการทดสอบให้เอเจนต์ตัวนี้ สร้าง PR อัตโนมัติ จริงในรีโพซิทอรี .NET Runtime
- แต่ PR เหล่านี้มีทั้ง การแก้ไขที่หละหลวมหรือไม่จำเป็น ทำให้ผู้รีวิวต้องลำบาก ขณะที่ผู้ใช้ Reddit ก็มองสถานการณ์นี้เป็นภาพที่ ทั้งขำทั้งขม
- ตัวอย่าง PR:
- PR #115762 – เพิ่มการเช็ก Null ซ้ำโดยไม่จำเป็นในโค้ดที่เช็กไว้แล้วตรงการเรียก
string.Concat - PR #115743 – เสนอการรีแฟกเตอร์เงื่อนไขที่ไม่มีผลอะไร
- PR #115733, PR #115732 และอื่น ๆ ก็อยู่ในบริบทคล้ายกัน
- PR #115762 – เพิ่มการเช็ก Null ซ้ำโดยไม่จำเป็นในโค้ดที่เช็กไว้แล้วตรงการเรียก
- ผู้เขียนบอกว่า “ถ้านี่คืออนาคตของวงการ ผมก็พร้อมจะลงจากรถแล้ว” พร้อมแสดง ความเหนื่อยล้าและความกังขาต่อการนำ AI มาใช้
- แต่ในขณะเดียวกันก็ย้ำว่า “ผมรู้สึกเห็นใจพนักงานที่ต้องรับหน้าที่รีวิว” และเสริมว่าสถานการณ์นี้อาจเป็น ภาระที่เกิดจากคำสั่งให้นำ Copilot มาใช้จากผู้บริหาร
"schadenfreude(ความสะใจ)" ของผมมุ่งไปที่ผู้บริหาร Microsoft ที่โหมกระแสเกินจริงเรื่อง AI โปรดให้ความเคารพนักพัฒนาด้วย
- schadenfreude เป็นคำที่มาจากภาษาเยอรมัน แปลตรงตัวได้ว่า “ความสุขที่เกิดจากอันตราย” หรือก็คือ “ความรู้สึกพอใจลึก ๆ จากความโชคร้ายของคนอื่น”
สรุปคอมเมนต์สำคัญ
1. PR ที่ AI เขียนไม่แม่นยำ และแค่ ‘เดา’ ซ้ำ ๆ โดยไม่เข้าใจบริบท
- เสนอการแก้ไขโดยไม่เข้าใจว่าโค้ดใน PR ทำอะไรจริง ๆ
- วนลูปไม่รู้จบแบบ แก้ข้อผิดพลาดซ้ำ → โค้ดยังผิด → แก้อีกรอบ…
- มีคนมองว่ากระบวนการแบบ “แก้แล้วครับ” → “ยังผิดอยู่” → “คราวนี้แก้จริงแล้ว” เหมือนแพตเทิร์นนักพัฒนาจูเนียร์
2. ยิ่งเป็นปัญหาซับซ้อนกลับยิ่งเสียเวลามากกว่าเดิม
- ช่วยได้กับการแก้ไขง่าย ๆ แต่ ใช้ไม่ได้กับปัญหาซับซ้อนที่อยากประหยัดเวลาจริง ๆ
- ต้องเข้าใจปัญหา → เข้าใจสิ่งที่ Copilot ทำ → เปรียบเทียบ → ตรวจสอบ → แล้วค่อยจัดการเอง
- ในทางปฏิบัติ ลงมือแก้เองเร็วกว่า
3. แนวคิด ‘AI ทำได้ทุกอย่าง’ ของผู้นำองค์กรกำลังผลักนักพัฒนาออกไป
- ข้อความแบบ “ใช้ Copilot แล้วจะไม่ตกขบวน” ห่างไกลจากความจริงของนักพัฒนาหน้างาน
- เวลารีวิว PR นานขึ้น และความรับผิดชอบก็ถูกผลักกลับมาที่นักพัฒนา
- มีความกังวลเรื่อง ‘ลูปการเรียนรู้ของ AI เพื่อ AI’ ที่ AI เรียนจากโค้ดที่ Copilot สร้าง แล้วทำให้คุณภาพโค้ดยิ่งแย่ลง
4. AI แค่ให้ ‘คำตอบผิดอย่างมั่นใจ’ แต่ไม่ได้มั่นใจว่ามันถูกจริง
- ต่อให้ได้รับฟีดแบ็กว่าผิด ก็ยังตอบว่า “แก้แล้วครับ!” แล้วเสนอการแก้ไขที่ประหลาดกว่าเดิม
- มันไม่ตัดสินว่า “โค้ดนี้โอเคอยู่แล้ว ไม่ต้องแก้”
- ยังมีคนชี้ว่านี่อาจเป็นการออกแบบเพื่อเลี่ยงความรับผิดชอบทางกฎหมาย
5. การยัดเยียดให้ใช้ AI อย่างต่อเนื่องกำลังทำลายประสบการณ์ของนักพัฒนา
- การทดลองใช้ AI เดินหน้าต่อเพราะคำสั่งผู้จัดการหรือการประเมินผลงาน
- นักพัฒนาบ่นถึงความเหนื่อยล้าราวกับตัวเองกลายเป็นพี่เลี้ยงให้ AI
- มีมุมมองในแง่ร้ายว่าถ้ากระแสนี้ยังไปต่อ “นักพัฒนาจะเหนื่อยกับ AI จนออกจากวงการ”
ประโยคเด่น ๆ
- “AI เหมือนเด็กฝึกงานที่เดาผิดซ้ำ ๆ แต่ยังมั่นใจในตัวเองเต็มที่”
- “แทนที่จะเสียเวลารีวิวโค้ดจาก Copilot ผมเขียนใหม่เองยังดีกว่า”
- “นี่คือสภาวะ reverse centaurs ที่นักพัฒนากลายเป็นฝ่ายช่วยเครื่องจักร”
- คำที่ Cory Doctorow ใช้ หมายถึง “เราไม่ใช่มนุษย์ที่ได้เครื่องจักรมาช่วย แต่เป็นมนุษย์ที่ถูกบังคับให้ช่วยเครื่องจักร”
- “Copilot ก็เหมือนนักพัฒนาที่เอาพลาสเตอร์คุณภาพแย่ไปแปะมั่ว ๆ เพียงแต่มันทำอัตโนมัติ เลยกลายเป็นพลาสเตอร์น่าปวดหัวนับพันชิ้น”
- “ดูเหมือนค่าเริ่มต้นของ LLM คือ ‘อาจผิดได้ แต่ไม่เคยไม่มั่นใจ’”
12 ความคิดเห็น
เวิร์กโฟลว์แบบอะซิงโครนัสที่โยนปัญหาเข้าไปแล้วถ้าคำตอบผิดก็ทิ้ง ทำให้ประสิทธิภาพเพิ่มขึ้นมาก แต่แบบนี้ก็คล้ายกับเครื่องมือแบบสแตติกไม่ใช่เหรอ? ถ้ามองว่าเป็นเครื่องมือวิเคราะห์แบบสแตติกที่พัฒนาไปมากแล้ว ก็ถือว่าเป็นเพื่อนคู่ใจที่ดี พูดตามตรงคือวิเคราะห์ก็เร็วและรู้มากกว่าวิศวกรจูเนียร์ด้วย
ก็ใช้ AI อยู่นะ แต่เพราะมันโง่ ถ้าแก้สิ่งที่มันทำพลาดให้ถูกไม่ได้ก็เอาไปทำจริงให้ถูกต้องไม่ได้ พอเห็นคนทำแบบ vibe coding ก็มีแต่โค้ดที่เต็มไปด้วยข้อผิดพลาด...
ทุกครั้งที่ใช้ LLM ผมมักจะเจอประสบการณ์แบบนี้ ส่วนที่มันทำไม่ได้ ต่อให้ชี้ให้เห็นซ้ำๆ แบบไม่รู้จบ มันก็ยังทำไม่ได้อยู่ดี
สุดท้ายก็เหนื่อยจนต้องมานั่งวิเคราะห์และแก้เอง พอประสบการณ์แบบนี้สะสมไปเรื่อยๆ ไม่ว่าจะเป็น LLM หรืออะไรก็ดูเหมือนขยะไปหมด จนไม่อยากใช้อีกเลย
ชวนให้นึกถึงเว็บตูนที่ AI กลับเป็นฝ่ายพรอมป์ตให้มนุษย์เขียนโค้ดเลยครับ
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
ดูเหมือนว่านี่จะยังเป็นปัญหาที่เกิดขึ้นต่อไป เว้นแต่ AI จะสามารถแก้ปัญหาและเรียนรู้ไปพร้อมกันได้เหมือนมนุษย์จริง ๆ
ถ้าทำตามเดดไลน์กับข้อกำหนดได้ครบ เวลาจะเขียนโค้ดก็ไม่ค่อยสำคัญหรอกว่าใช้ AI ไหม หรือไม่ใช้แม้แต่ IDE แล้วทำเท่แบบลูกผู้ชายด้วย Notepad อย่างเดียวหรือเปล่า
ตอนที่คิดว่านี่เป็นแค่เทคโนโลยีใหม่ ก็แค่มองด้วยความสงสัยปนสนใจเท่านั้น
แต่ตอนนี้เมื่อผู้จ้างงานลงมือปรับลดการจ้างงานและลดค่าจ้างจริง ๆ โดยอ้างเทคโนโลยีแบบนี้เป็นเหตุผล ก็ทำให้รู้สึกไม่ค่อยดีเอาเสียเลย..
ดูเหมือนว่าตอนนี้ยังเป็นช่วงเปลี่ยนผ่านอยู่ เลยมีเรื่องวุ่นวายเกิดขึ้นหลายอย่างครับ
ต่อไปอาจจะเปลี่ยนไปในทางที่ดีขึ้น หรืออาจจะเป็นแบบนี้ต่อเนื่องก็ได้ เพราะงั้นการได้ดูว่ามันจะเปลี่ยนไปยังไงก็น่าสนุกดีเหมือนกัน 555
ผมกำลังติด Gemini เข้ากับ Github เพื่อให้ช่วยรีวิว PR อยู่ แล้วก็มีจังหวะแบบนั้นเกิดขึ้นบ่อยพอสมควรเลยครับ
ทั้งที่เช็ก
nullไปแล้วในบรรทัดด้านบนแท้ ๆ แต่มันกลับรีวิวให้เพิ่มบรรทัดเดิมที่อยู่ข้างบนขึ้นมาอีกแบบเป๊ะ ๆ ว่ากำลังใช้งานโดยไม่เช็กnull.ความรู้พื้นฐาน รูปแบบการทำงาน ผลลัพธ์ที่คาดหวัง และรูปแบบของผลลัพธ์ที่คนเรารับรู้ได้เองตามธรรมชาติระหว่างทำงานนั้น
คงไม่อาจเขียนทั้งหมดลงไปในพรอมป์ต์ได้ และถึงจะเขียนได้จริง ก็ยังทำให้คิดเหมือนกันว่า
การทำให้งานเป็นอัตโนมัติด้วยอัลกอริทึมแบบดั้งเดิมก่อนยุคดีปเลิร์นนิง น่าจะเป็นแนวทางที่สมจริงกว่าการใช้ AI ที่ซับซ้อนอย่าง LLM.
พอลองใช้ดูแล้ว แม้ว่า vibe coding กับ coding agent จะมีส่วนที่สะดวกจริง แต่ถ้าอยากให้สะดวกก็ต้องส่งพรอมป์ต์แบบละเอียดและเข้มงวดมากอยู่ดี แล้วตั้งแต่แรกก็มีหลายโปรเจกต์ที่ไปกันไม่ค่อยได้ตามลักษณะของโปรเจกต์ด้วยนะ ถ้าเป็นเว็บเซิร์ฟเวอร์โครงสร้าง MSA ที่ฟังก์ชันต่าง ๆ ถูกแยกย่อยไว้อย่างกระชับและชัดเจน มันจะทำงานได้ดี แต่ถ้าจะให้ AI ไปแก้โลจิกซับซ้อนใน big monolith ที่มีโมดูลจำนวนมากผูกกันอยู่ ก็ต้องวางแผน task อย่างละเอียดมากและส่งพรอมป์ต์ให้ดีมาก ๆ
ความคิดเห็นจาก Hacker News
มีการแชร์ความน่าขำของสถานการณ์ที่ทุกคอมเมนต์มีข้อความ "Help improve Copilot by leaving feedback using the or buttons" ติดอยู่ แต่กลับไม่เคยเห็นว่ามีฟีดแบ็กจริง ๆ ถูกแนบมาสักครั้ง พร้อมเล่าประสบการณ์ว่าถ้าตั้งค่า system prompt สำหรับใช้งาน LLM ไม่ดี เรื่องแบบนี้เกิดขึ้นบ่อย ตัวอย่าง PR ที่ตลกที่สุดคืออ้างว่าจะแก้ test ที่ล้มเหลวด้วยการลบ test case ทิ้งไปเลย คอมเมนต์ทิ้งไว้ หรือเปลี่ยน assertion เฉย ๆ มีการคาดเดาว่าโมเดลของ Googles และ Microsofts ดูจะเจอสถานการณ์แบบนี้บ่อยกว่า OpenAIs และ Anthropics และเหมือนความต่างของกระบวนการภายในแต่ละบริษัทสะท้อนออกมาในผลลัพธ์ด้วย มีการแนะนำกระบวนการใน PR จริงที่มนุษย์ต้องทักท้วงเพิ่มอีก 3 ครั้งก่อนจะยอมแพ้ แทบจินตนาการอารมณ์ของคนที่ต้องรีวิว PR พวกนี้ไม่ออก เหมือนต้องรับมือกับนักพัฒนาจบใหม่ที่ไม่ค่อยฟัง แต่กรณีนี้คือไม่มีความเข้าใจบริบทเลย มีตัวอย่าง PR หนึ่งที่ 90% เต็มไปด้วย "Check failure" จนแทบดูโค้ดหรือ diff ไม่ได้ และใน unit test ก็มีแต่ข้อความว่า "Test expressions mentioned in the issue" ซึ่งชวนหดหู่ พร้อมความเห็นตรงไปตรงมาว่า ถ้าสถานการณ์นี้ไม่ได้ทรมานฝั่งมนุษย์มากขนาดนี้ มันก็คงตลกมากจริง ๆ
คำเปรียบเทียบกับนักพัฒนาจบใหม่ดูเกินจริงไปมาก ตัวเองก็ทำงานกับนักพัฒนาจบใหม่อยู่ แต่พวกเขาไม่ได้ทำพลาดประหลาด ๆ แบบ LLM บ่อยนัก ไม่ต้องคอยประคองมาก และเรียนรู้ได้ไว LLM เป็นเครื่องมือเสริมที่ใช้ได้ดีถ้าใช้อย่างระมัดระวัง ช่วยเรื่องความเร็วได้ และเป็นคู่คิดระดมไอเดียก็พอใช้ได้ แต่ไม่น่าแทน intern หรือนักพัฒนาจริง ๆ ได้
ตอนเริ่มเข้าสู่วงการ software engineering ช่วงปลายยุค 80 ยังมีความสนุกอยู่ แต่เดี๋ยวนี้ทั้งกระบวนการสัมภาษณ์ การที่บริษัทเล็กกลางพยายามเลียนแบบ big tech และการทดลอง AI PR ตอนนี้ ทำให้สภาพแวดล้อมกลายเป็นพิษมากขึ้น เลยรู้สึกสงสัยว่าทุกวันนี้งานในฐานะนักพัฒนามืออาชีพยังเหลือความสุขอยู่หรือไม่
อย่างน้อยนักพัฒนาจบใหม่ก็ยังบอกให้ลองรันเทสต์บนเครื่องตัวเองก่อนส่ง PR ได้ มีความกังวลว่าสักจุดหนึ่งนักพัฒนามนุษย์จะยอมแพ้แล้วปิด PR "ขยะ AI" ไปเลย แล้วเก็บไว้เฉพาะอันที่ใช้งานได้จริง ทุกคนอาจต้องทนรับการทดลองของเครื่องจักรไปเรื่อย ๆ จนถึงจุดที่ถึงขีดจำกัดแล้วก็เลิกกันหมด
ตั้งคำถามว่าจำเป็นต้องมีระบบฟีดแบ็กแบบนี้จริงหรือไม่ ในมาตรฐานการพัฒนา ความสำเร็จคือ PR ที่ merge ได้ตั้งแต่ครั้งแรก ความล้มเหลวคือการแย่ลงสะสมตามจำนวนรอบแก้ไขที่ agent ขอให้ทำ การขอฟีดแบ็กด้วยมือไม่มีประสิทธิภาพ และควรวัดผลเหมือนนักพัฒนาโดยใช้ตัวชี้วัดอย่าง cycle time, approval rate, change failure rate มากกว่า
แชร์ประสบการณ์ว่าตอนสื่อสารกับทีมซัพพอร์ตของ Microsoft รู้สึกเหมือนคุยกับกำแพง เปิดหลายเคสก็ไม่เคยได้การแก้ปัญหาที่น่าพอใจ เข้าใจได้ที่ Microsoft อยากใช้เทคโนโลยีของตัวเอง แต่ขออย่าบังคับผู้ใช้อย่างตัวเอง และหวังว่า Microsoft จะไม่ปล่อยผลิตภัณฑ์ที่ยังไม่พร้อมด้านการซัพพอร์ต
มีการเล่าถึงประสบการณ์ดูวิดีโอที่ Eric ของ Google พูดถึง AI ซึ่งเจ้าตัวอ้างว่า AI ยังถูกประเมินค่าต่ำไป โดยยกเหตุผลเรื่องการซื้อบริษัทร็อกเก็ตและการใช้ AI ท้าทายในสาขาที่ตัวเองไม่เชี่ยวชาญ เช่น Deep Research พร้อมเน้นคำว่า "ไม่ใช่ผู้เชี่ยวชาญ" ผู้แสดงความเห็นเองไม่ได้เกลียด AI แต่เห็นว่า generative AI รุ่นปัจจุบันที่อาศัยการกู้คืนแพตเทิร์นของคนรุ่นนี้เก่งมากในการทำให้ "มือใหม่ว้าว" ถ้าไม่มีความรู้ในสาขานั้น ผลลัพธ์จะดูน่าทึ่งมาก แต่พอรู้ลึกขึ้นก็จะผิดหวังกับช่องโหว่อย่างรวดเร็ว คนที่ทำงานแนวหน้าแบบ Microsoft ย่อมเห็นชัดว่าปัญหาคืออะไร แต่ผู้บริหาร โดยเฉพาะคนแบบ Eric มีจุดอ่อนคือหลงเชื่อ AI ได้ง่ายถ้ามันพูดได้หวือหวา แม้จะคาดหวังว่าสักวัน AI จะเขียนโค้ดที่ทำงานได้จริงด้วยตัวมันเอง แต่ตอนนี้ยังอีกไกล
เจ้าตัวใช้ AI อย่างระมัดระวังและจำกัดมาก ในขณะที่มหาเศรษฐีแนว "ซื้อบริษัทร็อกเก็ต" แบบนั้นกลับคลั่งไคล้ AI และใช้มันตัดสินใจลงทุนเพื่อเพิ่มความมั่งคั่งต่อไป ต่อให้ล้มเหลวหนัก สิ่งที่เสียไปก็เป็นเพียงระดับเครื่องประดับบางชิ้น จึงไม่กระทบต่อสถานะทางสังคมของพวกเขา แต่สำหรับงาน IT หน้างาน กลับรู้สึกว่าไม่ว่าผลจะออกทางไหนก็เสี่ยงทั้งคู่
เมื่อผู้นำที่ไม่ใช่ผู้เชี่ยวชาญตื่นตาตื่นใจกับ AI ได้ง่าย ก็อดจินตนาการไม่ได้ว่าอะไรจะเกิดขึ้นถ้า Google ร่วมมือกับกองทัพสหรัฐและนำ Gemini ไปใส่ในฝูงโดรนอัตโนมัติขนาดใหญ่
สงสัยว่าการเห็นพนักงาน Microsoft ใช้เวลาหลายชั่วโมงถกเถียงกับ LLM แทนการแก้ปัญหาจริง จะสร้างความเชื่อมั่นแบบไหนให้กับบริษัทที่สร้างผลิตภัณฑ์บน .NET
ก่อนมี LLM ก็เคยเห็นใน GitHub issue ว่าผู้ใช้อธิบายปัญหาได้ไม่ดีและผู้ดูแลเริ่มหงุดหงิด ตอนนี้แม้แต่ผู้ใช้ปลายทางที่หงุดหงิดก็ไม่จำเป็นอีกต่อไปแล้ว
ในอีกมุมหนึ่ง ผลลัพธ์แบบนี้ก็เป็นบทสรุปตามธรรมชาติของการบริหารที่ย่ำแย่และคำสั่งที่เละเทะ ครั้งนี้จะโทษนักพัฒนาจบใหม่ก็ไม่ได้แล้ว เหลือแต่ต้องโทษตัวเอง
ยิ่งเจ็บปวดเป็นพิเศษเมื่อแม้แต่ Stephen Toub ที่ขึ้นชื่อเรื่องบล็อก .net performance ก็ยังมีส่วนร่วมกับกระบวนการแบบนี้
ไม่ได้อยากขัดขวางการทดลองเทคโนโลยีใหม่ เพียงแต่ความต่างคือคราวนี้การทดลองถูกเปิดให้ทุกคนเห็น
มีความเห็นเชิงประชดว่า Microsoft มีวัฒนธรรมแบบ "แค่เพิกเฉยต่อ error ไป" และโยนเป็น Will Not Fix มาตั้งนาน พร้อมผู้จัดการที่หมกมุ่นกับความพอใจของตัวเอง สุดท้ายสิ่งที่เกิดขึ้นตอนนี้ก็เป็นผลจากสิ่งที่บริษัทก่อไว้เอง
มีการอธิบายบริบทจากคอมเมนต์แรกใน PR ว่าพวกเขากำลังสำรวจข้อจำกัดของเครื่องมือผ่านการทดลองหลายแบบเพื่อเตรียมพร้อมสำหรับอนาคต และความรับผิดชอบในการ merge ยังเป็นของ maintainer เหมือน PR ปกติ ไม่มีอะไรจะถูก merge จนกว่าจะผ่านมาตรฐานคุณภาพ
พนักงาน Microsoft ผู้เขียนคอมเมนต์นั้นยังเสนอด้วยว่าถ้าไม่คิดจะใช้ AI ก็จะถูกทิ้งไว้ข้างหลัง บรรยากาศใน Microsoft ดูเหมือนถูกครอบงำด้วยทั้งความกังวลและความตื่นเต้นว่า AI จะพลิกวงการ software engineering มุมมองนี้ทำให้การทดลองดูไม่เหมือนการสำรวจข้อจำกัดของเครื่องมือ แต่เหมือนการเข้าร่วมแบบไร้ทิศทางเพื่อรักษางานตัวเอง จึงยิ่งลดความเชื่อมั่น
ควรเข้าใจว่าผู้จัดการยังไม่ได้สรุปความสามารถของโมเดลไปแล้วล่วงหน้า แต่นี่เป็นการทดลองอย่างมีเหตุผลเพื่อดูจุดแข็งและจุดอ่อนในบริบทโลกจริง
การ assign PR ที่ยังไม่ผ่าน CI ให้ใครสักคนตั้งแต่แรกดูแปลก อย่างน้อยควร assign เฉพาะ PR ที่ผ่านแล้วเท่านั้นถึงจะสมเหตุสมผล แต่ดูเหมือนระบบจะเละเทะเกินกว่าจะทำได้แม้แต่เรื่องนั้น พร้อมน้ำเสียงประชดว่าถ้ามันทำงานได้จริง เรื่องระดับนี้ควรเป็นพื้นฐานอยู่แล้ว
อยากให้เลิกตีความทุกอย่างเป็นสถานการณ์เลวร้ายที่สุด มนุษย์ที่เกี่ยวข้องก็น่าจะรู้ว่านี่คือการทดลองและมีการปรับความคาดหวังไว้แล้ว หากไม่มีแนวทางทดลองแบบนี้ ระบบก็พัฒนาได้ยาก จึงอาจกำลังปรับจูนและทดสอบในสภาพแวดล้อมจริง บริษัทของผู้แสดงความเห็นเองก็เคยทำการทดลองแบบเดียวกันตอนเริ่มนำเครื่องมือช่วยเขียนโค้ดด้วย AI มาใช้ แม้คุณภาพโค้ดจะแย่กว่าตอนมนุษย์เขียนเอง แต่ก็ได้เรียนรู้อะไรใหม่ ๆ มากจากกระบวนการนั้น และมี baseline ชัดเจนให้เห็นแนวโน้มการปรับปรุง
ในคอมเมนต์มีคำอธิบายว่ามีปัญหา firewall ทำให้ยังเช็กไม่ได้ว่าเทสต์ผ่านหรือไม่ และถ้าแก้ปัญหานั้นได้ ระบบก็น่าจะทำงานปกติได้
ถ้าแทน AI agent ด้วยเทคโนโลยีใหม่ชนิดอื่น ภาพนี้ก็ดูเหมือนพฤติกรรมปกติของบริษัทอยู่ดี คือทดลองอย่างเปิดเผยแบบ big tech dogfooding, ช่วยผลักดันความก้าวหน้าทางเทคโนโลยีของอุตสาหกรรมจริง และถ้ามีปัญหา ความเสียหายก็จำกัดอยู่ภายในทีม จึงตั้งคำถามว่าเหตุใดถึงไม่มีเหตุผลให้สนับสนุนการทดลองแบบนี้
รู้สึกแปลกกับบรรยากาศที่ทุกคนรุมตำหนิการทดลองแบบเปิดเผย แทนที่จะซ่อนไว้ใน private fork การเปิดเผยความสามารถจริงอย่างโปร่งใสดูมีประโยชน์กว่ามาก และดีกว่าคำโฆษณาเกินจริงจากฝ่ายขายการตลาด
การทำการทดลองแบบนี้กับ framework โครงสร้างพื้นฐานหลักของการพัฒนาซอฟต์แวร์ยังคงเป็นเรื่องถกเถียงได้
สงสัยว่า "พวกเรา" ควรสนับสนุนหรือไม่สนับสนุนอะไร อย่างไร และเพราะอะไร ส่วนตัวแค่รู้สึกขำที่ MS ล้มเหลวอย่างเอะอะโวยวาย
มองว่าเรียกว่า "ความก้าวหน้า" จริง ๆ ไม่ได้ การเผยให้เห็นปัญหาของระบบต่อสาธารณะโดยไม่มี POC ภายในมาก่อนกลับดูไร้ความรับผิดชอบ สงสัยว่าทำไมไม่ตรวจสอบสภาพแวดล้อมพื้นฐานอย่าง firewall ก่อน หรือไม่ลองกับ codebase ภายในอื่นก่อน โค้ดโครงสร้างพื้นฐานต้องมีมาตรฐานสูง ต่อให้จะอ้าง dogfooding ก็ควรเริ่มจากโปรเจ็กต์ลำดับรองลงมา อีกทั้งยังไม่ใช่ "state of the art" ด้วยซ้ำ และมีน้ำเสียงประชดว่าผลลัพธ์มันหยาบเกินไปเมื่อเทียบกับต้นทุนที่ใส่ลงไป
การทดลองแบบนี้ในโปรเจ็กต์ยอดนิยมที่นักพัฒนาจำนวนมากพึ่งพาเป็นเรื่องมีปัญหา มีความกังวลว่าโค้ดคุณภาพต่ำจาก AI จะทำให้คุณภาพโดยรวมตกลง สะสมโค้ดไร้ประโยชน์ หรือแค่กัดกิน productivity ของทีม
ถ้าจะยอมจำนนแบบเฉื่อยชา ก็ควรอนุมัติทุกคำขอไปเลยโดยไม่ต้องรีวิว แล้วถ้าเทคโนโลยีสแต็กของ Microsoft พังทั่วโลก ค่อยลาออกไปเป็น consultant รับเงินเดือน 3 เท่าก็พอ เป็นข้อเสนอเชิงประชด
ไม่อยากทำงานด้วยท่าทีถากถางแบบนี้ และไม่เข้าใจกรอบคิดเป็นปฏิปักษ์แบบ "พวกเรา vs พวกเขา" กับผู้บริหารบริษัท หรือแนวคิดจงใจปล่อยให้พัง การบ่นถึงความไม่สมบูรณ์ไม่ได้หมายความว่าควรขัดขวางหรือโจมตีทั้งองค์กร ซึ่งขัดกับมโนธรรมของตัวเอง
มีการตอบกลับเชิงประชดว่าอันที่จริงเทคโนโลยีสแต็กของ Microsoft ก็พัง(?) อยู่แล้ว
มีคนชี้ว่าจริง ๆ แล้ว PR ที่สร้างด้วย CoPilot นั้นถูกส่งโดยทีมงานผู้ดูแลเองโดยตรง
มีมุกว่าสักวัน CoPilot อาจเขียนทับ codebase ทั้งหมด แล้วถ้าไม่มีโค้ดอยู่เลย ก็จะไม่มี test ล้มเหลวอีกต่อไป
มีความเห็นว่าในองค์กรแบบนี้ไม่จำเป็นต้องภักดีนัก เพราะพร้อมจะถูก layoff ได้ทุกเมื่ออยู่แล้ว เหมือนกรณีคนที่ทำ TypeScript compiler เป็น Go
การเปิด PR อย่างน้อยก็เป็นรูปแบบการทดลองที่ปลอดภัย ถ้าไร้ประโยชน์ก็ทิ้งได้ทันที ความพยายามใหม่ย่อมมาพร้อมการลองผิดลองถูกและความล้มเหลว แต่ประสบการณ์นั้นเองมีคุณค่า หากฝึกเครื่องมืออย่างเข้มข้นกับโค้ดจริงและปัญหาจริง เครื่องมือก็น่าจะพัฒนาได้เร็ว เช่น ในอนาคตอาจมีการปรับปรุงให้มันวนเรียนรู้จนกว่าเทสต์จะผ่าน หรือมีตัวตรวจไม่ให้ลบเทสต์ สุดท้ายคาดว่า AI จะรับงานซ้ำ ๆ และเป็นงานเชิงกลในกระบวนการพัฒนาไป ส่วนให้นักพัฒนามุ่งกับงานสร้างสรรค์ที่เป็นแก่นแท้มากกว่า
อย่างไรก็ดี การทดลองแบบนี้ควรทำใน private fork มากกว่า public repository เพื่อความปลอดภัย และก็สงสัยว่านี่เป็นการตัดสินใจที่ถูกต้องในเชิงการขายหรือไม่ เพราะเมื่อผู้ตัดสินใจในบริษัทเห็น CoPilot จากนิตยสารแล้วอยากทำตาม กรณีจริงแบบนี้อาจกลายเป็นข้อมูลอ้างอิงได้ โดยปกติบริษัทส่วนใหญ่มักพยายามซ่อนกรณีแอปพลิเคชันมีข้อบกพร่องและเผยแพร่แต่ภาพที่ดูสมบูรณ์
PR ที่ผิวเผินดูโอเคก็อาจซ่อนปัญหาที่มองไม่เห็นไว้ ทำให้ยิ่งอันตรายกว่าเดิม
มีประสบการณ์ว่ารีวิวโค้ด AI กลับน่าหงุดหงิดกว่างานซ้ำ ๆ เสียอีก โดยเฉพาะเมื่อมีบั๊กซ่อนอยู่ นักพัฒนาจะยิ่งเหนื่อยกว่าเดิม
แค่การเปิด PR ก็เพิ่มภาระและความซับซ้อนในการบริหารโปรเจ็กต์แล้ว การไปทดลองใน fork แยกต่างหากจะเป็นตัวอย่างที่ดีกว่าต่อชุมชน มีโปรเจ็กต์โอเพนซอร์สมากมายที่หมดแรงกับการจัดการ PR สะสม จนสุดท้ายการดูแลหยุดชะงัก หรือมีคน fork ไปแล้วหยิบเฉพาะ PR ที่ยังใช้ได้กลับมา จึงกังวลว่าจะมีโปรเจ็กต์ถูกทิ้งและมี fork ลักษณะนี้เพิ่มขึ้น
หากเชื่อจริง ๆ ว่า LLM สามารถเรียนรู้การเขียนโค้ดได้อย่างเหมาะสมแม้มีบั๊กปะปนอยู่ ขั้นต่อไปก็ควรต้องสร้าง dataset ที่แทบไม่มีบั๊ก แต่ความจริงกลับไม่ได้ทำแบบนั้น และยังคงกวาดข้อมูลอะไรก็ได้มาใช้ต่อไป
GitHub ทุ่มเงินหลายพันล้านดอลลาร์สร้าง AI ที่แม้แต่ lint เรื่องช่องว่างในหนึ่งใน repository ที่โตเต็มที่ที่สุดในโลกก็ยังสอบตกบ่อย ถ้าเป็นการทดลองเล่น ๆ เป็นงานอดิเรกก็คงอีกเรื่อง แต่การติดราคาแล้วขายเป็น "ผลิตภัณฑ์นวัตกรรม" จริงจังนั้นชวนให้ถกเถียง
จากมุมของนักวิจัย มันเป็นการทดลองที่เข้าใจได้อยู่แล้ว แต่ปัญหาคือท่าทีของบริษัทที่ขายของที่ยังไม่เสร็จดีในตอนนี้
มีมุกถึงอดีต CEO อย่าง Nat Friedman ว่า "คงเสียชีวิตไปแล้วมั้ง... อ้อ ยังมีชีวิตอยู่นี่"
ปัญหาที่แท้จริงคือการไม่มีตัวชี้วัดเชิงวัตถุสำหรับประเมินผลงานของนักพัฒนาซอฟต์แวร์ สุดท้ายจึงเหลือแต่การประเมินเชิงอัตวิสัยแบบประเมินปลายปี ทำให้ยากจะรู้ว่า AI ช่วยเพิ่มหรือลดประสิทธิภาพกันแน่ มันอาจดูถูกกว่า junior แต่กลับเปลืองเวลาของ senior และไม่ทำตามคำสั่ง อีกทั้งเมื่อผูกกับการบูชา CEO ก็ยิ่งทำให้ความเห็นต่างภายในองค์กรรุนแรงขึ้น เสียงคัดค้านของนักพัฒนาถูกปัดตกว่าเป็น "ความกลัวว่าจะถูกแทนที่" ฝั่ง CEO ก็มีแรงจูงใจให้ผลักดันตัวเลขความสำเร็จสูงสุด เพราะไม่มีมาตรฐานอุตสาหกรรมที่ทุกฝ่ายยอมรับร่วมกัน จึงแทบเป็นไปไม่ได้ที่จะรู้ความจริง ถึงขั้นมีการคาดเดาแบบสุดโต่งว่าองค์กรอาจสั่งให้ลดมาตรฐานการรีวิวเพื่อเพิ่มจำนวน AI PR ในระบบ