AI coding agents ในโปรดักชัน: ปัญหาไม่ใช่สมอง แต่เป็นโครงสร้าง
AI coding agents ในโปรดักชันคือระบบตัวแทนอัตโนมัติที่เขียน แก้ และรีแฟกเตอร์โค้ดเองจากคำสั่งภาษามนุษย์ โดยผูกกับเครื่องมือและ API ต่างๆ รอบตัว เพื่อให้ทีมพัฒนาส่งฟีเจอร์ได้เร็วขึ้น แต่เมื่อรันในสเกลใหญ่ ระบบเหล่านี้มักแสดงจุดอ่อนด้านสถาปัตยกรรม ความเชื่อถือได้ และการควบคุมคุณภาพ ซึ่งต่างจากเดโมเล็กๆ ที่ดูราบรื่นในวันแรกอย่างมาก
ประเด็นสำคัญคือ AI coding agents production ไม่พังเพราะโมเดล “ไม่ฉลาดพอ” แต่เพราะเราเอาเดโมไปยัดใส่ระบบที่ไม่พร้อมโหลดระดับโปรดักชัน ปัญหาที่เจอคือการตัดสินใจไม่คงเส้นคงวา เครื่องมือเรียกไม่ติด รีทรีฟข้อมูลแย่ลง คอนเท็กซ์ปนเปื้อนจนเละ และเวิร์กโฟลว์หลายเอเจนต์ถึงขั้นเดดล็อกเมื่อโหลดสูง ทั้งหมดนี้คือปัญหาโครงสร้าง AI ที่เชื่อถือได้ ไม่ใช่ปัญหาของโมเดลเอง และมันสะท้อนบทเรียนเดียวกับระบบกระจายตัว: แก้ที่สถาปัตยกรรม ไม่ใช่ปรับพรอมป์
เดบต์ความรู้: เมื่อเรารับโค้ด AI แบบไม่อ่าน บิลจะตามมาเก็บ
เสน่ห์ของ AI coding agents คือคุณพิมพ์คำสั่งวันเสาร์หนึ่งบรรทัด ปุ่มย้ายที่ ฟิลด์เพิ่มขึ้น ฟีเจอร์ทำงาน และคุณภูมิใจในสิ่งที่สร้างได้เองในวันหยุด นั่นคือความมหัศจรรย์แรก แต่จุดหักเหอยู่ที่การตัดสินใจ 4 วินาที: จะอ่านโค้ด 30 บรรทัดให้เข้าใจทุกบรรทัด หรือกดรับแล้วขอให้เอเจนต์ทำงานถัดไปต่อทันที
เมื่อรับโค้ดโดยไม่อ่าน คุณได้ซอฟต์แวร์ที่ทำงาน แต่ไม่ได้เพิ่มความเข้าใจระบบเลย พอทำแบบนี้ 40 ครั้งในบ่ายเดียว คุณจะได้ระบบที่ทำ 40 อย่าง แต่โมเดลในหัวคุณแทบไม่ครอบคลุมอะไรเลย นี่คือเดบต์เทคนิคจาก AI แบบพิเศษ: เดบต์ไม่ใช่แค่ในโค้ด แต่เป็นเดบต์ด้านความรู้ของทีม และงานวิจัย State of DevOps พบว่าทุกการเพิ่มการใช้ AI 25% เสถียรภาพการส่งมอบลดลงราว 7.2% และ throughput ลดลงราว 1.5% ในทีมมืออาชีพ นั่นคือสัญญาณว่าเดบต์ความรู้เริ่มกัดตอบสนองแล้ว
โครงสร้าง AI ที่เชื่อถือได้: บทเรียนจากระบบกระจายตัวและฟิตเนสฟังก์ชัน
เมื่อเอเจนต์ตัวเดียวในเดโมถูกดึงไปรันในงานจริงระดับองค์กร เช่น เอเจนต์ซัพพอร์ตที่ต้องตอบผู้ใช้พร้อมกันเป็นพันราย หรือเอเจนต์รีเสิร์ชที่ต้องเรียก API ภายนอกนับสิบครั้งในเวิร์กโฟลว์เดียว ความซับซ้อนจะโตแบบไม่เชิงเส้น สิ่งที่ดูเหมือน “ปัญหา AI” แท้จริงคือปัญหาอินฟราสตรักเจอร์ปลอมตัวมา ทีมที่พา AI coding agents production ขึ้นโปรดักชันได้เร็วคือทีมที่ยอมรับข้อเท็จจริงนี้ และยกบทบาท orchestration, การจัดการ state และ observability ขึ้นเป็นพลเมืองชั้นหนึ่งในสถาปัตยกรรม
หัวใจของโครงสร้าง AI ที่เชื่อถือได้ คือการออกแบบความเชื่อถือได้ตั้งแต่วันแรก ไม่ใช่หวังจะติดตั้งย้อนหลังด้วยรีทรายหรือแดชบอร์ดทีหลัง ฟิตเนสฟังก์ชันที่ชัดเจน — ตัวชี้วัดที่รันอัตโนมัติว่าระบบยังรักษาพฤติกรรมสำคัญครบหรือไม่ — ต้องผูกเข้ากับทุกการเปลี่ยนโค้ดจากเอเจนต์ และในสภาพแวดล้อมที่มีกฎกำกับ การรีวิวโค้ดโดย AI ต้องอยู่ใต้ความรับผิดชอบของมนุษย์ที่มีชื่อชัดเจน ไม่ใช่คณะกรรมการผลัดกันคลิก approve เครื่องมืออัตโนมัติเก่งในการจับรูปแบบช่องโหว่และ bug ซ้ำๆ ในสเกลที่มนุษย์สู้ไม่ได้ แต่พวกมันไม่สามารถแทนการตัดสินของผู้เชี่ยวชาญในระบบที่ผิดไม่ได้
ความเสี่ยงจริง: ฟีเจอร์หายเงียบและซีเคร็ตหลุดจากคอนเท็กซ์ของเอเจนต์
AI coding agents โดดเด่นเรื่องรีแฟกเตอร์: โค้ดสั้นลง สะอาดขึ้น ชื่อสื่อความขึ้น แต่แลกกับความเสี่ยงที่น่ากลัวคือฟีเจอร์สำคัญหายไปอย่างเงียบๆ เอเจนต์ไม่รู้เองว่าบรรทัดไหนคือโค้ดรับน้ำหนักระบบ บางครั้ง flag ที่ทำหน้าที่บอกว่า “ฟีเจอร์นี้ห้ามขาย” ไม่เคยถูกอ่านโดยโค้ดใดเลยจนเราให้เอเจนต์ช่วยปรับระบบแล้วค่อยค้นพบ นี่หมายความว่าหากไม่มีการกำหนดสิ่งที่ต้อง “ห้ามแตะ” อย่างชัดเจน เรากำลังเปิดทางให้เอเจนต์รีแฟกเตอร์จนทำลายตรรกะธุรกิจแบบไร้เสียงเตือน
อีกด้านหนึ่ง AI coding agents มีมูลค่าเพราะพวกมันอ่านทุกอย่างในโปรเจ็กต์ ทั้งซอร์สไฟล์ คอนฟิก env และข้อความ error แต่ “ทุกอย่าง” นั้นรวมถึงซีเคร็ต เช่น API key และรหัสผ่านที่ถูกอ่านเป็นคอนเท็กซ์แล้วส่งต่อไปยังผู้ให้บริการโมเดลพร้อมกัน กรณีหนึ่งมีผู้วิจัยด้านความปลอดภัยพบว่าเอเจนต์โหลดทั้ง Git repo รวมถึงคีย์ในไฟล์ .env ขึ้นคลาวด์แบบไม่ปิดทอน ความเสี่ยงจึงไม่ใช่แค่การบั๊ก แต่คือการรั่วไหลที่เงียบและบันทึกอยู่ในล็อกที่เราไม่เห็น
จากเดโมสู่โปรดักชัน: สามชั้นป้องกันและบทสรุปสำหรับทีมพัฒนา
เพื่อป้องกันข้อผิดพลาด AI ก่อนโค้ดถูกส่งขึ้นโปรดักชัน เราต้องคิดเป็นสถาปัตยกรรม ไม่ใช่แค่เป็นฟีเจอร์ แนวทางที่เห็นภาพชัดคือการสร้าง “จุดยึดการคงสภาพ” ของระบบไว้ต่อหน้าเอเจนต์ เช่น รายการสิ่งที่ห้ามแตะ พร้อมเหตุผลเชิงธุรกิจว่าเพราะอะไรต้องรักษาให้เหมือนเดิม เพื่อให้เอเจนต์ใช้เหตุผลร่วมกับกฎ ไม่ใช่หาทางเลี่ยงกฎ จากนั้นเสริมด้วยกลไกตรวจสอบหลายชั้น ตั้งแต่สแกนคอนเท็กซ์หา secrets ตั้งแต่ตอนพิมพ์ ก่อน commit ก่อนส่งคอนเท็กซ์ไปยังโมเดล และอีกครั้งเมื่อเปิด pull request
สิ่งที่ตามมาคือทีมต้องวางเกตที่ชัดเจนในสภาพแวดล้อมที่เอเจนต์รัน พร้อมผูกเข้ากับ quality gate เพื่อให้โค้ดที่มีปัญหาหรือมีซีเคร็ตไม่สามารถผ่านไปจนถึงขั้นรีวิวได้ง่ายๆ แนวทางต่อไปที่ผู้เขียนระบบเหล่านี้กำลังทำคือเลือกสภาพแวดล้อมที่เอเจนต์รัน แล้ววางเกตที่นั่น จากนั้นเชื่อมกับระบบตรวจคุณภาพโค้ดและฟิตเนสฟังก์ชันที่ออกแบบมาตั้งแต่ต้น บทสรุปคือ AI coding agents production จะไม่เชื่อถือได้หากเราใช้มันเหมือนของเล่นเดโม แต่ถ้าเรายอมลงทุนในโครงสร้าง AI ที่เชื่อถือได้ ยอมจ่ายเดบต์ความรู้ด้วยการอ่านและทำความเข้าใจ และรักษาบทบาท gatekeeper ของมนุษย์ไว้ในระบบวิกฤต AI ก็จะเป็นตัวช่วย ไม่ใช่ตัวสร้างหนี้
