ช่วงฮันนีมูนกับเครื่องมือเขียนโค้ดที่ขับเคลื่อนด้วย AI อาจจะใกล้จบแล้ว แม้ว่า Large Language Models (LLMs) จะสร้างความประทับใจให้กับนักพัฒนาด้วยความสามารถในการสร้างโค้ดได้อย่างรวดเร็ว แต่วิศวกรที่มีประสบการณ์จำนวนมากขึ้นเรื่อยๆ ก็เริ่มชี้ให้เห็นข้อจำกัดพื้นฐานที่ป้องกันไม่ให้เครื่องมือเหล่านี้สามารถสร้างซอฟต์แวร์ได้อย่างอิสระจริงๆ
การอภิปรายนี้มีจุดศูนย์กลางอยู่ที่ข้อมูลเชิงลึกที่สำคัญจากการปฏิบัติงานด้านวิศวกรรมซอฟต์แวร์: การเขียนโปรแกรมที่มีประสิทธิภาพไม่ได้เป็นเพียงแค่การเขียนโค้ด แต่เป็นการรักษา mental model ที่ชัดเจนเกี่ยวกับสิ่งที่โค้ดควรจะทำเทียบกับสิ่งที่มันทำจริงๆ กระบวนการแบบวนซ้ำของการสร้าง ทดสอบ และปรับแต่งตาม mental model นี้ดูเหมือนจะเป็นจุดที่ AI ในปัจจุบันยังทำได้ไม่ดีพอ
ปัญหา Mental Model
ปัญหาหลักไม่ได้อยู่ที่ว่า LLMs เขียนโค้ดไม่ได้ - จริงๆ แล้วพวกมันทำได้ค่อนข้างดี ปัญหาอยู่ที่ความไม่สามารถในการรักษาความเข้าใจที่สม่ำเสมอเกี่ยวกับโปรเจกต์ที่ซับซ้อนตลอดเวลา เมื่อการทดสอบล้มเหลวหรือมีบั๊กเกิดขึ้น ระบบ AI เหล่านี้มักจะหันไปใช้การเดาแทนที่จะเป็นการดีบักอย่างเป็นระบบ พวกมันมีปัญหากับการละเลยบริบท ประสบปัญหา recency bias ที่ข้อมูลล่าสุดบดบังบริบทก่อนหน้า และมักจะ hallucinate รายละเอียดที่ไม่มีจริง
สิ่งนี้สร้างวงจรที่น่าหงุดหงิดสำหรับนักพัฒนา AI อาจเขียนโค้ดที่น่าประทับใจในตอนแรก แต่เมื่อความซับซ้อนเพิ่มขึ้น มันก็เริ่มสูญเสียการติดตามสถาปัตยกรรมระบบโดยรวม เมื่อปัญหาเกิดขึ้น มันมีแนวโน้มที่จะลบทุกอย่างและเริ่มใหม่มากกว่าจะระบุและแก้ไขสาเหตุรากเหง้าอย่างเป็นระเบียบ
ข้อจำกัดหลักของ LLM ในการพัฒนาซอฟต์แวร์:
- การละเว้นบริบท: ไม่เก่งในการค้นหาบริบทที่ขาดหายไปในโปรเจกต์ที่ซับซ้อน
- อคติความใหม่: เน้นหนักไปที่ข้อมูลล่าสุดในขณะที่ลืมบริบทก่อนหน้า
- การหลอนลวง: มักจะแต่งรายละเอียดที่ไม่มีอยู่จริงในโค้ดเบส
- การรักษาแบบจำลองทางความคิด: ไม่สามารถรักษาความเข้าใจที่สอดคล้องกันตลอดการทำงานซ้ำ
- แนวทางการดีบัก: มีแนวโน้มที่จะเดาวิธีแก้ปัญหามากกว่าการระบุสาเหตุหลักอย่างเป็นระบบ
ความสามารถและข้อจำกัดในปัจจุบัน
แม้จะมีข้อจำกัดเหล่านี้ LLMs ก็ได้พบจุดที่เหมาะสมในการพัฒนาซอฟต์แวร์ พวกมันเก่งในการสร้าง boilerplate code เขียนเอกสาร และจัดการงานเขียนโปรแกรมประจำที่เคยทำมาแล้วนับครั้งไม่ถ้วน นักพัฒนาหลายคนรายงานว่าได้รับการเพิ่มผลิตภาพอย่างมีนัยสำคัญเมื่อใช้ AI สำหรับงานระดับจุลภาคเหล่านี้
อย่างไรก็ตาม เทคโนโลยีนี้ดูเหมือนจะถึงจุดคงที่ในช่วงไม่กี่เดือนที่ผ่านมา ในขณะที่การปรับปรุงจาก GPT-2 ไป GPT-3 นั้นน่าทึ่งมาก แต่ผลที่ได้จาก GPT-3 ไป GPT-4 และต่อไปนั้นเป็นแบบค่อยเป็นค่อยไปมากกว่า ความก้าวหน้าล่าสุดส่วนใหญ่มาจากการคัดสรรชุดข้อมูลที่ดีขึ้นและการปรับปรุงประสบการณ์ผู้ใช้มากกว่าการพัฒนาที่แท้จริงในความสามารถด้านการใช้เหตุผล
จุดแข็งของ LLM เทียบกับจุดอ่อน:
| สิ่งที่ LLM ทำได้ดี | สิ่งที่ LLM ทำได้ยาก |
|---|---|
| สร้างโค้ดแบบแม่แบบพื้นฐาน | รักษาบริบทในระดับโปรเจกต์ทั้งหมด |
| เขียนเอกสารประกอบ | แก้ไขปัญหาที่ซับซ้อนอย่างเป็นระบบ |
| จัดการงานการเขียนโปรแกรมที่เป็นกิจวัตร | สร้างและรักษาแบบจำลองทางความคิด |
| สังเคราะห์ความต้องการ | พัฒนาปัญหาที่ซับซ้อนแบบวนซ้ำ |
| สร้างโค้ดจากข้อกำหนดที่ชัดเจน | ตัดสินใจว่าควรแก้ไขโค้ดหรือการทดสอบ |
การอภิปรายเรื่อง Scaling
ชุมชนเทคโนโลยียังคงแบ่งออกเป็นสองฝ่ายเกี่ยวกับว่าข้อจำกัดในปัจจุบันสามารถเอาชนะได้ด้วยการขยายขนาดหรือไม่ บางคนแย้งว่า LLMs จะยังคงพัฒนาต่อไปเหมือนกับอินเทอร์เน็ตยุคแรก โทรศัพท์มือถือ และรถยนต์ไฟฟ้า - เทคโนโลยีที่ในตอนแรกแย่มาก แต่ก็ดีขึ้นเรื่อยๆ ผ่านการปรับปรุงซ้ำๆ
รถยนต์คันแรกๆ เสียบ่อยมาก มีระยะทางจำกัด ไม่มีอะไหล่มากมายสำหรับพวกมัน ไม่มีเครือข่ายสถานีเชื้อเพลิงมากมายเพื่อให้พลังงานแก่พวกมัน ม้าเป็นวิธีที่พิสูจน์แล้ว
อย่างไรก็ตาม นักวิจารณ์ชี้ให้เห็นว่า LLMs เผชิญกับความท้าทายที่แตกต่างจากตัวอย่างในประวัติศาสตร์เหล่านี้ ไม่เหมือนกับรถยนต์หรือโทรศัพท์ที่มีปัญหาทางวิศวกรรมที่สามารถแก้ไขได้ด้วยเวลาและทรัพยากร LLMs อาจมีข้อจำกัดด้านสถาปัตยกรรมพื้นฐาน การออกแบบหลักของพวกมัน - การทำนายข้อความถัดไปที่น่าจะเป็นไปได้มากที่สุดตามความน่าจะเป็น - อาจไม่เหมาะสมโดยธรรมชาติสำหรับการใช้เหตุผลประเภทที่ต้องการในการพัฒนาซอฟต์แวร์ที่ซับซ้อน
วงจรการพัฒนาซอฟต์แวร์ (มนุษย์ เทียบกับ LLM):
วิศวกรมนุษย์:
- สร้างแบบจำลองทางความคิดของความต้องการ
- เขียนโค้ดเพื่อนำความต้องการไปใช้งาน
- สร้างแบบจำลองทางความคิดของสิ่งที่โค้ดทำจริง ๆ
- ระบุความแตกต่างและปรับปรุงโค้ด/ความต้องการอย่างเป็นระบบ
พฤติกรรมของ LLM:
- สร้างโค้ดตามคำสั่ง
- สมมติว่าโค้ดที่สร้างขึ้นทำงานได้อย่างถูกต้อง
- เมื่อการทดสอบล้มเหลว ก็เดาหาวิธีแก้ไข
- เมื่อหงุดหงิด ก็ลบทุกอย่างและเริ่มใหม่
แนวทางปฏิบัติในการก้าวไปข้างหน้า
แทนที่จะรอการปรับปรุงที่ก้าวกระโดด นักพัฒนาหลายคนกำลังปรับเปลี่ยนขั้นตอนการทำงานเพื่อทำงานภายในข้อจำกัดของ AI ในปัจจุบัน ซึ่งรวมถึงการแบ่งปัญหาที่ซับซ้อนออกเป็นชิ้นเล็กๆ การรักษาเอกสารที่ชัดเจนที่ช่วยให้ AI เข้าใจบริบทของโปรเจกต์ และการใช้กระบวนการพัฒนาที่มีโครงสร้างที่นำทาง AI ผ่านแนวปฏิบัติด้านวิศวกรรมซอฟต์แวร์ที่เหมาะสม
ทีมบางทีมกำลังทดลองกับระบบ agent แบบลำดับชั้น ที่ instance AI ต่างๆ จัดการด้านต่างๆ ของการพัฒนาในขณะที่มนุษย์รักษา mental model โดยรวม ทีมอื่นๆ มุ่งเน้นไปที่การใช้ AI สำหรับงานเฉพาะที่กำหนดไว้อย่างชัดเจนในขณะที่ให้มนุษย์ควบคุมการตัดสินใจด้านสถาปัตยกรรมและการออกแบบ
ฉันทามติที่เกิดขึ้นจากชุมชนนักพัฒนาแสดงให้เห็นว่าแม้ว่า LLMs จะเป็นเครื่องมือที่มีค่าสำหรับเร่งด้านบางด้านของการพัฒนาซอฟต์แวร์ แต่พวกมันยังไม่พร้อมที่จะแทนที่วิศวกรมนุษย์ เทคโนโลยีนี้ทำงานได้ดีที่สุดเมื่อถือว่าเป็น autocomplete ขั้นสูงมากกว่าเป็นนักพัฒนาอิสระ ความสำเร็จมาจากการเข้าใจข้อจำกัดเหล่านี้และจัดโครงสร้างงานให้เหมาะสม มากกว่าการคาดหวังให้ AI จัดการกับความซับซ้อนเต็มรูปแบบของการพัฒนาซอฟต์แวร์สมัยใหม่ได้อย่างอิสระ
อ้างอิง: Why LLMs Can't Really Build Software