การเพิ่มขึ้นของการสร้างโค้ดด้วย AI กำลังสร้างปัญหาที่ไม่เคยเกิดขึ้นมาก่อนในการพัฒนาซอฟต์แวร์ คือโปรเจกต์ที่มี bus factor เป็นศูนย์ ซึ่งหมายความว่าไม่มีใครในทีมพัฒนาเข้าใจว่าส่วนสำคัญของซอฟต์แวร์ทำงานอย่างไรจริงๆ
Bus factor ตามแนวคิดดั้งเดิมใช้วัดว่าสมาชิกในทีมกี่คนที่อาจถูกรถบัสชนก่อนที่โปรเจกต์จะสูญเสียความรู้ขององค์กรทั้งหมด เป็นเวลาหลายทศวรรษที่ผ่านมา สถานการณ์เลวร้ายที่สุดคือ bus factor เท่ากับหนึ่ง ซึ่งหมายถึงมีเพียงคนเดียวที่เข้าใจระบบใดระบบหนึ่ง แต่การปรากฏของ vibe coding กับโมเดลภาษาขนาดใหญ่ได้นำเสนอสิ่งที่อันตรายกว่านี้มาก
คำจำกัดความของ Bus Factor:
- Traditional Bus Factor 1: มีเพียงคนเดียวที่เข้าใจระบบ (ความเสี่ยงสูง)
- Bus Factor Zero: ไม่มีใครเข้าใจระบบ (ความเสี่ยงที่ไม่เคยมีมาก่อน)
- Ideal Bus Factor: สมาชิกในทีมหลายคน (3+ คน) เข้าใจแต่ละส่วนประกอบของระบบ
การเพิ่มขึ้นของ Vibe Coding และการสูญเสียความรู้
ตั้งแต่ ChatGPT เปิดตัวสู่สาธารณะในเดือนพฤศจิกายน 2022 นักพัฒนาหลายคนได้ยอมรับสิ่งที่เรียกกันในปัจจุบันว่าการพัฒนาแบบ AI-first แทนที่จะเขียนและเข้าใจโค้ดด้วยตนเอง พวกเขาพึ่งพา AI ในการสร้างฟังก์ชันทั้งหมด ฟีเจอร์ หรือแม้กระทั่งโปรเจกต์ที่สมบูรณ์ แนวทางนี้ให้ความสำคัญกับความเร็วมากกว่าความเข้าใจ ทำให้ทีมต่างๆ มีซอฟต์แวร์ที่ไม่มีใครเข้าใจจริงๆ
ชุมชนได้ระบุสถานการณ์หลายอย่างที่เครื่องมือเขียนโค้ดด้วย AI มีความเป็นเลิศ เช่น การสร้าง boilerplate code การสร้าง test scaffolding และการใช้การเปลี่ยนแปลงซ้ำๆ ในโค้ดเบสขนาดใหญ่ อย่างไรก็ตาม การใช้งานที่ถูกต้องเหล่านี้กำลังถูกบดบังโดยนักพัฒนาที่สร้างโค้ดจำนวนมากโดยไม่ผ่านการตรวจสอบและไม่เข้าใจการทำงานภายใน
กรณีการใช้งาน AI Coding ที่มีประสิทธิภาพ (ตามความเห็นของชุมชน):
- สร้างโค้ดพื้นฐานและโครงสร้างโปรเจกต์
- สร้างข้อมูลทดสอบและพื้นฐานของ unit test
- ใช้การเปลี่ยนแปลงที่ซ้ำๆ กับโค้ดเบสขนาดใหญ่
- สร้างต้นแบบเร็วและ proof-of-concepts
- สร้างเอกสารจากโค้ดที่มีอยู่แล้ว
- สร้าง utility scripts และเครื่องมือใช้ครั้งเดียว
ฝันร้ายในการบำรุงรักษา
ปัญหาที่แท้จริงเกิดขึ้นเมื่อระบบที่สร้างด้วย AI เหล่านี้ต้องการการแก้ไขข้อบกพร่อง การแพทช์ความปลอดภัย หรือฟีเจอร์ใหม่ ไม่เหมือนกับโค้ดที่เขียนโดยมนุษย์ที่นักพัฒนาสามารถติดตามเหตุผลเบื้องหลังการตัดสินใจได้ โค้ดที่สร้างด้วย AI ขาดความรู้ขององค์กรที่มักจะมาพร้อมกับการพัฒนาซอฟต์แวร์ โมเดล AI ต้นฉบับไม่มีความทรงจำเกี่ยวกับกระบวนการสร้างโค้ด และ prompt ที่ใช้สร้างซอฟต์แวร์มักจะสูญหายหรือไม่เพียงพอสำหรับการอ้างอิงในอนาคต
หากคุณใช้ llm เพื่อสร้างโค้ดจำนวนมากโดยไม่ผ่านการตรวจสอบ คุณกำลังทำผิดและโปรเจกต์ของคุณจะกลายเป็นสิ่งที่ไม่สามารถบำรุงรักษาได้ในทันทีที่มันไปผิดทางในด้านสถาปัตยกรรม หรือคุณได้รับข้อบกพร่องที่มีสาเหตุซับซ้อนหรืออะไรก็ตาม
สิ่งนี้สร้างสถานการณ์ที่น่าวิตกโดยเฉพาะสำหรับผู้ใช้ที่อัปโหลดเอกสารส่วนตัว ข้อมูลบัตรเครดิต และข้อมูลส่วนตัวไปยังแอปพลิเคชันที่ไม่มีใครบนโลกนี้เข้าใจอย่างแท้จริง
การต่อต้านของอุตสาหกรรมและแนวทางแก้ไขที่ปฏิบัติได้
ชุมชนนักพัฒนาไม่ได้ยอมรับการสร้างโค้ดด้วย AI แบบไม่จำกัดอย่างสมบูรณ์ นักพัฒนาที่มีประสบการณ์หลายคนสนับสนุนแนวทางที่มีการวัดผลมากขึ้น โดยใช้เครื่องมือ AI สำหรับงานเฉพาะ เช่น การสร้างเอกสาร การสร้าง project scaffolding เริ่มต้น หรือการจัดการการเปลี่ยนแปลงซ้ำๆ นักพัฒนาเหล่านี้เน้นย้ำว่า AI ควรเสริมความเข้าใจของมนุษย์มากกว่าการแทนที่อย่างสมบูรณ์
ทีมบางทีมกำลังประสบความสำเร็จกับแนวทางแบบผสมผสานที่รวมถึงการตรวจสอบโค้ดอย่างละเอียด การสร้างเอกสารที่ครอบคลุม และการรักษาการดูแลของมนุษย์ตลอดกระบวนการพัฒนา ข้อมูลเชิงลึกที่สำคัญคือเครื่องมือ AI ทำงานได้ดีที่สุดเมื่อนักพัฒนามีทักษะในการประเมินและเข้าใจโค้ดที่สร้างขึ้นแล้ว
กลยุทธ์การลดความเสี่ยง:
- การตรวจสอบโค้ดอย่างละเอียดสำหรับโค้ดทั้งหมดที่สร้างโดย AI
- การจัดทำเอกสารประกอบที่ครอบคลุมสำหรับระบบที่สร้างโดย AI
- การรักษาความเข้าใจของมนุษย์ต่อสถาปัตยกรรมระบบ
- การใช้ AI สำหรับงานที่มีขอบเขตจำกัดและแบ่งเป็นส่วนเล็กๆ แทนที่จะเป็นฟีเจอร์ทั้งหมด
- การรักษาองค์ความรู้ขององค์กรผ่านการแบ่งปันความรู้ในทีม
- การมอง AI เป็นเครื่องมือเพิ่มประสิทธิภาพมากกว่าตัวทดแทนความเข้าใจ
ผลกระทบในวงกว้าง
แนวโน้มนี้ขยายไปไกลกว่าโปรเจกต์แต่ละโปรเจกต์และส่งผลต่ออุตสาหกรรมซอฟต์แวร์ทั้งหมด หลักสูตรวิทยาการคอมพิวเตอร์รายงานการลดลงของการลงทะเบียนเรียนเนื่องจากนักเรียนกังวลเกี่ยวกับ AI ที่จะมาแทนที่อาชีพการเขียนโปรแกรม สิ่งนี้สร้างลูปป้อนกลับที่อันตรายซึ่งมีคนน้อยลงที่พัฒนาความเชี่ยวชาญที่จำเป็นในการบำรุงรักษาระบบที่สำคัญ
สถานการณ์นี้คล้ายกับความท้าทายด้านระบบอัตโนมัติอื่นๆ ที่มนุษย์ดิ้นรนเพื่อรักษาทักษะในขณะที่มอบหมายงานให้กับเครื่องจักรบางส่วน เช่นเดียวกับที่นักบินสามารถสูญเสียทักษะการบินเมื่อพึ่งพาระบบ autopilot มากเกินไป นักพัฒนาเสี่ยงที่จะสูญเสียความสามารถในการเขียนโค้ดเมื่อพึ่งพาการสร้างด้วย AI มากเกินไป
บทสรุป
แม้ว่าเครื่องมือเขียนโค้ดด้วย AI จะให้ประโยชน์ด้านผลิตภาพที่แท้จริงเมื่อใช้อย่างเหมาะสม แต่การผลักดันไปสู่การพัฒนาแบบ AI-first ขู่ว่าจะสร้างซอฟต์แวร์รุ่นหนึ่งที่ไม่สามารถบำรุงรักษาได้ แนวทางแก้ไขไม่ใช่การละทิ้งเครื่องมือเหล่านี้ทั้งหมด แต่ใช้อย่างรอบคอบในขณะที่รักษาความเข้าใจของมนุษย์และความรู้ขององค์กร
อุตสาหกรรมจำเป็นต้องสร้างแนวปฏิบัติที่ดีกว่ารอบการพัฒนาที่ช่วยเหลือด้วย AI เพื่อให้แน่ใจว่าผลประโยชน์ด้านผลิตภาพไม่มาแลกกับการบำรุงรักษาและความปลอดภัยในระยะยาว มิฉะนั้นเราเสี่ยงที่จะสร้างโครงสร้างพื้นฐานดิจิทัลที่ไม่มีใครเข้าใจอย่างแท้จริงหรือสามารถบำรุงรักษาได้อย่างเชื่อถือได้
อ้างอิง: Al First and the Bus Factor of 0