- การพัฒนาซอฟต์แวร์ด้วย AI ช่วยเสริม ทำให้ความเร็วในการผลิตโค้ดเร็วกว่าความเร็วในการทำความเข้าใจของมนุษย์ และก่อให้เกิด ‘หนี้ทางการรับรู้ (cognitive debt)’
- แม้โค้ดจะทำงานได้ปกติและผ่านการทดสอบ แต่ก็มีการสะสมของ สภาวะที่นักพัฒนาเองไม่เข้าใจโครงสร้างและเหตุผลของโค้ดอย่างแท้จริง
- ข้อจำกัดในการตรวจทานของ reviewer, การสูญเสียความรู้โดยนัยขององค์กร, การขาดการเรียนรู้ของนักพัฒนามือใหม่ ฯลฯ ล้วนเร่งให้หนี้นี้สะสมเร็วขึ้น
- องค์กรวัดเพียง ตัวชี้วัดที่เน้นความเร็ว (DORA, story points ฯลฯ) จึงไม่สามารถจับสัญญาณของการขาดความเข้าใจได้
- ยิ่ง ช่องว่างระหว่างผลิตภาพกับความเข้าใจ กว้างขึ้นมากเท่าไร ก็ยิ่งเสี่ยงต่อความล้มเหลวในการบำรุงรักษา การขาดตอนขององค์ความรู้ และการหยุดชะงักของการเติบโตของวิศวกรในระยะยาว
ความล่าช้าของความเข้าใจ (The Comprehension Lag)
- การเขียนโค้ดด้วยตนเองทำให้เกิดทั้งกระบวนการ การผลิตและการซึมซับ ไปพร้อมกัน และแรงเสียดทานจากการพิมพ์ช่วยกระตุ้นการคิด
- ระหว่างที่เขียนโค้ด จะค่อย ๆ สร้าง mental model และสัญชาตญาณ ขึ้นมาโดยธรรมชาติ
- การพัฒนาที่มี AI ช่วยเสริมแยกสองกระบวนการนี้ออกจากกัน ทำให้ ความเร็วในการสร้างผลลัพธ์พุ่งสูงขึ้น แต่ความเร็วในการทำความเข้าใจยังติดอยู่ที่ขีดจำกัดของมนุษย์
- ช่องว่างระหว่างผลลัพธ์กับความเข้าใจ นี้เองคือหนี้ทางการรับรู้ และต่างจาก technical debt ตรงที่ มองไม่เห็นในตัวชี้วัดด้านความเร็ว
- ปัญหาจะไปปรากฏภายหลังในตัวชี้วัดด้านความน่าเชื่อถือ เช่น MTTR ที่เพิ่มขึ้น, อัตราความล้มเหลวของการเปลี่ยนแปลงที่สูงขึ้น
สิ่งที่องค์กรวัดจริง ๆ (What Organizations Actually Measure)
- องค์กรวัดเฉพาะ ผลลัพธ์ที่มองเห็นได้ (จำนวนฟีเจอร์, commit, ความเร็วในการรีวิว ฯลฯ)
- ในอดีต ผลลัพธ์กับความเข้าใจเชื่อมโยงกัน จึงมีสมมติฐานว่าเมื่อปล่อยฟีเจอร์ได้ ก็แปลว่ามีความเข้าใจอยู่ด้วย
- แต่ในยุค AI นั้น สามารถปล่อยฟีเจอร์ได้แม้มีเพียงความเข้าใจในระดับผิวเผิน ทำให้สมมติฐานนี้ใช้ไม่ได้อีกต่อไป
- ตัวชี้วัดขององค์กรไม่สามารถจับการขาดความเข้าใจได้ ส่งผลให้การประเมินผลงานและระบบรางวัลบิดเบี้ยว
ภาวะกลืนไม่เข้าคายไม่ออกของ reviewer (The Reviewer’s Dilemma)
- AI ทำให้ วิศวกรมือใหม่สามารถสร้างโค้ดได้เร็วกว่าวิศวกรอาวุโส
- reviewer ระดับอาวุโสไม่มีเวลาพอจะตรวจโค้ดจำนวนมหาศาลได้อย่างลึกซึ้ง จึงต้อง แลกความลึกของการตรวจทานกับเวลา
- ผลลัพธ์คือ สมมติฐานที่ว่า ‘โค้ดที่ผ่านการรีวิวแล้ว = โค้ดที่มีคนเข้าใจแล้ว’ พังทลายลง
- เนื่องจากแรงกดดันในองค์กรให้ความสำคัญกับความเร็วเป็นหลัก จึงยิ่งเสริม วัฒนธรรมที่เน้นปริมาณงานมากกว่าคุณภาพการตรวจทาน
รูปแบบของภาวะหมดไฟ (The Burnout Pattern)
- วิศวกรที่ใช้เครื่องมือ AI ต้องเผชิญกับความเหนื่อยล้าแบบที่ ผลผลิตสูงแต่ความมั่นใจต่ำ อยู่พร้อมกัน
- แม้โค้ดจะทำงานได้ แต่ก็ยังมี ความกังวลต่อเนื่องว่าตนเองยังไม่เข้าใจระบบที่สร้างขึ้นอย่างสมบูรณ์
- ระบบประเมินที่เน้นความเร็วทำให้ การใช้เวลาเพื่อสร้างความเข้าใจอย่างลึกซึ้ง กลายเป็นสิ่งที่เสียเปรียบ และเร่งให้หนี้ทางการรับรู้เพิ่มขึ้น
การล่มสลายของความทรงจำขององค์กร (When Organizational Memory Fails)
- ความรู้ในองค์กรประกอบด้วยทั้ง ความรู้ชัดแจ้งที่มีการบันทึกไว้ และ ความรู้โดยนัยที่อยู่ในหัวของนักพัฒนา
- การพัฒนาด้วย AI ทำให้ กระบวนการก่อรูปของความรู้โดยนัย (ประสบการณ์จากการลงมือทำจริง) สั้นลง จึงไม่เกิดการสะสมความรู้
- ผลคือ ระบบยังทำงานได้ แต่คนที่เข้าใจระบบจริง ๆ ค่อย ๆ หายไป
- เมื่อเกิดปัญหา ก็จะกลายเป็น สภาวะที่ไม่มีใครสามารถอธิบายบริบทของระบบได้
การสะสมทบต้นของหนี้ทางการรับรู้ (How the Debt Compounds)
- ประการแรก ยิ่งเป็นโค้ดเก่า ยิ่งมีความเสี่ยง — โค้ดที่เข้าใจไม่สมบูรณ์ตั้งแต่ตอนเขียนจะยิ่งกลายเป็นสิ่งที่ทึบดำมากขึ้น
- ประการที่สอง เวลาในการกู้คืนเมื่อเกิด incident เพิ่มขึ้นอย่างมาก — เกิดสถานการณ์ที่ต้อง debug “black box ที่สร้างโดย black box”
- ประการที่สาม การขาดหายของวิศวกรอาวุโสในอนาคต — เมื่อพึ่งพา AI จนเส้นโค้งการเรียนรู้หายไป ก็อาจนำไปสู่ช่องว่างด้านผู้นำในระยะยาว
มุมมองของ Director (The Director’s View)
- ฝ่ายบริหารมองเห็นแต่สัญญาณบวก เช่น ผลิตภาพที่สูงขึ้น, เวลาส่งมอบที่สั้นลง, การใช้กำลังคนที่มีประสิทธิภาพขึ้น
- เนื่องจากไม่มีตัวชี้วัดที่ใช้วัด ‘ความลึกของความเข้าใจ’ หรือ ‘ความสามารถในการอธิบาย’ หนี้ทางการรับรู้จึงไม่ถูกรายงานขึ้นมา
- ดังนั้น การตัดสินใจบนฐานข้อมูลจึงสมเหตุสมผลแต่ไม่สมบูรณ์ และความเสี่ยงที่แท้จริงจึงถูกซ่อนเอาไว้
ข้อจำกัดของโมเดลนี้ (Where This Model Breaks)
- แนวคิดเรื่องหนี้ทางการรับรู้ไม่ได้ใช้ได้เหมือนกันกับทุกงาน
- งานซ้ำ ๆ แบบง่ายหรือการทดลองอย่างรวดเร็วอาจเหมาะกับแนวทางนี้
- ในอดีต ระดับความเข้าใจของแต่ละคนก็แตกต่างกันอยู่แล้ว จึงอาจเป็น การเลื่อนของการกระจายตัว มากกว่าจะเป็นปรากฏการณ์ใหม่โดยสิ้นเชิง
- ในอนาคต ก็ยังมีความเป็นไปได้ที่ เครื่องมือและการทำเอกสารที่ดีขึ้น จะช่วยลดช่องว่างด้านความเข้าใจได้
ปัญหาของการวัด (The Measurement Problem)
- องค์กรจะปรับให้เหมาะกับสิ่งที่วัดได้เท่านั้น
- ความเร็ววัดได้ แต่ ความเข้าใจวัดไม่ได้
- ตราบใดที่ความเข้าใจยังไม่ถูกสะท้อนในระบบประเมิน แรงจูงใจที่เน้นความเร็วเป็นศูนย์กลาง ก็จะยังคงอยู่
- นี่ไม่ใช่ความล้มเหลวของบุคคลหรือผู้จัดการ แต่เป็นผลจาก ระบบการวัดของยุคก่อนที่ไม่สอดคล้องกับความเป็นจริงในปัจจุบัน
- ในท้ายที่สุด ช่องว่างนี้อาจปรากฏออกมาในรูปของ ต้นทุนการบำรุงรักษาที่สูงขึ้น, การตอบสนองต่อ incident ที่ล่าช้า, การเปิดเผยความเปราะบางของระบบ
- บทความสรุปด้วยข้อสรุปว่า “ระบบจะถูกปรับให้เหมาะกับสิ่งที่มันถูกใช้วัด แต่สิ่งที่เรากำลังวัดอยู่ตอนนี้ ไม่ได้ครอบคลุมสิ่งที่สำคัญอีกต่อไปแล้ว”
3 ความคิดเห็น
ช่วงนี้ผมก็คิดอะไรคล้าย ๆ กันอยู่ เลยเขียนบล็อกโพสต์เกี่ยวกับหนี้ทางความคิดไว้เมื่อวานนี้ ดูเหมือนว่าทุกคนก็กำลังกังวลเรื่องคล้าย ๆ กันนะครับ
เราควรทำความเข้าใจโค้ดอย่างไรดี ควรวัดด้วยการออกควิซจากโค้ดเบสภายในเลยไหม
ความคิดเห็นจาก Hacker News
ประสบการณ์ในช่วงไม่กี่เดือนที่ผ่านมาของฉันทำให้รู้สึกเห็นด้วยกับเนื้อหาในบทความนี้มาก
โปรเจ็กต์ที่ฉันทำงานอยู่เติบโตขึ้นอย่างต่อเนื่อง แต่จำนวนวิศวกรกลับลดลง
เราเพิ่มการพึ่งพาการทดสอบและเปลี่ยนไปใช้การพัฒนาแบบอิงซิมูเลเตอร์ การตรวจสอบกับระบบจริงเกิดขึ้นไม่บ่อย และทุกครั้งก็มักจะเป็นส่วนที่ซับซ้อนที่สุด
ตั้งแต่ราวปีที่แล้ว ฉันเริ่มรู้สึกว่าต่อให้เป็นฟีเจอร์ที่ทำมาหลายเดือน ก็ลืมรายละเอียดได้อย่างรวดเร็ว ทั้งที่ตอนนั้นยังไม่ถึงยุคที่coding agentถูกนำมาใช้อย่างจริงจัง
พอเอเจนต์เข้ามา การรีวิว PR ก็ยิ่งเป็นนัยมากขึ้น ทำให้บริบทไม่ค่อยติดอยู่ในหัว ต้องตั้งใจจดจ่ออย่างมีสติ และเพื่อนร่วมทีมก็รายงานประสบการณ์แบบเดียวกัน
ตอนนี้เรากำลังลองหลายวิธี เช่น commit แผนของเอเจนต์ไปพร้อมกับโค้ด ซึ่งช่วยให้กระบวนการมีความเป็นระบบและชัดเจนมากขึ้น
แต่ดูเหมือนผู้จัดการฝ่ายวิศวกรรมแทบไม่ตระหนักถึงภาระทางความคิดที่เพิ่มขึ้นนี้เลย
สมมติฐานของบทความที่ว่า “นักพัฒนาจำโค้ดที่ตัวเองเขียนเมื่อ 6 เดือนก่อนได้” นั้นไม่จริง
แต่เดิมการเข้าใจโค้ดตอนเขียนก็ง่ายกว่าตอนกลับมาอ่านอยู่แล้ว Joel Spolsky ก็เคยพูดว่า “การอ่านโค้ดยากกว่าการเขียน”
ปัญหา “โค้ดที่ไม่มีใครเข้าใจ” มีมาก่อนยุค AI แล้ว
ตัวอย่างเช่น กรณีลบโค้ด Pinball ของ Microsoft ซึ่งโค้ดเก่าที่จ้างคนนอกทำซับซ้อนเกินไปจนไม่มีใครเข้าใจ สุดท้ายจึงต้องทิ้งฟีเจอร์นั้นไป
กรณี codebase ของ Oracle RDBMS ก็คล้ายกัน
คำว่า “ระบบที่ทำงานได้ปกติแต่แปลกหน้า” น่าประทับใจมาก
มันคล้ายความรู้สึกตอนนักพัฒนาเปลี่ยนบทบาทไปเป็นผู้จัดการ ยิ่งห่างจากโค้ด ความเข้าใจก็ยิ่งเป็นนามธรรมและรู้สึกขาดตอน
ประโยคที่ว่า “วิศวกรที่พยายามทำความเข้าใจอย่างลึกซึ้งกลับตามหลังในตัวชี้วัดด้านความเร็ว” เจ็บที่สุด
ตลาดให้ความสำคัญกับความเร็วมากกว่าคุณภาพ และสุดท้ายก็กลายเป็นโครงสร้างที่วิศวกรที่รอบคอบถูกเลิกจ้าง
ตอนนี้อาจถึงยุคของ “LGTM, LLM” แล้วก็ได้
อุตสาหกรรมนี้มักพุ่งไปสุดทางก่อน แล้วค่อยหาสมดุลภายหลัง ปัญหาคือความคาดหวังที่เป็นไปไม่ได้แบบต้องการผลิตภาพเพิ่ม 20 เท่า แต่ยังให้รับผิดชอบ 100%
สุดท้ายก็ต้องยอมทิ้งความเข้าใจไป หรือไม่ก็ยอมรับการเพิ่มผลิตภาพได้แค่ราว 20%
ทำให้นึกถึงปรัชญา Worse Is Better ของ Richard Gabriel
โค้ดจาก AI มักเลือกความเรียบง่ายมากกว่าความถูกต้อง แต่แนวทางแบบโลกจริงที่ว่า “แค่ใช้งานได้ก็ชนะแล้ว” อาจเป็นฝ่ายชนะก็ได้
เมื่อมีระบบที่ใช้งานได้ก่อนแล้ว ก็สามารถค่อย ๆ ปรับปรุงต่อไปได้
ทีมของเราก็เจอปรากฏการณ์เดียวกับที่บทความพูดถึงตลอด 6 เดือนที่ผ่านมา
ประโยคแกนหลักที่ว่า การพัฒนาแบบมี AI ช่วยตัดขาดการสะสมความรู้โดยนัย นั้นตรงมาก
แต่ปรากฏการณ์นี้ก็อาจเป็นเพียงช่วงเปลี่ยนผ่านชั่วคราว
ในระยะยาว LLM อาจช่วยจัดระเบียบโครงสร้างโค้ดให้ดีขึ้น และมอบคุณค่าในระดับเมตาที่ช่วยให้มนุษย์เข้าใจลึกเฉพาะในเวลาที่จำเป็น
ถ้าขาดเอกสารประกอบที่ดี ฝ่ายสนับสนุนผลิตภัณฑ์ก็ได้รับผลกระทบหนักเช่นกัน
เมื่อลูกค้าถามว่าผลิตภัณฑ์ทำงานอย่างไร แม้แต่วิศวกรเองยังไม่ค่อยรู้โค้ดที่ตัวเองเขียน ก็ยิ่งตอบยาก
ถ้าความเร็วในการอัปเดตสูง ทีมอื่นก็ยิ่งตามไม่ทัน
ตอนที่ภาษาโปรแกรมระดับสูงเริ่มเกิดขึ้น ก็เคยมีเรื่องทำนองนี้มาก่อน แต่สุดท้ายก็ออกมาดี
ถ้าอย่างนั้นการที่ LLM มา abstract ความเข้าใจโค้ดออกไป จะถือว่าไม่เป็นไรไหม?
ความต่างคือcompiler เป็นแบบ deterministic แต่ LLM เป็นแบบ probabilistic