- ในปี 2019 วิศวกรซอฟต์แวร์ส่วนใหญ่ยังนึกภาพได้ยากว่าแมชชีนเลิร์นนิงจะช่วยงานของตนได้อย่างไร
- แต่ในปี 2024 มีความตื่นตัวอย่างกว้างขวางต่อวิธีที่ AI ช่วยเขียนโค้ด
- วิศวกรจำนวนมากได้ลองใช้การเติมโค้ดอัตโนมัติที่อิง ML ผ่านเครื่องมือภายในบริษัทหรือผลิตภัณฑ์เชิงพาณิชย์
- บทความนี้นำเสนอการปรับปรุงล่าสุดที่ขับเคลื่อนด้วย AI ท่ามกลางการเปลี่ยนแปลงอย่างต่อเนื่องของเครื่องมือพัฒนาซอฟต์แวร์ภายในของ Google
- รวมถึงพูดถึงการเปลี่ยนแปลงเพิ่มเติมที่คาดว่าจะเกิดขึ้นในอีก 5 ปีข้างหน้า
- ยังนำเสนอแนวทางการสร้างผลิตภัณฑ์ AI ที่ส่งมอบคุณค่าให้กับการพัฒนาซอฟต์แวร์ระดับมืออาชีพ
- ทีมนี้ดูแลสภาพแวดล้อมการพัฒนาซอฟต์แวร์ที่วิศวกรของ Google ใช้เวลาส่วนใหญ่อยู่กับมัน เช่น IDE, code review และ code search
- แสดงให้เห็นว่าการปรับปรุงเหล่านี้สามารถส่งผลโดยตรงต่อประสิทธิภาพและความพึงพอใจของนักพัฒนาได้
ความท้าทาย
- ความท้าทายต่อเนื่องในด้านนี้คือเทคโนโลยี AI พัฒนาอย่างรวดเร็วมาก จนยากจะคาดเดาได้ว่าควรสำรวจไอเดียใดก่อน
- มักมีช่องว่างขนาดใหญ่ระหว่างเดโมที่ทำได้จริงทางเทคนิคกับการทำให้เป็นผลิตภัณฑ์ที่ประสบความสำเร็จ
- แนวทางในการนำไอเดียไปใช้งานจริงในผลิตภัณฑ์มีหลักแนะนำอยู่ 3 ข้อ:
- จัดลำดับความสำคัญตามความเป็นไปได้ทางเทคนิคและผลกระทบ: ทำงานกับไอเดียที่พิสูจน์ความเป็นไปได้ทางเทคนิคแล้ว และคาดว่าจะมีผลกระทบสูงแบบวัดผลได้ต่อเวิร์กโฟลว์ของวิศวกร
- เรียนรู้อย่างรวดเร็วเพื่อปรับปรุง UX และคุณภาพของโมเดล: มุ่งเน้นการทำซ้ำอย่างรวดเร็วและสกัดบทเรียนที่ได้ โดยยังคงรักษาประสิทธิภาพการทำงานและความสุขของนักพัฒนาเอาไว้ ประสบการณ์ผู้ใช้สำคัญพอๆ กับคุณภาพของโมเดล
- วัดผลลัพธ์: เป้าหมายคือการเพิ่มตัวชี้วัดด้านประสิทธิภาพและความพึงพอใจ จึงต้องติดตามตัวชี้วัดเหล่านี้อย่างกว้างขวาง
การประยุกต์ใช้ LLM กับการพัฒนาซอฟต์แวร์
- เมื่อสถาปัตยกรรม Transformer ปรากฏขึ้น ก็เริ่มสำรวจวิธีนำ LLM มาใช้กับการพัฒนาซอฟต์แวร์
- การเติมโค้ดแบบ inline ที่อิง LLM เป็นหนึ่งในการประยุกต์ใช้ AI กับการพัฒนาซอฟต์แวร์ที่ได้รับความนิยมมากที่สุด
- การใช้โค้ดเองเป็นข้อมูลฝึกถือเป็นการประยุกต์ใช้เทคโนโลยี LLM ที่เป็นธรรมชาติ
- UX ให้ความรู้สึกเป็นธรรมชาติกับนักพัฒนา เพราะการเติมอัตโนมัติระดับคำเป็นฟีเจอร์หลักของ IDE มานานแล้ว
- สามารถวัดผลกระทบแบบคร่าวๆ ได้ เช่น สัดส่วนของอักขระใหม่ที่เขียนโดย AI
- ด้วยเหตุผลเหล่านี้ จึงสมเหตุสมผลที่การใช้งาน LLM รูปแบบนี้จะถูกนำไปใช้ก่อน
- ในบล็อกก่อนหน้านี้ได้อธิบายวิธีปรับปรุงประสบการณ์ผู้ใช้ด้วย code completion และวิธีวัดผลกระทบ
- หลังจากนั้นก็เติบโตอย่างรวดเร็วต่อเนื่อง คล้ายกับที่เห็นในสภาพแวดล้อมองค์กรอื่นๆ
- อัตราการยอมรับในหมู่วิศวกรซอฟต์แวร์อยู่ที่ 37% และช่วยเติมอักขระโค้ดได้ 50%
- การปรับปรุงหลักมาจากทั้งโมเดลและ UX
- วงจรนี้จำเป็นอย่างยิ่งต่อการเรียนรู้จากพฤติกรรมจริง ไม่ใช่สูตรสังเคราะห์
- มีการใช้ทั้งข้อมูลบันทึกจากเครื่องมือต่างๆ และข้อมูลการใช้งานที่สะท้อนความชอบและความต้องการของผู้ใช้ เพื่อปรับปรุงฟีเจอร์ AI ในเครื่องมือเขียนโค้ด เช่น IDE
- สัดส่วนของโค้ดที่สร้างขึ้นด้วยความช่วยเหลือจาก AI เพิ่มขึ้นอย่างต่อเนื่อง
- โดยนิยามเป็นจำนวนอักขระที่ยอมรับจากข้อเสนอของ AI หารด้วยผลรวมของจำนวนอักขระที่พิมพ์ด้วยมือและจำนวนอักขระที่ยอมรับจากข้อเสนอของ AI
- สิ่งที่ควรสังเกตคืออักขระที่มาจากการคัดลอกและวางจะไม่ถูกนับในตัวส่วน
- ใช้ log ภายในด้านกิจกรรมวิศวกรรมซอฟต์แวร์ที่มีขนาดใหญ่และคุณภาพสูง ซึ่งถูกคัดสรรมานานจากหลายเครื่องมือ
- ข้อมูลนี้ทำให้สามารถอธิบายการแก้ไขโค้ดแบบละเอียด ผลลัพธ์การ build การแก้ไขเพื่อแก้ปัญหา build การคัดลอกและวางโค้ด การแก้ไขโค้ดที่วางมา code review การแก้ไขเพื่อตอบข้อคิดเห็นของ reviewer และการส่งการเปลี่ยนแปลงเข้า repository ได้
- ข้อมูลฝึกเป็นคลังโค้ดที่จัดแนวกัน โดยมีคำอธิบายกำกับตามงานทั้งในส่วนอินพุตและเอาต์พุต
- การนำไปใช้งานที่สำคัญถัดมาคือการช่วยแก้ข้อคิดเห็นใน code review (ปัจจุบันมากกว่า 8% ถูกจัดการด้วยความช่วยเหลือจาก AI) และการปรับโค้ดที่วางมาให้เข้ากับบริบทโดยรอบโดยอัตโนมัติ (ปัจจุบันคิดเป็นราว 2% ของโค้ดใน IDE)
- การนำไปใช้งานเพิ่มเติมรวมถึงการสั่งให้ IDE แก้ไขโค้ดด้วยภาษาธรรมชาติ และการคาดเดาวิธีแก้สำหรับ build ที่ล้มเหลว
- ยังมีการประยุกต์ใช้อื่นได้อีก เช่น การคาดเดาคำแนะนำด้านความอ่านง่ายของโค้ดที่เป็นไปตามรูปแบบคล้ายกัน
- เมื่อนำมารวมกัน แอปพลิเคชันที่นำไปใช้จริงเหล่านี้ถือว่าประสบความสำเร็จและมีการใช้งานมากใน Google พร้อมสร้างผลกระทบต่อประสิทธิภาพการทำงานที่วัดผลได้ในสภาพแวดล้อมอุตสาหกรรมจริง
สิ่งที่ได้เรียนรู้
- จากงานจนถึงตอนนี้ ได้เรียนรู้ข้อเท็จจริงหลายประการ:
- ผลกระทบสูงสุดเกิดจาก UX ที่ผสานเข้ากับเวิร์กโฟลว์ของผู้ใช้อย่างเป็นธรรมชาติ ในทุกตัวอย่างข้างต้น ข้อเสนอจะถูกแสดงให้ผู้ใช้เห็นและสามารถไปยังขั้นตอนถัดไปของเวิร์กโฟลว์ได้ด้วยการแตะหรือคลิกครั้งเดียว การทดลองที่ต้องให้ผู้ใช้จำว่าต้องเป็นฝ่ายเรียกใช้ฟีเจอร์เองไม่สามารถขยายผลได้
- สังเกตว่าเมื่อมีข้อเสนอจาก AI ผู้เขียนโค้ด กำลังกลายเป็น reviewer มากขึ้นเรื่อยๆ สิ่งสำคัญคือการหาสมดุลระหว่างต้นทุนของการตรวจทานกับมูลค่าเพิ่ม โดยทั่วไปจะแก้โจทย์นี้ด้วยการตั้งเป้าหมายด้านอัตราการยอมรับ
- เนื่องจาก metric แบบออฟไลน์มักเป็นเพียงตัวแทนคร่าวๆ ของคุณค่าที่ผู้ใช้ได้รับ การทำซ้ำอย่างรวดเร็วผ่านการทดลองออนไลน์แบบ A/B จึงเป็นหัวใจสำคัญ การเปิดฟีเจอร์ AI ในเครื่องมือภายในมีข้อดีมาก เพราะทำให้ปล่อยใช้งานและทำซ้ำได้ง่าย วัดข้อมูลการใช้งานได้ และถามประสบการณ์จากผู้ใช้โดยตรงผ่าน UX research ได้
- ข้อมูลคุณภาพสูง จากกิจกรรมของวิศวกร Google ในเครื่องมือซอฟต์แวร์ต่างๆ รวมถึงการโต้ตอบกับฟีเจอร์ของเราเอง เป็นสิ่งจำเป็นต่อคุณภาพของโมเดล
- การใช้การปรับปรุงด้าน UX และโมเดลเพื่อลดคอขวดในขั้นกลาง พร้อมเพิ่มประสิทธิภาพการเปลี่ยนผ่านจากโอกาส (กิจกรรมของผู้ใช้เป็นหลัก แสดงด้านบนของ funnel ด้านล่าง) ไปสู่ผลกระทบ (ความช่วยเหลือจาก AI ที่ถูกนำไปใช้จริง ด้านล่างของ funnel) เป็นสิ่งสำคัญ
What's Next
- ด้วยแรงหนุนจากความสำเร็จจนถึงตอนนี้ จึงมุ่งเน้นการผสานโมเดลฐานล่าสุด (ตระกูล Gemini) เข้ากับข้อมูลนักพัฒนา (ส่วนหนึ่งของ DIDACT ที่กล่าวถึงข้างต้น) เพื่อขับเคลื่อนทั้งแอปพลิเคชันเดิมและแอปพลิเคชันใหม่ในการประยุกต์ใช้ ML กับงานวิศวกรรมซอฟต์แวร์ของ Google
- ทั่วทั้งอุตสาหกรรม code completion ที่อิง ML ได้มอบความช่วยเหลืออย่างมากแก่ผู้พัฒนาซอฟต์แวร์
- แม้ยังมีโอกาสปรับปรุงการสร้างโค้ดได้อีก แต่คาดว่าประโยชน์ในขั้นถัดไปจะมาจากความช่วยเหลือของ ML ในกิจกรรมวิศวกรรมซอฟต์แวร์ที่กว้างขึ้น เช่น การทดสอบ การทำความเข้าใจโค้ด และการดูแลรักษาโค้ด
- ด้านหลังนี้ได้รับความสนใจเป็นพิเศษในสภาพแวดล้อมองค์กร
- โอกาสเหล่านี้ช่วยให้ข้อมูลกับงานที่เรากำลังดำเนินอยู่เช่นกัน
- เน้นย้ำ 2 เทรนด์ที่เห็นได้ในอุตสาหกรรม:
- ปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์กำลังเคลื่อนไปสู่ภาษาธรรมชาติในฐานะรูปแบบทั่วไป และเปลี่ยนไปสู่การใช้ภาษาเป็นอินเทอร์เฟซสำหรับงานวิศวกรรมซอฟต์แวร์ รวมถึงเป็นประตูสู่ความต้องการข้อมูลของนักพัฒนาซอฟต์แวร์ที่ถูกรวมไว้ใน IDE
- ระบบอัตโนมัติด้วย ML สำหรับงานขนาดใหญ่ ตั้งแต่การวินิจฉัยปัญหาไปจนถึงการนำวิธีแก้ไปใช้ เริ่มแสดงหลักฐานของความเป็นไปได้ในระยะแรกแล้ว
- ความเป็นไปได้นี้ขับเคลื่อนโดยนวัตกรรมด้าน agent และการใช้เครื่องมือ ซึ่งทำให้สามารถสร้างระบบที่ใช้ LLM หนึ่งตัวหรือมากกว่านั้นเป็นองค์ประกอบเพื่อทำงานขนาดใหญ่ขึ้นได้
- เพื่อขยายความสำเร็จข้างต้นไปสู่ความสามารถรุ่นถัดไปเหล่านี้ ชุมชนนักปฏิบัติและนักวิจัยที่ศึกษาเรื่องนี้อาจได้รับประโยชน์จาก benchmark กลางร่วมกัน ซึ่งช่วยผลักดันให้สาขานี้ก้าวไปสู่งานวิศวกรรมที่ใช้งานได้จริง
- จนถึงตอนนี้ benchmark ส่วนใหญ่ยังเน้นไปที่การสร้างโค้ดเป็นหลัก (เช่น HumanEval)
- แต่ในสภาพแวดล้อมองค์กร benchmark สำหรับงานที่กว้างกว่า เช่น code migration และ production debugging อาจมีคุณค่าเป็นพิเศษ
- มีการเผยแพร่ benchmark สำหรับการแก้บั๊ก (เช่น SWEBench) และต้นแบบที่มุ่งเป้า benchmark ดังกล่าว (เช่น Cognition AI) แล้ว
- สนับสนุนให้ชุมชนร่วมมือกันเสนอ benchmark เพิ่มเติม เพื่อให้ครอบคลุมงานวิศวกรรมซอฟต์แวร์ที่กว้างขึ้น
ความเห็นของ GN⁺
- การพัฒนาอย่างรวดเร็วของ AI: เทคโนโลยี AI กำลังก้าวหน้าอย่างรวดเร็ว จึงสำคัญที่จะต้องเรียนรู้และนำเทคโนโลยีล่าสุดมาใช้ต่อเนื่อง
- UX และคุณภาพของโมเดล: ประสบการณ์ผู้ใช้และคุณภาพของโมเดลเป็นปัจจัยสำคัญต่อความสำเร็จของเครื่องมือ AI
- ความสำคัญของข้อมูล: ข้อมูลคุณภาพสูงมีผลอย่างมากต่อประสิทธิภาพของโมเดล AI
- ความเป็นไปได้ในอนาคต: AI มีแนวโน้มจะมีบทบาทมากขึ้นในหลายด้านของวิศวกรรมซอฟต์แวร์
- เทรนด์ของอุตสาหกรรม: อินเทอร์เฟซภาษาธรรมชาติและระบบอัตโนมัติสำหรับงานขนาดใหญ่จะเป็นแรงขับอนาคตของการพัฒนาซอฟต์แวร์
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เมื่อใช้ AI อย่างถูกต้อง มันทำได้สองบทบาท: 1) ช่วยประหยัดเวลาของนักพัฒนาและลดภาระทางความคิดด้วยการแก้ไขที่ไม่เป็นข้อถกเถียง 2) ทำให้ผู้ใช้ฉลาดขึ้นและมีความรู้มากขึ้นผ่านข้อเสนอแนะ ตัวอย่างเช่น บางครั้งฟีเจอร์เติมโค้ดอัตโนมัติก็ทำงานได้ดี
มีข้อสังเกตที่น่าสนใจว่าเครื่องมือ AI มัก "ขยายต่อไม่ได้" เมื่อถึงจุดที่ผู้ใช้ต้องเป็นคนทริกเกอร์ฟีเจอร์เอง กำลังคิดอยู่ว่า AI ใน IDE จะถูกออกแบบให้เสนอแนวคิดระดับดีไซน์และแนวคิดเชิงนามธรรมที่เป็นประโยชน์ได้อย่างไร
มีการสังเกตเห็นปรากฏการณ์ที่ผู้เขียนโค้ดค่อย ๆ กลายเป็นผู้รีวิวมากขึ้นเพราะข้อเสนอแนะจาก AI สิ่งสำคัญคือการหาสมดุลระหว่างต้นทุนของการรีวิวกับมูลค่าเพิ่มที่ได้รับ
รู้สึกว่าการใช้ GPT-4 สร้าง React UI และ Python UI ได้ภายในไม่กี่นาที แล้วรีวิวโค้ดเพื่อทำความเข้าใจวิธีการทำงานของมันนั้นมีประโยชน์
เนื่องจากมนุษย์มี RAM จำกัด จึงต้องนำไอเดียออกไปเก็บไว้ในสื่อภายนอก ข้อเสนอแนะของ AI ช่วยให้เดินหน้าในช่วงเริ่มต้นได้เร็วขึ้น
ปฏิเสธไม่ได้ว่า LLMs (โมเดลภาษาขนาดใหญ่) มีประโยชน์ต่อการเขียนโปรแกรม โดยความท้าทายหลักคือ UX ที่เหมาะสมเพื่อทำให้ประสบการณ์ลื่นไหลขึ้น เคยลองใช้ระบบเติมอัตโนมัติแล้ว แต่ปิดไปเพราะข้อเสนอแนะส่วนใหญ่ไม่ดี
รู้สึกว่าการใช้แอปเดสก์ท็อป ChatGPT เพื่อถามคำถามเกี่ยวกับโค้ดมีประโยชน์มากกว่า แต่การต้องอธิบายรายละเอียดทุกครั้งก็ยุ่งยาก
แนวโน้มที่สัดส่วนการเขียนโค้ดด้วยความช่วยเหลือของ AI เพิ่มขึ้นถึง 50% น่าสนใจ
AI บอกวิธีทำงานที่ร้องขอได้ แต่ไม่ได้บอกว่านั่นเป็นไอเดียที่ไม่ดี คุณภาพของโค้ดที่สร้างโดย ML ขึ้นอยู่กับข้อมูลที่ใช้ฝึก
สงสัยว่าจะต้องใช้เวลาอีกนานแค่ไหนกว่า AI จะเข้ามาแทนที่วิศวกรซอฟต์แวร์ของ Google ได้ทั้งหมด
เป้าหมายสูงสุดของ AI คือการดูแลระบบ ดีบักแอป จัดการ data store และเขียนโค้ดแอปตามคำอธิบายความต้องการและฟีดแบ็กจากผู้ใช้
การทดลองใช้เครื่องมือ AI เป็นเรื่องที่ดี แต่การที่คนอื่นคัดลอกแบบไม่ลืมหูลืมตาอาจส่งผลเสียได้ ยากที่จะหาจุดขายหลักของการเขียนโค้ดด้วย LLM