Complexity Ratchet ในยุค AI Coding: ทำไมจึงต้องมี Test Coverage 90%

นี่คือบทความยาวที่ Garry Tan (CEO ของ Y Combinator) แชร์บน X ซึ่งสรุปประสบการณ์จากการสร้างโปรเจ็กต์โอเพนซอร์ส 2 โปรเจ็กต์ร่วมกับ AI agent (เช่น Claude Code, Codex ฯลฯ) ตลอด 1 ปีที่ผ่านมา เขาระบุว่า AI เป็นผู้เขียนโค้ดเกือบทั้งหมดจากโค้ดราว 970,000 บรรทัดและไฟล์ทดสอบ 665 ไฟล์ พร้อมกับรัน agent session พร้อมกันถึง 15 เซสชัน เขาอ้างว่าผ่านกระบวนการนี้ หลักคิดเก่าแก่ของวิศวกรรมซอฟต์แวร์ที่ว่า “ความเร็วกับคุณภาพต้องเลือกอย่างใดอย่างหนึ่ง” ได้ถูกทำลายลง และเสนอแนวคิดชื่อว่า 'Complexity Ratchet' เป็นกลไกหลักของเรื่องนี้

สรุปแนวคิดสำคัญ

• Ratchet คืออะไร เป็นอุปมาจากกลไกเฟืองที่เคลื่อนไปได้ทางเดียว หมายถึงโครงสร้างที่ทำให้คุณภาพของ codebase เดินหน้าได้อย่างเดียวโดยไม่ถอยหลัง
• สิ่งสะสม 3 อย่าง ในทุก coding session กับ agent จะมี 3 อย่างสะสมเข้าไปใน codebase ได้แก่ test (อะไรคือสิ่งที่ถูกต้อง), document (ทำไมจึงตัดสินใจแบบนั้น), และผลการประเมิน (เส้นฐานของคุณภาพ)
• การใช้ context window ใน session ถัดไป AI agent จะอ่านทั้ง 3 อย่างนี้ก่อนลงมือ ทำให้มันไม่อาจทำ test พัง เมินเอกสาร หรือทำคะแนนประเมินลดลงได้ง่าย

ความต่างจากวิธีเดิม

• โมเดลของข้อผิดพลาดที่เปลี่ยนไป ตลอด 50 ปีที่ผ่านมา วิศวกรรมซอฟต์แวร์ตั้งอยู่บนสมมติฐานว่า “ข้อผิดพลาดเป็นเรื่องร้ายแรงจึงต้องป้องกันไว้ก่อน” จึงเกิดกระบวนการซับซ้อนอย่าง code review, QA, staging ฯลฯ แต่ตอนนี้ข้อผิดพลาดส่วนใหญ่ agent สามารถวินิจฉัยและแก้ได้ในเทิร์นถัดไป
• การขยายเพดานความซับซ้อน ขีดจำกัดบนของความซับซ้อนของระบบได้ขยับจาก ‘ปริมาณที่หนึ่งทีมเก็บไว้ในหัวได้’ ไปเป็น ‘คนหนึ่งคนพร้อม agent หลายตัวที่โหลด codebase ทั้งหมดเข้า context’
• ความคงอยู่ของ institutional memory คนอาจลาออกหรือหมดไฟแล้วจากไป แต่ความรู้ที่คงอยู่ในรูป test และเอกสารสามารถเรียกกลับมาใช้ได้ใหม่ ไม่ว่าจะเป็นโมเดลใดหรือเวลาใดก็ตาม

ความหมายของ test coverage 90%

• เส้นโค้งคุณภาพแบบไม่เป็นเชิงเส้น จากงานวิจัยกว่า 10,000 โปรเจ็กต์ของ Capers Jones พบว่าเมื่อ coverage ต่ำกว่า 70% อัตราการกำจัด defect อยู่เพียง 65–75% แต่ที่ช่วง 85–95% จะพุ่งขึ้นเป็น 92–97% โดยมี ‘จุดหักเข่า’ สำคัญอยู่ตรงนั้น
• แบบอย่างจากอุตสาหกรรมการบิน มาตรฐานซอฟต์แวร์การบิน DO-178C บังคับใช้ MC/DC coverage กับระบบ Level A (วิกฤตสูงสุด) เพื่อให้บรรลุอัตราการกำจัด defect มากกว่า 99%
• AI ทำลายกำแพงด้านต้นทุน การเก็บ coverage ช่วง 20% สุดท้ายเคยเป็นงานที่น่าเบื่อและมีต้นทุนสูงสำหรับมนุษย์ แต่ agent ไม่รู้จักเหนื่อย จึงสามารถเขียน edge case test ได้ไม่รู้จบแม้ในตอนตีสาม

กรณีจริงที่ผู้เขียนยกมา

• การปรับปรุงความแม่นยำในการดึงข้อมูลของ GBrain ในการดึง belief กว่า 100,000 รายการ มีปัญหาที่ระบบระบุผิดถึง 35% ว่า ‘ใครเป็นคนกล่าวอ้างนั้น’ ผู้เขียนใช้ test 17 รายการตรึงปัญหานี้ไว้ ทำให้เวอร์ชันถัดไปไม่อาจตกต่ำกว่าจุดนั้นได้
• TTY test ของ Superpowers AI agent มีพฤติกรรมข้าม interactive review จึงมีการใช้ความสามารถ pseudo terminal ของ Bun เพื่อตรวจจับและบล็อกโดยตรง ทำให้ข้อกำหนดที่ไม่ดั้งเดิมอย่าง “AI ได้มีการสนทนาหรือไม่” ถูกทำให้เป็น test ได้เช่นกัน

ข้อดีและข้อจำกัด

• ข้อดี ผู้มีส่วนร่วมจากภายนอกไม่จำเป็นต้องเข้าใจทั้งระบบทั้งหมด ขอเพียงทำให้ test ผ่าน ก็สามารถ merge PR ได้อย่างปลอดภัย จึงลดกำแพงในการร่วมมือกัน
• ข้อจำกัด ข้อผิดพลาดประเภทที่ทำลาย state เช่น DB migration ที่ผิดพลาด, การละเมิดความปลอดภัย, การรั่วไหลของความเป็นส่วนตัว ยังเป็นเรื่องร้ายแรงเช่นเดิม และยังมีราว 10% ของจุดเชื่อมต่อกับระบบอื่นรวมถึงโครงสร้างพื้นฐานที่ทดสอบได้ยากโดยเนื้อแท้
• คำตอบต่อข้อโต้แย้ง ต่อข้อสังเกตที่ว่า “คนที่เขียน test เก่ง เดิมทีก็มักออกแบบสถาปัตยกรรมได้ดีอยู่แล้ว” ผู้เขียนย้ำว่าหัวใจของ ratchet ไม่ใช่ตัวคน แต่คือ safety net ของเทิร์นถัดไป

สารสำคัญที่ผู้เขียนต้องการสื่อคือ มูลค่าที่แท้จริงของ AI coding ไม่ใช่ ‘การเขียนได้เร็วขึ้น’ แต่คือการทำให้ ‘ระดับการตรวจสอบที่ก่อนหน้านี้แพงเกินกว่าจะทำ’ กลายเป็นของฟรี Test coverage 90% ที่ตลอด 50 ปีที่ผ่านมาเป็นอภิสิทธิ์ของวงการการบินและการแพทย์ อาจกลายเป็นเรื่องปกติในชีวิตประจำวันของคนคนเดียวได้แล้ว และผลลัพธ์คือเพดานความซับซ้อนของซอฟต์แวร์ที่นักพัฒนาคนหนึ่งสามารถสร้างได้สูงขึ้นอย่างมาก อย่างไรก็ดี ตัวบทความเองก็ทำหน้าที่โปรโมตโปรเจ็กต์โอเพนซอร์สของผู้เขียน (Superpowers, GBrain) ไปพร้อมกัน และบางส่วนของสถิติที่อ้างถึง (เช่น GPT-5.5) ก็ยังมีจุดที่ต้องตรวจสอบ จึงเป็นข้อความที่ควรอ่านอย่างมีวิจารณญาณ

[skymer]

https://www.youtube.com/watch?v=mJ2GZRV63TE
คนที่สร้างบล็อก RoR ด้วย LOC มากกว่า sqlite ถึง 4 เท่า...