การสร้างโค้ดด้วย LLM อาจนำไปสู่การลดทอนความน่าเชื่อถือ
(jaysthoughts.com)- ช่วงหลังมานี้ การสร้างโค้ดด้วย LLM ถูกใช้งานมากขึ้นเรื่อย ๆ ในหมู่นักพัฒนา
- โค้ดที่สร้างขึ้นอัตโนมัติทำให้เกิดความกังวลเกี่ยวกับ คุณภาพและความน่าเชื่อถือของโค้ด มากขึ้น
- นักพัฒนาพบว่า ความยากในการบำรุงรักษาโปรเจกต์เพิ่มสูงขึ้น เนื่องจากความเข้าใจโค้ดไม่เพียงพอและการตรวจสอบไม่รัดกุม
- การใช้งานโค้ดที่ไม่น่าเชื่อถืออย่างแพร่หลาย ส่งผลกระทบต่อระบบนิเวศซอฟต์แวร์โดยรวม
- มีการเน้นย้ำถึงความจำเป็นในการจัดทำแนวทางเพื่อรับประกันความน่าเชื่อถือควบคู่ไปกับความก้าวหน้าทางเทคโนโลยี
ภาพรวม
Jay กล่าวในบล็อกของตนถึงผลกระทบที่เทคโนโลยีการสร้างโค้ดด้วย LLM (โมเดลภาษาขนาดใหญ่) ซึ่งเพิ่งเกิดขึ้นไม่นานนี้ มีต่อการพัฒนาซอฟต์แวร์ในภาคปฏิบัติ แม้การพัฒนาของเครื่องมือเหล่านี้จะช่วยเพิ่มประสิทธิภาพการทำงาน แต่ในขณะเดียวกันก็ทำให้ประเด็นเรื่อง ความน่าเชื่อถือ และ คุณภาพ ของโค้ดเด่นชัดขึ้น
การเติบโตของเทคโนโลยีสร้างโค้ดด้วย LLM
- เครื่องมือ สร้างโค้ดอัตโนมัติ ที่ใช้ LLM กำลังแพร่กระจายอย่างรวดเร็วในงานพัฒนา
- ให้ผลิตภาพสูงในการพัฒนาฟีเจอร์ที่ซับซ้อนหรือการเขียนโค้ดงานซ้ำ ๆ
- มีข้อดีทั้งในด้านการสร้างต้นแบบอย่างรวดเร็วและช่วยลดภาระในการเรียนรู้ภาษาใหม่
ปัญหาด้านความน่าเชื่อถือ
- มีกรณีที่โค้ดที่ LLM สร้างขึ้น ไม่ทำงานตามที่ตั้งใจไว้เสมอไป
- เจตนาและตรรกะการออกแบบภายในโค้ดไม่ชัดเจน ทำให้ กระบวนการทำความเข้าใจและการตรวจสอบ ยากขึ้น
- หากกระบวนการรีวิวและทดสอบไม่เพียงพอ ก็อาจเกิด บั๊กหรือช่องโหว่ที่ไม่คาดคิด ได้
การบำรุงรักษาโปรเจกต์และผลกระทบต่อระบบนิเวศ
- เกิดปัญหาเรื่อง การจัดทำเอกสารไม่เพียงพอ และคำอธิบายของโค้ดที่สร้างอัตโนมัติไม่ชัดเจน
- นักพัฒนาประสบความยากลำบากในการทำความเข้าใจหลักการทำงานของโค้ด ส่งผลให้ ความซับซ้อนในการบำรุงรักษา เพิ่มขึ้น
- มีความเสี่ยงที่วัฒนธรรมการพัฒนาซอฟต์แวร์ที่เน้นความน่าเชื่อถือจะ ถูกบ่อนทำลาย
บทสรุปและข้อเสนอแนะ
- เทคโนโลยีการสร้างโค้ดด้วย LLM เป็นนวัตกรรมที่สำคัญ แต่การทำให้ ความน่าเชื่อถือ เกิดขึ้นจริงยังเป็นภารกิจที่จำเป็น
- เมื่อมีการนำโค้ดที่สร้างอัตโนมัติมาใช้ ควรเน้นการ เสริมความเข้มงวดในการตรวจสอบ และการรีวิวโค้ดอย่างเป็นระบบ
- ในระยะยาว การกำหนดมาตรฐานเพื่อ ปกป้องความน่าเชื่อถือของระบบนิเวศการประมวลผล เป็นเรื่องสำคัญ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
https://archive.is/5I9sB
ใช้งานได้แม้บนเบราว์เซอร์รุ่นเก่า และไม่ต้องใช้ JavaScript ยกเว้นตอนผ่าน CloudSnare
เพื่อนของผมมักพูดเสมอว่า “นวัตกรรมเกิดขึ้นด้วย ความเร็วของความไว้วางใจ” และตั้งแต่ GPT-3 เป็นต้นมา ประโยคนี้ก็ผุดขึ้นมาในหัวตลอด
การตรวจสอบมีต้นทุนสูง และเครื่องมือหลักที่ช่วยลดต้นทุนนั้นคือความไว้วางใจ ผมไม่รู้ว่าจะทำให้เราไว้วางใจ LLM ได้อย่างไร ทั้งในโค้ดและภาษาธรรมชาติ มันลื่นไหลมาก แต่ในขณะเดียวกันก็พร้อมจะพาเราเข้าไปในโพรงกระต่ายที่ขุดลึกไม่รู้จบแบบแฟร็กทัล และยังแสดงพฤติกรรมที่ถ้าเป็นมนุษย์ก็คงถือว่าเป็นเจตนาร้ายด้วย
โลกใหม่ที่ต้องตรวจสอบทุกอย่างตลอดเวลานี้ค่อนข้างเหนื่อย และพูดตรง ๆ คือช้ามาก
มันมีประโยชน์เกินกว่าจะมองข้ามได้ และความไว้วางใจก็ถูกสร้างขึ้นทีละก้อนอิฐเสมอ อย่าลืมว่ามนุษย์เองก็ไม่ได้ไว้วางใจได้มากนักตั้งแต่แรก เหมือนการขับรถ ความสามารถในการสร้าง โค้ดที่มีบั๊กน้อยกว่า บนถนนที่กำหนดไว้ล่วงหน้าน่าจะจะแซงมนุษย์ในไม่ช้า จากนั้นก็เหลือแค่การแข่งกันที่พื้นฐานเพื่อปรับปรุงความซับซ้อน
ในวิทยาศาสตร์ เราสร้างความไว้วางใจไปพร้อมกับความก้าวหน้า
ที่ทำงานผมเจอเรื่องแบบนี้ในแบบที่ไม่คาดคิด เพื่อนร่วมงานกับผมถูกกดดันให้แสดงความคืบหน้า และเราตัดสินใจรีบ merge refactoring ขนาดค่อนข้างใหญ่ที่ผมกำลังทำอยู่ แม้มันจะเป็น PR ฉบับร่าง แต่เราก็ merge เพื่อให้มีแรงส่ง แล้วสัปดาห์ถัดมาก็มีบั๊กหลายตัวโผล่ในส่วนของโค้ดที่ยังไม่ได้ทดสอบ
ระหว่าง debug เพื่อนร่วมงานเผยออกมาว่าเขาคิดไปเองว่าผมน่าจะเขียนด้วย AI และบอกว่าการพยายามทำความเข้าใจสิ่งที่ AI สร้างขึ้นทีหลังนั้นน่าหงุดหงิด แต่โค้ดนี้ไม่ได้ใช้ AI แน่นอนว่าผมใช้ AI ในการเขียนโค้ดบ้าง แต่โค้ดนี้ผมเขียนด้วยมือตามการออกแบบภาพรวมที่คิดอย่างรอบคอบ บั๊กเหล่านั้นไม่ใช่ข้อบกพร่องพื้นฐานของการ refactor แต่เป็นการตกหล่นเล็ก ๆ น้อย ๆ ที่เกิดขึ้นตอนปรับโค้ดเดิมให้เข้ากับ API ที่เปลี่ยนไป
สุดท้ายมันกลายเป็น ประสบการณ์ที่ช่วยสร้างความไว้วางใจ เพราะผมกับเพื่อนร่วมงานได้พูดคุยถึงความตึงเครียดนั้นอย่างชัดเจน ถือว่าได้เผชิญกับพลังของสิ่งที่กำลังเกิดขึ้นในตอนนี้อย่างค่อนข้างนุ่มนวล เมื่อมองย้อนกลับไป ผมดีใจที่เรื่องคลี่คลายแบบนี้ และนึกภาพได้ว่าในสภาพแวดล้อมการทำงานแบบอื่น เรื่องอาจเละเทะกว่านี้มาก ต้องระวังให้ดี
ประมาณ 4 ปีก่อน ผมเคยทำเรื่องโง่ครั้งใหญ่ หนังสือพิมพ์ท้องถิ่นลงบทความกล่าวอ้างเรื่องเหลวไหลเกี่ยวกับบุคคลหนึ่ง โดยใช้รูปถ่ายเป็นหลักฐานสำคัญ และผมส่งอีเมลไปหา editor โดยตรง อธิบายว่าทำไมผมถึงมั่นใจว่าภาพถูกดัดแปลง ตรรกะของผมตั้งอยู่บนความเข้าใจผิดของตัวเอง ผมตีความผิดว่าบุคคลในภาพแทบไม่เปลี่ยนตำแหน่งและท่าทางเลยขณะโพสกับคนหลายคนในงาน meet-and-greet editor รู้สึกไม่พอใจและตอบกลับมาแบบล้อเลียนผม และเมื่อผมไม่ยอมถอย เขาก็รู้ว่าผมไม่ได้เป็นนักปลุกปั่น แต่แค่โง่ จึงแชร์ วิดีโอเต็มที่ยังไม่เผยแพร่ ซึ่งเป็นที่มาของภาพนั้นให้ดู ตอนนั้นผมขอโทษอย่างจริงจังและบริจาคเงินด้วย หลังจากนั้นอีก 1 ปี อัตตาของผมหดเล็กลงอย่างเหมาะสม
ก่อนส่งอีเมล ผมก็ไม่อยากกล่าวหาเท็จ จึงแชร์รูปให้เพื่อน ๆ ที่ใจเย็นดูและถามความเห็น พวกเขาก็สรุปว่ามีโอกาสสูงที่ภาพถูกดัดแปลง ผมเลยมั่นใจพอสมควร ตอนนี้ผมไว้วางใจหนังสือพิมพ์นั้นและคนที่เกี่ยวข้องโดยปริยาย แต่แค่จะทำให้คนคนเดียวเชื่อได้ก็ต้องใช้ความพยายามมากจริง ๆ
เข้าใจสมมติฐานตั้งต้นได้ยาก ถ้าเราเชื่อใจใครสักคนว่าเขาเขียนโค้ดได้ดี ความเชื่อนั้นเกิดจากการเรียนรู้ว่าโค้ดของคนนั้นทำงานได้ดี ไม่ใช่เพราะในใจของคนนั้นมีโมเดลทางความคิดโดยกำเนิดบางอย่างที่ “ผลิตโค้ดที่ดี” ได้
ถ้ามีคนใช้ LLM สร้างโค้ดที่ไม่มีบั๊ก ผมก็จะเชื่อใจ ถ้ามีคนใช้ LLM สร้างโค้ดที่มีบั๊กเยอะ ผมก็จะไม่เชื่อใจ แล้วมันต่างอะไรกับตอนที่คนนั้นเขียนโค้ดโดยใช้แต่สมองของตัวเอง?
เพราะ LLM ทำให้ยากมากที่จะตัดสินคุณภาพของนักพัฒนาที่ส่งแพตช์ได้ทันทีจากโค้ดที่ส่งมาอย่างเดียว ถ้าประเมินไม่ได้ว่าอีกฝ่ายเป็นคนประเภทไหน ก็ต้องกลับไปใช้แนวทาง “ไม่เชื่อใจ” และตรวจทุกอย่างอย่างละเอียดมาก กล่าวคือไม่มี “ทางลัดในการรีวิว” ที่ปลอดภัยอีกต่อไป และในที่ที่เคยพึ่งพาสัญญาณแบบนั้นเพื่อให้งานเดินต่อได้ เรื่องนี้อาจเจ็บปวดได้ ถ้าเป็นทีมที่มีความสามารถและความเชื่อใจสูงอยู่แล้ว ปัญหานี้จะไม่เข้าเค้า และตัวแนวคิดเองก็น่าจะรู้สึกแปลกใหม่
ถ้าผู้ร่วมพัฒนาอธิบายการเปลี่ยนแปลงได้ดี ก็เชื่อใจมากขึ้น ถ้าเคยทำงานยอดเยี่ยมมาก่อน ก็เชื่อใจมากขึ้น ถ้าจัดการหน่วยของการเปลี่ยนแปลงได้ดี เช่น คอมมิตที่สมเหตุสมผล ก็เชื่อใจมากขึ้น ถ้าเลือกแก้ปัญหาที่ถูกต้อง เช่น แก้บั๊กก่อนเพิ่มฟีเจอร์ใหม่ ก็เชื่อใจมากขึ้น ถ้าแสดงให้เห็นว่าดูแลรักษาโค้ดเดิมได้ ก็เชื่อใจมากกว่าแค่เขียนทับเพิ่มลงไปข้างบน ถ้ามีส่วนร่วมอย่างสม่ำเสมอ ก็เชื่อใจมากขึ้น
ปัญหามักเป็นความผิดพลาดในการสื่อสาร งานอาจชัดเจนสำหรับผู้ปฏิบัติ แต่เพราะ LLM รีเซ็ตบริบทบ่อย จึงรับประกันได้ยากว่ามันเข้าใจภาพรวมทั้งหมดด้วยหรือไม่ และถ้ามีจุดกำกวม มันก็มักตั้งสมมติฐานโง่ ๆ ได้ง่าย ผมคิดว่าวิธีที่ deep research ของ 4o ถามข้อมูลเพิ่มเติมก่อนทำอะไรบางอย่าง ควรกลายเป็นมาตรฐานในการสร้างโค้ดด้วย แบบนั้นจะช่วยป้องกันปัญหาเป็นกองภูเขาได้
บางกรณีก็เรียบง่าย เป็นแค่ว่ารูทีนนี้คืนค่าที่ต้องการหรือไม่ แต่สถานการณ์อื่นซับซ้อนกว่านั้นมาก เพราะต้องคาดการณ์ว่ามันจะโต้ตอบกับส่วนอื่นของระบบอย่างไร และมีกรณีขอบที่ไม่ค่อยสะดุดตาอะไรบ้าง ในสถานการณ์แบบนั้น การจะเขียนโค้ดที่ “ไม่มีบั๊ก” ได้ ผู้เขียนต้องเข้าใจนัยของโค้ด และถ้านักพัฒนาไม่เข้าใจว่าโค้ดที่ LLM เขียนทำอะไรอย่างแน่ชัด ก็ย่อมเข้าใจนัยเหล่านั้นไม่ได้เช่นกัน แล้วภาระนั้นก็จะตกไปอยู่ที่รีวิวเวอร์ ทำให้งานของรีวิวเวอร์เพิ่มขึ้น นั่นคือสมมติฐานตั้งต้น
หลักปฏิบัติที่ดีคือ งานที่มี LLM เกี่ยวข้องให้ปฏิเสธไปเลย และการสื่อสารที่ LLM เขียนก็ให้มองข้ามไปด้วย แม้แต่คนที่ใช้ภาษาอังกฤษเป็นภาษาต่างประเทศ ผมก็คิดว่าภาษาอังกฤษที่ “ไม่คล่อง” ของคนนั้นดีกว่าการให้ ChatGPT พูดแทนมาก เมื่อปัญหาร้ายแรงของ LLM ชัดเจนขึ้น ผมคิดว่านโยบายแบบนี้จะกลายเป็นมาตรฐานทั่วไป และก็หวังให้เป็นเช่นนั้น
LLM ทำให้งานแย่ๆ ทุกประเภทดูเหมือนเป็น งานที่ดีอย่างน่าเชื่อ ดังนั้นจึงสมเหตุสมผลที่จะลดน้ำหนักผลงานของคนที่ใช้ AI โดยอัตโนมัติ
เมื่อก่อนมีญาติคนหนึ่งของผมถูกเปิดโปงว่าเป็นนักต้มตุ๋น หลังถูกจับได้ ผมตัดการติดต่อและบอกว่าไม่รู้จักคนคนนั้น เขาพูดว่า “ฉันก็คือคนเดิมที่เธอรู้จักมาตลอด 10 ปีนั่นแหละ” ผมตอบว่า “ก็อาจจะใช่ แต่ตอนนี้ผมเพิ่งตระหนักว่าผมไม่เคยรู้เลยจริงๆ ว่าเขาเป็นใคร และต่อไปก็คงไม่มีทางรู้ได้”
เราทุกคนต่างสมมติว่าผู้คนในชีวิตไม่ได้พยายามทำร้ายเราอย่างแข็งขัน เมื่อความไว้วางใจนั้นแตก มันก็แตกอย่างรุนแรง คนที่ใช้ AI ไม่มีใครอ้างได้ว่า “นี่คืองานของฉัน” เพราะเราไม่อาจรู้ได้ว่านั่นเป็นงานของคุณจริงหรือไม่ คนที่ใช้ AI ก็ไม่อาจอ้างได้ว่ามันเป็นงานที่ดี เว้นแต่จะเข้าใจมันอย่างถ่องแท้ และก็น่าจะไม่ได้เข้าใจอย่างถ่องแท้ นักเรียนของผมจำนวนไม่น้อยอ้างว่าอ่านและเข้าใจสิ่งที่ผมเขียน แต่ผมพบว่าจริงๆ แล้วไม่ใช่เลย ถ้าผมเป็น AI และพวกเขาเอางานของผมไปใส่ชื่อตัวเองเป็นผู้เขียนล่ะ? พวกเขาจะอธิบาย ปกป้อง หรือทำงานต่อยอดอะไรไม่ได้เลย ปัญหาแบบนี้มีอยู่ก่อน AI แล้ว แต่ตอนนี้มันแย่ลงเป็นสิบเท่า
ผมเป็นคนที่ทุ่ม “มากกว่า 10,000 ชั่วโมง” ให้กับการเขียนโปรแกรมแอปพลิเคชันที่ซับซ้อน ก่อนจะมี LLM ที่ใช้งานได้จริงออกมา หลายปีที่ผมหมกมุ่นกับการฝึกฝนฟูลสแตกอย่างเต็มที่ ทุกคืนขุดคุ้ยเอกสารและซอร์สโค้ดของคนอื่น ในท้ายที่สุดความหมกมุ่นนั้นนำไปสู่ภาวะหมดไฟอย่างรุนแรง สุขภาพก็แย่ลง ชีวิตแต่งงานก็สั่นคลอน หลังจากปล่อยแอปพลิเคชัน ผมต้องวางมือทั้งหมดเป็นเวลา 3 ปีเพื่อฟื้นตัว และมั่นใจว่าจะไม่มีวันหยิบมันขึ้นมาอีก
หลังจากได้ยินเรื่องราวมากมายว่า LLM เริ่มเก่งเรื่องโค้ดพอสมควร ผมจึงค่อยๆ กลับมาหน้าคอมพิวเตอร์อย่างระมัดระวัง และตรงจุดนั้น ประสบการณ์ของผมก็แยกออกจากความกังวลข้างต้นอย่างมาก ผมไม่เห็นด้วยกับคำกล่าวที่ว่า “คนที่ใช้ AI ไม่อาจอ้างได้ว่า ‘นี่คืองานของฉัน’” เมื่อผมใช้ LLM ผมคือ ผู้ออกแบบและผู้ตรวจรับขั้นสุดท้าย ผมกำหนดวิสัยทัศน์ ออกแบบระบบ และตรวจทุกบรรทัดที่ LLM สร้างด้วยเครื่องมือ diff ไม่นานมานี้ผมสร้างโมเดล optimization ที่ซับซ้อนสำหรับเครื่องมือประเมินราคาในธุรกิจร่วมกับ LLM การใช้โมเดล optimization จริงๆ เป็นวิธีที่ “ถูกต้อง” เสมอมา แต่ถ้าเป็นเมื่อก่อนคงต้องทำงานหนักหลายเดือนเพื่อเรียนรู้รายละเอียดทุกอย่างของไลบรารีและอ่านโค้ดของคนอื่น ครั้งนี้ผมทำเสร็จในหนึ่งสัปดาห์ มันรู้สึกเหมือนงานของผมไหม? แน่นอนที่สุด เพียงแต่ผมมีผู้ช่วยที่ไม่เหนื่อย เก่งมาก แต่บางครั้งก็มีข้อบกพร่อง
ประสบการณ์ของผมยังตรงข้ามกับคำกล่าวที่ว่าผู้ใช้ “น่าจะไม่ได้เข้าใจอย่างถ่องแท้” ด้วย หากจะใช้ LLM อย่างมีประสิทธิภาพกับงานที่ไม่ใช่เรื่องเล็กๆ คุณจำเป็นต้องมีความเข้าใจพื้นฐานที่ลึกขึ้น เพื่อชี้นำ LLM และจับข้อผิดพลาดละเอียดอ่อนที่เกิดขึ้นบ่อย หากไม่มีประสบการณ์หลายปีของผม ผมคงไม่สามารถนำการพัฒนาแบบหลายโมดูลที่ซับซ้อน ดีบักผลลัพธ์ หรือรู้ได้ว่างานที่ดูดีอย่างน่าเชื่อนั้นจริงๆ แล้วผิดในลักษณะอย่างปัญหา N+1
ผมเห็นใจประสบการณ์ในฐานะครูของคุณ ปัญหาที่นักเรียนใช้เครื่องมือเหล่านี้ทำทีว่าเข้าใจนั้นเป็นเรื่องจริงและยาก ในแวดวงวิชาการ เป้าหมายคือกระบวนการเรียนรู้ หรือการได้มาซึ่งส่วนที่มีสาระสำคัญบางส่วนของ 10,000 ชั่วโมงนั้น แต่ในโลกวิชาชีพ เป้าหมายคือผลลัพธ์ และนี่คือเครื่องมือใหม่ที่ทรงพลังเพื่อให้ได้ผลลัพธ์ที่ดีกว่า ผมไม่รู้ว่าครูควรสอนนักเรียนอย่างไรในความจริงใหม่นี้ แต่การทำให้การใช้ LLM กลายเป็นปีศาจก็คงไม่ใช่วิธีที่ดีที่สุด
สำหรับผม สิ่งนี้ไม่ได้ทำให้งานแย่ดูดีขึ้น แต่มันทำให้ งานที่ยอดเยี่ยมกลับมาเป็นไปได้อีกครั้ง และในขณะเดียวกันก็ทำให้ผมได้ชีวิตคืนมา มันคืนความสุขของ craft อย่างการพัฒนาซอฟต์แวร์ให้ผม โดยไม่ต้องทำลายตัวผมและครอบครัว และตอนนี้ชีวิตก็สมดุลขึ้นมาก ผมจึงรู้สึกขอบคุณ
สำหรับผม มันเป็นแบบนั้นอยู่แล้ว ผมอ่านประโยค “ขอโทษที่มองข้ามไป คุณพูดถูกทั้งหมด” มาไม่รู้กี่ครั้ง ประมาณ 8–9 ครั้งจาก 10 ครั้ง
อีกด้านหนึ่ง ผมยังเห็นคนคัดลอกโค้ดที่ LLM แบบเสียเงินสร้างขึ้นมาแบบไม่คิดอะไร แล้วพอไม่ทำงานตามที่คาดก็เดือดดาล อนึ่ง นั่นยังเป็นทางเลือกที่ดีกว่า เพราะ พังอย่างชัดเจน ยังดีกว่าสิ่งที่ภายนอกดูเหมือนทำงานได้
ถึงอย่างนั้น prediction engine ก็ยังทำวิศวกรรมจริงๆ ไม่ได้ ถ้าไม่สั่งอย่างเจาะจงให้ใช้สิ่งอย่าง Python generator ก็มีโอกาสสูงที่จะได้โค้ดที่กินหน่วยความจำมหาศาล น่าเสียดายที่ก็ไม่ได้ต่างจากโปรแกรมเมอร์ Python หลายคนที่ผมรู้จักมากนัก แต่นี่ก็เป็นตัวอย่างที่แย่ตรงตามที่พูดถึง LLM เช่นกัน ด้านบวกคือมันทำให้ผู้คนเขียนสเปกงานจริงๆ ที่ละเอียดกว่าบรรทัดเดียวว่า “เพิ่มฟีเจอร์”
จุดที่ AI agent มีประโยชน์ที่สุดสำหรับเราคือ โค้ดเลกาซี ที่ไม่มีใครจัดลำดับความสำคัญไว้ เรามีตัวดึงข้อมูลที่เขียนขึ้นในสหัสวรรษก่อน ใช้พิกัดที่ฮาร์ดโค้ดไว้ราว 200 จุดเพื่อดึงข้อมูลจากเอกสารประเภทหนึ่งที่เข้ามาทางแฟกซ์ เอกสารนั้นแทบไม่เปลี่ยนมา 30 ปีจึงทำงานได้ดี แต่ล่าสุดมันเปลี่ยน และ Copilot ใช้เวลาประมาณ 30 วินาทีในการแก้พิกัด ถ้าให้คนทำคงเป็นงานทั้งวันที่น่าเบื่อสุดๆ อย่างไรก็ตาม ผมไม่รู้เลยว่าอุตสาหกรรมของเราคิดจะบ่มเพาะผู้เชี่ยวชาญอย่างไรในยุค vibe coding
การต่อสู้กับ LLM ก็เหมือนปัสสาวะสวนลม
LLM ในรูปแบบปัจจุบันดูเหมือนจะทำให้นักพัฒนามีประสิทธิภาพมากขึ้น และอาจให้ประโยชน์กับนักพัฒนาที่มีประสบการณ์น้อยมากกว่านักพัฒนาที่ชำนาญด้วยซ้ำ การเพิ่มผลิตภาพ หรืออาจเป็นการเพิ่มผลิตภาพหลายเท่าตัว จะไม่ถูกละทิ้งเพราะอุปสรรคที่คนซึ่งต่อต้านเทคโนโลยีด้วยเหตุผลบางอย่างตั้งขึ้นมา
ต่อให้มีตัวอย่างที่เครื่องมือเพิ่มผลิตภาพตัวใหม่ก่อความเสียหายมหาศาล เช่น เกิดบั๊กที่ทำให้บริการขนาดใหญ่ล่มเป็นเวลานาน หากเทคโนโลยีนั้นให้ผลิตภาพได้มากพอ มันก็จะไม่หยุดลง หนทางที่สมเหตุสมผลเพียงอย่างเดียวคือทำงานร่วมกับเทคโนโลยีและบรรเทาจุดอ่อนของมัน และมาตรการบรรเทานั้นไม่ควรเป็นชุดกฎที่ลบล้างประโยชน์ด้านผลิตภาพของเทคโนโลยีใหม่ไปหมด มาตรการบรรเทาควรทำงานร่วมกับเทคโนโลยีในทิศทางที่เพิ่มการนำเทคโนโลยีไปใช้ ไม่อย่างนั้นมันก็จะถูกเลี่ยง
จากประสบการณ์ของผม คนที่ยืนยันหนักแน่นว่า LLM ทำให้ผลิตภาพเพิ่มขึ้น 10 เท่า มักเป็นนักพัฒนา front-end ที่ค่อนข้าง junior หรือเป็นนักพัฒนา startup แบบ serial ที่คอยสร้างแอปใหม่ตั้งแต่ศูนย์อยู่เรื่อย ๆ แน่นอนว่านั่นเป็น use case ที่สมเหตุสมผลโดยสิ้นเชิง แต่ด้วยเหตุนี้ นักพัฒนา front-end ระดับ junior กับนักพัฒนา embedded C ระดับ senior จึงมักคุยกันคนละเรื่องเมื่อพูดถึงการเพิ่มผลิตภาพด้วย AI
แทนที่จะบอกว่าการทำงานร่วมกับเทคโนโลยีและบรรเทาจุดอ่อนของมันเท่านั้นที่สมเหตุสมผล แค่ใช้มันอย่างมีวิจารณญาณมากขึ้นก็พอ ตัวอย่างเช่น แนวคิดเรื่อง AI “agent” เองดีจริงหรือไม่? เหตุการณ์ Copilot ล่าสุด[0] ทำให้ MS และ AI ดูเหมือนกลายเป็นเรื่องตลก ความพยายามที่จะให้ AI ทำงานอย่างอิสระเองอาจไม่ใช่เรื่องฉลาดนัก
อุปมาใกล้เคียงในช่วงหลังก็คือ blockchain และคริปโตเคอร์เรนซี ไม่ว่าจะชอบหรือไม่ ความสำเร็จของ Coinbase เป็นต้น แสดงให้เห็นชัดว่า blockchain พบ use case ที่มีอยู่จริงแต่แคบมาก อย่างไรก็ตาม ในช่วงคริปโตบูม มีคนพูดทำนองว่า “จะติดตาม supply chain ของเมล็ดกาแฟด้วย blockchain” ในปี 2025 มันฟังดูเหมือนมุกล้อเลียนเกินจริงบน Twitter แต่ในปี 2020 IBM พยายามขายสิ่งนี้จริง ๆ[1] สักวันหนึ่งเมื่อมองย้อนกลับไป เราอาจเห็นว่า AI agent หรือบางแอปพลิเคชันของ generative AI ในปัจจุบันคือ blockchain สำหรับกาแฟ ของฟองสบู่นี้
[0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
[1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
แต่นี่ไม่ได้หมายความว่าการจับคู่โมเดล/มนุษย์ตอบสนองความต้องการของผู้ใช้ได้มีประสิทธิผลมากขึ้น มันหมายถึงผลิต “โค้ดมากขึ้น” ไม่มี LLM ตัวไหนปล่อย ชุดการเปลี่ยนแปลงที่ลบโค้ด 2,000 บรรทัด ออกมา ดังนั้นเราจึงรู้ได้ว่าคำว่า “ทำให้วิศวกรมีผลิตภาพมากขึ้น” เป็นเรื่องของปริมาณโค้ดที่ถูกสร้างขึ้น
ราวกับว่าคุณกำลังเสนอให้เป็นประเด็นสองขั้วว่าใช้ LLM หรือไม่ใช้ แต่ผู้เขียนพูดถึง การบรรเทาความเสี่ยง เป็นหลัก เปรียบเทียบได้ว่า ผู้เขียนแค่ชี้ว่ารถยนต์บางคันระเบิด และบอกว่าม้าในอดีตไม่ระเบิด ดังนั้นก่อนจะเปิดโรงงานกาว เราควรทำให้รถยนต์ระเบิดน้อยลงก่อน แต่คุณกลับดูเหมือนมองว่าผู้เขียนคัดค้านการพัฒนารถยนต์โดยพื้นฐาน
ตอนนี้ผมก็ยังมีความรู้สึกไม่อยากใช้ GPT อยู่ แต่ช่วงหลังเพื่อนร่วมงานมักพูดว่า “ChatGPT บอกว่า” หรือ “โค้ดนี้ ChatGPT เป็นคนสร้าง” ผมภูมิใจที่เขียนโค้ดเองและไม่ใช้ GPT แต่ในขณะเดียวกันผมก็ใช้ Google กับ Stack Overflow อยู่เหมือนกัน จะบอกว่านั่นก็เป็น GPT เวอร์ชันที่ช้ากว่าก็คงได้
ดูเหมือนผู้เขียนจะพลาดประเด็นที่ว่า แม้แต่ตัวกระทำที่ไม่สมบูรณ์และเป็นเชิงความน่าจะเป็น ก็สามารถสร้าง ระบบเชิงกำหนดที่เชื่อถือได้ ได้
เราคงไม่ได้เชื่อถือเครื่องมือ garbage collection ในแง่ความน่าเชื่อถือแบบเดียวกับผู้เขียน แต่จะเชื่อเมื่อเห็นว่าหลังจากการทดสอบอย่างกว้างขวาง มันพิสูจน์ได้ว่าทำงานตามที่ตั้งใจไว้ ในอนาคตจินตนาการได้ไม่ยากว่าความเชื่อใจจะอ่อนลง และผลก็คือการพัฒนาแบบขับเคลื่อนด้วยการทดสอบน่าจะได้รับแรงส่งมากขึ้น อย่าเชื่อ ต้องตรวจสอบ
คำถามที่สำคัญกว่าคือ แล้วใครเป็นคนทดสอบตัวเทสต์เอง ในการพัฒนาแบบดั้งเดิม ตรรกะทั้งหมดจะถูกทำซ้ำสองครั้ง ครั้งหนึ่งในโค้ด อีกครั้งในเทสต์ เทสต์ตรวจสอบโค้ด และในทางกลับกัน โค้ดก็ตรวจสอบเทสต์โดยปริยาย กรณีที่บั๊กอยู่ในเทสต์ ไม่ใช่ในโค้ดแอปพลิเคชันนั้นพบได้ค่อนข้างบ่อย เราไม่สามารถเชื่อเทสต์แบบมืดบอด แล้วรอจนกว่าเอเจนต์จะหาวิธีคัดลอกบั๊กของเทสต์เข้าไปในโค้ดได้
ถ้ายกตัวอย่าง garbage collection แน่นอนว่าสักวันระบบแบบเอเจนต์อาจตั้งอะไรบางอย่างขึ้นมา แล้วทุบปรับด้วย test harness และการแก้บั๊กจนพอใช้งานได้ แต่ลองจินตนาการว่าคุณใช้โมเดลเป็น garbage collector/เครื่องมือนั้นเอง เช่น ทุกครั้งที่ sweep ก็โยนหน่วยความจำของโปรแกรมเข้าไปในโมเดลแล้วสั่งให้ปล่อยบล็อกที่ไม่จำเป็น คุณไม่มีทางเชื่อได้เลยว่าโมเดลจะระบุบล็อกหน่วยความจำที่ถูกต้องได้อย่างแม่นยำ และไม่ว่า “แพตช์” หรือ “การ fine-tune” แบบใดก็ไม่น่าพาไปถึงจุดนั้นได้
ใน abstraction รุ่นก่อน ๆ อย่าง JVM ถ้าเอาต์พุตเชิงกำหนด เช่น assembly ที่ JIT ปล่อยออกมาในกรณีนี้ ผิดพลาด บั๊กนั้นก็จะถูกแพตช์ และ abstraction นั้นจะไม่เกิดข้อบกพร่องเดิมอีก LLM ไม่ใช่แบบนั้น เวลาพูดถึงเครื่องมือพัฒนารุ่นก่อนที่เปลี่ยนธรรมชาติของทั้งอุตสาหกรรม สำหรับผมความต่างนี้สำคัญมาก ผมไม่ได้บอกว่า LLM จะไม่ส่งผลอย่างลึกซึ้งต่อวิธีการทำงานในอนาคต เพียงแต่มองว่าเรากำลังเข้าสู่ดินแดนที่ไม่รู้จักอย่างสิ้นเชิง ซึ่งแทบไม่มีกรณีในประวัติศาสตร์ให้เทียบ
ส่วนที่บอกว่า test-driven development จะได้แรงส่งมากขึ้น ผมก็ไม่เข้าใจว่าทำไม TDD ถึงถูกยกขึ้นมาเสมือนกระสุนเงินที่แก้ปัญหาทั้งหมดของการสร้างซอฟต์แวร์อยู่เรื่อย ๆ จำนวนครั้งที่ผมเห็น TDD เริ่มจากเทสต์ที่ผิด แล้วสร้างซอฟต์แวร์ที่ผิดตามนั้น พูดตามตรงก็น่าอายทีเดียว
ควรกำหนดสิ่งส่งมอบ ไม่ใช่กำหนดกระบวนการ การคาดหวังให้ผู้มีส่วนร่วมเข้าใจแพตช์เป็นแนวคิดที่ดี
แต่การแนะนำหรือบังคับให้ junior หลีกเลี่ยงเครื่องมือช่วยเหลือด้วย LLM ไปสักพักในช่วง onboarding เป็นความคิดที่แย่มาก ช่วง onboarding มี ปัญหาการตั้งค่าสภาพแวดล้อม แบบสุ่ม ๆ เยอะ และ LLM มักค่อนข้างเก่งกับเรื่องพวกนี้ อีกทั้งยังเป็นการตามโค้ดและเอกสารให้ทัน และยังมีเครื่องมือค้นหา/สรุปข้อความดี ๆ ที่น่าแชร์ด้วย
ดูเหมือนชัดเจนมากว่า หากคุณทำให้ความยากและความซับซ้อนทั้งหมดในชีวิตเรียบลื่นหายไปหมด ไม่นานนักเมื่อคุณเจอความยากหรือความซับซ้อน คุณก็จะไม่รู้เลยว่าควรทำอะไร มีแค่ผมที่คิดแบบนี้หรือเปล่า?
ผมเพิ่งเคยได้ยินปรากฏการณ์ที่ผู้เขียนเรียกว่า หน้าผา AI ซึ่งหมายถึง LLM “ประมาณคำตอบที่ใกล้เคียงความถูกต้องได้อยู่ช่วงหนึ่ง แล้วพอเวลาผ่านไปความแม่นยำก็ร่วงฮวบ” คนอื่นเคยเจอไหม?
generator ปัจจุบันมีแนวโน้มทำให้สิ่งต่าง ๆ ซับซ้อนขึ้นเรื่อย ๆ มากกว่าทำให้ง่ายลง ผมมักเป็นฝ่าย prompt ให้ LLM refactor ให้ง่ายขึ้น หรือ refactor เองเมื่อมันซับซ้อนเกินกว่าที่ LLM จะรับไหว ดังนั้นอย่างน้อยสำหรับ LLM รุ่นปัจจุบัน ถ้าคุณแค่ “ปล่อยสายบังเหียนให้ LLM” แล้วให้มันทำตามใจ สุดท้ายมันค่อนข้างหลีกเลี่ยงไม่ได้ที่จะสร้าง ความเละเทะแบบเครื่องกล Rube Goldberg ขนาดมหึมา แล้วคุณก็ต้องพยายามไปเก็บกวาด
เชื่อมกับใจความของบทความ คนที่มีประสบการณ์จะสังเกตได้เร็วว่า LLM เริ่มพาคุณออกทะเลไปไกล และถึงจะออกไปไกลบ้างก็ยังหาทางกลับสู่น้ำตื้นได้ ส่วนมือใหม่จะหลุดออกนอกระดับความลึกของตัวเองและหลงอยู่กลางทะเล ก่อนจะรู้ด้วยซ้ำว่าเกิดอะไรขึ้น
ลองนึกว่ามี 10,000 โทเค็นใน context input ที่ถูกต้อง 99% ทุกครั้งที่ LLM ตอบ มันเพิ่มอีก 1,000 โทเค็นที่ถูกต้อง 90% หลังจากโต้ตอบกันไม่กี่รอบและแก้ LLM ไปมา context window ก็จะเต็มไปด้วยเศษเอาต์พุตของ LLM เองเป็นส่วนใหญ่ ที่แย่กว่านั้นคือข้อผิดพลาดสะสมขึ้น แม้ส่วนที่ถูก 90% ก็เป็นเพียงการ extrapolate อย่างถูกต้องจากการอภิปรายเกี่ยวกับโค้ดที่ผิด และ LLM ก็ให้น้ำหนักกับโทเค็นล่าสุดมากกว่า ปัญหาเดียวกันนี้เกิดในงานร้อยแก้วด้วย
ในโมเดลแบบ reasoning ปัญหานี้อาจยิ่งเลวร้ายกว่าเดิม เพราะกระบวนการคิดทั้งหมดอยู่ใน context และถ้าความคิดออกนอกลู่นอกทางจริง ๆ มันจะปลูกเมล็ดพิษที่ป้อนให้การผุพัง อยากให้มีการทำ context pruning ในรูปแบบใดรูปแบบหนึ่ง เพื่อจะตัด context ที่ไม่เกี่ยวข้องเมื่อมันเกิดขึ้นได้ ตอนนี้ถ้ารู้สึกว่าเริ่มมีการผุ ผมจะทำสรุปแล้วย้ายไป instance ใหม่
ในเครื่องมือแบบเอเจนต์อย่าง claude code, codex, gemini cli ปัญหานี้น้อยกว่ามาก เพราะเครื่องมือเหล่านี้จัดการ context window ของตัวเองได้ และรันเครื่องมือพัฒนาเพื่อ sanity check ตัวเองได้
กระบวนการนี้ฝึกนิสัยให้เราบันทึกสถานะงานปัจจุบันเป็นเอกสาร เพื่อให้เอเจนต์ใหม่ตามทัน