กลไกความซับซ้อนแบบแรตเชต (Complexity Ratchet) ในยุค AI Coding - สรุปบทความของ Garry Tan
นี่คือบทความยาวที่ Garry Tan (CEO ของ Y Combinator) แชร์บน X โดยสรุปประสบการณ์จากตลอด 1 ปีที่ผ่านมาในการสร้างโอเพนซอร์ส 2 โปรเจ็กต์ร่วมกับ AI agent (เช่น Claude Code, Codex) เขาระบุว่าในโค้ดราว 970,000 บรรทัดและไฟล์ทดสอบ 665 ไฟล์นั้น ส่วนใหญ่เขียนโดย AI และในเวลาเดียวกันยังรัน agent session พร้อมกันถึง 15 เซสชัน เขาอ้างว่ากระบวนการนี้ได้หักล้างคำกล่าวเก่าแก่ของวิศวกรรมซอฟต์แวร์ที่ว่า “ความเร็วกับคุณภาพต้องเลือกอย่างใดอย่างหนึ่ง” และเสนอแนวคิดที่เป็นกลไกหลักของเรื่องนี้คือ ‘Complexity Ratchet’
แนวคิดสำคัญ
- Ratchet คืออะไร เป็นอุปมาเปรียบกับล้อเฟืองที่หมุนได้ทางเดียว หมายถึงโครงสร้างที่ทำให้คุณภาพของ codebase เดินหน้าได้อย่างเดียวโดยไม่ถอยหลัง
- สิ่งสะสม 3 อย่าง ในแต่ละ coding session ร่วมกับ agent จะมีสิ่ง 3 อย่างสะสมอยู่ใน codebase ได้แก่ test (อะไรคือสิ่งที่ถูกต้อง), document (ทำไมจึงตัดสินใจแบบนั้น), และผลการประเมิน (baseline ของคุณภาพ)
- การใช้ context window ใน session ถัดไป AI agent จะอ่านทั้ง 3 อย่างนี้ก่อนทำงาน จึงทำให้ไม่สามารถทำ test พัง, เมินเอกสาร, หรือทำให้คะแนนประเมินลดลงได้ง่าย ๆ
ความต่างจากแนวทางเดิม
- โมเดลของข้อผิดพลาดที่เปลี่ยนไป ตลอด 50 ปีที่ผ่านมา วิศวกรรมซอฟต์แวร์สร้างกระบวนการซับซ้อนอย่าง code review, QA, staging ภายใต้สมมติฐานว่า “ข้อผิดพลาดเป็นเรื่องร้ายแรงจึงต้องป้องกันไว้ก่อน” แต่ตอนนี้ข้อผิดพลาดส่วนใหญ่สามารถให้ agent วินิจฉัยและแก้ในเทิร์นถัดไปได้
- การขยายเพดานความซับซ้อน ขีดจำกัดสูงสุดของความซับซ้อนของระบบได้ขยับจาก ‘ปริมาณที่ทีมหนึ่งทีมเก็บไว้ในหัวได้’ ไปเป็น ‘คนหนึ่งคนพร้อม agent ที่โหลด codebase ทั้งหมดเข้า context’
- ความคงทนของความทรงจำเชิงสถาบัน คนอาจลาออกหรือหมดไฟแล้วจากไป แต่ความรู้ที่เก็บอยู่ใน 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 ในการดึง “ความเชื่อ” กว่า 100,000 รายการ เคยมีปัญหาระบุผิด 35% ว่า ‘ใครเป็นคนกล่าวอ้างนั้น’ จึงใช้ test 17 รายการตรึงปัญหานี้ไว้ ทำให้เวอร์ชันถัดไปไม่สามารถตกลงไปต่ำกว่านั้นได้
- TTY test ของ Superpowers AI agent มีพฤติกรรมข้ามขั้นตอน interactive review จึงใช้ฟังก์ชัน pseudo-terminal ของ Bun มาตรวจจับและบล็อกโดยตรง ทำให้ข้อกำหนดที่ไม่ดั้งเดิมอย่าง “AI ได้มีการสนทนาหรือไม่” ก็สามารถทำให้เป็น test ได้
ข้อดีและข้อจำกัด
- ข้อดี ผู้ร่วมพัฒนาจากภายนอกไม่จำเป็นต้องเข้าใจทั้งระบบก็สามารถ merge PR ได้อย่างปลอดภัย หากทำให้ test ผ่านทั้งหมด จึงลดกำแพงในการร่วมมือพัฒนา
- ข้อจำกัด ข้อผิดพลาดประเภทที่ทำลาย state เช่น DB migration ที่ผิดพลาด, การเจาะระบบความปลอดภัย, การรั่วไหลของข้อมูลส่วนตัว ยังเป็นปัญหาร้ายแรงเหมือนเดิม และจุดเชื่อมต่อ integration กับโครงสร้างพื้นฐานอีกราว 10% ก็ยังทดสอบได้ยากโดยธรรมชาติ
- คำตอบต่อข้อโต้แย้ง ต่อข้อสังเกตว่า “คนที่เขียน test เก่งแต่เดิมก็มักออกแบบสถาปัตยกรรมเก่งอยู่แล้ว” ผู้เขียนย้ำว่าแก่นของ ratchet ไม่ใช่ตัวคน แต่คือ safety net ในเทิร์นถัดไป
ใจความสำคัญที่ผู้เขียนต้องการสื่อคือ มูลค่าที่แท้จริงของ AI coding ไม่ใช่ ‘การเขียนได้เร็วขึ้น’ แต่คือการทำให้ ‘การตรวจสอบในระดับที่ก่อนหน้านี้แพงเกินกว่าจะทำ’ กลายเป็นของฟรี Test coverage 90% ซึ่งตลอด 50 ปีที่ผ่านมาเป็นเรื่องที่สงวนไว้แทบเฉพาะในอุตสาหกรรมการบินและการแพทย์ ตอนนี้อาจกลายเป็นกิจวัตรของนักพัฒนาคนเดียวได้ และผลลัพธ์คือเพดานความซับซ้อนของซอฟต์แวร์ที่นักพัฒนาหนึ่งคนสร้างได้สูงขึ้นอย่างมาก อย่างไรก็ตาม ตัวบทความเองก็มีลักษณะเป็นการโปรโมตโอเพนซอร์สโปรเจ็กต์ของผู้เขียน (Superpowers, GBrain) ไปพร้อมกัน และการอ้างอิงสถิติบางส่วน (เช่น GPT-5.5) ก็ยังมีจุดที่ต้องตรวจสอบ จึงเป็นข้อความที่ควรอ่านอย่างมีวิจารณญาณ
ยังไม่มีความคิดเห็น