ความคิดล่าสุดของ Martin Fowler เกี่ยวกับ LLMs และการพัฒนาซอฟต์แวร์ได้จุดประกายการโต้เถียงอย่างเข้มข้นเกี่ยวกับว่าโลกการเขียนโปรแกรมควรยอมรับหรือต่อต้านลักษณะที่ไม่สามารถกำหนดผลลัพธ์ได้ของเครื่องมือเขียนโค้ดที่ขับเคลื่อนด้วย AI การอภิปรายนี้เผยให้เห็นความตึงเครียดพื้นฐานระหว่างหลักการวิศวกรรมซอฟต์แวร์แบบดั้งเดิมกับความเป็นจริงที่เกิดขึ้นใหม่ของการพัฒนาที่ได้รับความช่วยเหลือจาก AI
ความแตกแยกครั้งยิ่งใหญ่เรื่องการกำหนดผลลัพธ์
ชุมชนโปรแกรมเมอร์พบว่าตัวเองแบ่งออกเป็นสองฝ่ายในคำถามหลัก: การพัฒนาซอฟต์แวร์ควรละทิ้งรากเหง้าแบบกำหนดผลลัพธ์ได้หรือไม่? การเขียนโปรแกรมแบบดั้งเดิมสร้างขึ้นมาบนหลักการที่ว่าเมื่อได้รับข้อมูลเข้าเหมือนกัน โค้ดจะสร้างผลลัพธ์ที่เหมือนกันทุกครั้ง ความสามารถในการคาดเดาได้นี้เป็นทั้งจุดแข็งและลักษณะเฉพาะที่กำหนดตัวตนของสาขานี้
อย่างไรก็ตาม LLMs ทำงานแตกต่างออกไป พวกมันสร้างการตอบสนองผ่านกระบวนการความน่าจะเป็น หมายความว่าคำถามเดียวกันสามารถให้คำตอบที่แตกต่างกันในแต่ละครั้ง นักพัฒนาบางคนมองว่านี่เป็นการถอยหลัง โดยโต้แย้งว่าการนำความไม่แน่นอนเข้ามาในสาขาที่มีตรรกะโดยธรรมชาติจะทำลายความก้าวหน้าทางวิศวกrรรมหลายทศวรรษ คนอื่นๆ มองว่าเป็นการวิวัฒนาการ โดยเสนอว่าวิศวกรรมซอฟต์แวร์ควรเข้าร่วมกับสาขาวิศวกรรมอื่นๆ ที่เผชิญกับความแปรผันและความคลาดเคลื่อนมาโดยตลอด
การโต้เถียงขยายไปไกลกว่าปรัชญาเข้าสู่ความกังวลเชิงปฏิบัติ นักพัฒนารายงานว่าใช้เวลาอย่างมากในการแก้ไขข้อผิดพลาดของโค้ดที่ AI สร้างขึ้นซึ่งดูถูกต้องแต่มีข้อผิดพลาดเล็กๆ น้อยๆ ปรากฏการณ์ 90% ดี 10% เสียได้กลายเป็นประสบการณ์ทั่วไป ที่ LLMs สร้างโค้ดที่ใช้งานได้ส่วนใหญ่อย่างรวดเร็วแต่ต้องการการตรวจสอบและปรับปรุงอย่างละเอียด
สงครามเวิร์กโฟลว์: การเติมข้อความอัตโนมัติ เทียบกับ การจัดการโค้ดโดยตรง
ข้อมูลเชิงลึกสำคัญจากการอภิปรายของชุมชนมุ่งเน้นไปที่วิธีที่นักพัฒนาใช้ LLMs จริงๆ การสำรวจส่วนใหญ่มุ่งเน้นไปที่ฟังก์ชันการเติมข้อความอัตโนมัติพื้นฐานผ่านเครื่องมือเช่น GitHub Copilot แต่ผู้ปฏิบัติงานที่มีประสบการณ์รายงานว่าได้ผลลัพธ์ที่ดีกว่าจากเวิร์กโฟลว์ที่อนุญาตให้ LLMs อ่านและแก้ไขไฟล์ซอร์สโค้ดทั้งหมดโดยตรง
ความแตกต่างนี้สำคัญเพราะส่งผลต่อการวัดประสิทธิภาพและกลยุทธ์การนำมาใช้ นักพัฒนาที่ใช้ LLMs เป็นเครื่องมือเติมข้อความอัตโนมัติขั้นสูงมักรายงานการปรับปรุงเพียงเล็กน้อย ในขณะที่ผู้ที่ใช้วิธีการที่ซับซ้อนกว่าอ้างว่าได้รับการเพิ่มประสิทธิภาพอย่างมาก ช่องว่างนี้บ่งชี้ว่างานวิจัยปัจจุบันอาจวัดเมตริกที่ผิดและสรุปไม่ครบถ้วนเกี่ยวกับผลกระทบของ AI ต่อการพัฒนาซอฟต์แวร์
นักพัฒนาบางคนพบความสำเร็จจากการรวม Test-Driven Development กับ LLMs โดยใช้ AI เพื่อสร้างทั้งการทดสอบและโค้ดการใช้งานในรอบการทำงานแบบวนซ้ำ วิธีการนี้ให้กรอบงานสำหรับจัดการความไม่แน่นอนที่มีอยู่ในโค้ดที่ AI สร้างขึ้นในขณะที่รักษามาตรฐานคุณภาพ
รูปแบบการใช้งาน LLM ในการพัฒนาซอฟต์แวร์
แนวทางแบบดั้งเดิม (ใช้กันมากที่สุด)
- ฟังก์ชันการเติมข้อความอัตโนมัติ ( GitHub Copilot )
- การตระหนักรู้บริบทที่จำกัด
- การปรับปรุงประสิทธิภาพการทำงานในระดับปานกลาง
แนวทางขั้นสูง (มีคุณค่าสูงกว่า)
- การอ่านและแก้ไขไฟล์โดยตรง
- บริบทของ codebase แบบเต็มรูปแบบ
- การเพิ่มประสิทธิภาพการทำงานอย่างมีนัยสำคัญ
- ผสมผสานกับ Test-Driven Development
การหลอนลวงเป็นฟีเจอร์ ไม่ใช่ข้อผิดพลาด
ข้อมูลเชิงลึกที่ยั่วยุที่สุดจากการอภิปรายคือการปรับกรอบความคิดของการหลอนลวงของ AI ให้เป็นฟีเจอร์หลักมากกว่าข้อบกพร่อง มุมมองนี้บ่งชี้ว่า LLMs ไม่แยกแยะระหว่างผลลัพธ์ที่ถูกต้องและไม่ถูกต้อง - พวกมันเพียงแค่สร้างข้อความตามรูปแบบในข้อมูลการฝึกอบรม
สิ่งที่ LLM ทำคือสร้างการหลอนลวง เพียงแต่เราพบว่าบางอย่างมีประโยชน์
ความเข้าใจนี้นำไปสู่คำแนะนำเชิงปฏิบัติ: ถามคำถามเดียวกันหลายครั้ง เปรียบเทียบการตอบสนอง และใช้ความแปรผันเป็นข้อมูลเพิ่มเติม สำหรับการคำนวณเชิงตัวเลข นักพัฒนาควรสอบถาม LLMs อย่างน้อยสามครั้งเพื่อประเมินความสอดคล้อง แม้ว่าหลายคนจะโต้แย้งว่าการคำนวณแบบกำหนดได้ไม่ควรมอบหมายให้กับระบบความน่าจะเป็นตั้งแต่แรก
แนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างโค้ดด้วย LLM
กลยุทธ์การสอบถาม:
- ถามคำถามเดียวกันหลายๆ ครั้ง
- เปลี่ยนแปลงการใช้คำระหว่างการลองถาม
- เปรียบเทียบคำตอบเพื่อดูความสอดคล้อง
- ใช้ LLM เพื่อวิเคราะห์ความแตกต่างระหว่างคำตอบ
สำหรับการคำนวณเชิงตัวเลข:
- สอบถามอย่างน้อย 3 ครั้งขั้นต่ำ
- ไม่ควรใช้ LLM สำหรับการคำนวณแบบกำหนดแน่นอน
- สร้างโค้ดสำหรับการคำนวณแทนการคำนวณโดยตรง
- ตรวจสอบผลลัพธ์อย่างอิสระเสมอ
ความเสี่ยงด้านความปลอดภัยและการขยายพื้นผิวการโจมตี
การรวม LLMs เข้าสู่เวิร์กโฟลว์การพัฒนานำเข้าช่องโหว่ด้านความปลอดภัยใหม่ที่ชุมชนยังคงเรียนรู้ที่จะจัดการ เอเจนต์ AI ที่มีการเข้าถึงข้อมูลส่วนตัว การเปิดรับเนื้อหาที่ไม่น่าเชื่อถือ และความสามารถในการสื่อสาร สร้างสิ่งที่ผู้เชี่ยวชาญด้านความปลอดภัยเรียกว่าสามเหลี่ยมมรณะสำหรับการโจมตีที่อาจเกิดขึ้น
ผู้ร้ายสามารถฝังคำสั่งที่มองไม่เห็นในหน้าเว็บที่หลอก LLMs ให้แยกข้อมูลที่ละเอียดอ่อนหรือดำเนินการที่ไม่ได้รับอนุญาต เอเจนต์ AI ที่ทำงานบนเบราว์เซอร์เผชิญความเสี่ยงเฉพาะ เนื่องจากพวกมันอาจถูกจัดการให้เข้าถึงเว็บไซต์ธนาคารหรือบริการที่ละเอียดอ่อนอื่นๆ ในนามของผู้ใช้ ความกังวลเหล่านี้ทำให้นักวิจัยด้านความปลอดภัยบางคนตั้งคำถามว่าเครื่องมือที่ขับเคลื่อนด้วย AI บางอย่างจะสามารถทำให้ปลอดภัยเพียงพอได้หรือไม่
ความเสี่ยงด้านความปลอดภัย: สามองค์ประกอบร้ายแรงสำหรับ AI Agent
สามองค์ประกอบสำคัญ:
- การเข้าถึงข้อมูลส่วนตัว - AI สามารถอ่านข้อมูลที่มีความละเอียดอ่อนได้
- การสัมผัสกับเนื้อหาที่ไม่น่าเชื่อถือ - หน้าเว็บ ข้อมูลจากผู้ใช้ แหล่งข้อมูลภายนอก
- ความสามารถในการสื่อสารภายนอก - ความสามารถในการส่งข้อมูลออกนอกระบบ
รูปแบบการโจมตี:
- คำสั่งที่มองไม่เห็นในหน้าเว็บ (ฟอนต์ขนาด 1pt สีขาวบนพื้นขาว)
- การจัดการเบราว์เซอร์เพื่อทำธุรกรรมโดยไม่ได้รับอนุญาต
- การขโมยข้อมูลผ่านคำขอที่ดูเหมือนไม่เป็นอันตราย
คำถามเรื่องฟองสบู่และความไม่แน่นอนในอนาคต
ในขณะที่ยอมรับว่า AI เป็นตัวแทนของฟองสบู่เทคโนโลยีแบบคลาสสิก ชุมชนนักพัฒนายังคงแบ่งออกเป็นสองฝ่ายเรื่องเวลาและผลกระทบสุดท้าย การเปรียบเทียบทางประวัติศาสตร์กับฟองสบู่เทคโนโลยีก่อนหน้านี้ให้ทั้งความหวังและความระมัดระวัง - บริษัทบางแห่งจะอยู่รอดและเจริญเติบโต ในขณะที่บริษัทอื่นๆ จะหายไปเมื่อฟองสบู่แตก
ความไม่แน่นอนขยายไปถึงผลกระทบต่ออาชีพสำหรับนักพัฒนาในทุกระดับ นักพัฒนาระดับเริ่มต้นเผชิญความท้าทายเฉพาะ เนื่องจากเครื่องมือ AI อาจขจัดเส้นทางการเรียนรู้แบบดั้งเดิมในขณะเดียวกันก็ต้องการทักษะใหม่เพื่อทำงานอย่างมีประสิทธิภาพกับระบบ AI นักพัฒนาระดับอาวุโสต้องปรับบทบาทของตนให้มุ่งเน้นไปที่สถาปัตยกรรมและการกำกับดูแลมากกว่าการผลิตโค้ดโดยตรง
แม้จะมีการหยุดชะงัก นักพัฒนาส่วนใหญ่เห็นพ้องกันว่าการทดลองและการเรียนรู้ยังคงเป็นสิ่งจำเป็น เทคโนโลยีกำลังพัฒนาอย่างรวดเร็ว และวิธีการที่มีประสิทธิภาพมากที่สุดยังคงถูกค้นพบผ่านการลองผิดลองถูกทั่วชุมชน
โลกการเขียนโปรแกรมยืนอยู่ที่สี่แยกระหว่างประเพณีแบบกำหนดได้และนวัตกรรมแบบความน่าจะเป็น ในขณะที่จุดหมายปลายทางสุดท้ายยังไม่ชัดเจน การเดินทางกำลังปรับรูปแบบวิธีการสร้างซอฟต์แวร์และผู้ที่สร้างมัน