การสร้างโค้ดด้วย LLM อาจนำไปสู่การลดทอนความน่าเชื่อถือ

• ช่วงหลังมานี้ การสร้างโค้ดด้วย LLM ถูกใช้งานมากขึ้นเรื่อย ๆ ในหมู่นักพัฒนา
• โค้ดที่สร้างขึ้นอัตโนมัติทำให้เกิดความกังวลเกี่ยวกับ คุณภาพและความน่าเชื่อถือของโค้ด มากขึ้น
• นักพัฒนาพบว่า ความยากในการบำรุงรักษาโปรเจกต์เพิ่มสูงขึ้น เนื่องจากความเข้าใจโค้ดไม่เพียงพอและการตรวจสอบไม่รัดกุม
• การใช้งานโค้ดที่ไม่น่าเชื่อถืออย่างแพร่หลาย ส่งผลกระทบต่อระบบนิเวศซอฟต์แวร์โดยรวม
• มีการเน้นย้ำถึงความจำเป็นในการจัดทำแนวทางเพื่อรับประกันความน่าเชื่อถือควบคู่ไปกับความก้าวหน้าทางเทคโนโลยี

---

ภาพรวม

Jay กล่าวในบล็อกของตนถึงผลกระทบที่เทคโนโลยีการสร้างโค้ดด้วย LLM (โมเดลภาษาขนาดใหญ่) ซึ่งเพิ่งเกิดขึ้นไม่นานนี้ มีต่อการพัฒนาซอฟต์แวร์ในภาคปฏิบัติ แม้การพัฒนาของเครื่องมือเหล่านี้จะช่วยเพิ่มประสิทธิภาพการทำงาน แต่ในขณะเดียวกันก็ทำให้ประเด็นเรื่อง ความน่าเชื่อถือ และ คุณภาพ ของโค้ดเด่นชัดขึ้น

การเติบโตของเทคโนโลยีสร้างโค้ดด้วย LLM

• เครื่องมือ สร้างโค้ดอัตโนมัติ ที่ใช้ LLM กำลังแพร่กระจายอย่างรวดเร็วในงานพัฒนา
• ให้ผลิตภาพสูงในการพัฒนาฟีเจอร์ที่ซับซ้อนหรือการเขียนโค้ดงานซ้ำ ๆ
• มีข้อดีทั้งในด้านการสร้างต้นแบบอย่างรวดเร็วและช่วยลดภาระในการเรียนรู้ภาษาใหม่

ปัญหาด้านความน่าเชื่อถือ

• มีกรณีที่โค้ดที่ LLM สร้างขึ้น ไม่ทำงานตามที่ตั้งใจไว้เสมอไป
• เจตนาและตรรกะการออกแบบภายในโค้ดไม่ชัดเจน ทำให้ กระบวนการทำความเข้าใจและการตรวจสอบ ยากขึ้น
• หากกระบวนการรีวิวและทดสอบไม่เพียงพอ ก็อาจเกิด บั๊กหรือช่องโหว่ที่ไม่คาดคิด ได้

การบำรุงรักษาโปรเจกต์และผลกระทบต่อระบบนิเวศ

• เกิดปัญหาเรื่อง การจัดทำเอกสารไม่เพียงพอ และคำอธิบายของโค้ดที่สร้างอัตโนมัติไม่ชัดเจน
• นักพัฒนาประสบความยากลำบากในการทำความเข้าใจหลักการทำงานของโค้ด ส่งผลให้ ความซับซ้อนในการบำรุงรักษา เพิ่มขึ้น
• มีความเสี่ยงที่วัฒนธรรมการพัฒนาซอฟต์แวร์ที่เน้นความน่าเชื่อถือจะ ถูกบ่อนทำลาย

บทสรุปและข้อเสนอแนะ

• เทคโนโลยีการสร้างโค้ดด้วย LLM เป็นนวัตกรรมที่สำคัญ แต่การทำให้ ความน่าเชื่อถือ เกิดขึ้นจริงยังเป็นภารกิจที่จำเป็น
• เมื่อมีการนำโค้ดที่สร้างอัตโนมัติมาใช้ ควรเน้นการ เสริมความเข้มงวดในการตรวจสอบ และการรีวิวโค้ดอย่างเป็นระบบ
• ในระยะยาว การกำหนดมาตรฐานเพื่อ ปกป้องความน่าเชื่อถือของระบบนิเวศการประมวลผล เป็นเรื่องสำคัญ

[GN⁺]

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

• แชร์ลิงก์ archive.is ใช้งานได้แม้กับเบราว์เซอร์รุ่นเก่า และต้องใช้ JavaScript แค่เพื่อหลบ CloudSnare เท่านั้น

• เพื่อนของฉันชอบพูดเสมอว่า "นวัตกรรมเกิดขึ้นด้วยความเร็วของความไว้วางใจ" ตั้งแต่ GPT3 ออกมา คำนี้ก็วนอยู่ในหัวตลอด การตรวจสอบมีต้นทุนสูง และความไว้วางใจคือวิธีหลักที่ช่วยลดต้นทุนนั้น แต่ฉันไม่รู้จะสร้างความไว้วางใจกับ LLM ได้อย่างไร มันทั้งเขียนโค้ดและใช้ภาษาธรรมชาติได้อย่างลื่นไหล แต่ในขณะเดียวกันก็หลงทางไปในทิศทางที่ถ้าเป็นคน เราจะมองว่าเจตนาไม่ดีได้

  • ผู้เขียนเอง: ฉันชอบคำพูดนั้นมาก มันสรุปสิ่งที่ฉันอธิบายไว้หลายย่อหน้าได้สั้นมาก โลกที่ต้องตรวจทุกอย่างทีละชิ้นแบบนี้ ถ้าพูดตรง ๆ มันทั้งเหนื่อยและช้ามาก
  • เราไม่อาจไว้วางใจผลลัพธ์จาก LLM ได้แบบสมบูรณ์ แต่เราพอจะขัดเกลาและจำกัดอานุภาพทำลายล้างของมันได้ เช่น กรองอินพุตผู้ใช้ ทำ penetration test และซ่อนความลับไว้ในไฟล์ dot สุดท้ายก็คงจะไปจบที่มาตรฐานอย่าง "best practice" และ "การปฏิบัติตามข้อกำกับดูแล SOC-AI" LLM มีประโยชน์เกินกว่าจะเมินได้ ความไว้วางใจก็สร้างกันทีละขั้น มนุษย์เองก็ไม่ได้ใกล้เคียงกับความน่าเชื่อถือสมบูรณ์อยู่แล้ว และถ้าเทียบกับรถขับเคลื่อนอัตโนมัติ ก็ดูเป็นไปได้ว่าในกรอบกฎที่กำหนดไว้ มันจะผลิตโค้ดที่มีบั๊กน้อยกว่ามนุษย์ จากนั้นก็ค่อย ๆ ปรับปรุงด้านความซับซ้อนต่อไป
  • คำว่า "นวัตกรรมเกิดขึ้นด้วยความเร็วของความไว้วางใจ" น่าจะต้องอธิบายเพิ่มหน่อย ตอนที่ค้นพบไฟฟ้า การบิน หรือกัมมันตรังสีครั้งแรก เรามีความไว้วางใจในระดับนั้นแล้วหรือ? ในวิทยาศาสตร์ ความไว้วางใจเป็นสิ่งที่ค่อย ๆ สร้างขึ้นระหว่างทาง

• ที่บริษัทฉันได้เจอประเด็นนี้ในแบบไม่คาดคิด เพื่อนร่วมงานกับแรงกดดันเรื่องผลงานระยะสั้น ตัดสินใจ merge งาน refactor ใหญ่ที่ฉันทำทั้งที่ยังอยู่ในสถานะ PR ชั่วคราว หลังจากนั้นก็เกิดบั๊กจากโค้ดที่ยังไม่ได้ทดสอบ ระหว่าง debug เพื่อนร่วมงานยอมรับว่าเขาคิดว่าฉันใช้ AI เขียนโค้ด และรู้สึกหงุดหงิดที่ต้องมาพยายามทำความเข้าใจโค้ดที่ AI สร้างขึ้นทีหลัง แต่จริง ๆ แล้วโค้ดนั้นฉันเขียนเองอย่างละเอียดทั้งหมด และต้นเหตุของบั๊กคือความผิดพลาดเล็ก ๆ ระหว่างการเปลี่ยน API แบบง่าย ๆ เสียมากกว่า ประสบการณ์นี้กลับทำให้ฉันกับเพื่อนร่วมงานได้เปิดเผยความตึงเครียดเรื่องความไว้วางใจกันอย่างเป็นธรรมชาติ และคุยกันแบบสร้างสรรค์ได้ ตอนนี้พอย้อนดูแล้ว ฉันว่าประสบการณ์การสร้างความไว้วางใจแบบนี้มีความหมายมาก และถ้าสภาพแวดล้อมต่างออกไป มันอาจจะซับซ้อนยุ่งเหยิงกว่านี้มาก จึงยิ่งรู้สึกว่าต้องระวังอยู่เสมอ

• ฉันไม่ค่อยเข้าใจสมมติฐานตั้งต้น ความไว้วางใจว่าใครสักคนเขียนโค้ดดีได้ มันก็มาจากประสบการณ์จริงว่าคนนั้นลงมือเขียนเองแล้วผลลัพธ์ออกมาดี ถ้าใช้ LLM แล้วส่งโค้ดไม่มีบั๊กมาให้ ก็ไว้ใจ ถ้าใช้ LLM แล้วมีบั๊ก ก็ไม่ไว้ใจ ฉันไม่เห็นว่ามันต่างจากการเขียนด้วยหัวตัวเองตรงไหน

  • ผู้เขียนเอง: ประเด็นของฉันคือ ในสภาพแวดล้อมที่ความไว้วางใจต่ำ เช่น ทีมขนาดใหญ่ที่เชื่อใจกันระดับกลาง ๆ หรือโอเพนซอร์ส LLM จะทำให้การตัดสินความสามารถของนักพัฒนาจากโค้ดที่ส่งมายากขึ้นเรื่อย ๆ เราอ่านนิสัยหรือแนวทางของอีกฝ่ายไม่ได้ สุดท้ายจึงต้องกลับไปสู่สภาพ "ไม่ไว้วางใจเลย" แล้วตรวจทุกบรรทัดอย่างละเอียด ทางลัดที่เราเคยใช้ในการรีวิวอย่างรวดเร็วใช้ไม่ได้อีกแล้ว และในองค์กรที่คุ้นกับวัฒนธรรมแบบนั้น มันอาจเจ็บปวดพอสมควร ถ้าเป็นทีมที่มีความไว้วางใจสูงอยู่แล้ว ก็อาจไม่รู้สึกว่าปัญหานี้เกี่ยวกับตัวเองเลย
  • ถ้าเมื่อก่อน A=B การที่ B ดีขึ้นก็แปลว่า A ก็ดีด้วย แต่ตอนนี้มันกลายเป็น A+Ai=B ดังนั้นแม้ B จะดี A ก็อาจไม่ได้ดี และด้วยสภาพ AI ตอนนี้ที่เป็นเชิงความน่าจะเป็น บ่อยครั้งมันแย่กว่าการไม่ทำอะไรเสียอีก
  • คุณบอกว่า "ไว้ใจเฉพาะโค้ดที่ทำงานได้" แต่รากฐานของความไว้วางใจคือผู้พัฒนารู้ล่วงหน้าว่าโค้ดนั้นไม่มีบั๊กจริง ๆ แต่ในระบบที่ซับซ้อน การจะรู้ว่าโค้ดจะโต้ตอบกับส่วนอื่นอย่างไร และ edge case จะเกิดที่ไหน ผู้เขียนโค้ดต้องเข้าใจบริบททั้งหมด ถ้า LLM เป็นคนเขียนแทนและผู้พัฒนาไม่ได้เข้าใจเนื้อหาทั้งหมด ภาระการตรวจสอบนั้นก็จะถูกโยนไปที่ reviewer และนำไปสู่ภาวะล้นมือ นั่นคือใจความ
  • เวลาเขียนโค้ดด้วย LLM บางครั้งมันได้ผลดีอยู่หลายรอบ จนทำให้มั่นใจเกินไปและละเลยการทดสอบ ปัญหาจริง ๆ มักเกิดจากความผิดพลาดในการสื่อสาร คนทำงานอาจเข้าใจโจทย์ทั้งหมดชัดเจน แต่ LLM รักษาสถานะได้ไม่ดี และถ้าบริบทกำกวมก็ชอบตั้งสมมติฐานเพี้ยน ๆ ฉันอยากให้แนวทางแบบ 4o ที่คอยถามข้อมูลเพิ่มก่อน กลายเป็นมาตรฐานของโมเดลสร้างโค้ดทุกตัว เพราะมันน่าจะป้องกันปัญหาได้เยอะมาก
  • ความไว้วางใจไม่ได้สร้างจากแค่ว่าโค้ดใช้งานได้เท่านั้น เรายังดูหลายอย่าง เช่น อธิบายการเปลี่ยนแปลงได้ชัดเจน มีประวัติการมีส่วนร่วมที่ดีในอดีต ขนาดของการเปลี่ยนแปลงเหมาะสม (เช่น commit ไม่ใหญ่หรือเล็กเกินไป) การจัดลำดับความสำคัญของปัญหา (แก้บั๊กก่อนเพิ่มฟีเจอร์) ความสามารถในการดูแลโค้ดเดิม ความสม่ำเสมอในการทำงาน ฯลฯ

• เราอยู่ในยุคนั้นแล้วจริง ๆ ฉันเห็นประโยคอย่าง "ขอโทษที่มองข้ามจุดนี้ คุณพูดถูก" บ่อยมาก มากประมาณ 8 หรือ 9 ครั้งจาก 10 ครั้ง ในทางกลับกัน ฉันก็เห็นคนก๊อปวางโค้ดที่ LLM สร้างมาแบบไม่คิดความหมาย แล้วพอผลไม่ตรงหวังก็โมโหอยู่บ่อย ๆ ซึ่งจริง ๆ แบบนั้นยังดีกว่า ฉันคิดว่าของที่พังอย่างชัดเจนยังดีกว่าของที่ดูเผิน ๆ เหมือนถูกต้อง

  • จากประสบการณ์ของฉัน LLM มักมีแนวโน้มแก้โค้ดให้แค่ผ่านเทสต์ มากกว่าจะทำให้ตรงตามความต้องการจริง
  • คุณใช้ LLM ผ่านแชตบอตในเบราว์เซอร์หรือเปล่า? ฝั่งเราใช้ AI agent ที่เข้าถึงโค้ดโดยตรง มันพูดน้อยกว่ามาก และหลายครั้งทำงานได้ดีกว่าจูเนียร์รอบตัวจริง ๆ มันทำงานสั้น ๆ ที่เฉพาะเจาะจงได้ดี จนแทบต้องการแค่ code review แล้วใช้ได้เลย แน่นอนว่า prediction engine พวกนี้ยังทำ engineering จริง ๆ ไม่เป็น เช่น ถ้าไม่ระบุชัดว่าต้องใช้ Python generator มันก็มักสร้างโค้ดที่กินหน่วยความจำมหาศาล แต่เอาจริงนักพัฒนา Python รอบตัวฉันก็พลาดแบบนี้กันเยอะด้วยซ้ำ จุดนี้กลับช่วยกระตุ้นให้เราเขียนสเปกให้ชัด แทนที่จะสั่งแค่ "add feature" พื้นที่ที่ AI agent มีประโยชน์ที่สุดคือโค้ด legacy ที่ไม่มีใครอยากแตะ เรามีระบบเก่ามากที่ดึงข้อมูลจากเอกสารแฟกซ์ด้วยพิกัด 200 จุด ใช้มานานเกิน 30 ปีแบบแทบไม่เปลี่ยน จนล่าสุดรูปแบบเอกสารเปลี่ยน copilot ใช้เวลาแก้พิกัดแค่ 30 วินาที ถ้าเป็นคนคงกินเวลาอย่างน้อยทั้งวัน แต่ในยุคเขียนโค้ดแบบนี้ ฉันไม่รู้เลยว่าจะกลายเป็นผู้เชี่ยวชาญได้อย่างไร
  • 8 หรือ 9 ครั้งจาก 10 ครั้งนี่เว่อร์ไปมาก เป็นสถิติที่แต่งขึ้น 100%

• เครื่องมือ abstraction รุ่นก่อน ๆ ลดความซับซ้อนได้โดยตั้งอยู่บนสมมติฐานพื้นฐานว่า abstraction นั้น "ถูกต้อง" แน่นอนว่ามันไม่สมบูรณ์และมีบั๊กได้ แต่ปัญหาอยู่ที่ implementation ไม่ใช่ความผิดพลาดเชิงเนื้อแท้ และเมื่อแพตช์แล้วก็มักจะแข็งแรงขึ้น ในทางกลับกัน LLM เป็น prediction engine เชิงความน่าจะเป็น จึงให้ความถูกต้องแบบประมาณค่าได้แค่ช่วงเวลาหนึ่ง สิ่งที่ผู้เขียนมองข้ามคือ เราสามารถสร้างระบบ deterministic ที่น่าเชื่อถือได้แม้ใช้ agent เชิงความน่าจะเป็นที่ไม่สมบูรณ์ ตัวอย่างเช่น เราไม่ได้เชื่อใจผู้เขียนเครื่องมือ garbage collection แต่เชื่อใจเพราะตัวเครื่องมือถูกทดสอบมากพอและพิสูจน์ได้ว่าทำงานตามต้องการ ฉันคิดว่าในอนาคต test-driven development จะยิ่งเข้มข้นขึ้น ไม่ใช่ความไว้วางใจ แต่เป็นการตรวจสอบยืนยัน

  • การคิดว่า automated test จะจับได้ทุกปัญหานั้นไร้เดียงสามาก เรื่อง concurrency การจัดการทรัพยากร ช่องโหว่ความปลอดภัย และอีกหลายอย่างล้วนทำให้ระบบทดสอบอัตโนมัติได้ยาก แล้วใครจะเป็นคนตรวจสอบตัวเทสต์เอง? ทั้งโค้ดและเทสต์ต่างก็เป็นการถ่ายทอดตรรกะ และบางครั้งต้นตอของบั๊กก็โผล่ที่ฝั่งเทสต์ ไม่ใช่ฝั่งโค้ด เราจึงไม่ควรไว้วางใจเทสต์แบบไม่มีเงื่อนไขเช่นกัน
  • ผู้เขียนเอง: ที่นี่ฉันกำลังพูดถึงตัวเครื่องมือมากกว่าผลของการใช้เครื่องมือ ยกตัวอย่างเช่น ถ้าโมเดลทำหน้าที่เป็น garbage collector เองโดยตรง รับ memory dump ของโปรแกรมแล้วตัดสินใจปลดบล็อกที่ไม่จำเป็น ฉันก็คงไม่มีวันเชื่อถือการตัดสินนั้นได้ตลอดไป ต่อให้คอยเสริมด้วย "patch" หรือ "fine-tuning" ก็มีขีดจำกัด ต่างจากผลลัพธ์ deterministic แบบ JVM ที่ถ้าเกิดข้อผิดพลาด แพตช์ครั้งเดียวก็ทำให้ข้อผิดพลาดแบบนั้นหายไปถาวร LLM ไม่เป็นแบบนั้น ฉันคิดว่าความต่างนี้คือจุดแยกเชิงสาระสำคัญระหว่าง abstraction แบบเดิมกับโลกของ LLM ฉันเชื่อว่า LLM จะส่งผลกระทบต่ออุตสาหกรรมอย่างมาก แต่เพราะมีกรณีศึกษาทางประวัติศาสตร์จำกัด มันยังเป็นดินแดนที่ไม่รู้จริง ๆ
  • ประโยคที่ว่า "ระบบ deterministic ที่น่าเชื่อถือสามารถเกิดจากปัจจัยสุ่ม (เครื่องจักรเอนโทรปี) ได้" ฟังดูสุดโต่งมากสำหรับฉัน และ TDD ก็มักถูกนำเสนอเหมือนเป็นเครื่องมือวิเศษที่แก้ได้ทุกอย่าง แต่ฉันเห็นตัวอย่างที่สร้างซอฟต์แวร์ผิดทิศผิดทางเพราะเทสต์ผิดมาเยอะจนน่าอาย

• ความไม่ชอบ LLM ไม่ช่วยอะไรเลย ตอนนี้ LLM เพิ่มผลิตภาพของนักพัฒนาได้ อย่างน้อยก็เป็นประโยชน์มากสำหรับนักพัฒนาที่ประสบการณ์น้อย เครื่องมือที่เพิ่มผลิตภาพได้มากขนาดนี้ ต่อให้ใครพูดอย่างไรก็ไม่มีทางถูกทิ้ง แน่นอนว่าแม้จะมีกรณีเสียหาย เช่น บั๊กใหญ่ทำให้บริการขนาดใหญ่ล่มนาน เทคโนโลยีก็จะไม่หยุดถ้าผลิตภาพยังสำคัญ ทางที่เป็นจริงมีเพียงอยู่ร่วมกับมันและแก้ไข/บรรเทาจุดอ่อนเหล่านั้นไปพร้อมกัน ในกระบวนการนั้น ถ้ามาตรการบรรเทาไปขัดกับการเพิ่มผลิตภาพ ผู้คนก็จะหาทางอ้อม และสุดท้ายมาตรการเสริมที่สอดคล้องกับเทคโนโลยีจะเป็นสิ่งที่ฝังตัวอยู่รอด

  • คำว่า "LLM เพิ่มผลิตภาพของนักพัฒนา" นั้นต่างกันมากตามคนและสถานการณ์ จากประสบการณ์ของฉัน คนที่ชอบพูดว่า 'productive ขึ้น 10 เท่า' มักเป็นนักพัฒนา front-end ระดับจูเนียร์ หรือคนที่ทำแอปเริ่มต้นในสตาร์ตอัปบ่อย ๆ ซึ่งแน่นอนว่าเป็นตัวอย่างที่ดี แต่คนแบบนี้กับวิศวกร embedded C ระดับซีเนียร์ เหมือนพูดกันคนละภาษาโดยสิ้นเชิง ดังนั้นข้อถกเถียงเรื่องผลิตภาพของ AI มักเป็นการคุยกันคนละบริบท และในแง่ "การใช้อย่างมีเหตุผล" ฉันก็ยังสงสัยว่าแนวคิด AI agent เองดีจริงหรือไม่ ดูจากกรณี Copilot แล้ว ทั้ง MS และ AI กลายเป็นตัวตลกไปเลย วิธีมอบหมายงานให้ AI ทำเองอย่างอิสระอาจไม่ได้ฉลาดเสมอไป คล้ายกับ blockchain ที่แม้ช่วงคลั่งไคล้คริปโตจะเต็มไปด้วยตัวอย่างโอเวอร์เกินจริง แต่ก็มีบางกรณีอย่าง Coinbase ที่ไปลงหลักปักฐานใน niche ที่มีความหมายจริงได้ ปี 2020 IBM ยังเคยอ้างว่าจะใช้ blockchain จัดการซัพพลายเชนเมล็ดกาแฟ (มองจากปี 2025 วันนี้ฟังเหมือนมุกใน Twitter แต่ตอนนั้นพูดจริงจัง) สุดท้าย AI agent ปัจจุบัน และการประยุกต์ใช้ generative AI แบบอื่น ๆ ก็อาจถูกมองภายหลังว่าเป็นอีกตัวอย่างของ hype ที่มากเกินไป กรณี Copilot บทความ Forbes
  • คำว่า "มีผลิตภาพมากขึ้น" ถูกพูดซ้ำบ่อย แต่ไม่ได้บอกเลยว่าการผสมคนกับ AI ให้ผลลัพธ์ที่ตรงกับความต้องการผู้ใช้มากขึ้นหรือไม่ มันแค่หมายถึง "มีการผลิตโค้ดมากขึ้น" ฉันไม่เคยได้ยินเรื่อง LLM สร้าง PR ที่ลบโค้ดทิ้ง 2,000 บรรทัด คำว่า "เพิ่มผลิตภาพของวิศวกร" ในทางปฏิบัติจึงแทบจะแปลว่าเขียนโค้ดมากขึ้น
  • การคิดว่าผู้เขียนมีเจตนาวิพากษ์วิจารณ์อย่างเดียวเป็นความเข้าใจผิด ประเด็นไม่ได้อยู่ที่ว่าจะใช้หรือไม่ใช้ LLM แบบเลือกข้าง แต่โฟกัสอยู่ที่การจัดการและบรรเทาความเสี่ยง เปรียบได้กับการไม่ได้คัดค้านการพัฒนารถยนต์ แต่กำลังบอกว่ารถมีความเสี่ยงระเบิด เราจึงควรโฟกัสกับการลดโอกาสระเบิดมากกว่า
  • ฉันรู้สึกว่าโพสต์ต้นฉบับไม่ใช่ "การบ่นไร้สาระ" แต่เป็นความพยายามคิดอย่างจริงจังถึงกับดักที่คนทำงานร่วมกับ LLM มักเผลอพลาด และมาตรการเสริมภายในทีมที่เป็นจริงได้
  • ฉันยังจำได้ว่าตอน React ออกมาใหม่ ๆ ฉันไม่ยอมเรียนรู้แล้วสุดท้ายก็เสียใจ ตอนนี้ก็ยังมีแรงต้าน GPT อยู่ รอบตัวชอบพูดว่า "chatGPT บอกมาแบบนี้" หรือ "นี่คือโค้ดจาก chatGPT" ส่วนฉันภูมิใจที่ฝ่าฟันเขียนโค้ดด้วยตัวเอง แม้จะไม่ใช้ GPT แต่เอาเข้าจริงก็อาจมองว่า Google หรือ Stack Overflow เป็น GPT แบบช้ากว่าได้เหมือนกัน

• แทนที่จะออกนโยบายอย่าง "รับรองว่าโค้ดที่ส่งมาไม่ใช่ผลผลิตจาก LLM เป็นงานต้นฉบับ และเข้าใจทั้งหมดอย่างสมบูรณ์" หรือ "ส่วนใหญ่ต้องทำด้วยมือ" ฉันคิดว่าควรโฟกัสที่ผลลัพธ์มากกว่า การกำหนดให้ผู้มีส่วนร่วมต้องเข้าใจการเปลี่ยนแปลงที่ตัวเองส่งมานั้นเป็นเรื่องดี แต่นโยบายอย่าง "จูเนียร์ควรงดหรือถูกห้ามใช้เครื่องมือ LLM ชั่วคราว" ฉันไม่ค่อยเห็นด้วย LLM ช่วยได้มากกับปัญหา setup สภาพแวดล้อมที่วุ่นวายตอน onboarding นอกจากนี้ยังช่วยทำความเข้าใจโค้ด/เอกสาร และเป็นเครื่องมือค้นหาข้อความกับสรุปข้อมูลที่มีประโยชน์ด้วย

  • การ onboarding โดยพฤตินัยก็คือกระบวนการเรียนรู้การแก้ปัญหาสภาพแวดล้อมที่สุ่มและวุ่นวายนั่นแหละ ถ้าเราใช้ automation ลบความยากและความซับซ้อนพวกนี้ออกไปหมด สุดท้ายจะไม่มีใครรู้ว่าควรทำอย่างไรเมื่อเจอสถานการณ์แบบนั้นอีกต่อไปหรือเปล่า ไม่รู้ว่ามีแค่ฉันที่คิดแบบนี้ไหม

• เพิ่งเคยได้ยินแนวคิดเรื่อง "AI Cliff" (อาการที่ความแม่นยำของ LLM ตกฮวบแบบฉับพลัน) อยากรู้ว่าคนอื่นเคยเจอบ้างไหม

  • ฉันเจอบ่อย พอความซับซ้อนของโค้ดเกินจุดวิกฤต LLM ก็ไม่สามารถเก็บบริบททั้งหมดไว้ในหัวได้และเริ่มทำตัวเพี้ยน บทบาทของฉันคือจัดการระดับความซับซ้อนที่ LLM ต้องมอง ปัจจุบัน LLM มีแนวโน้มทำให้โครงสร้างซับซ้อนขึ้นเรื่อย ๆ เมื่อใช้ไปนาน ๆ โดยทั่วไปฉันต้องคอยขอให้มัน refactor เพื่อลดความซับซ้อน หรือถ้าซับซ้อนเกินไปก็ลงมือจัดการเอง ตอนนี้ถ้าปล่อยให้ LLM ทำต่อเนื่องไปเรื่อย ๆ มันสุดท้ายจะสร้างความยุ่งเหยิงแบบ Rube Goldberg ขนาดใหญ่ และสุดท้ายมนุษย์ก็ต้องมานั่งเก็บกวาด นักพัฒนาที่มีประสบการณ์จะรู้เร็วว่า LLM พาออกทะเลไปได้ไกลแค่ไหนและดึงกลับได้แต่เนิ่น ๆ แต่ถ้าเป็นมือใหม่อาจหลงทางจนไม่ทันรู้ตัวว่าเหตุการณ์กำลังเกิดขึ้นด้วยซ้ำ
  • บางคนเรียกว่า context drunk ถ้าอินพุตบริบทมี 10,000 โทเคนและถูก 99% สมมุติว่า LLM ตอบกลับมา 1,000 โทเคนที่ถูกแค่ 90% พอโต้ตอบกันไปเรื่อย ๆ พื้นที่บริบทส่วนใหญ่ก็จะเต็มไปด้วยการวนซ้ำของเอาต์พุตที่แม่นน้อยกว่าซึ่ง LLM ผลิตขึ้นเอง ความผิดพลาดจึงสะสม และเพราะข้อมูลล่าสุดมีน้ำหนักมากกว่า มันก็ยิ่งเพี้ยนขึ้นเรื่อย ๆ ปัญหานี้ไม่ได้เกิดแค่กับโค้ด แต่เกิดกับงานเขียนร้อยแก้วด้วย
  • ฉันเรียกมันว่า context rot บริบทสะสมไปเรื่อย ๆ แล้วคุณภาพเอาต์พุตตกลง ยิ่งมีบทสนทนาเล่น ๆ หรือเนื้อหาออกนอกเรื่องมาก ก็ยิ่งแย่เร็ว โดยเฉพาะเมื่อ chain of thought (COT) ค้างอยู่ในบริบท ถ้ากระบวนการคิดเริ่มหลงทาง ร่องรอยนั้นก็ยิ่งทำให้ทุกอย่างทรุดลง ส่วนตัวอยากได้ฟีเจอร์ pruning ที่ตัดเฉพาะบางส่วนของบริบทออกได้ ตอนนี้ฉันรับมือกับ context rot ด้วยการสรุปเองแล้วเริ่มเซสชันใหม่
  • ฉันเจอแบบนี้เฉพาะเวลาทำ vibe coding ผ่านอินเทอร์เฟซแชต ส่วนเครื่องมือแบบ agent จัดการหน้าต่างบริบทของโค้ดเองและรัน dev tooling เพื่อตรวจ sanity check โดยตรง จึงเกิดน้อยกว่ามาก
  • ฉันมักรีเซ็ตเซสชัน AI ที่ใช้ทำงานบ่อย ๆ เลยไม่ค่อยรู้สึกถึง 'AI cliff' แต่ตอนทำงานเขียนนิยาย ความยาวและความสม่ำเสมอของบริบทสำคัญมาก จึงเคยเจอช่วงที่ AI รักษานิสัยตัวละครไม่ได้และตอบสนองแปลก ๆ แบบกู้กลับไม่ได้ เป็นประสบการณ์ที่แปลกมาก

• ดูเหมือนผู้เขียนต้นฉบับจะประกาศว่าไม่คิดสรุปความคิดเห็นของหลายคน แต่เอาเข้าจริงก็เหมือนกำลังทำแบบนั้นอยู่ ถึงอย่างนั้น ฉันก็อยากให้ใน PR มีตัวบ่งชี้ว่าไฟล์ไหนมีโค้ดที่ AI สร้างรวมอยู่ด้วย เพราะรูปแบบความผิดพลาดของโค้ดจาก LLM กับโค้ดจากคนไม่เหมือนกัน ถ้าแยกรีวิวได้ก็น่าจะประหยัดเวลา อยากรู้ว่ามีใครเคยเจอนโยบายแบบนี้ในองค์กรใหญ่ หรือมีเครื่องมืออัตโนมัติแบบนี้อยู่แล้วหรือไม่ ถ้าบริษัทต่าง ๆ วัดสัดส่วนโค้ดที่สร้างโดย LLM ก็อาจมีเครื่องมือแบบนี้อยู่แล้วเพื่อเก็บ metric รายละเอียด

  • ผู้เขียนเอง: เอาจริง ๆ ฉันยังไม่ค่อยเห็นการพูดคุยเรื่องความไว้วางใจภายในทีมกับ LLM มากพอ จึงไม่เคยเห็นกรณีที่ถูกเขียนเป็นข้อกำหนดชัดเจน ฉันไม่แน่ใจว่าเป็นเพราะตัวเองทำงานอยู่ในพื้นที่ที่ไม่ใช่ หรือเพราะมันยังเป็นเรื่องที่ยากจะพบในกระแสหลักกันแน่