สโลปอคาลิปส์ของโค้ด AI ความเร็วที่แปลงเป็นหนี้เทคนิคและบั๊ก
การควบคุมคุณภาพโค้ดจาก AI คือกรอบกติกาและเครื่องมือที่ออกแบบมาเพื่อจับบั๊ก รูปแบบโค้ดไม่ดี และหนี้เทคนิคที่เกิดจากการสร้างโค้ดด้วยความเร็วสูง โดยใช้กฎรีวิวอัตโนมัติ เมตริกวิศวกรรม และขั้นตอนตรวจสอบก่อนดีพลอย เพื่อให้โค้ดที่ AI ช่วยเขียนปลอดภัยพอสำหรับระบบโปรดักชันและไม่เร่งสะสมปัญหาในระยะยาว หัวใจของปัญหาไม่ใช่ว่า AI แย่ แต่คือความเร็วของมัน AI สามารถเขียนโค้ดเร็วกว่าที่ทีมจะรีวิวทัน ภาวะนี้ถูกอธิบายว่าเป็นสโลปอคาลิปส์ จุดที่ AI ผลิตโค้ดเร็วกว่ารีวิวและวินัยของทีมจะรับมือได้ หากยังพึ่งคำสัญญาว่า “รีวิวให้ละเอียดรอบต่อไป” ผลลัพธ์ตามจริงคือโค้ดจำนวนมากถูกเมิร์จเพราะเดดไลน์และงานอื่นแทรก สโลปอคาลิปส์จึงไม่ใช่เหตุให้เลิกใช้ AI แต่เป็นสัญญาณว่าต้องเปลี่ยนจากวินัยล้วน ไปสู่ระบบ AI code quality control ที่มีเกราะอัตโนมัติและเกณฑ์ชัดเจนก่อนโค้ดจะถึงโปรดักชัน
จากดิสซิปพลินส่วนตัวสู่เกราะอัตโนมัติ Tripwire และรอบรีวิวรายวัน
เมื่อจำนวน PR จาก AI ทะลุหลักสิบก่อนสแตนด์อัพ วินัยส่วนตัวไม่พออีกต่อไป ทีมต้องสร้าง automated code review ที่ยิงเตือนเองแม้ไม่มีใครมองหน้าจออยู่ แนวคิดคือเพิ่ม “tripwire” ในขั้นตอนรีวิวให้โค้ดฝ่าด่านไม่ได้หากมีสัญญาณเสี่ยง กฎง่าย ๆ แต่แรง เช่น เตือนทันทีเมื่อ PR มีโค้ดเปลี่ยนเกินประมาณ 400 บรรทัดหรือมากกว่า 10 ไฟล์ เพราะนี่คือเมก้าเชนจ์ที่รีวิวให้ละเอียดแทบเป็นไปไม่ได้ เตือนเมื่อมีการเมิร์จโดยไม่มีรีวิว อัพเดตไฟล์สำคัญอย่าง auth billing migration หรือไฟล์ CI และเตือนหาก PR ปล่อยค้างเกินจำนวนวันที่กำหนด เพื่อไม่ให้ทีมจมกับ notification ทั้งวัน การสรุปเป็นรายงานรายวันช่วยมาก รายงานที่ลิสต์ PR ที่เปิดอยู่ งานรีวิวที่รอคุณ และรายการที่โดน tripwire ทำให้ทีมมีจุดรวมสายตาเดียวในการรักษา production deployment safety โดยไม่ต้องเปิดทุก diff ทีละบรรทัด
TODO ของ AI คือคำสารภาพหนี้เทคนิค ไม่ใช่โน้ตเตือนตัวเอง
อีก failure mode ที่ทีมประเมินต่ำไปคือคอมเมนต์ TODO ที่ AI สร้างทิ้งไว้ เดิม TODO เป็นโน้ตเตือนตัวเองของมนุษย์ เช่น “TODO รองรับเคสโค้ดโปรโมชั่นว่าง” ผู้เขียนกับผู้กลับมาทำมักเป็นคนเดียวกัน และอัตราการเขียนถูกจำกัดด้วยความเร็วพิมพ์มือ แต่ในยุคเอเจนต์ TODO เปลี่ยนความหมาย Two independent 2026 studies แสดงว่า TODO จาก AI มีรายละเอียดเชิงเทคนิคมากกว่าเดิม บรรยายงานที่เลื่อน เหตุผล และรูปทรงของวิธีแก้ เช่นอธิบายว่าบรานช์นี้ยังไม่ตรวจวันหมดอายุคูปองและควรเรียกเมธอดใด ที่สำคัญ AI สร้างคอมเมนต์เหล่านี้ด้วย generation speed ทำให้อัตราการสะสมหนี้เทคนิคดีดขึ้นเหมือนคนเซ็นใบรับสภาพหนี้ทั้งวันโดยไม่มีคนกลับมาเคลียร์ มุมมองที่ถูกต้องคือ “An agent-authored TODO is not a note. It is an unresolved acceptance criterion” ทีมจึงควรใส่ TODO tracking เข้าไปใน code governance framework ตรวจนับจำนวน TODO สุทธิในทุก PR ด้วย CI check และบังคับให้อธิบาย TODO ทุกตัวไว้ใน PR template ก่อนอนุญาตให้เมิร์จ
เคส GitHub โครงสร้างฐานข้อมูลที่ตึงกับความเร็วโค้ดและเอเจนต์
เมื่อการส่งโค้ดและการทำงานของเอเจนต์พุ่งสูงขึ้น โครงสร้างระบบที่ไม่เตรียมรับแรงมักเป็นจุดแตก ตัวอย่างคือแพลตฟอร์มโค้ดรายใหญ่ที่ประสบเหตุขัดข้องห้าครั้งในเดือนสิงหาคม โดยสองครั้งกินเวลากว่าเก้าชั่วโมง จุดร่วมทั้งหมดคือผู้ใช้จำนวนมากและเอเจนต์จำนวนมากกดดันโครงสร้างที่ใกล้เต็มกำลังอยู่แล้ว เหตุหนึ่งมาจากการดีพลอยตามปกติที่ลดจำนวนพ็อดลงเล็กน้อย การลดลงนี้กิน headroom ที่เหลือจนหมด ทำให้ไซด์คาร์ในเซอร์วิสเมชโดนจำกัด CPU และรีสตาร์ตจาก out of memory ลุกลามไปสู่ปัญหาแคช DNS และ API สำหรับผู้ใช้ ปัญหาปรากฏเป็นการสร้าง issue และ PR ที่ล้มเหลวและ API ใช้งานไม่ได้ อีกเหตุจากการพีกทราฟฟิกและอีเวนต์เข้า ระบบฐานข้อมูลที่ใช้ใน Actions ล้ม ตามรายงาน “Additional production capacity has trimmed peak cache CPU utilisation for GitHub Actions from a worrying 98% to 80% – a win it expects to last just three months as demand continues to surge” ซึ่งบอกชัดว่าแค่เพิ่ม capacity ไม่พอ ต้องเสริม capacity management และ auto scaling ที่ทนทานต่อคลื่นงานจากคนและเอเจนต์
สร้างกรอบกำกับโค้ด AI ด้วยเมตริกและ workflow ที่รับปริมาณ PR ได้
หากทีมยอมรับว่าความเร็วโค้ดจาก AI คือความจริงใหม่ สิ่งต่อมาคือออกแบบ code governance framework ให้รองรับปริมาณ PR ที่สูงขึ้นโดยไม่ลดมาตรฐานคุณภาพ โครงนี้ไม่ต้องซับซ้อนเสมอไป แนวคิดจากงานวิจัยด้านหนี้เทคนิคเสนอว่าเครื่องมือบังคับใช้สามารถอยู่ใน CI job ขนาดเล็ก บวกกับกฎ branch protection ที่ชัดเจน ตัวอย่างเช่นตั้ง CI check ที่ตรวจนับ TODO ใหม่ทั้งหมดใน diff ของ PR จากเอเจนต์ และไม่อนุญาตให้เมิร์จหาก TODO สุทธิเพิ่มโดยไม่มี ticket รองรับ หรือใช้ stacked PR workflows แยกฟีเจอร์ใหญ่เป็น PR ย่อยหลายชั้น ทำให้รีวิวได้ทีละส่วนเล็กตามหลัก “keep PRs small and read every diff” แต่เสริมด้วยกฎอัตโนมัติที่ยิงไม่ว่าคนจะมีสมาธิอยู่หรือไม่ สุดท้าย ทีมต้องเลือกเกราะไปปิดเส้นทางวิกฤตก่อน Guard critical paths เช่น auth payment และ database migration เพราะสโลปใน README แค่กวนใจ แต่สโลปในเส้นทางเหล่านี้คือจุดเริ่ม outage ระดับ GitHub ที่เราเห็นว่าฐานข้อมูล overloaded ทำให้ job assignment ล้มและ Actions ไม่เริ่มรันตามเวลา หากกรอบกำกับโค้ด AI วางน้ำหนักถูกที่ และใช้เมตริกอย่าง TODO tracking กับ code smell detection อย่างสม่ำเสมอ การให้ AI เขียนโค้ดเร็วขึ้นจึงกลายเป็นข้อได้เปรียบมากกว่าระเบิดเวลาของโปรดักชัน
