AI: ความไร้ความสามารถที่ถูกเร่งให้เร็วขึ้น
(slater.dev)- ในวิศวกรรมซอฟต์แวร์ การพึ่งพา LLM มากเกินไปอาจช่วยเพิ่มความเร็วในระยะสั้น แต่ทำให้ การคิดเชิงวิพากษ์ และความสามารถในการแก้ปัญหาอ่อนแอลง
- ความเสี่ยงที่ใหญ่กว่าผลลัพธ์ผิดพลาด คือการยอมรับพรอมป์ต์ที่มีข้อบกพร่องตามเดิม และทำให้ หนี้ทางเทคนิค กับความสามารถของผู้ใช้ที่ลดลงสะสมอย่างรวดเร็ว
- เนื่องจาก LLM ในปัจจุบันไม่สามารถจดจำหรือทำให้ ทฤษฎีของโปรแกรม กลายเป็นความเข้าใจภายในได้เกินกว่าหน้าต่างคอนเท็กซ์ พื้นที่ของแบบจำลองทางความคิดร่วมกันที่จำเป็นต่อการออกแบบและการบำรุงรักษาจึงยังคงเป็นของวิศวกรมนุษย์
- ความซับซ้อนเพิ่มขึ้นอย่างต่อเนื่องในกระบวนการบำรุงรักษา และ LLM ซึ่งเป็นตัวทำนายโทเค็นในระดับข้อความ อาจเพิ่ม เอนโทรปีของโปรแกรม ผ่านการเปลี่ยนแปลงที่ไม่จำเป็นหรือแปลกประหลาด
- AI ใช้เป็นเครื่องมือได้ แต่ไม่ควรพึ่งพาเหมือนไม้ค้ำยัน และยังต้องลงทุนต่อไปกับ ทักษะวิศวกรรมพื้นฐาน และการคิดอย่างลึกซึ้งที่ยังมีคุณค่าอยู่ในปี 2019
ความเสี่ยงทางวิศวกรรมจากการพึ่งพา LLM
- ท่าทีที่เรียก LLM ว่าเป็น “เพื่อน” นั้น ใกล้เคียงกับถ้อยคำอ้อมค้อมที่บอกว่ามันให้ประโยชน์กับผู้ใช้ มากกว่าจะเป็นเพื่อนร่วมทางจริงๆ
- วิศวกรที่มองแบบนี้มักให้ความสำคัญกับ ความเร็ว ก่อน หรือถูกกดดันให้ต้องให้ความสำคัญกับความเร็ว
- LLM สามารถสร้างโค้ดจำนวนมากได้อย่างรวดเร็ว แต่การใช้งานมาพร้อม ความเสี่ยง แบบหางยาว
ความเสี่ยงห้าประการที่เห็นได้จากการสร้างโค้ด
-
ความเสี่ยงด้านเอาต์พุต
- LLM อาจให้ผลลัพธ์ที่ผิดอย่างชัดเจน เช่น โค้ดที่คอมไพล์ไม่ผ่าน
- กรณีที่อันตรายกว่าคือผลลัพธ์ที่ผิดแบบละเอียดและตรวจจับยาก เช่น logical bug
- ความเสี่ยงจะยิ่งมากขึ้นเมื่อผู้เขียนพรอมป์ต์ไม่มีคุณสมบัติพอจะประเมินผลลัพธ์ได้
- มีตัวอย่างสถานการณ์ที่ผู้จัดการโครงการร้องขอซอร์สโค้ด
-
ความเสี่ยงด้านอินพุต
- LLM จะไม่คัดค้านพรอมป์ต์ที่เป็นคำถามชี้นำ มีสมมติฐานผิด หรือมีบริบทไม่ครบ
- ตัวอย่างเช่น คำขอว่า “ช่วยเขียนการทำงานของรายการแบบ thread-safe ใน C#” อาจได้โค้ดที่ดูน่าเชื่อถือยาว 200 บรรทัด แต่คำถามที่แท้จริงอาจเป็น “ต้องทำอย่างไรให้โค้ดนี้ thread-safe?”
- ในกรณีนี้ คำตอบอาจเป็นโค้ดเพียงบรรทัดเดียวที่ใช้
System.Collections.Concurrent - เพราะไม่ได้ถูกขอให้ทำเช่นนั้น LLM จึงไม่สามารถรับรู้ได้ว่านี่คือกรณีของ XY Problem
-
ความเร็วในอนาคตที่ลดลง
- LLM สามารถลดคุณภาพของ codebase ได้อย่างรวดเร็วมาก
- หากไม่มี guardrail ที่แข็งแรง โค้ดที่ LLM สร้างอาจดูเหมือนปกติภายนอก แต่ภายในกลายเป็นพื้นที่ที่ไร้สุขลักษณะและใช้งานจริงไม่ได้
- เรื่องนี้ถูกมองว่าเร่งด่วนกว่าการถกเถียงเรื่องหนี้ทางเทคนิคทั่วไป
-
การทำให้ผู้ใช้กลายเป็นเด็ก
- ในบุคคลและองค์กรที่ยกภาระการคิดกับการแก้ปัญหาให้ LLM ความสามารถอาจค่อยๆ หายไป
- วิศวกรอาวุโสอาจสูญเสียโอกาสในการเรียนรู้ผ่านการต่อสู้อย่างมีคุณค่า ทำให้ความสามารถในการแก้ปัญหาและการคิดเชิงวิพากษ์อ่อนแอลง
- วิศวกรจูเนียร์อาจไม่ได้พัฒนาความสามารถเหล่านั้นตั้งแต่แรก และต่อมาก็ยากจะเป็นพี่เลี้ยงให้จูเนียร์รุ่นถัดไป
- ThoughtWorks Technology Radar Volume 32 กล่าวถึงกรณีที่ความมั่นใจจาก AI เกิดขึ้นโดยแลกกับการเสียการคิดเชิงวิพากษ์
- Coding as Craft: Going Back to the Old Gym เน้นการทำงานร่วมกับ AI อย่างตั้งใจเพื่อรักษาการเขียนโค้ดในฐานะงานฝีมือ
- Thoughts on Thinking มองว่า LLM อาจให้ความคิดที่เสร็จแล้วได้ แต่ไม่ก่อให้เกิดการเติบโตทางปัญญาที่พัฒนาขึ้นด้วยตนเอง
-
การสูญเสียความสนุก
- นักพัฒนาหลายคนรายงานว่าการใช้ AI ดึงเอาสภาวะจดจ่อและความสุขจากการสร้างสรรค์ออกไป
- โค้ดที่ AI สร้างอาจกลายเป็นโค้ดที่อ่านและแก้ไขอย่างทรมาน
- มีการเชื่อมโยงไปยังบทความ The Hidden Cost of AI Coding
สองทักษะที่ LLM ทดแทนไม่ได้
- เพื่อตอบความกังวลว่าวิศวกรที่มีทักษะจะหมดความจำเป็นเพราะ AI ทักษะการเขียนโปรแกรมที่ LLM มอบให้ไม่ได้ถูกสรุปไว้สองอย่าง
- ทักษะเหล่านั้นคือ ทฤษฎีของโปรแกรม และ เอนโทรปีของโปรแกรม
ทฤษฎีของโปรแกรม: โค้ดไม่ใช่ตัวโปรแกรมเอง
- Programming as Theory Building ของ Peter Naur มองการเขียนโปรแกรมว่าเป็นกิจกรรมของการสร้างความเข้าใจหรือทฤษฎีต่อปัญหา
- ในมุมมองของ Naur โปรแกรมไม่ใช่ซอร์สโค้ด แต่เป็นโครงสร้างทางความคิดที่ใช้ร่วมกัน หรือก็คือ ทฤษฎี หรือการออกแบบ
- โค้ดเป็นสิ่งที่สืบเนื่องมาจากการออกแบบนั้น แต่ผลลัพธ์ที่มีคุณค่าอยู่ที่การออกแบบมากกว่าโค้ด
-
การทดลองทางความคิดของสองทีม
- ทีม A และ B ซึ่งมีความสามารถเท่ากัน อยู่ในห้องแยกกันโดยไม่สื่อสารกัน
- ทีม A เขียนโปรแกรมอย่างเกมหมากรุกบนเทอร์มินัล ส่วนทีม B รออยู่หรือเล่นหมากรุกจริง
- หลังทีม A ทำเสร็จ ซอร์สโค้ดจะถูกส่งให้ทีม B และทั้งสองทีมต้องเพิ่มฟังก์ชันอย่างผู้เล่นหมากรุกเสมือน
- ทีมที่จะให้ทางออกที่ดีกว่าคือทีม A
- ทีม A มี แบบจำลองทางความคิด ที่สดใหม่ของโปรแกรมที่เพิ่งสร้างขึ้น
- ทีม B ไม่มีแบบจำลองเช่นนั้น
- โปรแกรมยังคงถูกแก้ไขต่อเนื่องหลังการสร้างครั้งแรก ดังนั้นหากมีเพียงซอร์สโค้ดแต่ไม่มีความเข้าใจต่อการออกแบบที่ถูกทำให้เป็นส่วนหนึ่งของตัวเอง ต้นทุนของการเปลี่ยนแปลงจะสูงขึ้น
- สิ่งนี้เชื่อมโยงกับประสบการณ์ที่เมื่อเข้าไปใน codebase ขนาดใหญ่เดิมครั้งแรก ผลิตภาพแทบเป็นศูนย์ ก่อนจะค่อยๆ สูงขึ้นเมื่อบรรจุทฤษฎีของโปรแกรมไว้ในหัว
-
LLM กับทฤษฎีของโปรแกรม
- LLM ในปัจจุบันไม่สามารถจดจำสิ่งที่เกินกว่าหน้าต่างคอนเท็กซ์ได้ จึงไม่อาจเชี่ยวชาญทฤษฎี การออกแบบ หรือโครงสร้างทางความคิด
- สิ่งมีชีวิตที่สามารถได้มาและรักษา ทฤษฎีของโปรแกรม ไว้ได้คือมนุษย์
เอนโทรปีของโปรแกรม: ความสามารถในการลดหรือทานความซับซ้อน
- ความซับซ้อนเป็นแรงพื้นฐานที่ต่อต้านการเขียนโปรแกรม และเกี่ยวข้องกับเอนโทรปี
- The Mythical Man-Month ของ Fred Brooks มองการสร้างโปรแกรมเป็นกระบวนการลดเอนโทรปี และการบำรุงรักษาเป็นกระบวนการเพิ่มเอนโทรปี
- ในมุมมองของ Brooks หลังจากสร้างเสร็จครั้งแรก การเปลี่ยนแปลงโปรแกรมย่อมทำให้ซอร์สโค้ดซับซ้อนขึ้น
- อย่างไรก็ดี การเปลี่ยนแปลงที่สอดคล้องกับการออกแบบสามารถชะลออัตราการเพิ่มของความซับซ้อนได้
-
LLM กับเอนโทรปีของโปรแกรม
- LLM เป็น ตัวทำนายโทเค็น และทำงานได้เพียงในระดับข้อความ
- LLM ไม่สามารถให้เหตุผลในระดับแนวคิด เช่น ไอเดีย ไดอะแกรม หรือข้อกำหนดความต้องการ
- ใครก็ตามที่เคยใส่ก้อนโค้ดขนาดใหญ่ให้ LLM จะเห็นแนวโน้มที่มันมักใช้การเปลี่ยนแปลงที่ไม่จำเป็นและแปลกประหลาด
- ยิ่งบทสนทนายาว ผลลัพธ์ก็อาจยิ่งออกนอกลู่นอกทาง
- ความสามารถในการลดความซับซ้อนของโค้ดหรือทานต่อความซับซ้อนนั้นเป็นของมนุษย์
วิธีใช้ AI ในงานวิศวกรรม
- หากเคยคาดหวังว่า AI จะยกระดับอาชีพวิศวกรรมของคุณไปอีกขั้น มันอาจให้ผลในทางตรงกันข้าม
- LLM อาจเร่งความไร้ความสามารถ แต่ไม่อาจแทนที่วิศวกรรมของมนุษย์ได้
- เสน่ห์ทางธุรกิจของ AI อยู่ที่การทำให้งานวิศวกรรมกลายเป็นสินค้าและลดต้นทุน
- อย่างไรก็ตาม เช่นเดียวกับการใช้บุคลากรวิศวกรรมจากต่างประเทศที่ให้ผลลัพธ์แบบผสม LLM ก็มีทั้งข้อจำกัดและความเสี่ยง
- วงจร hype ของ AI อาจไปถึงจุดสูงสุดในที่สุด
- บริษัทที่ใช้ AI มากเกินไปในตอนนี้จะต้องแบกรับต้นทุนระยะยาว และอาจต้องเปลี่ยนทิศทางหรือหายไป
- คุณค่าระยะยาวของมนุษย์ในงานวิศวกรรมไม่ได้เปลี่ยนไป
- โลกยังคงต้องการความสามารถทางเทคนิคและการคิดอย่างลึกซึ้ง
- และพร้อมจะจ่ายให้กับความสามารถเหล่านั้น
- AI จะยังคงอยู่ต่อไป แต่ต้องใช้ในฐานะ เครื่องมือ และไม่ควรพึ่งพาเหมือนไม้ค้ำยัน
- ต้องลงทุนต่อไปกับทักษะวิศวกรรมพื้นฐานที่เคยถูกมองว่ามีคุณค่าในปี 2019
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
บางครั้งวาทกรรมเรื่องการเขียนโค้ดด้วย AI ให้ความรู้สึกเหมือนสะท้อนความแตกต่างระหว่าง วิศวกรซอฟต์แวร์ กับ นักวิทยาศาสตร์ข้อมูล/วิศวกรแมชชีนเลิร์นนิง
ทั้งสองฝ่ายต่างต้องรับมือกับข้อกำหนดที่ไม่ชัดเจนและบั๊กที่จับยาก แต่โดยทั่วไปวิศวกรซอฟต์แวร์สร้างซอฟต์แวร์ที่ต้องทำงานในรูปแบบที่กำหนดเสมอ และความสามารถในการทำซ้ำ การทดสอบ รวมถึงเครื่องมือที่สุกงอมแล้วมีความสำคัญ
ในทางกลับกัน วิศวกรแมชชีนเลิร์นนิงรับมือกับโมเดลที่โดยแก่นแท้เป็นเชิงความน่าจะเป็น และการทดสอบก็เน้นตัวชี้วัดการประเมินอย่าง “ให้ผลลัพธ์ถูกต้องใน 90% ของกรณี” มากกว่าการดูว่าให้เอาต์พุตเฉพาะเจาะจงหรือไม่
ดังนั้นกรอบคิดในการรับมือกับ AI ที่ไว้ใจไม่ได้เสมอจึงเป็นธรรมชาติกับฝั่งแมชชีนเลิร์นนิงมากกว่า และทำให้ประเมินผู้ช่วยเขียนโค้ดในทำนองว่า “มันถูก 80% ช่วยลดงานได้ แล้วอีก 20% ฉันค่อยจับเอง”
ตอนทำงานที่ Amazon มักมีหลายกรณีที่โซลูชันบนฐานแมชชีนเลิร์นนิงเหมาะกับปัญหาจริงที่ไม่มีวิธีแบบคลาสสิก เช่น การทำนายการเคลื่อนที่ บนแผนที่กริด หรือการจำแนกภาพ/แผนที่กริด ซึ่งผสานเข้ากับไปป์ไลน์การประมาณค่าและการควบคุมที่มีอยู่ได้ดีและมีประโยชน์
กลับกัน ที่สตาร์ทอัพแห่งหนึ่ง ผมถูกผู้จัดการระดับล่างตำหนิอยู่เรื่อย ๆ เพียงเพราะสงสัยแนวทางบนฐานการเรียนรู้สำหรับปัญหาการประมาณทิศทางของระนาบที่อยู่นิ่งตามเวลา เพราะทีมไม่รู้พื้นฐานของการทำแผนที่หรือการกรอง และสมมติว่า “ใส่ข้อมูลเพิ่มก็แก้ได้” ทำให้ไปป์ไลน์ควบคุมรถทั้งชุดต้องรับค่าประมาณการหมุนแบบสุ่มที่กะพริบและกระตุก
ช่องว่างนี้ใหญ่จริง ๆ และถ้ามีวิธีคัดกรองในการสัมภาษณ์ให้ดีกว่านี้ก็คงดี
ก่อนหน้านี้ผมได้ยินสถาปนิกอาวุโสของบริษัทบ่นหลังประชุมว่า ผลิตภัณฑ์ของบริษัทเราขายได้ด้วยจุดเด่นเรื่อง ความแม่นยำและความถูกต้อง มาโดยตลอด แต่ทีมแมชชีนเลิร์นนิงจากออฟฟิศอีกแห่งไม่เข้าใจเรื่องนั้น และคิดว่าความแม่นยำ 80–90% ก็เพียงพอสำหรับลูกค้า
ทำให้นึกถึงข้อถกเถียงว่าอัตราการเสียชีวิต 1% ของโรคระบาดนั้นน้อยหรือมาก เลข 1 เป็นจำนวนเต็มที่เล็กที่สุดก็จริง แต่ 1% ของ 300 ล้านคนคือ 3 ล้านคน
แต่ผมคิดว่าบทความนี้ไม่ได้พูดแค่นั้น บทความกล่าวถึงความกังวลระดับเมตาของคนที่ทำวิศวกรรมซอฟต์แวร์ และ AI เข้าไปอยู่ในนั้นอย่างไร และตอนที่พูดถึง “เอนโทรปีของโปรแกรม” ก็ชี้ตรงประเด็น
ส่วนใหญ่ของการสร้างผลิตภัณฑ์ซอฟต์แวร์คือการจัดการเอนโทรปี เพิ่มทั้งโค้ดและคน แต่ยังรักษาความเร็วในการเดินหน้าให้เหมาะสม และทำให้ทุกคนเข้าใจว่าชิ้นส่วนต่าง ๆ ประกอบกันอย่างไรและจะเพิ่มชิ้นใหม่เข้าไปอย่างไร สักวัน AI อาจทำให้สิ่งนี้ง่ายขึ้น แต่ตอนนี้หลายครั้งกลับทำให้เอนโทรปีแย่ลง
เรื่องนี้คงไม่ใช่ปัญหาใหญ่ ถ้าไม่มีผู้มีส่วนได้ส่วนเสียพยายามโน้มน้าวว่า “ไม่ใช่อย่างนั้น AI ใช้กับทุกอย่างได้ทันที”
สมมติฐานนี้เหลวไหลจนแทบโต้แย้งด้วยตรรกะได้ยาก และจนถึงตอนนี้มันประสบความสำเร็จมากในฐานะ เรื่องเล่าบนฐานความเชื่อ ที่ดึงเงินลงทุนมหาศาลและห่อหุ้มการปรับกำลังคนโดยเน้นผลกำไร
ผมเห็นด้วยอย่างมากกับสมมติฐานของบทความและประเด็นเฉพาะส่วนใหญ่ แต่ในชีวิตประจำวันผมก็ใช้ LLM และเห็นด้านบวกด้วย อนึ่ง ผมทำงานในอุตสาหกรรมซอฟต์แวร์มาประมาณ 30 ปี
เมื่อรับมือกับโค้ดที่ AI สร้างขึ้น คุณจะต้องอ่านโค้ด การพัฒนาจะคล้ายชุดของการรีวิวโค้ดมากกว่าการเดินทางสร้างสรรค์จากศูนย์ และสำหรับนักพัฒนาเดี่ยว มันมีข้อดีตรงที่ช่วยให้ได้ฝึกความรับผิดชอบแบบที่ปกติเรียนรู้ได้ง่ายกว่าในทีม
อีกอย่าง การทำงานกับ LLM ทำให้เห็นอย่างรวดเร็วว่านักพัฒนาต้องเข้าใจปัญหาเป็นชั้น ๆ ที่ชัดเจนและมีโครงสร้างดี ถ้าสั่งงานใหญ่ทีเดียวมักจะกลายเป็นยิงเท้าตัวเอง ดังนั้นการเข้าหาจากมุมมองการออกแบบ เขียนสเปกรายละเอียด และลงมือทำเป็นส่วน ๆ จึงช่วยกำหนดขอบเขตและอินเทอร์เฟซของบล็อกเชิงแนวคิดได้
อาจมองได้ว่า LLM เป็น ตัวเร่ง อันทรงพลังที่ช่วยให้นักพัฒนาจูเนียร์เติบโตไปสู่บทบาทซีเนียร์ เมื่อมีการชี้แนะที่เหมาะสม มันเผยให้เห็นลำดับความก้าวหน้าของบทเรียนที่คนมีประสบการณ์มากกว่าต้องใช้เวลาเรียนรู้ ผมไม่ได้มองว่าทุกอย่างมืดมน และ AI ก็จะไม่แทนที่นักพัฒนา ตอนนี้มันก่อความปั่นป่วนมาก แต่ท้ายที่สุดน่าจะไปอยู่ตรงไหนสักแห่งท่ามกลางเครื่องมืออื่น ๆ
การรีวิวโค้ดที่ LLM ช่วยสร้างอาจถือได้ว่าเป็นการอ่านโค้ดที่จืดชืดกว่า แต่ผมก็ยังคิดว่าได้เรียนรู้ ผมอ่านโค้ดที่ LLM สร้างไว้มาก และมักได้เรียนรู้ idiom ที่ไม่คุ้นหรือการเรียกใช้ไลบรารีที่ไม่เคยรู้มาก่อน
สำหรับนักพัฒนาซีเนียร์ LLM ยิ่งเป็นตัวเร่งที่ทรงพลังกว่า เพราะรู้ว่าอะไรมีอยู่แล้วและอะไรไม่จำเป็นต้องลอง จึง prompt ได้ดีกว่า
แค่ดูข่าวล่าสุดก็เห็นว่าการเลิกจ้างยังเกิดขึ้นต่อเนื่องทั้งใน Big Tech บริษัทเทคโนโลยีขนาดกลาง และบริษัทเทคโนโลยีขนาดเล็ก
ยังจำช่วงที่เคยบอกกันว่า 3D printing จะมาแทนที่การผลิตทั้งหมดได้ไหม?
AI ใกล้เคียงกับอารมณ์แบบนั้นมากกว่าภาวะเอกฐาน
อาจมองได้ว่า LLM ไม่ได้ทำให้อะไรดีขึ้นเท่าไร แค่เปิดโปงข้อบกพร่องเชิงระบบเท่านั้น แต่ผลกระทบนั้นชัดเจนแน่นอน รูปแบบการสอนหลายสิบแบบที่เมื่อ 2 ปีก่อนยังเป็นมาตรฐาน ตอนนี้ใช้ไม่ได้แล้ว
โดยเฉพาะอย่างยิ่ง การศึกษาออนไลน์/ทางไกลทั้งหมดก็รวมอยู่ในนี้ด้วย ซึ่งน่าขันตรงที่ ChatGPT ออกมาในช่วงเดียวกับที่มหาวิทยาลัยจำนวนมากเพิ่งเริ่มลงทุนด้านนี้หลัง Covid พอดี นี่เป็นผลกระทบในระดับทั้งภาคการศึกษาระดับอุดมศึกษาและมัธยมศึกษาทั่วโลก
อุตสาหกรรมการบินและอวกาศเป็นตัวอย่างที่ดี หลายอย่างที่ SpaceX และสตาร์ทอัพรุ่นใหม่ในสาขานี้ทำอยู่ คงเป็นไปไม่ได้หากไม่มีชิ้นส่วน 3D printing ชิ้นส่วนอย่าง nozzle, combustion chamber, turbopump มักถูกพิมพ์ขึ้นมา
แต่ถึงอย่างนั้น การเปรียบเทียบนี้ก็ดูไม่ยุติธรรม ตอนที่ผมทำวิศวกรรมเครื่องกล 3D printing ช่วยให้ผมสร้าง prototype และทำพลาดได้เร็วขึ้นและถูกลง จนทำให้ทักษะวิศวกรรมของผมดีขึ้นเสียด้วยซ้ำ
มันไม่ได้แทนที่การผลิตทั้งหมด แต่มีบทบาทสำคัญในการออกแบบ และไม่ได้ทำให้ทักษะของผู้ใช้ถดถอย
LLM นั้นน่าทึ่งสำหรับการเขียนโค้ด แต่แย่มากสำหรับการ เป็นเจ้าของและดูแลรักษา โค้ดนั้น
ทุกบรรทัดที่ยอมรับมาโดยไม่เข้าใจคือความเข้าใจที่ยืมมา และตอนบำรุงรักษาจะต้องจ่ายคืนพร้อมดอกเบี้ยแพง ๆ มันให้ความรู้สึกเหมือนได้ความเร็วฟรี แต่จริง ๆ แล้วใกล้เคียงกับหนี้ทางเทคนิคที่คิดดอกเบี้ยราว 40% ต่อปี
กลุ่มของเราต้องหาวิธีใช้ AI อัตโนมัติในงานพิมพ์โค้ด แต่ ไม่ทำให้การคิดเป็นอัตโนมัติ
แต่ไม่ใช่เช่นนั้น และด้วยวิธีการทำงานของมันก็เป็นเช่นนั้นไม่ได้
ดังนั้นทุกบรรทัดจาก LLM ที่ยอมรับมาโดยไม่เข้าใจ จริง ๆ แล้วคือความเข้าใจที่ไม่มีอยู่ เป็นเพียงโค้ดหนึ่งบรรทัดที่โมเดลความน่าจะเป็นพ่นออกมา และยังอยู่ในสภาพที่ไม่มีใครเข้าใจ จนกว่าจะมีสิ่งมีชีวิตที่เข้าใจบริบทของ codebase ระบบ และการออกแบบได้จริง ๆ มาดูเสียก่อน ปัจจุบันสิ่งมีชีวิตที่รู้กันว่าทำแบบนั้นได้มีเพียงมนุษย์เท่านั้น
ในการพัฒนาแบบดั้งเดิม ผมไม่ค่อยชอบทั้งสองอย่างนัก แต่ LLM ในปัจจุบันทำให้ทั้งสองอย่างง่ายและมีประโยชน์ขึ้น
และ “กฎสามครั้ง” แทบจะหยุดใช้ได้ระหว่าง component ต่าง ๆ โค้ดควรมีผลกระทบเฉพาะที่ หรือไม่ก็เป็นส่วนหนึ่งของไลบรารีฐานที่แข็งแรงมาก ๆ อย่างใดอย่างหนึ่ง กรณีตรงกลางจะทำให้ความซับซ้อนของการ refactor ระเบิด
“LLM ไม่โต้แย้งพรอมป์ต์ที่ชี้นำ” คือ ความเสี่ยงด้านอินพุต ที่เป็นความเจ็บปวดใหญ่ที่สุดจนถึงตอนนี้
ที่น่าหงุดหงิดยิ่งกว่าคือ เราอาจไม่รู้ด้วยซ้ำว่าตัวเองกำลังชี้นำไปในทิศทางหนึ่งอยู่ เมื่อคิดถึงวิธีทำงานของ LLM แล้วก็สมเหตุสมผล แต่แค่คำที่เขียนคลุมเครือเพียงคำเดียวก็ทำให้ผลลัพธ์เอนเอียงไปในทางที่แย่ และพาเราไปในทิศทางตรงข้ามกับที่ต้องการ จนหลงลงโพรงกระต่ายผิดทางได้
กว่าจะรู้ตัวก็พบว่าตัวเองอยู่กลางบ่อโคลนของโค้ดที่ถูกปะติดปะต่อมั่ว ๆ แต่พอจะทำงานได้แบบกระท่อนกระแท่น ภาษามนุษย์มีความกำกวมและไม่เฉพาะเจาะจงสูงมาก จนแทบเหมือนกับว่าเราเป็นผู้ประดิษฐ์ภาษารูปแบบที่มีกฎเกณฑ์เพื่อให้เกิดความแม่นยำตั้งแต่แรก
ส่วนตัวก็รู้สึกด้วยว่าเครื่องมือ AI ทำให้ฝีมือถดถอยอย่างรวดเร็ว ช่วงหนึ่งเคยขี้เกียจจนเอื้อมมือไปหา AI กับงานเล็ก ๆ ทุกอย่าง แต่พอถอยออกมามองก็ไม่ได้ประหยัดเวลาเท่าไรนัก กลับเหนื่อยเร็วขึ้นมากเพราะต้องอ่านโค้ดหลายสิบหรือหลายร้อยบรรทัด คิดว่า AI ผิดอย่างไร แล้วแก้ไขมัน
ไม่ได้วัดจริงจัง แต่โดยรวมแล้วรู้สึกว่าเวลาที่เสียไปกับเครื่องมือ AI มากกว่าเวลาที่มันช่วยประหยัดได้มาก
ปัญหาจริง ๆ คือ AI มีประโยชน์จริงกับงานจำนวนมาก แต่ผู้ใช้แบ่งเป็นสองกลุ่ม กลุ่มหนึ่งเอาไปใช้กับงานซับซ้อนที่ข้อผิดพลาดเล็ก ๆ สะสมได้อย่างรวดเร็ว อีกกลุ่มหนึ่งส่วนใหญ่เป็นคนสายผู้จัดการ ที่เห็นมันพ่นโค้ด 200 บรรทัดซึ่งตัวเองไม่เข้าใจออกมา แล้วมองว่าแอป TODO ที่พอทำงานได้อย่างหวุดหวิดนั้นเป็น “MVP” และคิดว่า “ในเมื่อสร้างสิ่งนี้ได้ งานของคุณก็คงทำได้ง่าย ๆ เหมือนกัน”
ถ้าจะตอบแบบที่เจอบ่อย ๆ ว่าฉันใช้ผิดเองหรือโมเดลผิดไปเอง อยากให้อ่านคอมเมนต์เก่าของฉันที่ให้บริบทเกี่ยวกับประสบการณ์กับเครื่องมือเหล่านี้ก่อน https://news.ycombinator.com/item?id=44055448
พูดอีกอย่างคือ AI เป็นผู้ช่วยของฉัน แต่ความรับผิดชอบในการส่งมอบผลลัพธ์ที่มีคุณภาพดีและบำรุงรักษาได้ยังอยู่ที่ฉัน
อย่างไรก็ตาม ถ้ามองจากมุมของคนทั่วไป ลองนึกถึงเครื่องคิดเลขธรรมดา เครื่องคิดเลขทำลายความสามารถในการคิดเลขในใจของผู้คน AI ก็จะทำแบบนั้นกับทักษะการเขียนและการสื่อสาร ความสามารถในการแก้ปัญหา และอื่น ๆ
ดูเหมือนว่าโมเดลจะไปเกาะติดกับคีย์เวิร์ดบางคำที่อยู่ตรงไหนสักแห่งในกระแสของพรอมป์ต์ แล้วทิ้งตรรกะแบบดั้งเดิม จากนั้นผลักให้คำตอบเข้าไปในเส้นทางที่แคบลง ซึ่งแก้ปัญหาเดิมได้ไม่ดีด้วยซ้ำ สุดท้ายก็มีแต่เพิ่มความหงุดหงิดและความทุกข์ให้ฝั่งมนุษย์
เพื่อป้องกันไม่ให้ฝีมือถดถอย ฉันพยายามใช้ AI เฉพาะกับงานเล็ก ๆ ที่ชัดเจน ซึ่งเดิมทีแก้ด้วยการค้นหา StackOverflow แทนที่จะค้นว่า “จะทำ X อย่างไร?” ก็ถามโมเดลด้วยคำถามเดียวกัน แล้วใช้คำตอบนั้นเป็นแนวทางแก้ปัญหา ไม่ใช่คำตอบที่ถูกต้องตายตัว
ถึงอย่างนั้น ปัจจุบันก็มีงานที่ AI ทำให้ง่ายขึ้นจริง เช่น ถ้ามีตัวอย่างให้ใช้แบบ “ทำให้เหมือนหน้านี้ แต่ใช้ข้อมูล x แทน y” ก็มักเร็วกว่าการไปหาเอกสารเอง มีข้อแม้ว่ามันอาจ hallucinate ได้ แต่ก็มีโอกาสสูงที่จะดีขึ้นเมื่อเวลาผ่านไป
สิ่งที่อยากเห็นคือ นอกจากความแม่นยำโดยรวมที่ดีขึ้นแล้ว คือการที่มันหา วิธีแก้ที่เรียบง่ายที่สุด ได้โดยไม่ต้องบอกทุกครั้ง ข้อเสียใหญ่ที่สุดตอนปล่อย ChatGPT, Claude ฯลฯ ให้ทำงานคือมันสร้างขยะจำนวนมากอย่างรวดเร็ว และไม่หยุดตัวเองด้วยเหตุผลว่า “แบบนี้จะซับซ้อนเกินไปที่จะจัดการภายหลัง” ต้นฉบับอ้างว่ามีเพียงมนุษย์ที่เข้าใจการออกแบบทั้งหมดเท่านั้นที่ต่อต้านเอนโทรปีได้ ซึ่งแม้ส่วนนี้อาจไม่ใช่สิ่งที่จะไม่มีวันปรับปรุง แต่ตอนนี้รู้สึกว่าเป็นปัญหาใหญ่ที่สุด
รอบแรกมักเผยให้เห็นสมมติฐานหลัก ๆ ที่โมเดลกำลังตั้งอยู่ แล้วจากตรงนั้นก็สามารถค่อย ๆ จำกัดขอบเขตและทำให้ชัดเจนขึ้นได้
อ่านคอมเมนต์เก่าที่บอกว่าเคยลองมาหลายวิธีแล้ว ดูเหมือนว่าประสบการณ์กับ LLM จะกว้างกว่าฉันมาก เพียงแต่ไม่เห็นเทคนิคนี้ เลยทิ้งไว้เผื่อจะเป็นประโยชน์กับใครบางคน
คำพูดอย่าง “มันให้เหตุผลจากไอเดีย แผนภาพ หรือสเปกความต้องการไม่ได้” และ “มีแต่มนุษย์เท่านั้นที่ลดความซับซ้อนได้” ดูเหมือนเป็นกรณีที่มีข้ออ้างย่อยซึ่งผิดอย่างเห็นได้ชัดแปะอยู่หลังแนวคิดที่น่าสนใจ
เรื่องนี้ทำได้ง่ายมาก แค่ขอโค้ดที่เรียบง่ายกว่านี้ ฉันใช้มันบ่อยเพื่อขอความเห็นที่สอง และได้ผลลัพธ์ดี
ถ้าไม่ถามโมเดล ก็จะไม่ได้ทั้งคำตอบที่ซับซ้อนและคำตอบที่เรียบง่าย การตั้งคำถามแบบค่าเริ่มต้นก็เป็นทางเลือกอย่างหนึ่ง ไม่ใช่สิ่งที่ฝังอยู่ในแนวคิดของ LLM เอง
ฉันยังใช้มันได้ดีในการแปลงไปมาระหว่างโค้ดกับไอเดียหรือแผนภาพ ไม่เข้าใจว่าทำไมถึงมีคนกล่าวอ้างแรง ๆ ทั้งที่ผู้คนหักล้างมันในการใช้งานจริงกันทุกวัน
บทความยังย้ำตรรกะแปลก ๆ ที่ดูเผิน ๆ เหมือนถูก แต่พอดูละเอียดแล้วเอาไม่อยู่ด้วย เรื่องของ Naur ตอนนี้กลายเป็นมีมไปแล้ว และถูกพูดซ้ำในโลกจริงราวกับเป็นข้อคิดลึกซึ้ง แต่กลับลืมกฎพื้นฐานและใช้งานได้จริงอีกข้อหนึ่งของวิศวกรรมซอฟต์แวร์ไป โปรแกรมที่ไม่ใช่เรื่องเล็กน้อยย่อมเกินความสามารถที่คนคนเดียวจะเก็บทฤษฎีทั้งหมดไว้ในหัวได้ในไม่ช้า
เราแทบไม่ได้ทำงานโดยมีทฤษฎีของโปรแกรมที่สมบูรณ์จริง ๆ ภาษาโปรแกรม เทคนิค ระเบียบวิธี และเครื่องมือต่าง ๆ ล้วนพัฒนาไปในทิศทางที่ทำให้ผู้คนทำงานได้ดีขึ้นโดยไม่ต้องเข้าใจโค้ดส่วนใหญ่
ในแง่นี้ มนุษย์ก็มีข้อจำกัดเดียวกับ LLM เพียงแต่เราจัดการมันได้ดีกว่า เพราะไม่ต้องรอจนกว่าจะได้รับอนุญาตให้วนลูปให้เหตุผลอีกครั้งเพื่อให้ได้มุมมองอื่น
ผมคิดว่าสามารถใช้ตรรกะคล้ายกันกับเทคโนโลยีแผนที่อย่าง Google Maps หรือ Apple Maps ได้เหมือนกัน ข้ออ้างคือการใช้เครื่องมือเหล่านี้ทำให้ความสามารถในการสำรวจโลกทางกายภาพ สัญชาตญาณเรื่องทิศทาง และความรู้สึกทางภูมิศาสตร์เสื่อมถอยลง
จริง ๆ แล้วก็ไม่ใช่เรื่องผิดเสียทีเดียว ทุกวันนี้ผู้คนจำนวนมากหาทางได้ยากหากไม่มีเครื่องค้ำยันอย่าง Google Maps และความสัมพันธ์กับโลกทางกายภาพก็เปลี่ยนไปหลายด้าน
แต่ในอดีตก็มีคนจำนวนมากที่ไม่ได้เก่งเรื่องการหาทางเป็นพิเศษอยู่แล้ว โดยเฉพาะความสามารถเฉลี่ยในการเดินทางจากจุด A ไปยังจุด B ในพื้นที่ไม่คุ้นเคยอย่างปลอดภัยและมั่นคงนั้นเพิ่มขึ้นมากอย่างแน่นอน
และคนส่วนน้อยที่มีพรสวรรค์ด้านภูมิศาสตร์และการหาทาง ก็ไม่ได้ถูกเครื่องมืออย่าง Google Maps เข้ามาแทนที่ความสามารถ แต่กลับถูกเสริมความสามารถ
AI ก็น่าจะลงเอยคล้ายกันในสเกลที่ใหญ่กว่า แน่นอนว่ามี trade-off และทักษะกับความสามารถบางอย่างจะลดลง แต่ผู้คนจำนวนมากกว่ามากจะสามารถทำสิ่งที่เมื่อก่อนไม่เคยทำได้ และคนส่วนน้อยจะทำงานของตัวเองได้ดียิ่งขึ้น
แน่นอนว่าไม่ใช่เสมอไป เพราะการทำแผนที่ทั้งโลกเป็นงานที่ซับซ้อนมาก มีข้อยกเว้นและกรณีขอบจำนวนมหาศาล แต่เมื่อเทียบกับผลลัพธ์ของ LLM แล้วต่างกันมาก ต่อให้ตั้ง temperature เป็น 0 แล้วสร้างคำตอบใหม่จาก prompt เดิมหลายครั้ง ผลลัพธ์ก็ยังต่างกันมาก
อีกอย่าง LLM ครอบคลุมขอบเขตแนวคิดที่กว้างกว่ามาก ผู้คนจึงจะใช้มันแทนสมองของตัวเองในสถานการณ์มากมายที่ไม่ควรทำอย่างยิ่ง แค่แผนที่อย่างเดียวก็ยังมีคนขับรถลงทะเลสาบเพราะ Google Maps บอกว่าเป็นถนนแล้ว นึกไม่ออกเลยว่าจะเกิดอะไรขึ้นเมื่อผู้คนเชื่อผลลัพธ์ของ LLM อย่างมืดบอดและใช้มันแทนความคิดของตัวเอง
ในที่ที่ผมอยู่ Google Maps ดีกว่าคนขับแท็กซี่ใน 90% ของกรณี
แต่ AI ไม่ได้ดีกว่าคนที่เพิ่งทำงานนั้นมาไม่กี่วันด้วยซ้ำ
ในความเป็นจริง พนักงาน 70% ทำงานแบบลวก ๆ จน AI มักทำได้พอ ๆ กันหรือดีกว่า
ความยากจริง ๆ คือคนที่เคยทำงานลวก ๆ ต่อให้ใช้ AI ก็ยังไร้ประโยชน์เหมือนเดิม ส่วนคนที่เหลือจะเรียนรู้และเติบโตไปพร้อมกับ AI
รถขับเคลื่อนอัตโนมัติเต็มรูปแบบก็คล้ายกัน FSD ดีกว่าคนขับมนุษย์ที่แย่ เมา หรือส่งข้อความขณะขับ ซึ่งบนถนนก็มีคนขับแบบนั้นอยู่มาก
อยากรู้ว่าผู้เขียนได้ความรู้สึกว่า “[AI] ไม่สามารถทำงานในระดับแนวคิดได้” มาจากไหน
สิ่งที่ LLM รุ่นหลัง ๆ พิสูจน์ซ้ำแล้วซ้ำเล่าคือ มันสามารถทำงานใน ระดับแนวคิด ได้อย่างชัดเจน เช่น แปลแนวคิดจากภาษาหนึ่งไปยังอีกภาษาได้อย่างถูกต้องตามบริบท
การบอกว่ามันไม่ได้ “เข้าใจ” แนวคิดเหมือนมนุษย์เป็นอีกเรื่องหนึ่ง มันคงไม่ได้ “เข้าใจ” ความเจ็บปวดเพราะไม่เคยมีประสบการณ์ความเจ็บปวด แต่มนุษย์เองก็พูดถึงสิ่งที่ไม่เคยประสบโดยตรงอยู่ตลอด การทำแบบนั้นสมควรหรือไม่เป็นอีกประเด็นหนึ่ง
นี่เป็นแบบจำลองอ่อน ๆ ของคุณลักษณะบางอย่างของแนวคิด เช่น ความสัมพันธ์เชื่อมโยง ตัวอย่างเช่น “dog” เชื่อมโยงกับ “cat” แต่ไม่ได้จำลองสิ่งอย่างการประกอบกันได้ ความหมายโดยนัย หรือบทบาทของคำศัพท์ในประโยคเงื่อนไขแบบสวนทางกับความจริง
อย่างไรก็ตาม หากคำถามคล้ายกับข้อมูลฝึก ก็สามารถใช้กำลังดันความสามารถเชิงแนวคิดแบบผิวเผินออกมาได้ หากเคยมีใครถามว่า “สุนัขจะมีความสุขไหมถ้าไปเล่นบนดาวอังคาร?” หรือกลุ่มคำถามที่คล้ายกันพอ ก็สามารถวาง “dog” ไว้ใกล้ ๆ กลุ่ม “ข้อเท็จจริงตามตัวอักษร” และกลุ่มของบางส่วนของเหตุการณ์สวนทางกับความจริงที่รู้จักอยู่แล้วได้
หากต้องการเห็นความต่างระหว่างสิ่งนี้กับความสามารถทางจิตที่แท้จริง ให้ดูว่าการผสมผสานแนวคิดที่มีความลึกเท่าใดก็ได้มีจำนวนไม่สิ้นสุด และอาจประกอบด้วยเหตุการณ์สวนทางกับความจริงจำนวนไม่สิ้นสุด เด็กที่มีเพียงองค์ประกอบพื้นฐานกับจินตนาการก็สามารถประเมินความหลากหลายไม่สิ้นสุดนี้ได้
ดังนั้น LLM จึงถูกใช้มากที่สุดในสาขาแคบ ๆ ที่ “งานเชิงแนวคิด” ที่ต้องการมีการบันทึกไว้ดีมากและค่อนข้างเสถียร โดยเฉพาะอย่างยิ่งในวิศวกรรมซอฟต์แวร์
ผมเริ่มคิดหนักขึ้นเรื่อย ๆ ว่าควรเปลี่ยน 90s.dev ให้เป็นชุมชนที่ไม่มี AI อยากให้เป็นที่ที่โฟกัสกับทักษะโบราณในการเขียนซอฟต์แวร์ให้ดี และต้อนรับทุกคนที่ฝึกฝนทักษะนั้น
ต้องมีอะไรบ้างถึงจะเริ่มได้? ฟอรัม? mailing list? วิธีรวบรวมบล็อกจากผู้เขียนหลายคนแบบ hackernoon?
ผมสร้าง mailing list ชั่วคราวสำหรับคนที่สนใจไว้ที่ https://github.com/sdegutis/90s.dev/issues/2 แล้ว ถ้าต้องการรับอีเมลเกี่ยวกับหัวข้อนี้ก็ subscribe หรือคอมเมนต์ได้
ฟอรัมพังไปแล้วเพราะ LLM กับบ็อต ดังนั้นตัวเลือกนั้นตัดทิ้งได้เลย ถ้าสิ่งนี้จะทำงานได้ ต้องเป็นแบบเชิญเท่านั้น และผู้แนะนำแต่ละคนต้องรับผิดชอบสายการเชิญของตัวเอง
ชุมชนต้องดีพอจนการสูญเสียสิทธิ์เข้าถึงช่วยกระตุ้นให้ประพฤติดีได้ วิธีนี้ใช้ได้ผลดีมากในบางชุมชนออนไลน์