Vibe Coding ทำให้ Bus Factor กลายเป็น 0

• ในการพัฒนาซอฟต์แวร์ Bus Factor คือแนวคิดที่ใช้บอกว่าต้องมีผู้ถือครองความรู้เฉพาะกี่คนจึงจะยังดูแลโปรเจกต์ต่อไปได้ โดยเดิมนั้น ค่าต่ำสุดในกรณีเลวร้ายคือ 1
• อย่างไรก็ตาม หลังจาก การเปิดตัว ChatGPT (30 พฤศจิกายน 2022) เมื่อ generative AI ถูกนำไปใช้กันอย่างแพร่หลาย หลายคนไม่ได้เก็บรักษาความรู้ไว้ด้วยตนเองอีกต่อไป แต่พึ่งพา AI แทน จนเกิดสถานการณ์ที่แทบจะเป็น Bus Factor 0
• ในสายงานเขียนโปรแกรม นักพัฒนาจำนวนมากขึ้นเรื่อยๆ ใช้ โค้ดและฟังก์ชันที่ LLM สร้างขึ้น ตรงๆ โดยเลิกพยายามทำความเข้าใจ codebase และหันไปใช้ “vibe coding”
• ผลคือเมื่อถึงเวลาต้องแก้บั๊ก อุดช่องโหว่ความปลอดภัย หรือขยายฟีเจอร์ อาจต้องเผชิญกับสถานการณ์ที่ ไม่มีใครรู้ว่าเหตุใดโค้ดจึงถูกเขียนแบบนั้น
• สิ่งนี้ก่อให้เกิดความเสี่ยงร้ายแรงต่อความน่าเชื่อถือและความปลอดภัยของซอฟต์แวร์ และตราบใดที่ วันที่ AI สามารถสร้างโค้ดที่สมบูรณ์แบบได้อย่างสมบูรณ์แบบ ยังมาไม่ถึง ข้อจำกัดเชิงรากฐานนี้ก็ยังคงอยู่

---

แนวคิดและประวัติของ Bus Factor

• Bus Factor คือแนวคิดที่ แสดงเป็นตัวเลขว่าความรู้เฉพาะถูกแบ่งปันอยู่กับคนกี่คน
  • ตัวอย่าง: ถ้ามี 3 คนที่รู้วิธีกู้คืน database backup ได้ Bus Factor ของความสามารถนี้ก็คือ 3
• ตามธรรมเนียมแล้วค่าที่แย่ที่สุดคือ 1 และหากคนคนนั้นสูญเสียความรู้นั้นไป ก็จะไม่สามารถดูแลโปรเจกต์ต่อได้
• มนุษย์พยายามเอาชนะปัญหานี้ผ่านวิธีมากมาย เช่น การทำเอกสาร การสอน การถ่ายทอดความรู้ สัมมนา โรงเรียน ฯลฯ
  • นำไปสู่ความพยายามอย่างเป็นระบบในการสืบทอดและเก็บรักษาความรู้ โดยใช้ทั้งทรัพยากรบุคคลและเวลาเป็นจำนวนมาก

การนำ AI มาใช้และ Bus Factor 0

• การเปิดตัว ChatGPT ในเดือนพฤศจิกายน 2022 เปิดยุค “AI First”
• ในกระบวนการที่ AI สร้างโค้ดและฟังก์ชัน หลายคนถูกกันออกจากการเป็นผู้เก็บรักษาความรู้ และเริ่มพึ่งพาสิ่งที่ AI สร้างขึ้น ทำให้ความเข้าใจต่อโปรเจกต์ลดลงอย่างรวดเร็ว
• ผลลัพธ์คือเกิด ภาวะที่ไม่มีผู้ถือครองความรู้อยู่เลย หรือก็คือ สถานการณ์ Bus Factor 0
• โปรแกรมเมอร์มีแนวโน้มจะไม่เขียนหรือทำความเข้าใจโค้ดและฟังก์ชันด้วยตนเอง แต่ มอบหมายให้ AI ไปทั้งหมด
• ในกระบวนการนี้ นักพัฒนาเริ่ม หลีกเลี่ยงการทำความเข้าใจ codebase และการทำเอกสาร แล้วเปลี่ยนไปเป็นรูปแบบที่เพียง ขอให้ AI อธิบายใหม่อีกครั้ง

ปัญหาของการเขียนโค้ดด้วย LLM

• ต่อให้ยังไม่พูดถึงปัญหาคุณภาพโค้ด ประเด็นสำคัญคือ การอ่านและการบำรุงรักษานั้นยากกว่าการเขียนโดยเนื้อแท้
• ในอดีต อย่างน้อยก็ยังมีเมนเทอร์หรือเอกสารคอยช่วยเหลือขั้นต่ำ แต่ในสภาพแวดล้อมที่พึ่งพา AI แม้แต่ตาข่ายนิรภัยแบบนี้ก็หายไป
• ในการพัฒนาที่อิง LLM กระบวนการสร้างโค้ดไม่ได้ถูกบันทึกไว้ และ แม้แต่ AI เองก็จำบริบทของโค้ดที่มันสร้างไม่ได้
• สุดท้ายแล้ว นักพัฒนาต้องตกอยู่ในสถานการณ์ที่ต้องวิเคราะห์และแก้ไข โค้ดที่ AI เขียน แต่มีบริบทไม่ชัดเจน
• สิ่งนี้นำไปสู่ภาวะที่ ไม่มีใครรู้เจตนาและโครงสร้างของโค้ด เมื่อต้องแก้บั๊ก แพตช์ช่องโหว่ความปลอดภัย หรืออัปเกรด dependency

ความเสี่ยงจากมุมมองของผู้ใช้

• ไม่ใช่แค่นักพัฒนา แต่ผู้ใช้เองก็เผชิญความเสี่ยงเช่นกัน
  • ซอฟต์แวร์ที่ให้อัปโหลดเอกสารส่วนตัว ข้อมูลบัตรเครดิต รูปถ่ายส่วนตัว หรือความคิดส่วนตัว อาจถูกสร้างขึ้นจาก โค้ดที่ไม่มีใครรู้โครงสร้างภายในและจุดประสงค์ของมัน
• สิ่งนี้แฝงความเสี่ยงร้ายแรงในแง่ การคุ้มครองข้อมูลและความน่าเชื่อถือ และทำให้เกิดคำถามต่อ เสถียรภาพของบริการ

บทสรุป

• vibe coding ที่นำไปสู่ Bus Factor 0 เป็นแนวทางที่มีข้อบกพร่องในระดับพื้นฐาน
• นี่คือข้อจำกัดที่หลีกเลี่ยงไม่ได้ ตราบใดที่ AI ยังไม่สามารถสร้างโค้ดที่ถูกต้อง 100% จากพรอมป์ต์ที่ถูกต้อง 100% ได้
• ดังนั้นในสถานการณ์ปัจจุบัน นอกเหนือจาก การใช้ AI แล้ว ก็ไม่อาจมองข้ามความสำคัญของ การเก็บรักษาความรู้ และ ความเข้าใจโค้ด ได้ และจำเป็นต้อง คงระบบการจัดการความรู้และการทำเอกสาร ไว้

[iolothebard]

หรือว่าบัสแฟกเตอร์กลายเป็นอนันต์ไปแล้วไม่ใช่เหรอ?

[cdwdong2]

ถ้านักพัฒนาที่สังกัดบริษัทไม่มีความรู้ บัสแฟกเตอร์ก็จะเข้าใกล้ 0

[GN⁺]

ความคิดเห็นจาก Hacker News

• การใช้ LLM เพื่อปั่นโค้ดจำนวนมหาศาลที่ไม่ได้รับการรีวิวออกมาเฉยๆ เป็นวิธีใช้งานที่ผิด โปรเจกต์แบบนั้นหมายความว่าในเชิงโครงสร้างมันกำลังเดินไปผิดทาง หรือถ้าเกิดบั๊กซับซ้อนขึ้นมาก็จะกลายเป็นสิ่งที่บำรุงรักษาไม่ได้ในไม่ช้า จุดแข็งที่แท้จริงของ LLM คือสถานการณ์แบบนี้: เมื่อต้องนำอัลกอริทึมที่เป็นที่รู้จักไปใช้กับโครงสร้างข้อมูลเดิมที่ซับซ้อน, เมื่อต้องตั้งโครงของข้อมูลทดสอบหรือ unit test ที่มี dependency เยอะ, เมื่อต้องทำ visual web editor กับ backend API พร้อมเพิ่มความสามารถในการบันทึกลง sqlite, หรือเมื่อต้องนำงานที่ทำซ้ำซึ่งแม้แต่ regular expression ที่ซับซ้อนก็ยังจัดการยาก ไปใช้กับ codebase ขนาดใหญ่ เป็นต้น ในทางปฏิบัติ LLM ทำให้งานที่เคยกินเวลาครึ่งวันหรือ 3 วัน เริ่มต้นได้ใน 2 นาที ประเด็นสำคัญคือ ต่อให้ LLM แก้ปัญหาที่ยากมากไม่ได้ ก็ยังเพิ่มผลิตภาพได้อย่างมหาศาล เราจึงหลุดพ้นจากงานซ้ำๆ น่าเบื่อ แล้วไปโฟกัสกับปัญหาที่น่าสนใจกว่าได้

  • ตอนแรกคิดว่า LLM จะจัดการงานเปลี่ยนแปลงซ้ำๆ ใน codebase ขนาดใหญ่ได้ภายใน 2 นาที แต่พอลองจริงกับโมเดลใหญ่หลายตัวกลับพบว่ายิ่ง context ซับซ้อน ความผิดพลาดยิ่งสะสม และบางครั้งยังมีการเปลี่ยนแปลงที่ไม่เกี่ยวข้องโผล่มาด้วย สุดท้ายเลยเชื่อถือไม่ได้ กับตัวอย่างขนาดเล็กมันสมบูรณ์แบบ แต่พอขนาดใหญ่ขึ้นก็เริ่มไม่ไหว จะปรับปรุงด้วย agentic loop ก็ได้ แต่พอต้องรันและรีวิวซ้ำๆ กลับใช้เวลามากกว่าเดิมมาก ให้ LLM เขียนโปรแกรมเพื่อทำงานเปลี่ยนแปลงนั้นแบบอัตโนมัติกลับน่าเชื่อถือกว่ามาก

  • ตัวอย่างที่ยกมาทั้งหมดก็ดูดี แต่จริงๆ แล้วกรณีใช้งานที่เป็นไปได้มีมากกว่านั้นมาก คุณพูดถึงกรณีของนักพัฒนาที่ชำนาญ แต่สำหรับคนที่ทักษะทางเทคนิคยังไม่มากหรือเพิ่งเริ่มเรียน LLM ก็ทำให้สิ่งที่พวกเขาทำได้เพิ่มขึ้นมากเช่นกัน งานที่เมื่อก่อนต้องจ่าย 100 ดอลลาร์ ตอนนี้ลองทำเองได้ใน 3 นาที ผลลัพธ์จะสมบูรณ์แบบและบำรุงรักษาได้ไหมกลับไม่ใช่เรื่องสำคัญนัก การได้เห็นความเป็นไปได้นั้นมีคุณค่ามากกว่า

  • ฉันเห็นด้วยกับความเห็นของคุณ แต่อยากเล่าประสบการณ์ขำๆ ล่าสุด ฉันขอให้ Claude เขียน unit test แล้วพอรีวิวก็พบว่าโค้ดของฉันเองมีบั๊กจริง และ test นั้นจับได้ แต่แทนที่ Claude จะแก้บั๊ก มันกลับทำให้ test ที่ล้มเหลวนั้นไม่ถูกรันไปเลยเพื่อให้ผ่าน เป็นเรื่องชวนขำในโลกจริง LLM อ่อนเรื่องการนิยาม requirement, การออกแบบสถาปัตยกรรม, และการเขียนสเปกให้ตรง requirement แต่มีจุดแข็งในงานอย่างการเขียนโค้ดที่ขอบเขตชัดและผลกระทบจำกัด

  • ฉันเคยลองใช้ขั้นกลางแบบให้ AI รีวิว PR อัตโนมัติก่อน แล้วค่อยทำ manual review การสร้างโค้ดใช้เวลา 5~10 นาที ส่วนการรีวิวและ commit เพิ่มเติมโดยทั่วไปใช้ 1~3 ชั่วโมง แต่ฉันก็ใช้วิธีนี้ได้ผลในหลายโปรเจกต์ (10~20k LOC, ราว 100 ไฟล์) ถ้าให้สเปกดี ฟีเจอร์จำนวนมากจะถูกทำออกมาได้แทบจะถูกต้องโดยไม่ต้องแก้เยอะ และส่วนใหญ่จะเป็นการ refactor ตาม feedback แน่นอนว่าถ้าทำงานไม่ถูกต้องจริงๆ บางครั้งก็ใช้เวลาเกือบทั้งวันในการแก้ แต่โดยรวมแล้วผลิตภาพดีขึ้น 3~5 เท่า สำหรับโปรเจกต์ขนาดใหญ่ ดูเหมือนว่าการแยกชิ้นส่วนและทำให้เป็นโมดูลจะดีกว่า

  • การพูดทำนองว่า "LLM ทำงานปริมาณ x วันเสร็จใน 2 นาที" ค่อนข้างเกินจริงเล็กน้อย เพราะไม่ได้รวมเวลารีวิวไว้ ถ้ารวมกระบวนการรีวิวและตรวจสอบจริง เวลาจะมากกว่านั้นมาก และอาจเผลอตกไปอยู่ใน “วิธีที่ผิด” ที่พูดถึงตอนต้นได้ด้วย

• บทความนี้ยกปัญหาของการสร้างโค้ดด้วย AI มาได้หลายข้อ แต่ดูเหมือนจะไม่คำนึงถึงวิธีแก้ที่มีอยู่แล้วหรืออาจเกิดขึ้นในอนาคต แต่ก่อน ต่อให้ทีมลงแรงกับ codebase เพียงเล็กน้อย ก็ยังช่วยให้คนที่เพิ่งเข้ามาใหม่เข้าใจโค้ดได้ เลยสงสัยว่าเจ้าของบทความไม่ค่อยมีประสบการณ์กับ legacy code หรือคิดจริงๆ ว่าประเด็นที่ AI “ลืม context ทั้งหมดของกระบวนการเขียนครั้งแรก” เป็นสิ่งที่แก้ไม่ได้ เขายังดูเหมือนเข้าใจปัญหา Bus Factor 0 ว่าต้องแก้ได้อย่างถูกต้องสมบูรณ์ 100% เท่านั้น ทั้งที่จริงมนุษย์เองก็ไม่ได้ถูกต้อง 100% ตลอดเวลา แต่เราก็ยังเชื่อถือกัน

  • รู้สึกว่าบทความนั้นมองปัญหาแบบย่อเกินไปมาก ความจริงก็คือ เรามีข้อจำกัดอยู่แล้วตั้งแต่แรกว่าไม่อาจทำทุกอย่างร่วมกับผู้เขียนได้เสมอ แค่มีคู่ช่วยหรือ AI ที่คอยอธิบายได้ก็ถือว่าก้าวหน้าอย่างมากแล้ว มันเหมือนกำลังจินตนาการถึงโลกที่ไม่มีมนุษย์ แต่เราก็เจอสถานการณ์แบบนั้นบ่อยอยู่แล้ว

  • ฉันคือผู้เขียน เห็นด้วยกับข้อทักท้วงข้อแรก และคิดว่า AI จะค่อยๆ ลดช่องว่างนี้ได้ในอนาคต แต่กว่าจะถึงตอนนั้น ปัญหาบางอย่างอาจเกิดขึ้นไปแล้ว ยังมีปัญหาเรื่องโค้ดที่เหลืออยู่โดยไม่มีทั้งบริบทเชิงตรรกะหรือประวัติการแก้ไขด้วย มีคนพูดกันมากว่า AI “เรียนรู้ตลอดเวลา” แต่ในความเป็นจริง มันไม่ได้เรียนรู้อะไรจนกว่าจะมีโมเดลใหม่ออกมา มนุษย์เองก็ไม่แม่น 100% แต่ก็ไม่ใช่ Bus Factor 0 และการระบุปัญหากับแก้ปัญหาก็ง่ายกว่า ถ้าปัญหาอื่นๆ ถูกแก้ได้ ปัญหา bus factor ก็จะลดลงตามไปด้วย

  • ฉันเคยคิดเหมือนกันว่า ถ้าตอนต้องวิเคราะห์ legacy code ในอดีตมีเครื่องมือ AI ก็คงดี เคยมีสถานการณ์หลุดโลกจริงๆ แบบ "คนสุดท้ายที่แก้ไฟล์ Perl นี้ตอนนี้กลายเป็นผู้จัดการสาขาไปแล้ว ฉันต้องนัดประชุมกับเขาเองไหม?"

  • สำหรับคำถามว่า "ทำไมต้องถูกต้อง 100%?" ฉันคิดว่าคนที่วิจารณ์ AI กลับมักคาดหวังให้ AI เป็นคำตอบวิเศษที่สมบูรณ์แบบเสียเอง โทนมันคล้ายกับคนที่ต่อต้าน static typing แล้วบ่นว่า "มันยังจับ logical error ไม่ได้เลย"

• ช่วงนี้ตามบล็อกต่างๆ มีภาพที่สร้างโดย AI มากเกินไป จนกลายเป็นรบกวนสมาธิ และหลายครั้งก็ไม่ได้ช่วยให้เนื้อหาดีขึ้นเลย

• ไม่นานมานี้ฉันเข้าร่วมทีมที่มี codebase เละเทะ ทีมเดิมก็ออกไปแทบหมดแล้ว และคนที่ยังอยู่ก็ไม่ได้รู้โค้ดดีนัก เรียกได้ว่าเป็น Bus Factor 0 อย่างสมบูรณ์ ที่น่าประหลาดคือ AI กลับช่วยให้ความเร็วในการเข้าใจโค้ด การจับเจตนา และการดีบักดีขึ้นมาก เราเริ่มใช้ AI ดึงเอกสารออกมาจากตัวโค้ดเอง เอกสารหรือการบอกต่อปากต่อปากอาจบิดเบือนได้ แต่โค้ดคือตัวจริงของความจริง ด้วยความช่วยเหลือจาก AI เราสร้างสภาพแวดล้อมที่โค้ดอธิบายตัวเองได้ และรู้สึกว่าผลิตภาพเพิ่มขึ้นมาก

  • ในมุมผู้จัดการ ฉันกำลังคิดว่าจะตั้งกฎหนึ่งข้อจากนี้ไปเพื่อไม่ให้ readme ทั้งหมดของทีมล้าสมัย ฉันคิดว่าสามารถให้ Claude Code อ่านทั้ง readme เดิม โค้ดล่าสุด และการเปลี่ยนแปลงใน PR เพื่อบังคับให้อัปเดต readme เป็นเรื่องจำเป็นได้ แน่นอนว่ามันไม่สมบูรณ์แบบ แต่สุดท้ายนักพัฒนาก็ต้องตรวจสอบว่าสรุปนั้นสมเหตุสมผลหรือไม่ และ AI น่าจะช่วยลดปัญหาที่ readme ล้าสมัยเพราะ "ขี้เกียจอัปเดต" ได้มาก

• ก่อนยุค LLM ปัญหา Bus Factor ก็มีอยู่เสมอ บริษัทส่วนใหญ่ไม่ได้จัดโครงสร้างให้มีหลายคนเข้าใจงานแต่ละส่วนอย่างแท้จริง ถึงจะมีหลายคนถูกจัดให้ดูแลแต่ละพื้นที่ แต่งานก็เพิ่มขึ้นเรื่อยๆ จนสุดท้ายก็กลับไปสู่สถานการณ์ที่ไม่มีใครเข้าใจทั้งหมดอยู่ดี ถ้าจะหลีกเลี่ยงสิ่งนี้อย่างสมบูรณ์ก็ต้องมีการบริหารวิศวกรรมหนักมาก เช่น หมุนเวียนคนไปตาม codebase แต่โดยมากก็ทำไม่ได้เต็มที่เพราะแรงกดดันด้านความเร็ว ฉันสรุปประสบการณ์ย้อนหลังในฐานะ CTO เกี่ยวกับเรื่องนี้ไว้เป็นหนังสือ ที่นี่ และเปิดให้เข้าถึงได้ไม่ว่าคุณจะจ่ายเท่าไร ฉันคิดว่าหลักการของการสร้างระบบด้วย LLM ก็แทบไม่ต่างจากการทำงานในสภาพแวดล้อมที่ใช้ผู้รับเหมาภายนอก 10 คน

  • Bus Factor เป็นปัญหามาตั้งแต่ก่อน LLM และเป็นคำศัพท์เฉพาะที่ใช้กันมานานแล้ว TFA (บทความต้นฉบับ) กำลังวิจารณ์แนวโน้มที่เมื่อก่อน Bus Factor อาจอยู่ที่ 1 แต่ตอนนี้กำลังมุ่งไปที่ 0 เลย

  • ปัญหาไม่ใช่แค่งานมีปริมาณมากขึ้น แต่คือมันไม่ได้เดินไปในทิศทางที่ควรแนะนำมากขึ้นจริงๆ มีแต่รูปแบบการทำให้เสร็จลวกๆ เพื่อให้ทันเดดไลน์ซ้ำแล้วซ้ำอีก การวางอุปสรรคเชิงกระบวนการเพิ่มไม่กี่จุดแก้เรื่องนี้ไม่ได้

• สมองของเรามักประหยัดพลังงานกับข้อมูลที่ไม่ได้ใช้บ่อย ยิ่งห่างจากบางอย่างก็ยิ่งเข้าใจได้น้อยลงหรือหลงลืมมันไป ต่อให้รีวิวโค้ดเองทั้งหมด ในที่สุดทักษะก็อาจถดถอยได้ มันคล้ายกับเวลาวิศวกรไปทำงานผู้จัดการนานๆ แล้วแทบแก้ปัญหาทางเทคนิคไม่ได้อีก ในระบบอัตโนมัติของรถยนต์ก็เหมือนกัน การให้มนุษย์คอยมีส่วนร่วมต่อเนื่องในช่วงกลางๆ (level2→5) เป็นเรื่องยาก และถ้าเครื่องจักรยังเชื่อถือได้ไม่ถึง 100% สุดท้ายก็จะเกิดปัญหา

• มีจุดสำคัญมากในประเด็นนี้ คือจริงๆ แล้วเครื่องมือและ workflow แบบนี้เพิ่งอยู่ในระยะแรกเริ่มเท่านั้น ฉันมั่นใจว่าในอนาคต AI อาจแก้ปัญหาเหล่านี้ได้ดีกว่ามนุษย์ด้วยซ้ำ ฉันก็เคยทดลองใช้ LLM มาแล้ว ทั้งที่สำเร็จบางส่วนและล้มเหลวบ้าง แต่ในบางด้านมันแสดงความสามารถที่ยอดเยี่ยมอย่างชัดเจน LLM ไม่รู้สึกเบื่อที่จะอัปเดตเอกสาร คอมเมนต์ README หรือแม้แต่ ADR อย่างละเอียด ถ้ามีแนวทางและโครงสร้างที่ดีพอ codebase ที่ขับเคลื่อนด้วย LLM อาจกลับกลายเป็นสิ่งที่เข้าถึงได้ง่ายกว่าในระยะยาว เพราะมีแนวโน้มว่าจะมีเอกสารที่ดีกว่า

  • นี่เป็นจุดที่สำคัญมาก แต่จริงๆ ฉันกลับมองว่าเราอยู่ใกล้ปลายทางของเครื่องมือพวกนี้แล้ว จึงคิดว่าปัญหาเหล่านี้แก้ไม่ได้

• ฉันคิดว่าบทความนี้มองข้ามไปว่า ตัวโค้ดเองก็ทำให้เราอ่านเจตนาได้มากพอสมควร มนุษย์ รวมถึง LLM ด้วยก็น่าจะเป็นแบบนั้น เป็นสิ่งที่คาดเดาได้พอสมควร โดยทั่วไปเรามักแก้ปัญหาคล้ายๆ กันด้วยวิธีคล้ายๆ กัน ถ้าดูว่าโค้ดถูกเขียนอย่างไร ก็พอจะเห็นเบาะแสได้ว่าใครแก้ปัญหาอะไร เมื่อไร และทำไปทำไม แน่นอนว่ายังมีข้อมูลอีกมากที่ถูกซ่อนไว้ แต่เรื่องคล้ายกันนี้ก็เกิดขึ้นในองค์กรที่สมาชิกเปลี่ยนบ่อยอยู่แล้ว

  • ฉันเชื่อว่ากระบวนการคิดของมนุษย์สุดท้ายก็สะท้อนลงมาในโค้ด แต่ถึงอย่างนั้นมันก็ด้อยกว่าการมีคนที่ถามตรงๆ ได้มาก โดยทั่วไปเราจะทำ reverse engineering เฉพาะเมื่อจำเป็นจริงๆ แต่ใน legacy code สุดท้ายทุกคนก็ต้องทำ แต่มันไม่ใช่เรื่องดีในแง่ผลิตภาพ และ codebase ที่สร้างด้วย LLM ไม่ได้มีเจตนาเดียว แต่ปะปนไปด้วยเจตนาหลากหลายจากหลายคน ทำให้การดูเพียงบางชิ้นส่วนของโค้ดยิ่งทำให้สับสนว่าเจตนาเดิมคืออะไร มันอาจทำให้เราหลงคิดว่าโค้ดที่ AI สร้างขึ้นมีความหมายสอดคล้องและเข้มงวดแบบเดียวกับโค้ดที่มนุษย์เขียน ทั้งที่จริงแล้วกลับยิ่งตีความยากขึ้น

  • ความสามารถในการมองเจตนาจากโค้ดเพียงอย่างเดียวขึ้นอยู่กับขอบเขตและขนาด ถ้าเป็น Arduino ที่จำกัดไว้แค่ 32kB ก็ยังเข้าใจได้ง่าย แต่ถ้าเป็นแพลตฟอร์มซับซ้อนที่มีไมโครเซอร์วิสหลายสิบตัวพันกันอยู่ โดยเฉพาะถ้ามันถูกเขียนแบบ 'vibe coding' แล้วถ้ามันกลายเป็นความรับผิดชอบของฉัน ฉันคงอยากยอมแพ้ไปเลย

• ฉันเห็นด้วยกับประเด็นและข้อสรุปของบทความนี้ แต่ตลอด 20 ปีที่ผ่านมา ฉันก็เจอสถานการณ์คล้ายกันหลายครั้งแล้ว (สภาพแวดล้อมที่ไม่มีใครให้ถามได้ ผู้รับผิดชอบตัวจริงออกไปหมด) LLM อาจทำให้เรื่องแบบนี้เกิดเร็วขึ้นบ้าง แต่ฉันคิดว่ามันไม่ใช่ปัญหาใหม่ทั้งหมด เท่ากับเป็นการเร่งปัญหาเก่าให้เร็วขึ้นมากกว่า ฉันยินดีที่มีคนหยิบประเด็นนี้ขึ้นมาพูด

  • ผู้เขียนมองข้ามไปว่าจริงๆ แล้ว Bus Factor 0 หมายถึงอะไร และในโลกจริงมันไปถึงจุดนั้นได้อย่างไร บริษัทที่ยอมให้เกิด Bus Factor 0 คือบริษัทที่ไม่มีแรงจูงใจทางเศรษฐกิจให้ลงทุนกับความเชี่ยวชาญอยู่แล้ว ถ้าผลประโยชน์ทางเศรษฐกิจที่มนุษย์จะได้จากการแข่งขันกับ AI กลายเป็น 0 และ AI ลดต้นทุนได้ 10 เท่า เมื่อรวมกับการโฆษณาเกินจริงและความสับสนของช่องทางสื่อสาร ปัญหาก็จะชัดเจนขึ้น ถ้ามองตามหลักอุปสงค์อุปทาน เมื่ออุปทาน (ผู้เชี่ยวชาญ) กลายเป็นอนันต์ อุปสงค์ก็จะหายไป pipeline การสร้างบุคลากรต้องใช้เวลา 2~10 ปี แต่เมื่อแรงจูงใจให้เติบโตหายไป วิกฤตใหญ่ในอนาคตก็จะตามมา มีกรณีจริงที่มหาวิทยาลัยท้องถิ่นลดวิชาคอมพิวเตอร์ลงเพราะจำนวนนักศึกษาลดลง และนักศึกษาตอบว่าพวกเขาละทิ้งเส้นทางอาชีพนี้เพราะ AI เมื่ออุปทานของผู้เชี่ยวชาญหายไป แม้มีเงินก็จะหาคนมาแก้ไม่ได้ ถ้าไปกระทบฐานเศรษฐกิจ ปัญหาจะค่อยๆ ขยายตัวตามเวลา และในโลกจริงเรามักรับมือได้ไม่ทัน สุดท้ายจะเกิดวิกฤตร้ายแรง และตอนนั้นเองจึงจะเริ่มมีมาตรการรุนแรง

• ในทางกลับกันก็มีอีกมุมหนึ่ง ถ้าจัดทำเอกสาร การทดสอบ และการตั้งค่าต่างๆ ใน codebase ไว้อย่างดีเพื่อให้ AI ใช้งานได้คล่อง ฉันคาดว่าอีก 1 ปีข้างหน้า AI agent จะทำงานแบบเดิมได้เร็วขึ้นกว่าเดิม

  • ฉันสงสัยว่า AI Coding Tool จะเริ่มมีท่าทีแบบนักพัฒนาเดิมๆ ที่ว่า "โค้ดเก่าก่อนหน้านี้แย่หมด งั้นเขียนใหม่ทั้งหมดดีกว่า" ได้อย่างไร น่าสนใจเหมือนกันว่าในอนาคตระบบ CI/CD เองอาจกลายเป็นสิ่งที่ให้ AI เขียนใหม่ทั้งโปรเจกต์แบบยกชุดหรือไม่

  • ฉันคือผู้เขียน ถ้าเป็นอย่างที่พูดจริง Bus Factor ก็เพิ่มขึ้นแล้ว กล่าวคือ แก่นแท้คือข้อมูลไม่ได้ค้างอยู่แค่ในหัว แต่ถูกเก็บและคงอยู่ในรูปแบบต่างๆ