เข้าใจปัญหา: ทำไมต้องป้องกัน AI ไม่ให้ลบฟีเจอร์
การป้องกัน AI coding agent ไม่ให้ลบหรือแก้ไขฟีเจอร์สำคัญคือการกำหนดกติกา เครื่องมือ และขั้นตอนตรวจสอบ เพื่อให้การปรับปรุงโค้ดแบบอัตโนมัติยังคงรักษาพฤติกรรมเดิมที่จำเป็นต่อธุรกิจ ระบบ และข้อมูลของผู้ใช้ไว้ครบถ้วน โดยไม่เสี่ยงทำให้ฟีเจอร์สำคัญหายไปหรือเสียหายระหว่างการรีแฟกเตอร์หรืออัปเดตโค้ดใหม่ๆ.
ถ้าคุณใช้ AI coding agent ให้ช่วยรีแฟกเตอร์หรือเขียนโค้ดซ้ำ การตั้งเกราะ AI coding agent ความปลอดภัย เป็นเรื่องจำเป็นมาก เพราะ agent สามารถส่งพีอาร์ที่ทั้งสั้นลง สะอาดขึ้น ตั้งชื่อดีขึ้น แต่แอบทำฟีเจอร์หายไปแบบเงียบๆ. มันไม่รู้เองว่าบรรทัดไหนคือโค้ดรับน้ำหนักจริง เช่น trigger แบบ append-only บนตาราง ledger หรือค่า NULL ใน foreign key ที่ดูเหมือน bug แต่คือเงื่อนไขทางธุรกิจสำคัญ.
เพื่อป้องกัน feature deletion คุณต้องเตรียมทั้งรายการสิ่งที่ห้ามแตะ นโยบาย code quality control และระบบ automated code review ที่จะคอยเตือนเมื่อ AI ไปแตะจุดเสี่ยง ขั้นตอนในบทความนี้เหมาะกับทีมที่ใช้ workflow แบบ agentic ทำงานร่วมกับเครื่องมืออัปเดต dependency อัตโนมัติ และอยากได้อัตโนมัติแบบไม่แลกกับความน่าเชื่อถือของโค้ด.
ออกแบบ Preservation Anchors: กฎพื้นฐานที่ AI ต้องอ่านและเข้าใจ
หัวใจของ AI coding agent ความปลอดภัย คือการมี “preservation anchors” หรือรายการสิ่งที่ห้ามเปลี่ยน เขียนไว้ในไฟล์คำสั่งที่ agent อ่านแน่นอน เช่น CLAUDE.md โดยมี section หนึ่งที่เอาไว้ระบุสิ่งที่แตะไม่ได้แบบตรงๆ. แต่ละบรรทัดควรบอกสามอย่าง: อะไร (what) ทำไม (why) และอยู่ที่ไหนในโค้ดหรือสคีมา.
ตัวอย่างเช่น การระบุว่า “ตาราง ledger เป็น append-only การคืนเงินให้เขียนแถวใหม่ ห้ามแก้แถวเก่า” พร้อมคำอธิบายเหตุผลว่าเกี่ยวกับการคำนวณ fraud clawback อย่างไร. ประโยคเหตุผลนี่สำคัญมาก เพราะถ้ากฎไม่มีเหตุผลประกบ agent จะหาทางหลบเลี่ยงทันทีที่กฎนั้นขวางการรีแฟกเตอร์ แต่ถ้ามีเหตุผล มันจะใช้เป็นข้อจำกัดในการออกแบบโค้ดใหม่ได้.
อีกจุดสำคัญคือ anchors ต้องพูดว่า “ต้องรักษาอะไร” ไม่ใช่ “ห้ามทำอะไรแบบกว้างๆ” เช่นคำสั่ง “อย่าทำ ledger พัง” ใช้ไม่ได้ แต่ “ตารางนี้ห้าม update/delete ให้ใช้ insert เท่านั้น” ใช้งานได้จริง. เมื่อคุณเริ่มมีรายการ anchors ที่ชัดเจน คุณก็เริ่มมี policy configuration ที่ทำหน้าที่เป็น gatekeeper สำหรับการเปลี่ยนโค้ดอัตโนมัติ ทั้งสำหรับ AI agent และเครื่องมืออื่น.
สามระดับการป้องกัน: จากคำอธิบาย ถึง trigger ในฐานข้อมูล
เพื่อป้องกัน feature deletion อย่างจริงจัง คุณควรสร้างระบบสามชั้น: ระดับคำอธิบาย, ระดับเทส, และระดับข้อจำกัดเชิงโครงสร้างในฐานข้อมูลหรือไฟล์. ชั้นแรกคือ prose ในไฟล์คำสั่งที่อธิบาย preservation anchors ทั้งหมด แต่นี่เป็นเพียงคำแนะนำ agent อาจอ่านและทำตามส่วนใหญ่ แต่พอรีแฟกเตอร์ลึกๆ ข้อจำกัดเหล่านี้อาจหลุดจาก context window ได้. ดังนั้น prose จำเป็นแต่ไม่พอ.
ชั้นที่สองคือเทสที่ล้มเหลวเมื่อ anchor ถูกแตะ โดยข้อความ error ต้องเอ่ยชื่อ anchor และอธิบาย invariant ที่พัง พร้อมทางเลือกที่ถูกต้องอย่างน้อยหนึ่งทาง. ตัวอย่างหนึ่งคือโปรเจกต์ที่มี 26 จาก 86 ไฟล์เทสกล่าวถึง preservation anchors โดยตรงใน assertion หรือ comment. นอกจากนี้ยังมีนโยบายชัดเจนว่า “ถ้าเทสที่เกี่ยวกับ preservation anchor ล้ม ห้ามแก้เทสก่อน ให้สงสัยว่าฟีเจอร์ถูกทำพัง” เพื่อป้องกัน agent ทำเทสให้เขียวแบบผิดทาง.
ชั้นที่สามคือการทำให้บางเรื่องผิดได้ในเชิงโครงสร้าง เช่น การใช้ Postgres trigger เพื่อบังคับให้ตาราง ledger บางตัวเป็น append-only ถ้าใครพยายาม UPDATE หรือ DELETE จะโดน exception พร้อมข้อความระบุ invariant ทันที. ตาราง points ledger, admin audit log และ consent log ถูกตั้งให้ไม่ยอมรับการแก้ไขแบบนี้ ทำให้แม้ AI จะเลือกวิธี update ด้วยความตั้งใจดี ก็จะเจอ error แทน bug เงียบๆ. แนวคิดเดียวกันนี้ยังใช้กับไฟล์ asset โดยการ pin ไฟล์ 26 ไฟล์ด้วย SHA-256 ใน manifest ถ้าเปลี่ยนแม้แต่ byte เดียว CI จะล้ม.
จัดการเครื่องมืออัตโนมัติ: ไม่ให้แก้ไฟล์ผิดและซ้ำกับ AI
นอกจาก AI coding agent แล้ว เครื่องมืออัปเดต dependency อัตโนมัติอย่าง Renovate ก็อาจทำให้ workflow พังได้ถ้าไม่มีเกณฑ์ควบคุม. ตัวอย่างหนึ่งคือ lock file จาก agentic workflows (ไฟล์ .lock.yml) ที่ใช้ GitHub actions แบบอ้าง SHA ถ้า Renovate ไปอัปเดต SHA ให้เป็นเวอร์ชันใหม่ แต่ script ในไฟล์นี้ยังเรียก helper script ที่เวอร์ชันใหม่ไม่มีอีกแล้ว workflow ก็จะล้มทันที. นี่คือรูปแบบหนึ่งของการทำให้ “ฟีเจอร์ของ pipeline” หายไปโดยไม่ตั้งใจ.
ความผิดพลาดที่สองคือการทำ workflow รีคอมไพล์ไฟล์ agentic ทุกครั้งที่ lock file เปลี่ยน ไม่ว่าการเปลี่ยนนั้นคืออะไร. เมื่อ Renovate เปิด PR เพื่อ pin เวอร์ชัน Node.js ในไฟล์เดียวกัน trigger นี้ก็ทำงาน รันคำสั่ง compile ทับไฟล์ และย้อนการเปลี่ยนเวอร์ชัน Node.js ที่ Renovate เพิ่งทำไป. สุดท้ายทีมจึงพบว่าแนวทางที่ถูกคือมองว่า “ไฟล์ generate ไม่ใช่ไฟล์ dependency” ถึงจะมีเวอร์ชันในนั้น เราก็ไม่ควรให้เครื่องมืออัตโนมัติไปแตะ.
- เพิ่ม path ของไฟล์ lock และไฟล์ workflow ที่ generate โดย agentic ลงใน ignorePaths ของ Renovate เพื่อกันไม่ให้โดนแก้ตรงๆ.
- อัปเดต “แหล่งจริง” ของเวอร์ชัน GitHub actions ในไฟล์ manifest .github/aw/actions-lock.json ผ่านคำสั่ง gh aw update-actions ซึ่งใช้เป็นที่มาของ action SHAs ตอน compile.
- ตั้ง GitHub workflow ให้ trigger เฉพาะเมื่อไฟล์ actions-lock.json เปลี่ยน แล้วรัน GH_TOKEN=${{ secrets.GITHUB_TOKEN }} gh aw compile เพื่อ regenerate ไฟล์ lock ทั้งหมดในคราวเดียว.
ผลลัพธ์คือ code quality control ดีขึ้นมาก เพราะเครื่องมืออัตโนมัติรู้ขอบเขตว่าแก้ได้เฉพาะไฟล์ manifest ต้นทาง ไม่แตะไฟล์ generate. เมื่อ combine กับ automated code review และ preservation anchors คุณจะได้ระบบที่อัตโนมัติสูงแต่ยังคงความน่าเชื่อถือของโค้ด.
สรุป: ให้ AI ช่วยโดยไม่เสียฟีเจอร์สำคัญ
หลังวางสามชั้นป้องกันและจัดการ policy configuration ดีแล้ว คุณจะปล่อยให้ AI coding agent ทำงานได้อย่างมั่นใจมากขึ้น. Preservation anchors ทำหน้าที่เหมือนแผนที่ว่าอะไรแตะได้ อะไรแตะไม่ได้ ขณะเดียวกันเทสและข้อจำกัดในฐานข้อมูลหรือ manifest ช่วยทำให้ “กฎที่บังคับไม่ได้” กลายเป็น “กฎที่ฝ่าฝืนไม่ได้” จริงๆ.
สิ่งที่ต้องเฝ้ามองคือสองกับดักหลัก: ปล่อยให้เครื่องมืออย่าง Renovate แก้ไฟล์ generate จน workflow พัง และปล่อยให้ agent แก้เทสเพื่อทำให้ไฟแดงกลายเป็นไฟเขียวโดยไม่รักษา invariant. บทสรุปที่ช่วยจำง่ายคือ “ดันข้อจำกัดลงไปให้ลึกที่สุด” จากคำอธิบาย ไปสู่เทส และลงท้ายที่ trigger หรือ constraint ที่ไม่มีใครพูดเจรจาด้วยได้. ถ้าคุณทำได้ครบ การป้องกัน feature deletion ก็จะไม่ใช่ภาระ แต่กลายเป็นเกราะบางๆ ที่ทำให้การใช้ AI และ automation คุ้มค่าขึ้นมาก.
