การสะท้อนความคิดอย่างตรงไปตรงมาของ วิศวกรซอฟต์แวร์ Alberto Fortin เกี่ยวกับการใช้ Large Language Models (LLMs) สำหรับการเขียนโค้ดได้สร้างเสียงสะท้อนกับนักพัฒนาทั่วโลก หลังจากที่เริ่มต้นด้วยการยอมรับเครื่องมือ AI อย่างกระตือรือร้น Fortin ประสบกับความท้าทายอย่างมากขณะสร้างโครงสร้างพื้นฐานใหม่ด้วย Go และ ClickHouse ซึ่งทำให้เขาต้องประเมินแนวทางการพัฒนาที่ช่วยเหลือด้วย LLM ใหม่โดยสิ้นเชิง
ภาพลวงแห่งผลิตภาพ
นักพัฒนาหลายคนประสบกับช่วงฮันนีมูนในช่วงแรกของการใช้ LLMs คำแนะนำการเติมข้อความอัตโนมัติครั้งแรกและฟีเจอร์เล็กๆ ให้ความรู้สึกเหมือนเวทมนตร์ สร้างภาพลวงของการเพิ่มผลิตภาพอย่างมากมาย อย่างไรก็ตาม ความตื่นเต้นในช่วงแรกนี้มักจะปกปิดปัญหาที่ลึกซึ้งกว่าที่เกิดขึ้นเมื่อทำงานกับโปรเจกต์ที่ใหญ่และซับซ้อนมากขึ้น
ชุมชนได้ระบุรูปแบบที่เกิดขึ้นซ้ำๆ: LLMs เก่งในการสร้างโค้ดอย่างรวดเร็ว แต่โค้ดเบสที่ได้กลับกลายเป็นสิ่งที่ยากต่อการดูแลรักษา ไม่เหมือนกับโค้ดที่เขียนโดยนักพัฒนามนุษย์ โค้ดที่สร้างโดย LLM ขาดความเป็นเจ้าของทางปัญญาที่มาจากการสร้างโซลูชันทีละขั้นตอน สิ่งนี้สร้างปัญหาพื้นฐาน - นักพัฒนาพบว่าตัวเองต้องจัดการกับโค้ดเบสที่ไม่เข้าใจอย่างถ่องแท้
ปัญหาของแบบจำลองทางความคิด
ข้อมูลเชิงลึกที่สำคัญที่เกิดขึ้นจากการอภิปรายของนักพัฒนาเน้นไปที่แนวคิดของการเขียนโปรแกรมในฐานะการสร้างทฤษฎี เมื่อนักพัฒนาเขียนโค้ดด้วยตนเอง พวกเขาสร้างแบบจำลองทางความคิดของวิธีที่คอมโพเนนต์ต่างๆ โต้ตอบกันและเหตุผลที่ตัดสินใจบางอย่าง ความเข้าใจอย่างลึกซึ้งนี้กลายเป็นสิ่งสำคัญเมื่อต้องแก้ไขปัญหาหรือเพิ่มฟีเจอร์ใหม่
โค้ดที่สร้างโดย LLM ทำลายกระบวนการธรรมชาตินี้ นักพัฒนาได้รับโซลูชันที่ใช้งานได้โดยไม่ต้องผ่านการเดินทางแก้ปัญหาที่สร้างความเข้าใจ เมื่อบั๊กเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้ การแก้ไขกลายเป็นเรื่องยากขึ้นแบบทวีคูณเพราะนักพัฒนาขาดความรู้พื้นฐานเกี่ยวกับวิธีการสร้างโค้ด
การหาสมดุลที่เหมาะสม
ชุมชนนักพัฒนากำลังมาบรรจบกันในแนวทางที่มีความแตกต่างมากขึ้นในการใช้ LLM แทนที่จะปฏิบัติต่อเครื่องมือเหล่านี้เป็นผู้ช่วยเขียนโค้ดแบบอัตโนมัติ ผู้ปฏิบัติงานที่ประสบความสำเร็จกำลังปรับตำแหน่งให้เป็นผู้ช่วยที่ซับซ้อนสำหรับงานเฉพาะ
ฉันคือวิศวกรซอฟต์แวร์ วิศวกรซอฟต์แวร์อาวุโส ฉันคือสถาปนิก LLM คือผู้ช่วย ผู้ช่วยตอบสนองต่อฉัน ฉันเป็นคนทำแผน
การเปลี่ยนแปลงความคิดนี้พิสูจน์แล้วว่าสำคัญ นักพัฒนารายงานผลลัพธ์ที่ดีกว่าเมื่อพวกเขารักษาการควบคุมสถาปัตยกรรมขณะใช้ LLMs สำหรับงานที่กำหนดไว้อย่างชัดเจนและเล็กกว่า เช่น การสร้างโค้ด boilerplate การเขียนยูนิตเทสต์ หรือการจัดการงาน refactoring ที่เป็นประจำ
กรณีการใช้งาน LLM ที่แนะนำ:
- การสร้างโค้ดส่วนเล็กๆ
- การสร้างโค้ดพื้นฐาน
- การเขียน unit test
- งานปรับปรุงโค้ดแบบประจำ
- การค้นหาเอกสารแบบขั้นสูง
- การอธิบายแนวคิดและการเรียนรู้
ไม่แนะนำ:
- การพัฒนาฟีเจอร์ที่สมบูรณ์
- การตัดสินใจด้านสถาปัตยกรรมขนาดใหญ่
- การแก้ไขบั๊กที่ซับซ้อนโดยไม่มีความเข้าใจจากมนุษย์
- โปรเจกต์ที่เกินขีดจำกัดของ context window
สเปกตรัมของความสำเร็จ
น่าสนใจที่ประสิทธิภาพของ LLM ดูเหมือนจะเป็นไปตามรูปแบบเส้นโค้งระฆัง ที่ปลายด้านหนึ่ง นักพัฒนาที่ไม่สามารถเขียนโค้ดบางอย่างได้ก่อนหน้านี้พบว่าตัวเองไม่มีอุปสรรคและสามารถสร้างโปรแกรมที่ใช้งานได้ ที่อีกปลายหนึ่ง นักพัฒนาที่มีประสบการณ์เรียนรู้ที่จะปฏิบัติต่อ LLMs เป็นกองทัพของโค้ดเดอร์จูเนียร์ รักษาการควบคุมอัลกอริทึมระดับสูงขณะมอบหมายรายละเอียดการดำเนินการ
การต่อสู้เกิดขึ้นในพื้นที่กลาง ที่นักพัฒนามีทักษะเพียงพอที่จะรับรู้ปัญหาคุณภาพแต่ยังไม่ได้พัฒนากลยุทธ์ที่มีประสิทธิภาพสำหรับการจัดการโค้ดที่สร้างโดย LLM นักพัฒนาเหล่านี้มักพบว่าตัวเองถูกครอบงำด้วยรูปแบบโค้ดที่ไม่คุ้นเคยและการตัดสินใจทางสถาปัตยกรรมที่พวกเขาไม่ได้เป็นคนทำ
รูปแบบการใช้งาน LLM จำแนกตามประสบการณ์ของนักพัฒนา:
- ผู้เริ่มต้น: ได้รับการปลดล็อกจาก LLM สามารถสร้างโปรแกรมที่ใช้งานได้ซึ่งเคยทำไม่ได้มาก่อน
- ระดับกลาง: มักจะประสบปัญหากับรูปแบบโค้ดที่ LLM สร้างขึ้นซึ่งไม่คุ้นเคย
- ระดับสูง: ใช้ LLM ได้อย่างประสบความสำเร็จเสมือน "กองทัพของโปรแกรมเมอร์รุ่นใหม่" พร้อมการดูแลด้านสถาปัตยกรรม
บทเรียนเชิงปฏิบัติที่ได้เรียนรู้
ชุมชนได้ระบุกลยุทธ์เชิงปฏิบัติหลายอย่างสำหรับการใช้ LLM อย่างมีประสิทธิภาพ การใช้เครื่องมือเหล่านี้เป็นเครื่องมือค้นหาที่ปรับปรุงแล้วหรือทางเลือกของ Stack Overflow ที่เป็นส่วนตัวพิสูจน์แล้วว่ายั่งยืนกว่าการพึ่งพาพวกมันสำหรับการดำเนินการฟีเจอร์ที่สมบูรณ์ นักพัฒนาหลายคนตอนนี้จำกัดการใช้ LLM ในการสร้างโค้ดสนิปเป็ตเล็กๆ ซึ่งพวกเขาจะตรวจสอบอย่างระมัดระวังและรวมเข้าด้วยกันด้วยตนเอง
ข้อจำกัดของหน้าต่างบริบทยังมีบทบาทสำคัญในประสิทธิภาพของ LLM เมื่อโปรเจกต์เติบโตเกินกว่าที่จะใส่ในบริบทของโมเดลได้ AI จะสูญเสียการติดตามสถาปัตยกรรมระบบที่กว้างขึ้น นำไปสู่คำแนะนำที่ไม่สอดคล้องกันหรือเข้ากันไม่ได้
มองไปข้างหน้า
แม้ว่า LLMs ปัจจุบันจะมีข้อจำกัดที่ชัดเจน เทคโนโลยียังคงพัฒนาอย่างรวดเร็ว นักพัฒนาบางคนคาดหวังอนาคตที่ LLMs จะซับซ้อนพอที่จะจัดการสถาปัตยกรรมโค้ดและการ refactoring โดยอัตโนมัติ คนอื่นตั้งคำถามว่าโมเดลการทำนาย next-token จะสามารถเข้าใจการใช้เหตุผลที่ซับซ้อนที่จำเป็นสำหรับการพัฒนาซอฟต์แวร์ขนาดใหญ่ได้หรือไม่
ในตوนนี้ แนวทางที่ประสบความสำเร็จมากที่สุดดูเหมือนจะเป็นการปฏิบัติต่อ LLMs เป็นเครื่องมือที่ทรงพลังแต่มีข้อจำกัดที่ต้องการการดูแลของมนุษย์อย่างระมัดระวัง กุญแจสำคัญอยู่ที่การเข้าใจทั้งความสามารถและข้อจำกัดของพวกมัน จากนั้นจึงจัดโครงสร้างเวิร์กโฟลว์เพื่อเพิ่มประโยชน์สูงสุดขณะลดความเสี่ยงของโค้ดที่ดูแลรักษาไม่ได้
การอภิปรายที่กำลังดำเนินอยู่สะท้อนถึงการเติบโตที่กว้างขึ้นในวิธีที่ชุมชนการพัฒนาซอฟต์แวร์เข้าหาเครื่องมือ AI - ก้าวผ่านความคึกคะนองในช่วงแรกไปสู่กลยุทธ์การรวมที่สมจริงและยั่งยืนมากขึ้น
อ้างอิง: Why I'm Dialing Back My LLM Usage