หอคอยยังคงสูงขึ้นเรื่อย ๆ
(lucumr.pocoo.org)- ภาพของซอฟต์แวร์ที่เขียนแบบไวบ์โค้ดดิ้งเปลี่ยนไปอย่างสุ่ม ๆ และคาดไม่ถึงนั้นคล้ายกับ หอคอยบาเบล ที่การก่อสร้างหยุดลงเพราะสูญเสียภาษาร่วมกันไป แต่ในยุค AI ความต่างคือแม้ความเข้าใจจะพังทลายไปแล้ว การก่อสร้างก็ยังเดินหน้าต่อได้
- ข้อจำกัดของซอฟต์แวร์ขนาดใหญ่ไม่ได้ขึ้นอยู่แค่ความเร็วที่แต่ละคนผลิตโค้ดได้เท่านั้น แต่ยังขึ้นอยู่กับการประสาน ความเข้าใจร่วมกัน เกี่ยวกับแนวคิด ขอบเขต เงื่อนไขคงตัว ความเป็นเจ้าของ และเหตุผลของการออกแบบได้ดีเพียงใด
- แรงเสียดทาน ที่เกิดขึ้นระหว่างการสำรวจโค้ด การตั้งคำถาม การรีวิว และการประสานงานข้ามทีม แม้จะเป็นความสูญเปล่าในแง่หนึ่ง แต่ก็เป็นกระบวนการซิงก์ความเข้าใจของกันและกัน และตรวจสอบฉันทามติเกี่ยวกับระบบด้วย
- เอเจนต์สามารถทำงานอย่างการเพิ่ม OAuth, การใส่แคช, หรือการสร้างฐานข้อมูลใหม่พร้อมกันแบบขนานได้โดยไม่ต้องสนทนากัน และแม้แต่ละการเปลี่ยนแปลงจะสมเหตุสมผลและผ่านการทดสอบ แต่ แบบจำลองร่วม ของมนุษย์อาจอ่อนแอลงได้
- ในงานวิศวกรรมที่มี AI ช่วย เอเจนต์จะตีความและแก้ไขแต่ละส่วนเพื่อให้การก่อสร้างดำเนินต่อไปได้โดยไม่เกิดความล้มเหลวทันที ทำให้ยากที่จะสังเกตเห็นการสูญเสีย ภาษาเชิงสถาปัตยกรรม ที่เคยทำให้มนุษย์ร่วมกันใช้เหตุผลกับระบบได้
พลังของหอคอยบาเบลไม่ได้อยู่ที่เทคโนโลยี แต่อยู่ที่การประสานกัน
- ภาพที่ซอฟต์แวร์บางส่วนจากการไวบ์โค้ดดิ้งเปลี่ยนไปในแบบที่ค่อนข้างสุ่มและคาดไม่ถึง ชวนให้นึกถึง The Tower of Babel ของ Bruegel
- เรื่องหอคอยบาเบลมักถูกตีความว่าเป็นเรื่องของความโอหัง ความทะเยอทะยาน และเหตุผลที่ผู้คนพูดกันคนละภาษา แต่ขณะเดียวกันก็สะท้อน ความเป็นหนึ่งเดียวที่ทำให้ความก้าวหน้าทางเทคโนโลยีเกิดขึ้นได้
- ใน ปฐมกาล 11:3-6 (KJV) ผู้คนพัฒนาเทคนิคโดยใช้ก้อนอิฐเผาแทนหิน และใช้น้ำมันดินแทนปูน ก่อนจะพยายามสร้างเมืองและหอคอยที่สูงถึงฟ้า
- สิ่งที่พระเจ้ามองว่าเป็นปัญหาไม่ใช่อิฐหรือความรู้ด้านการผลิต แต่คือการที่ผู้คนเป็นหนึ่งเดียวกันและมี ภาษาเดียวกัน จนแทบไม่มีสิ่งใดจำกัดพวกเขาได้
- เมื่อใช้ภาษาร่วมกันเพื่อเชื่อมงานของแต่ละคนเข้าด้วยกัน มนุษย์ก็สามารถสร้างสิ่งที่ไม่มีใครสร้างได้เพียงลำพัง
- เมื่อสิ่งที่หายไปไม่ใช่อิฐหรือสูตรการผลิต แต่เป็นความสามารถในการเข้าใจกันและกัน การประสานงานก็เป็นไปไม่ได้ และการก่อสร้างก็หยุดลง
หอคอยที่ยังสูงขึ้นต่อไปแม้ AI เอเจนต์จะลบแรงเสียดทานออกไปแล้ว
- การเขียนโปรแกรมแบบมี AI ช่วยมอบเครื่องมือที่ทรงพลังยิ่งขึ้นให้แต่ละคน และนักพัฒนาที่ใช้เอเจนต์ก็สามารถเปลี่ยนแปลงโค้ดเบสได้ในขอบเขตที่กว้างกว่ามาก
- อย่างไรก็ตาม ข้อจำกัดของโครงการขนาดใหญ่ไม่ได้ขึ้นอยู่แค่ความเร็วที่แต่ละคนสร้างโค้ดได้ แต่ยังขึ้นอยู่กับว่าผู้คนสามารถ ประสานความเข้าใจ เกี่ยวกับระบบที่ถูกเปลี่ยนแปลงได้ดีเพียงใดด้วย
- ภาษาร่วมของโครงการซอฟต์แวร์ไม่ใช่ภาษาอังกฤษหรือ Python เอง แต่คือความเข้าใจร่วมกันเกี่ยวกับสิ่งต่อไปนี้
- แต่ละแนวคิดหมายถึงอะไร
- ขอบเขตของระบบอยู่ตรงไหน
- มีเงื่อนไขคงตัวใดบ้างที่สำคัญ
- ใครเป็นเจ้าของอะไร
- อะไรคือเหตุผลที่ทำให้ระบบมีโครงสร้างแบบปัจจุบัน
- ความเข้าใจเหล่านี้ไม่ได้ถูกบันทึกไว้อย่างสมบูรณ์ในที่เดียว แต่สะสมอยู่ทั้งในเอกสารและโค้ด รวมถึงใน การรีวิวโค้ด บทสนทนา การโต้เถียง และประสบการณ์การอธิบายการเปลี่ยนแปลงให้ผู้อื่นฟัง
- ก่อนยุคเอเจนต์ หากต้องแก้ไข storage layer ของคนอื่น ก็มักต้องอ่านโค้ด ตั้งคำถาม และในหลายกรณีก็ต้องประสานกับอีกทีมที่ดูแลบริการซึ่งเป็น dependency
- กระบวนการนี้มีส่วนที่สูญเปล่าอยู่บ้าง แต่ก็ทำหน้าที่ถ่ายทอดความเข้าใจจากคนหนึ่งไปสู่อีกคน และยืนยันว่าทั้งสองฝ่ายยังเห็นตรงกันว่าระบบทำงานอย่างไร
- แรงเสียดทานแบบนี้ช่วยซิงก์ความเข้าใจของผู้คน
- เอเจนต์ลดแรงเสียดทานเหล่านี้ลงอย่างมาก ทำให้หลายคนสามารถขอการเปลี่ยนแปลงคนละแบบได้โดยไม่ต้องพูดคุยกัน
- คนหนึ่งเพิ่ม OAuth อีกคนใส่แคช อีกคนสร้างฐานข้อมูลใหม่ตั้งแต่ต้นและทำ UI ให้เป็นสีชมพู
- การเปลี่ยนแปลงแต่ละอย่างอาจสมเหตุสมผลได้ในตัวเอง โค้ดคอมไพล์ได้ ผ่านการทดสอบ และยังสร้างคำอธิบายได้เมื่อจำเป็น
- ไม่มีใครจำเป็นต้องคุยกับคนอื่น หรือเรียนรู้ ส่วนหนึ่งของแบบจำลองร่วม ที่ในอดีตเคยได้ซึมซับระหว่างกระบวนการเปลี่ยนแปลง
- เอเจนต์ไม่รู้สึกเจ็บปวด แต่ที่รู้สึกคือมนุษย์ และมันทำให้เราสามารถแก้ไขทั้งส่วนของระบบและโค้ดเบสที่ก่อนหน้านี้ต้องอาศัยความช่วยเหลือจากคนอื่นได้
- โครงการไวบ์โค้ดดิ้งที่ขยายขนาดขึ้นจะกลายเป็นโค้ดเบสแบบหอคอยบาเบล ไม่ใช่เพราะสื่อสารกันไม่ได้ แต่เพราะ ไม่จำเป็นต้องสื่อสารกันอีกต่อไป
- นักพัฒนาแต่ละคนมีนักแปลที่ไม่รู้จักเหน็ดเหนื่อยคอยอธิบายส่วนเฉพาะของหอคอย และทำการเปลี่ยนแปลงเฉพาะจุดตามที่ต้องการ
- การเปลี่ยนแปลงยังคงถูกนำเข้าไปเรื่อย ๆ แต่ภาษาเชิงสถาปัตยกรรมที่เคยทำให้มนุษย์ช่วยกันใช้เหตุผลกับระบบอาจหายไป
- ในเรื่องหอคอยบาเบลในคัมภีร์ การสูญเสียภาษาร่วมกันทำให้การก่อสร้างหยุดลง แต่ในงานวิศวกรรมที่มี AI ช่วยนั้น การก่อสร้างอาจดำเนินต่อไปได้แม้ความเข้าใจร่วมกันจะพังทลายไปแล้ว
- เพราะหอคอยไม่ได้พังลงและไม่มีความล้มเหลวฉับพลันเกิดขึ้น จึงยากที่จะสังเกตว่าเราได้สูญเสียอะไรไป และหอคอยก็ยังคงสูงขึ้นเรื่อย ๆ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมคิดมานานแล้วว่า ความสามารถในการประกอบรวมกัน ของซอฟต์แวร์ควรต้องมีการล้างแถวเหมือนเกม Tetris นักพัฒนาที่ใช้เอเจนต์แบบยังไม่ชำนาญหรือวิศวกรที่ประสบการณ์น้อยมักพลาดการจัดระเบียบแบบนี้ และมีแนวโน้มจะสร้างหอคอยให้สูงขึ้นเรื่อย ๆ
เราอาจทำให้เอเจนต์คอยรวมองค์ประกอบเดิมซ้ำ ๆ ให้กลายเป็นนามธรรมที่ดีกว่าได้ แต่แม้แต่ Fable หรือ 5.6 Sol ก็ยังตามมนุษย์ไม่ทันมากในเรื่อง สัญชาตญาณด้านสถาปัตยกรรมระดับสูง ที่ใช้คาดการณ์วิวัฒนาการอันละเอียดอ่อนของซอฟต์แวร์ ดูเหมือนว่าระบบปัจจุบันยังไม่สามารถรักษา world model ที่มีคุณภาพสูง แบบเบาบาง และขยายย่อได้ ซึ่งมนุษย์ใช้จัดการงานได้ดีพอ แต่แค่ความต่างตอนนี้หดเหลือถึงระดับความละเอียดอ่อนเช่นนี้ได้ก็นับว่าน่ามีความหวังแล้ว
นี่คือเวอร์ชัน AI ของปัญหาการขยายขนาดที่ Brooks กล่าวถึงใน 《The Mythical Man-Month》 ซึ่งเมื่อขนาดใหญ่ขึ้น การระเบิดเชิงจัดวางก็ยิ่งเลวร้ายลง และโค้ดที่ทำหน้าที่แทบเหมือนกันก็จะถูกเขียนซ้ำอยู่ทั่วทั้งโปรเจกต์ เราจำเป็นต้องหาวิธีทำให้การเขียนโค้ดด้วย AI มุ่งไปสู่ ความกระชับ
GPT3.5 และ gpt4 ที่ครั้งหนึ่งเคยถูกยกย่อง ตอนนี้ก็ถูก qwen27b หรือ gemma31b ทิ้งห่างไปมากแล้ว ถ้ามีเวลามากพอและมี การเรียนรู้แบบเสริมกำลัง (RL) ที่เหมาะสม โมเดลก็น่าจะสร้างโมเดลของระบบซอฟต์แวร์ที่ยอดเยี่ยมขึ้นมาในหัวได้เช่นกัน
แก่นของบทความนี้ทำให้นึกถึง Lisp Curse และ Bipolar Lisp Programmer มาก Lisp ทำให้คนคนเดียวสร้างสิ่งที่ตัวเองต้องการได้ง่ายเกินไป จนโปรแกรมเมอร์มีแรงจูงใจน้อยลงที่จะร่วมมือกันสร้างผลลัพธ์ทั่วไปและซับซ้อน และสุดท้ายระบบนิเวศซอฟต์แวร์สาธารณะก็เลยยากจนกว่าภาษาอื่นที่ต้องใช้ความพยายามมากกว่า
ดูเหมือน Armin กำลังเสนอประเด็นที่คล้ายกันมากเกี่ยวกับการเขียนโค้ดด้วย AI: Lisp Curse, Bipolar Lisp Programmer
อาจมี รูปแบบการประมวลผลทางการรับรู้ ที่ต่างกันระหว่างสองกลุ่มนี้ หาก Lisp จะมีประสิทธิผลทัดเทียมภาษาอื่น ก็ต้องใช้ homoiconicity อย่างจริงจัง ซึ่งผลลัพธ์คือโปรแกรม Lisp ที่จริงจังมักกลายเป็นชุดของ ภาษาเฉพาะโดเมน (DSL) ที่สุดท้ายมีคนเข้าใจอยู่แค่หนึ่งหรือสองคน
ข้อจำกัดของโครงการซอฟต์แวร์ขนาดใหญ่ไม่ได้อยู่ที่คนคนหนึ่งจะผลิตโค้ดได้เร็วแค่ไหน แต่อยู่ที่ว่าคนที่เปลี่ยนแปลงระบบนั้นสามารถ ประสานความเข้าใจร่วมกัน เกี่ยวกับระบบนั้นได้ดีเพียงใด คำพูดที่ว่าทุกอย่างซับซ้อนขึ้นหลังวันที่ 30 พฤศจิกายน 2022 นั้นตรงมาก
การเอา AI เข้ามาใส่ในเรื่องนี้จึงแทบเป็นความผิดพลาดแบบเอาความซับซ้อนอีกชั้นไปทับบนความซับซ้อนเดิม มองในแง่ดีก็คือการสิ้นเปลืองฮาร์ดแวร์มหาศาล มองในแง่ร้ายคือเอเจนต์อาจสร้างบั๊กใหม่พอ ๆ กับที่แก้บั๊ก ทำให้ซอฟต์แวร์ขยะที่เปราะบางเพิ่มขึ้น และในขณะเดียวกันผู้คนก็ไม่เรียนรู้ทักษะจนความสามารถโดยรวมของมนุษยชาติลดลง ซอฟต์แวร์ไม่ได้จำเป็นต้องซับซ้อนโดยเนื้อแท้ถึงเพียงนี้ และถ้าจะแก้ก็ต้องให้คุณค่ากับ ความเป็นช่างฝีมือ
HTML และการ prerender ก็กลับมาพร้อมกับ HTMx และ LiveView ส่วน CSS ก็หลุดพ้นจากวิธีแก้ปัญหาแปลกประหลาดในอดีตแล้ว ถ้าต้องอธิบายให้เพื่อนร่วมงานรุ่นใหม่ฟังว่าเมื่อก่อนดีบักเว็บเพจบน IE6 กันอย่างไร ก็จะรู้สึกถึงความต่างของยุคสมัย บางอย่างซับซ้อนขึ้น แต่บางอย่างก็สุกงอมพอจนเรียบง่ายลง
มนุษย์เมื่อ 20,000 ปีก่อนคริสตกาลใช้ชีวิตไปกับการหาอาหาร หลีกหนีความหนาวและผู้ล่า แต่เมื่อ 5,000 ปีก่อนคริสตกาล มนุษย์ต้องเพาะปลูก กังวลเรื่องฝนและโรคภัย และสร้างระบบเพื่อจัดการชุมชนกับที่ดิน ทุกวันนี้คนส่วนใหญ่ไม่ได้ปลูกอาหารเอง แต่คอยจัดการความซับซ้อนของสังคมขนาดใหญ่แทน ถ้านักพัฒนายุค 1970~80 มามอง ซอฟต์แวร์ก่อนยุค LLM ก็ซับซ้อนมหาศาลอยู่แล้ว และตอนนี้แทบไม่มีใครเขียนโค้ดลงฮาร์ดแวร์โดยตรงแบบไร้ชั้นนามธรรมอีกต่อไป แม้แต่เรื่องการเข้ารหัสก็มีไลบรารีคอยซ่อนความซับซ้อนและสอนว่า “อย่าเขียนเอง” ตอนนี้คำถามสำคัญคือ LLM จะประสานความเข้าใจเกี่ยวกับระบบที่กำลังถูกเปลี่ยนได้เร็วแค่ไหน
ภาษาร่วมของโครงการซอฟต์แวร์ไม่ใช่ทั้งภาษาอังกฤษหรือ Python แต่คือความเข้าใจร่วมกันเกี่ยวกับความหมายของแนวคิด ขอบเขต เงื่อนไขคงตัว ความเป็นเจ้าของ และเหตุผลที่ระบบมีรูปร่างอย่างทุกวันนี้ Pattern Language ของ Christopher Alexander พูดถึงปัญหานี้โดยตรง และการแนะนำให้สร้างภาษารูปแบบที่เหมาะกับแต่ละโดเมนก็นำไปสู่ GoF Design Patterns อันโด่งดัง
กำลังทดลองฟีเจอร์ที่ให้ AI ดูแลภาษารูปแบบ 3 ชุดสำหรับแต่ละโปรเจกต์ ได้แก่ ด้านธุรกิจ ผลิตภัณฑ์ และเทคนิค ซึ่งทำงานได้ดีมาก เมื่ออ้างอิงสิ่งนี้ตอนวางแผน และให้มันจัดระเบียบระหว่างการพัฒนาและการรีวิว โปรเจกต์ที่ เขียนโค้ดด้วย AI 100% ก็มีระบบระเบียบ จัดแนวข้ามโดเมนได้ดี และดูแลง่ายขึ้นมาก
ในหอบาเบล เมื่อภาษาร่วมสูญหาย การก่อสร้างก็หยุดลง แต่ในการพัฒนาที่มี AI ช่วย การก่อสร้างยังดำเนินต่อไปแม้ความเข้าใจร่วมกันจะพังทลายแล้ว ผู้เขียนไม่ได้ระบุชัดว่าดีหรือร้าย แต่เห็นได้ชัดว่ามองว่าเป็นเรื่องร้าย
ถ้าการรู้ว่ามะเขือเทศเป็นผลไม้คือความฉลาด และการไม่ใส่มันลงในสลัดผลไม้คือปัญญา AI ก็คือรูปแบบสูงสุดของความฉลาดที่ไร้ปัญญาโดยสิ้นเชิง หรือแทบจะเป็นภาพลวงของความฉลาดเสียมากกว่า ถ้าไม่มีใครเข้าใจว่า AI กำลังทำอะไร เราก็ควรหยุด และยอมรับว่าเราขาด ปัญญา ที่จะควบคุมสิ่งที่เรากำลังสร้าง
ผมเองก็นึกถึงบาเบลและภาพของ Bruegel เหมือนกัน แต่ในมุมที่มองโลกแง่น้อยกว่ามาก คือมีเอเจนต์ตัวเล็กสายตาสั้นจำนวนมากพัฒนาพื้นที่ของตัวเองในภาพรวมที่ใหญ่โตจนไม่มีทางรู้ทั้งหมด ด้านหนึ่งมีเชิงเทิน 50 อัน อีกด้านมีหอคอยยื่นประหลาด และเหนือคอร์ทยาร์ดก็มีหลังคา adobe ทั้งที่ไม่มีใครรู้ว่าทำไม ข้าง ๆ บนชานบันไดกลับมีหอที่ติดหลังคามุงจากอยู่ด้วย
ในระดับการออกแบบรายจุดมันอาจสมเหตุสมผล แต่เมื่อขาดนโยบายและการตัดสินใจหลายชั้นที่คอยบูรณาการทั้งโครงการ ก็จะกลายเป็น สัตว์ประหลาดทางสถาปัตยกรรมขนาดมหึมา ความจริงที่ว่าการสร้างและรักษาภาษาร่วมในองค์กรที่ใหญ่พอนั้นต้องอาศัยวินัย สะท้อนอยู่ในคำศัพท์เฉพาะของบริษัทที่ประสบความสำเร็จและแม้แต่กองทัพด้วย พวก “Gastown Mayors” กับ “polecats” ที่อยู่ต่ำลงมา และแม้แต่โกเล็มที่อยู่ถัดลงไปต่างก็คิดว่าตัวเองใช้ภาษาเดียวกัน แต่เมื่อทุกอย่างเสร็จสิ้นแล้วเท่านั้น จึงจะพบว่าความเข้าใจที่เคยเชื่อจากบัลลังก์ว่าถ่ายทอดลงมาอย่างสมบูรณ์นั้น แท้จริงแล้วไม่เคยถูกร่วมแบ่งปันเลย
Anakin: “นักพัฒนาที่ใช้เอเจนต์จะมีความสามารถในการเปลี่ยนโค้ดเบสเพิ่มขึ้นอย่างมหาศาล”
Padmé: “ไปในทางที่ดีขึ้น ใช่ไหม?”
Anakin: เงียบ
Padmé: “ไปในทางที่ดีขึ้น ใช่ไหม?”
เหตุผลที่การเขียนโค้ดแบบ vibe บอกว่าอย่าอ่านโค้ดที่ถูกสร้างขึ้นมา น่าจะเป็นเพราะ ถ้าเคยเห็นความสยองที่ซ่อนอยู่ในไฟล์ Python สักครั้ง จะไม่มีวันลืม ในความหมายกว้าง ๆ มันทำงานตามที่ขอ แต่ทุกครั้งที่ต้องเลือกวิธีไปให้ถึงเป้าหมาย มันกลับตัดสินใจอย่างไม่สม่ำเสมอ
มันใช้การตรวจสอบข้อมูลประหลาด ๆ กับอินพุตผู้ใช้เพียงบางส่วน เรียงข้อมูลซ้ำหรือลดเป็นตัวพิมพ์เล็กในสามขั้นตอนโดยไม่มีเหตุผล และถึงขั้นฮาร์ดโค้ดชื่อคอลัมน์ทุกอันจากแถวแรกของไฟล์ CSV อินพุตให้เป็นสตริง ครึ่งหนึ่งเขียนเป็นฟังก์ชัน global ที่รับ data class ส่วนอีกครึ่งกลับทำเป็นคลาส ถ้าคิดว่าสักวันจะต้องมาอัปเดตและบำรุงรักษาเอง ก็ยากที่จะไม่แก้ไขมัน แต่พอเริ่มแก้ไปเรื่อย ๆ เวลาที่ประหยัดได้ไปมากส่วนหนึ่ง ก็หายไป
การเขียนโปรแกรมแบบเอเจนต์ ใกล้เคียงกับงานบริหารมากกว่าการเขียนโปรแกรมจริงอย่างมาก ผู้จัดการมักรับรู้เพียงภาพรวมระดับสูงของงานที่ผู้มีส่วนร่วมแต่ละคนทำ และบ่อยครั้งก็ไม่มีทั้งเวลา พื้นที่ทางความคิด หรือความสามารถที่จะเข้าใจรายละเอียดทั้งหมด
ยิ่งมีซอฟต์แวร์ที่ถูกเขียนโดยเอเจนต์มากขึ้น บทบาทของวิศวกรซอฟต์แวร์ก็จะยิ่งใกล้กับงานบริหารมากกว่างานเทคนิค
เพราะไม่มีเวลาและกำลังจะเข้าใจทุกอย่าง จึงเพียงทำงานที่จำเป็นใน ชั้นนามธรรมของตนเอง
ในอดีต การรีแฟกเตอร์ครั้งใหญ่ต้องใช้ความพยายามมาก จึงต้องมีเหตุผลที่ดีพอ ตอนนี้ถ้าพรอมป์ต์คลุมเครือเพียงเล็กน้อยและไม่ได้ตรวจผลลัพธ์ให้ดี เอเจนต์ก็อาจเขียนโค้ดใหม่ไปครึ่งหนึ่งได้ ทำให้ จิตวิญญาณของโปรแกรมอาจเปลี่ยนไปอย่างมากในทุกวัน ได้ มันเป็นทั้งเรื่องที่ยอดเยี่ยมและในขณะเดียวกันก็ไม่ใช่เลย