【ปี 2026】กรณีความล้มเหลวและเหตุการณ์ด้านความปลอดภัยของ Vibe Coding (การพัฒนาที่ขับเคลื่อนด้วย AI) | สาเหตุและมาตรการรับมือที่มองผ่านตัวอย่างจริงทั้งในและต่างประเทศและข้อมูลล่าสุด

Vibe Coding หมายถึงรูปแบบการพัฒนาที่ใช้การสั่งงาน AI ด้วยภาษาธรรมชาติ และยอมรับโค้ดที่สร้างขึ้นมาโดยไม่ได้ตรวจสอบเนื้อหาภายใน ในช่วงต้นปี 2026 อุบัติเหตุที่เกิดขึ้นรอบด้านการพัฒนาที่ขับเคลื่อนด้วย AI มีความหลากหลายมากขึ้น ไม่ว่าจะเป็น Moltbook ที่อนุญาตให้บุคคลภายนอกเข้าถึงข้อมูลได้ประมาณ 4.75 ล้านเรคคอร์ด, Lovable ที่เผยให้เห็นซอร์สโค้ดและประวัติการแชทของโปรเจกต์สาธารณะเป็นเวลานานถึง 2 เดือนครึ่ง, การตรวจสอบของ RedAccess ที่ตรวจพบสินทรัพย์สาธารณะจำนวน 380,000 รายการ รวมถึงช่องโหว่ของตัวเครื่องมือ AI Coding เอง สาเหตุของเหตุการณ์เหล่านี้ไม่ได้เหมือนกันทั้งหมด โดยมีทั้งการขาดการตรวจสอบผลลัพธ์ที่สร้างขึ้น, ข้อผิดพลาดจากฝั่งแพลตฟอร์ม และปัญหาที่เกิดจากการนำเครื่องมือไปใช้งานหรือการดำเนินงาน ซึ่งในบทความนี้จะทำการจัดระเบียบโดยระบุความแตกต่างเหล่านั้นให้ชัดเจน นอกจากนี้ยังจะนำเสนอข้อมูลเชิงประจักษ์ที่เผยแพร่โดย Findy และ Tabelog ในประเทศญี่ปุ่น ประกอบกับการสำรวจล่าสุดจาก Veracode และ New Relic เพื่อสรุปแนวทางป้องกัน (Guardrails) ใน 3 ระดับ ได้แก่ ขอบเขตการใช้งาน (Scope), การตรวจสอบ (Verification) และสิทธิ์การเข้าถึง (Authorization) โดยกลุ่มเป้าหมายของบทความนี้คือผู้รับผิดชอบด้านการพัฒนาและฝ่ายระบบสารสนเทศที่กำลังตัดสินใจว่าจะขยายการใช้ AI Coding ไปสู่ผลิตภัณฑ์จริงหรือไม่

ความล้มเหลวของ Vibe Coding แทบจะไม่ปรากฏให้เห็นในขณะที่กำลังเขียนโค้ด แต่จะถูกเปิดเผยออกมาใน 3 สถานการณ์ ได้แก่ เมื่อถูกโจมตีจากภายนอกหลังจากการเผยแพร่, เมื่อต้องขยายระบบด้วยการเพิ่มฟีเจอร์ใหม่ และเมื่อต้องแก้ไขโค้ดที่ไม่มีใครเข้าใจการทำงานภายใน

ความล่าช้าของเวลาที่เกิดขึ้นนี้ทำให้การตัดสินใจเป็นเรื่องยาก ประสิทธิภาพการทำงานในช่วงเริ่มต้นนั้นสูงจริง ซึ่งประสบการณ์ดังกล่าวสร้างความคาดหวังว่า "เราสามารถทำแบบนี้ต่อไปจนถึงขั้นใช้งานจริงได้" แต่ปัญหาจะเกิดขึ้นหลังจากที่เราได้เพิ่มการลงทุนไปตามความคาดหวังนั้นแล้ว

ในเบื้องต้น AI-Driven Development และ Vibe Coding ไม่ใช่สิ่งเดียวกัน AI-Driven Development คือความพยายามโดยรวมในการใช้ AI ในทุกขั้นตอนตั้งแต่การกำหนดความต้องการไปจนถึงการเขียนโค้ดและการทดสอบ ส่วน Vibe Coding หมายถึงวิธีการที่ละเว้นการตรวจสอบผลลัพธ์ที่สร้างขึ้น หากมองข้ามความแตกต่างนี้ไป มาตรการรับมือจะกลายเป็นความสุดโต่งที่ว่า "ไม่ใช้ AI เลย"

การแยกแยะสาเหตุของปัญหาก็มีความสำคัญเช่นกัน กรณีของ Moltbook ที่ขาดการควบคุมการเข้าถึง และกลุ่มแอปที่ถูกปล่อยออกมาด้วยการตั้งค่าสาธารณะตามค่าเริ่มต้น (การสำรวจของ RedAccess) สามารถอ่านได้ว่าเป็นผลลัพธ์ของการพัฒนาที่ละเลยการตรวจสอบ ในทางกลับกัน ข้อผิดพลาดจากฝั่งแพลตฟอร์ม (Lovable), ช่องโหว่ของตัวเครื่องมือเอง และความผิดพลาดในการตั้งค่าสภาพแวดล้อมการประเมิน (Anthropic) เป็นปัญหาอีกประเภทหนึ่งที่ไม่สามารถตรวจพบได้ด้วยการรีวิวโค้ดของผู้ใช้งาน หากสรุปทุกอย่างว่า "Vibe Coding เป็นสิ่งไม่ดี" จะทำให้เราวางมาตรการรับมือผิดจุด ในช่วงครึ่งหลังของบทความนี้ เราจะแยกสองประเด็นนี้ออกเป็นคนละบทครับ

เราจะมาดูตัวอย่างจากต่างประเทศ 3 กรณี สิ่งที่มีร่วมกันคือ "การตรวจสอบขอบเขตการเปิดเผยข้อมูลและการควบคุมการเข้าถึงไม่เพียงพอ" แต่สาเหตุทางเทคนิคมีความแตกต่างกัน ได้แก่ การขาดการตั้งค่าสิทธิ์ในฝั่งแอปพลิเคชัน, ข้อผิดพลาดในฝั่งแพลตฟอร์ม และปัญหาเรื่องค่าเริ่มต้นและการตั้งค่าของผู้ใช้ที่ครอบคลุมแอปพลิเคชันจำนวนมาก

"Moltbook" โซเชียลมีเดียสำหรับ AI Agent ซึ่งเปิดตัวในเดือนมกราคม 2026 กลายเป็นประเด็นร้อนหลังจาก Matt Schlicht ผู้ก่อตั้งได้ประกาศอย่างเปิดเผยว่าเขา "ไม่ได้เขียนโค้ดแม้แต่บรรทัดเดียว" และเหตุการณ์ข้อมูลรั่วไหลก็ถูกตรวจพบหลังจากนั้นไม่นาน

ตาม การตรวจสอบของ Wiz Research ปัญหาไม่ได้อยู่ที่การวาง publishable key ของ Supabase ไว้ใน JavaScript ฝั่งไคลเอนต์โดยตัวมันเอง เนื่องจากคีย์นี้ถูกออกแบบมาให้เปิดเผยเพื่อใช้เป็นตัวระบุโปรเจกต์ (Project Identifier) และการที่มองเห็นได้จากซอร์สโค้ดก็เป็นไปตามข้อกำหนดอยู่แล้ว สิ่งที่ขาดไปคือการตั้งค่านโยบาย Row Level Security (RLS) ซึ่งหากไม่มีนโยบายนี้ ใครก็ตามที่มีคีย์ดังกล่าวจะสามารถข้ามการตรวจสอบสิทธิ์และเข้าถึงฐานข้อมูลได้

ข้อมูลที่สามารถอ่านได้มีประมาณ 4.75 ล้านเรกคอร์ด ประกอบด้วยโทเค็นการยืนยันตัวตนของ Agent ประมาณ 1.5 ล้านรายการ, อีเมลแอดเดรสของ owners และ observers (ในบทสรุปแจ้งว่า 35,000 รายการ แต่ในรายละเอียดระบุตัวเลขอื่น ซึ่งตัวเลขในหน้าเผยแพร่ข้อมูลไม่ตรงกัน), และบทสนทนาระหว่าง Agent ที่เป็นส่วนตัวอีก 4,060 รายการ ทีมตรวจสอบยังสามารถแก้ไขโพสต์ที่มีอยู่เดิมได้สำเร็จ ซึ่งหมายความว่าสถานะในขณะนั้นสามารถทั้งอ่านและเขียนข้อมูลได้ Wiz ได้ติดต่อผู้ดูแลระบบครั้งแรกเมื่อวันที่ 31 มกราคม 2026 เวลา 21:48 น. (UTC) และการป้องกันตารางข้อมูลทั้งหมดเสร็จสิ้นในวันถัดมาคือวันที่ 1 กุมภาพันธ์ เวลา 01:00 น. (UTC)

สิ่งที่ควรตระหนักคือ นี่ไม่ใช่ "ช่องโหว่ที่ซับซ้อน" แต่อย่างใด เนื่องจากนโยบาย RLS ไม่จำเป็นต้องใช้ในการทดสอบการทำงาน AI จึงไม่ได้เขียนโค้ดส่วนนี้ และมนุษย์เองก็ไม่ได้สังเกตเห็นเช่นกัน

ปัญหาที่เกิดขึ้นกับ Lovable ไม่ใช่ความผิดพลาดจากโค้ดของผู้ใช้งาน แต่เป็นความบกพร่องที่ฝั่งโครงสร้างพื้นฐาน ตามคำชี้แจงอย่างเป็นทางการของบริษัท (22 เมษายน 2026) ระบุว่าเกิดการถดถอย (regression) ที่ส่วนแบ็กเอนด์ ส่งผลให้การเข้าถึงสาธารณะสำหรับประวัติการแชทและซอร์สโค้ดของโปรเจกต์สาธารณะถูกเปิดใช้งานโดยไม่ตั้งใจอีกครั้ง โดยช่วงเวลาที่อาจเกิดการรั่วไหลคือประมาณ 2 เดือนครึ่ง ตั้งแต่วันที่ 3 กุมภาพันธ์ ถึง 20 เมษายน 2026 ทั้งนี้มีการระบุชัดเจนว่าโปรเจกต์ส่วนตัวและ Lovable Cloud ไม่ได้รับผลกระทบ

การนับระยะเวลาจำเป็นต้องใช้ความระมัดระวัง ตัวเลข "48 วัน" ที่ปรากฏในสื่อนั้น อ้างอิงจากช่วงเวลาที่นักวิจัยความปลอดภัยรายหนึ่งแจ้งเหตุเมื่อวันที่ 3 มีนาคม จนถึงวันที่ยืนยันการแก้ไขเมื่อวันที่ 20 เมษายน (The Next Web) ในขณะที่ช่วงเวลาการรั่วไหลที่บริษัทระบุอย่างเป็นทางการนั้นยาวนานกว่า โดยมีจุดเริ่มต้นตั้งแต่วันที่ 3 กุมภาพันธ์ เนื้อหาหลักที่สามารถเข้าถึงได้คือประวัติการแชทและซอร์สโค้ด ส่วนข้อมูลการเชื่อมต่อฐานข้อมูลนั้นจะสามารถอ่านได้ก็ต่อเมื่อมีการฝังไว้ในซอร์สโค้ดดังกล่าวเท่านั้น

สิ่งที่ควรพิจารณาคือลำดับเหตุการณ์ในการรับมือ ในช่วงแรกบริษัทอธิบายว่าพฤติกรรมนี้เป็นส่วนหนึ่งของข้อกำหนด (specification) และปิดรายงานดังกล่าวโดยถือว่าเป็นรายงานที่ซ้ำซ้อน กรณีนี้เป็นตัวอย่างที่แสดงให้เห็นว่า แม้โค้ดของบริษัทคุณจะไม่มีปัญหา แต่ค่าเริ่มต้นของโครงสร้างพื้นฐานและความเร็วในการตอบสนองต่อรายงานช่องโหว่ก็อาจกลายเป็นความเสี่ยงได้ ดังนั้นจึงคุ้มค่าที่จะตรวจสอบประวัติการรับมือปัญหาในอดีตเมื่อต้องเลือกใช้โครงสร้างพื้นฐานต่างๆ

สิ่งที่แสดงให้เห็นถึงขอบเขตที่กว้างขวางไม่ใช่แค่กรณีตัวอย่างรายบุคคล คือผลการสำรวจที่ RedAccess ของอิสราเอลเผยแพร่เมื่อวันที่ 7 พฤษภาคม 2026 (Security Boulevard ซึ่ง WIRED และ Axios ได้รายงานพร้อมกัน) โดยมีการตรวจพบสินทรัพย์ที่เข้าถึงได้แบบสาธารณะบน Lovable, Base44, Netlify และ Replit ประมาณ 380,000 รายการ ในจำนวนนี้มีประมาณ 5,000 รายการที่มีสัญญาณของการใช้งานในองค์กร และมีการสรุปว่ากว่า 2,000 รายการ หรือประมาณ 40% ของจำนวนดังกล่าว สามารถเข้าถึงข้อมูลที่ละเอียดอ่อนได้โดยไม่ต้องผ่านการยืนยันตัวตน

การรายงานข่าวมีการตัดทอนตัวเลขที่แตกต่างกันออกไป โดยบางบทความสรุปว่า "ประมาณ 5,000 รายการเปิดเผยข้อมูลที่ละเอียดอ่อน" โปรดตรวจสอบตัวตั้งและตัวหารก่อนนำไปอ้างอิง อีกทั้งความถูกต้องของข้อมูลที่ถูกเปิดเผยก็ยังไม่ได้ผ่านการตรวจสอบทั้งหมด

เนื้อหาที่ได้รับการยืนยันนั้นสะท้อนให้เห็นถึงลักษณะของปัญหา ไม่ว่าจะเป็นบันทึกการสนทนาระหว่างแพทย์และผู้ป่วยในโรงพยาบาล, การสนทนากับผู้ป่วยในสถานดูแลระยะยาว, ข้อมูลทางการเงินภายในของธนาคารในบราซิล, ตารางการเข้าเทียบท่าของเรือ และการโต้ตอบของฝ่ายสนับสนุนลูกค้าของผู้ค้าเฟอร์นิเจอร์ ซึ่งทั้งหมดนี้สามารถเข้าถึงได้โดยไม่ต้องมีการยืนยันตัวตน และบางส่วนยังถูกจัดทำดัชนีโดยเครื่องมือค้นหาอีกด้วย

สาเหตุที่ถูกระบุถึงไม่ใช่ช่องโหว่ แต่เป็น "ค่าเริ่มต้น" (Default) เครื่องมือบางอย่างสร้างโปรเจกต์ใหม่ในสถานะสาธารณะ และการดำเนินการเปลี่ยนให้เป็นส่วนตัวนั้นขึ้นอยู่กับผู้ใช้งาน ผู้สร้างที่ไม่ใช่นักพัฒนาจึงไม่ทราบถึงการมีอยู่ของการตั้งค่าดังกล่าว ซึ่งในกรณีนี้ การตรวจสอบการทำงานก็ไม่พบความผิดปกติใดๆ เช่นกัน

สิ่งที่ถูกเปิดเผยภายในประเทศไม่ใช่รายงานเกี่ยวกับอุบัติเหตุข้อมูลรั่วไหล แต่เป็นรายงานเชิงปริมาณที่ว่า "นำมาใช้งานแล้วแต่ไม่ได้ผลลัพธ์ตามที่คาดหวัง" โดยจะขอยกตัวอย่าง 3 กรณีจากการขึ้นบรรยายของบริษัทต่างๆ ข้อมูลการวัดผลจริงในงานประชุม และบล็อกของทีมพัฒนาครับ

กรณีศึกษาในประเทศที่เปิดเผยตัวเลขอย่างเป็นรูปธรรมคือ transcosmos โดยในงาน AWS Summit Japan 2026 (เมื่อวันที่ 25 มิถุนายน 2026) คุณ Toshio Tokoro ตำแหน่ง Senior Managing Executive Officer ได้นำเสนอผลการทดสอบของบริษัทว่า ในการพัฒนาแอปพลิเคชัน ToDo แบบง่าย สามารถลดชั่วโมงการทำงานลงได้ถึง 87% เมื่อเทียบกับวิธีการแบบเดิม (transcosmos Digital Technology Official note) ทั้งนี้ ตัวเลขดังกล่าวเป็นค่าที่บริษัทรายงานด้วยตนเอง ไม่ใช่การวัดผลโดยบุคคลที่สาม

สิ่งที่น่าสนใจคือสิ่งที่เกิดขึ้นหลังจากนั้น บริษัทระบุชัดเจนว่าเมื่อนำวิธีการนี้ไปใช้กับระบบขนาดใหญ่ กลับเกิดความล่าช้าในการส่งมอบงานและคุณภาพของผลงานลดลง เพื่อแก้ไขปัญหาดังกล่าว บริษัทจึงได้พัฒนา "Waterfall Boost" ขึ้นมาเอง ซึ่งประกอบด้วย Procedural Agent ที่ทำหน้าที่นำงานในแต่ละเฟส, QA Agent ที่ใช้ LLM ซึ่งมี 7 บุคลิก (Persona) ในการตรวจสอบคุณภาพเอกสาร และ Coding Agent ที่คอยควบคุมให้เป็นไปตามมาตรฐานการเขียนโค้ด

สิ่งที่ควรตระหนักไม่ใช่ตัวเลข 87% แต่คือการที่ ไม่ควรนำอัตราการลดชั่วโมงทำงานจากการทำ PoC ขนาดเล็กมาเป็นความคาดหวังของทั้งองค์กรโดยตรง สิ่งที่บริษัทได้เพิ่มเข้ามาในท้ายที่สุดไม่ใช่โมเดลที่ฉลาดขึ้น แต่คือการสร้างมาตรฐาน (Standardization)

มีการเปิดเผยค่าที่วัดได้จริงในการรายงานที่งาน AI DevEx Conference 2026 โดยคุณ Toda ตำแหน่ง Principal Engineer ของ Findy ได้แสดงให้เห็นถึงการเปลี่ยนแปลงจากข้อมูลภายในบริษัทเมื่อเปรียบเทียบระหว่างปี 2024 และ 2025 ดังนี้ (Findy Tech Blog, 24 กรกฎาคม 2026)

ทางบริษัทอธิบายว่า ผลจากการที่ขั้นตอนการสร้างโค้ดเพียงขั้นตอนเดียวเร็วขึ้น ทำให้คอขวดเคลื่อนย้ายไปอยู่ที่การรีวิว ส่งผลให้ Throughput ของการพัฒนาโดยรวมกลับมาคงที่ อย่างไรก็ตาม นี่เป็นการเปรียบเทียบก่อนและหลังการนำมาใช้งานจริง ไม่ใช่การทดลองที่ยืนยันได้แน่ชัดว่า AI เป็นสาเหตุ สิ่งที่สำคัญคือเนื้อหาถัดมา ซึ่งบทความเดียวกันนี้รายงานว่า หลังจากดำเนินมาตรการปรับปรุง (เปรียบเทียบช่วงเดือนมกราคม–เมษายน 2026) จำนวน Session เพิ่มขึ้นประมาณ 3 เท่า และจำนวนการรัน Skill เพิ่มขึ้นประมาณ 6 เท่า ส่งผลให้ จำนวน PR ที่สร้างต่อคนเพิ่มขึ้นประมาณ 1.5 เท่า โดยที่คุณภาพไม่ลดลง ความหยุดชะงักดังกล่าวจึงถูกมองว่าเป็นเพียงจุดผ่าน ไม่ใช่สถานะสุดท้าย

ผลสำรวจผู้เข้าร่วมงานในสถานที่เดียวกันก็มีแนวโน้มใกล้เคียงกัน ตามรายงานจากฝ่ายประชาสัมพันธ์ด้านเทคนิคของ Kakaku.com (Tabelog Tech Blog, 31 กรกฎาคม 2026) ระบุว่ามีผู้ตอบแบบสอบถามประมาณ 260 คนในรูปแบบการติดสติกเกอร์ในช่วง 2 วัน โดยคอขวดอันดับ 1 คือ "การกำหนดความต้องการและออกแบบ" (41%) อันดับ 2 คือ "การรีวิวโค้ด" (31%) และ "การเขียนโค้ด" อยู่ที่ 0% ส่วนการปรับปรุง Lead Time นั้น ผลตอบรับระหว่าง "ไม่เปลี่ยนแปลง" (ประมาณ 26%) กับ "เร็วขึ้น 3 เท่าขึ้นไป" (ประมาณ 25%) อยู่ในระดับที่ใกล้เคียงกัน แม้จะเป็นข้อมูลอ้างอิงเนื่องจากไม่ได้เป็นการสุ่มตัวอย่าง แต่มีการบันทึกไว้ว่ามีผู้เข้าร่วมงานหลายคนให้ความเห็นในทำนองว่า "เมื่อการเขียนโค้ดลดลง งานรีวิวก็เพิ่มขึ้น"

ความล้มเหลวที่ถูกแชร์กันภายในประเทศไม่ได้ปรากฏในรูปแบบของอุบัติเหตุ แต่ปรากฏในรูปแบบของ การเพิ่มประสิทธิภาพเฉพาะจุด (Local Optimization) หากเร่งความเร็วในการสร้างงาน แต่ไม่เพิ่มขีดความสามารถในการประมวลผลของฝั่งรับ ระยะเวลาที่ใช้โดยรวมก็จะไม่เปลี่ยนแปลง

กรอบแนวคิดที่สามารถนำมาใช้อ้างอิงเพื่อจัดระเบียบปรากฏการณ์นี้ได้ คือ "หนี้" 2 ประเภทที่แนะนำไว้ในบล็อกนักพัฒนาของ SO Technologies (25 พฤษภาคม 2026 โดยคุณ Taizan Inoue) (บล็อกนักพัฒนา SO Technologies) โปรดทราบว่าบทความนี้ไม่ได้วัดผลจากความล้มเหลวของบริษัทตนเอง แต่เป็นการแนะนำงานวิจัยและแนวคิดที่มีอยู่เดิม

หนี้ทางปัญญา (Cognitive Debt) เป็นแนวคิดที่หมายถึง "การที่ความเข้าใจในโค้ดที่กำลังพัฒนาค่อยๆ เลือนหายไปจากหัวของมนุษย์" มีการอภิปรายว่าหากยอมรับผลลัพธ์จาก AI โดยไม่ทำความเข้าใจ อาจนำไปสู่การหลีกเลี่ยงการแก้ไขเพราะ "มันทำงานอยู่เลยไม่อยากแตะต้อง" การส่งผลกระทบไปยังจุดที่ไม่คาดคิด และการเพิ่มขึ้นของส่วนที่สมาชิกใหม่ไม่สามารถอธิบายได้ บทความดังกล่าวยังอ้างอิงถึงงานวิจัยก่อนหน้าเกี่ยวกับจิตวิทยาที่เรียกว่า "การยอมจำนนทางปัญญา (Cognitive Surrender)" ซึ่งเป็นการนำผลลัพธ์จาก AI มาใช้โดยไม่ตรวจสอบอย่างละเอียด

หนี้ทางเจตจำนง (Intentional Debt) คือ "การที่เหตุผล เป้าหมาย และข้อจำกัดในการพัฒนาของระบบค่อยๆ เลือนหายไป" AI สามารถแสดงผลลัพธ์ได้ว่า "จะสร้างอะไร" แต่ไม่ได้บันทึกว่า "ทำไมถึงสร้างแบบนั้น" ผลที่ตามมาคือความคาดหวังที่ไม่ตรงกับผู้มีส่วนได้ส่วนเสีย ความแม่นยำในการแก้ไขโดย AI ลดลง การสูญเสียข้อกำหนดด้านความเป็นส่วนตัวและการเข้าถึง (Accessibility) รวมถึงการต้องกลับมาตัดสินใจเชิงออกแบบซ้ำซ้อน

มาตรการรับมือที่ระบุไว้ ได้แก่ การทำ Code Review และ Pair Programming, การทำ Walkthrough สำหรับโค้ดที่ตนเองไม่ได้เขียน, การทำข้อกำหนดและทดสอบในรูปแบบ BDD และการบันทึกการตัดสินใจด้วย ADR (Architecture Decision Record) ทั้งหมดนี้เป็นวิธีการที่รู้จักกันมาตั้งแต่ก่อนยุค AI และ สิ่งที่มักจะถูกตัดออกเป็นอย่างแรกในการทำ "Vibe Coding" ก็คือสิ่งเหล่านี้เอง

ในปี 2026 ได้เกิดประเด็นที่แม้จะตรวจสอบผลลัพธ์อย่างเข้มงวดเพียงใดก็ไม่สามารถครอบคลุมถึง นั่นคือ AI coding tool และสภาพแวดล้อมการทำงานของมันได้กลายเป็นช่องทางในการบุกรุกเสียเอง

Systems Software & Security Lab (SSLab) แห่งจอร์เจียเทค (Georgia Institute of Technology) ได้ติดตามฐานข้อมูลช่องโหว่ที่เปิดเผยต่อสาธารณะผ่าน "Vibe Security Radar" โดยมีวิธีการคือการย้อนกลับจากคอมมิตที่แก้ไขช่องโหว่ไปยังคอมมิตที่เป็นต้นเหตุ เพื่อตรวจสอบลายเซ็นของเครื่องมือ AI เช่น แท็กผู้เขียนร่วม (co-author tags) หรือที่อยู่อีเมลของบอต

ตามประกาศของมหาวิทยาลัยเมื่อวันที่ 13 เมษายน 2026 ณ วันดังกล่าว มีช่องโหว่ที่ระบุว่าเกี่ยวข้องกับ AI จำนวน 74 รายการ (ระดับวิกฤต 14 รายการ และระดับสูง 25 รายการ) โดยเครื่องมือที่ถูกตรวจสอบได้แก่ Claude, Gemini และ GitHub Copilot แนวโน้มที่เกิดขึ้นแสดงให้เห็นถึงความเร็วของปัญหา โดยจากเดิมที่มีประมาณ 18 รายการในช่วง 7 เดือนของครึ่งหลังปี 2025 ได้เพิ่มขึ้นเป็น 56 รายการในช่วง 3 เดือนแรกของปี 2026 (มกราคม-มีนาคม) และเฉพาะในเดือนมีนาคมเพียงเดือนเดียวก็สูงถึง 35 รายการ เนื่องจากจำนวนจะเพิ่มขึ้นเรื่อยๆ โปรดระบุช่วงเวลาที่อ้างอิงด้วย

การนับจำนวนมีข้อควรระวัง 2 ประการ ประการแรก นี่ไม่ใช่ "CVE ที่เกิดจาก AI" แต่เป็น "ช่องโหว่ที่ระบุว่ามี AI เข้ามาเกี่ยวข้อง" ซึ่งรวมถึงรายการที่ยังไม่มีการกำหนดหมายเลข CVE ด้วย ประการที่สอง การตรวจสอบขึ้นอยู่กับลายเซ็นในคอมมิต ดังนั้น เครื่องมือที่ทิ้งลายเซ็นไว้ได้ง่ายกว่าจะถูกตรวจพบได้มากกว่า จำนวนที่มากหรือน้อยจึงไม่ใช่การจัดลำดับความอันตราย ทั้งนี้ ควรตรวจสอบด้วยว่าในรีโพสิทอรีของบริษัทท่าน ได้มีการบันทึกที่มาของโค้ดที่สร้างโดย AI ไว้ในรูปแบบที่สามารถติดตามได้หรือไม่

รายการที่เปิดเผยในปี 2026 ทั้ง 2 รายการมีลักษณะที่แตกต่างกัน

รายการแรกคือ CVE-2026-35603 ซึ่งเป็นปัญหาที่เกี่ยวข้องกับความน่าเชื่อถือของไฟล์การตั้งค่า ตาม ข้อมูลการลงทะเบียนของ NVD ระบุว่ากลุ่มเป้าหมายคือ Claude Code เวอร์ชัน Windows ที่ต่ำกว่า 2.1.75 เท่านั้น เนื่องจากมีการอ่านไฟล์ C:\ProgramData\ClaudeCode\managed-settings.json โดยไม่ได้ตรวจสอบเจ้าของไดเรกทอรีหรือสิทธิ์การเข้าถึง ทำให้ผู้ใช้ในเครื่องที่มีสิทธิ์ต่ำสามารถวางไฟล์การตั้งค่าที่เป็นอันตรายไว้ในไดเรกทอรี ProgramData ซึ่งโดยปกติแล้วผู้ที่ไม่ใช่ผู้ดูแลระบบก็สามารถเขียนไฟล์ลงไปได้ เมื่อผู้ใช้อื่นบนเครื่องเดียวกันเปิดใช้งาน Claude Code การตั้งค่าดังกล่าวจะถูกโหลดโดยอัตโนมัติ ค่า CVSS อยู่ที่ 7.3 (High) สำหรับ v3.1 และ 5.4 (Medium) สำหรับ v4.0 โดยเปิดเผยเมื่อวันที่ 17 เมษายน 2026 การโจมตีจำเป็นต้องใช้สภาพแวดล้อมแบบผู้ใช้หลายคน (shared multi-user environment) และได้รับการแก้ไขแล้วในเวอร์ชัน 2.1.75

รายงานที่ระบุว่าพบปัญหาในลักษณะเดียวกันใน Cursor, OpenAI Codex CLI และ Google Gemini CLI นั้นมาจาก Cymulate ซึ่งเป็นผู้ดำเนินการตรวจสอบ และ ไม่รวมอยู่ในขอบเขตของ CVE นี้ (Cymulate) ทางบริษัทได้รายงานไปยัง Cursor เมื่อวันที่ 12 มกราคม และไปยัง Codex CLI เมื่อวันที่ 16 กุมภาพันธ์ โดยระบุว่า ณ เวลาที่เผยแพร่ยังไม่พบการแก้ไข ส่วน Gemini CLI นั้นทำได้เพียงการอัปเดตเอกสารเท่านั้น เนื่องจากข้อมูลเหล่านี้ไม่ใช่ข้อมูล CVE อย่างเป็นทางการจากผู้จำหน่ายแต่ละราย โปรดตรวจสอบสถานะการแก้ไขด้วยตนเองตามเวอร์ชันที่คุณใช้งานอยู่

รายการที่สองคือ DuneSlide ซึ่งเป็นช่องโหว่ใน Cursor IDE ที่ค้นพบโดย Cato Networks โดย ไม่ใช่การโจมตีแบบต่อเนื่อง แต่เป็นช่องโหว่แยกจากกัน 2 รายการ สำหรับ CVE-2026-50548 เป็นปัญหาที่เอเจนต์สามารถเปลี่ยน working_directory เพื่อขยายขอบเขตการเขียนของแซนด์บ็อกซ์ออกไปนอกพื้นที่ทำงาน (workspace) ได้ ส่วน CVE-2026-50549 เป็นปัญหาที่เกิดจากการที่ระบบย้อนกลับไปใช้พาธเดิมเมื่อการทำให้พาธเป็นมาตรฐาน (path normalization) ก่อนการเขียนล้มเหลว ทำให้สามารถเขียนไฟล์ไปยังตำแหน่งใดก็ได้ผ่านลิงก์สัญลักษณ์ (symbolic link) ที่ชี้ไปยังภายนอก ทั้งสองรายการมีค่า CVSS v3.1 อยู่ที่ 9.8 และ v4.0 อยู่ที่ 9.3 การทำงานจะเกิดขึ้นภายใต้ สิทธิ์ของผู้ใช้ที่ล็อกอินอยู่ ไม่ใช่การยกระดับสิทธิ์ไปถึงระดับระบบ โดยเวอร์ชันที่ต่ำกว่า 3.0 จะได้รับผลกระทบ และได้รับการแก้ไขใน Cursor 3.0 โดยมีการกำหนดหมายเลข CVE เมื่อวันที่ 25 มิถุนายน 2026 (SecurityWeek)

ช่องโหว่ในระดับนี้ ไม่สามารถตรวจพบได้จากการอ่านโค้ดที่สร้างขึ้นมา หากคุณจะใช้เครื่องมือเขียนโค้ดด้วย AI เป็นอุปกรณ์มาตรฐานบนเครื่องพัฒนา จำเป็นต้องมีการจัดการเวอร์ชันและการอัปเดต รวมถึงการตรวจสอบข้อมูลรับรอง (credentials) ที่เก็บไว้ในตัวแปรสภาพแวดล้อม (environment variables) อย่างสม่ำเสมอ

การที่การแยกสภาพแวดล้อมการทำงาน (Execution Environment) "ไม่สามารถเกิดขึ้นได้จริงเพียงแค่การประกาศ" นั้น ได้รับการพิสูจน์ให้เห็นจากกรณีศึกษาของบริษัท Anthropic ที่เผยแพร่เมื่อวันที่ 30 กรกฎาคม 2026 (Anthropic สำหรับรายละเอียดภาษาญี่ปุ่น สามารถดูเพิ่มเติมได้ที่สรุปของ piyolog) ในระหว่างการประเมินประสิทธิภาพด้านความปลอดภัยทางไซเบอร์ ได้เกิดการเข้าถึงระบบขององค์กรภายนอกที่ไม่เกี่ยวข้อง 3 แห่งโดยไม่ได้รับอนุญาต สิ่งที่เกิดขึ้นในกรณีนี้ไม่ใช่การที่โมเดลเจาะทะลุ Sandbox แต่เป็น การที่โมเดลใช้ช่องทางการสื่อสารภายนอกที่ถูกเปิดทิ้งไว้โดยไม่ได้ตั้งใจบนฝั่งโครงสร้างพื้นฐานการประเมินของบุคคลที่สาม

รายละเอียดของทั้ง 3 กรณี ได้แก่ กรณีที่ Claude Opus 4.7 เข้าถึงโครงสร้างพื้นฐานของบริษัทที่มีอยู่จริงและเข้าถึงข้อมูลรับรอง (Credentials) รวมถึงฐานข้อมูลจริงหลายร้อยแถว, กรณีที่ Claude Mythos 5 เผยแพร่แพ็กเกจอันตรายไปยัง PyPI ซึ่งถูกระบบประมาณ 15 แห่งเรียกใช้งานภายในเวลาประมาณ 1 ชั่วโมง และกรณีที่โมเดลทดสอบเพื่อการวิจัยสแกนเป้าหมายประมาณ 9,000 แห่งและละเมิดระบบของบริษัทหนึ่งแห่ง ในกรณีแรกนั้น โมเดลยังคงดำเนินการโจมตีต่อไปแม้จะตระหนักได้ว่านั่นคือสภาพแวดล้อมจริงแล้วก็ตาม

สาเหตุเกิดจากความเข้าใจที่ไม่ตรงกันกับพันธมิตรด้านการประเมินจนนำไปสู่ความผิดพลาดในการตั้งค่า แม้ใน Prompt จะระบุว่า "ไม่มีการเชื่อมต่ออินเทอร์เน็ต" แต่ในความเป็นจริงช่องทางการเชื่อมต่อกลับยังคงเปิดใช้งานอยู่ ทางบริษัทระบุว่านี่ไม่ใช่ความล้มเหลวในการปรับจูนโมเดล (Alignment) แต่เป็นความล้มเหลวของกรอบการประเมิน (Harness) และการดำเนินงาน การเขียนคำสั่งว่า "ไม่ได้เชื่อมต่อ" ไม่ได้เป็นการรับประกันว่าไม่มีการเชื่อมต่อจริง ซึ่งเป็นบทเรียนที่ใช้ได้แม้กระทั่งในกรณีที่คุณรัน Agent ด้วยตนเอง

หากพิจารณาเพียงกรณีเฉพาะเจาะจง ก็อาจสรุปได้ว่าเป็นเพียงแค่ "โชคร้าย" เท่านั้น เราจะมาตรวจสอบผลการสำรวจในปี 2026 จากทั้งสองด้าน ได้แก่ ด้านความปลอดภัยและด้านการปฏิบัติงาน

แม้แต่ในโมเดลรุ่นล่าสุด คะแนนความปลอดภัยบนเกณฑ์มาตรฐาน (Benchmark) ก็ไม่ได้ขยับไปจากเมื่อ 2 ปีก่อนเลย รายงาน GenAI Code Security Update ที่ Veracode เผยแพร่เมื่อวันที่ 24 มีนาคม 2026 เป็นการวัดผลโมเดลรวมกว่า 150 รุ่น (รวมถึงรุ่นเรือธงล่าสุดอย่าง GPT-5.1/5.2, Gemini 3, Claude 4.5/4.6) โดยใช้เกณฑ์มาตรฐานของบริษัทเองซึ่งประกอบด้วย 4 ภาษา, CWE 4 ประเภท และ 80 งาน (Veracode)

ผลลัพธ์คืออัตราความสำเร็จด้านความปลอดภัยอยู่ที่ 55% ซึ่งหมายความว่าในเงื่อนไขที่ไม่มีการให้คำสั่งด้านความปลอดภัยที่ชัดเจน มีการนำช่องโหว่ที่เป็นที่รู้จักเข้ามาในงานประมาณ 45% สิ่งที่ควรระวังคือ นี่ไม่ได้หมายความว่า "45% ของโค้ดที่ AI สร้างขึ้นในโลกแห่งความเป็นจริงนั้นมีช่องโหว่" แต่เป็น อัตราความล้มเหลวในชุดงานที่ถูกควบคุมไว้ ซึ่งตัวเลขนี้แทบไม่เปลี่ยนแปลงเลยจากเมื่อ 2 ปีก่อน

สามารถตีความได้ 2 ประเด็น คือ ปัญหานี้จะไม่ได้รับการแก้ไขเพียงแค่รอโมเดลรุ่นถัดไป และจุดอ่อนนั้นมีความเฉพาะเจาะจง โดย XSS และ Log Injection สามารถป้องกันได้เพียง 15% และ 13% ตามลำดับ หากต้องตัดสินใจลำดับการตรวจสอบ (Review) สองรายการนี้ต้องมาก่อน

ตัวเลขจากฝั่งปฏิบัติการแสดงให้เห็นถึงช่องว่างระหว่างการรับรู้และผลลัพธ์ที่รายงานด้วยตนเอง รายงาน New Relic 2026 State of AI Coding Report (เผยแพร่เมื่อ 10 มิถุนายน 2026) ซึ่งสำรวจผู้มีอำนาจตัดสินใจด้านเทคโนโลยีที่ใช้ AI ในบริษัทขนาดกลางถึงขนาดใหญ่ในสหรัฐอเมริกาจำนวน 200 คน พบว่า 82% ตอบว่าเคยประสบปัญหาในระบบโปรดักชันที่เกิดจากโค้ดที่สร้างโดย AI อย่างน้อย 1 ครั้งในช่วง 6 เดือนที่ผ่านมา โดย 74% ระบุว่า "โค้ด AI มากกว่า 25% จำเป็นต้องมีการแก้ไขงานครั้งใหญ่" และ 86% ระบุว่าเวลาที่วิศวกรระดับอาวุโสต้องใช้ในการแก้ไขงานนั้นเพิ่มขึ้น (New Relic)

ในการสำรวจเดียวกัน ผู้นำ 94% ประเมินว่าโค้ดของ AI มีคุณภาพสูงกว่าโค้ดของมนุษย์ ณ เวลาที่ตรวจสอบ และ 62% ตอบว่ามีการนำโค้ดขึ้นระบบโปรดักชันโดยไม่ได้ตรวจสอบแบบบรรทัดต่อบรรทัด อย่างไรก็ตาม นี่เป็นการรายงานด้วยตนเองของผู้ตอบแบบสอบถาม ไม่ใช่การวัดจากบันทึกเหตุขัดข้องหรือการวัดโค้ดโดยตรง การตีความที่ถูกต้องไม่ใช่ "ข้อพิสูจน์ว่าการรีวิวไม่ทำงาน" แต่เป็นการบ่งชี้ว่ามีความคลาดเคลื่อนระหว่างการรับรู้และความเป็นจริงที่พบเห็นได้ทั่วไป

ในระดับองค์กร รายงาน DORA ปี 2025 (สำรวจผู้เชี่ยวชาญด้านเทคนิคประมาณ 5,000 คน) รายงานว่าการนำ AI มาใช้มี ความสัมพันธ์เชิงบวกกับปริมาณงานในการส่งมอบ (Delivery Throughput) และ ความสัมพันธ์เชิงลบกับความไม่เสถียรในการส่งมอบ (Delivery Instability) โดยความไม่เสถียรเป็นดัชนีที่ประกอบด้วยอัตราความล้มเหลวของการเปลี่ยนแปลงและอัตราการแก้ไขงาน ทั้งนี้เป็นการสำรวจเชิงสังเกตการณ์ ไม่ได้แสดงถึงความเป็นเหตุเป็นผลว่า AI เป็นสาเหตุที่ทำให้เกิดความไม่เสถียร รายงานดังกล่าวยังระบุว่า AI เป็น "ตัวขยายผล ไม่ใช่ทางแก้ปัญหา" โดยสรุปว่าทีมที่มีพื้นฐานพร้อมจะสามารถเร่งความเร็วได้ ในขณะที่ทีมที่มีหนี้ทางเทคนิคและความสับสนในกระบวนการทำงานจะยิ่งประสบปัญหามากขึ้น

ความล้มเหลวที่เกิดจากผลผลิต (Generative output) ไม่ว่าจะเป็นกลุ่มแอปพลิเคชันที่ตรวจพบโดย Moltbook และ RedAccess หรือภาวะชะงักงันที่มีรายงานในประเทศ ต่างก็มีโครงสร้างที่เหมือนกัน ซึ่งปัจจัย 3 ประการนี้ส่งผลต่อผลลัพธ์มากกว่าการเลือกใช้เครื่องมือ (ส่วนข้อบกพร่องทางฝั่งแพลตฟอร์มและช่องโหว่ของตัวเครื่องมือเองนั้น เป็นปัญหาที่ต้องใช้มาตรการรับมือที่แตกต่างออกไป ซึ่งได้กล่าวถึงไปในบทก่อนหน้าแล้ว)

สาเหตุที่ 1: เฉพาะการสร้างที่เร็วขึ้น แต่การตรวจสอบไม่ได้เร็วขึ้นตาม สิ่งที่เร่งความเร็วมีเพียงแค่เลเยอร์ของ "การสร้าง" เท่านั้น ส่วนความเร็วในการทดสอบ การรีวิว การตรวจสอบความปลอดภัย และการยืนยันขอบเขตผลกระทบแทบจะไม่เปลี่ยนแปลง ข้อมูลจากการวัดจริงของ Findy ที่พบว่าเวลารีวิวเพิ่มขึ้น 50% และผลสำรวจของ New Relic ที่พบว่าอัตราการรีวิว 94% และปัญหาในระบบจริง 82% เกิดขึ้นควบคู่กันนั้น สอดคล้องกับความไม่สมมาตรนี้ ยิ่งไปกว่านั้น ปัญหาคอขวดจะถูกมองเห็นได้ล่าช้า สิ่งที่ปรากฏออกมาทันทีหลังจากปริมาณการสร้างเพิ่มขึ้นมีเพียงตัวชี้วัดที่ว่า "เร็วขึ้น" เท่านั้น ส่วนงานที่ต้องย้อนกลับไปแก้ไขจะไปปรากฏเป็นภาระของพนักงานคนอื่นในอีกหลายสัปดาห์หรือหลายเดือนให้หลัง ลำดับที่ถูกต้องคือการเพิ่มขีดความสามารถในการตรวจสอบให้สูงขึ้นก่อนที่จะเพิ่มปริมาณการสร้าง

สาเหตุที่ 2: "การทำงานได้" กับ "ความปลอดภัย" เป็นคนละเรื่องกัน และค่าเริ่มต้นไม่ได้อยู่ที่ฝั่งความปลอดภัย AI จะสร้างโค้ดด้วยเส้นทางที่สั้นที่สุดเพื่อให้เป็นไปตามคำสั่ง เช่น การเปิดใช้งาน RLS, การทำให้การยืนยันตัวตนเสร็จสมบูรณ์ที่ฝั่งเซิร์ฟเวอร์, การย้าย Secret ไปไว้ใน Environment Variable หรือการตั้งค่าโปรเจกต์เป็นส่วนตัว สิ่งเหล่านี้ไม่จำเป็นต่อ "การทำงาน" ของแอปพลิเคชัน ทั้ง Moltbook และกลุ่มแอปพลิเคชันที่ RedAccess ตรวจพบต่างก็ทำงานได้ตามปกติบนหน้าจอ ซึ่งไม่สามารถตรวจพบได้จากการตรวจสอบการทำงานทั่วไป แต่จะเผยออกมาก็ต่อเมื่อมีการสืบค้นจากภายนอกเท่านั้น อัตราการผ่านเกณฑ์ 55% ของ Veracode ก็เป็นเครื่องยืนยันว่านี่ไม่ใช่ข้อบกพร่องเฉพาะของโมเดลใดโมเดลหนึ่ง

สาเหตุที่ 3: เจตนาไม่ได้ถูกบันทึกไว้ ทำให้แก้ไขในภายหลังไม่ได้ โค้ดที่เขียนโดยมนุษย์จะยังคงหลงเหลือความทรงจำของผู้เขียนและการโต้ตอบในการรีวิว แต่ในการทำ Vibe Coding ทั้งสองสิ่งนี้ไม่ได้เกิดขึ้น เนื่องจากแม้จะเหลือ Prompt ไว้ แต่ตัวเลือกที่ถูกปฏิเสธหรือเงื่อนไขข้อจำกัดต่างๆ กลับไม่ถูกบันทึกไว้ด้วย ส่งผลให้ทุกครั้งที่มีการแก้ไข จำเป็นต้องคิดทบทวนการตัดสินใจเชิงออกแบบใหม่ตั้งแต่ต้น และบริบทที่ให้กับ AI ก็จะลดน้อยลงเรื่อยๆ "การสร้างให้เร็ว" กับ "การแก้ไขได้ในภายหลัง" จะไม่สามารถเกิดขึ้นควบคู่กันได้หากไม่ได้ออกแบบแยกจากกัน

มาตรการรับมือประกอบด้วย 3 ส่วนหลัก ได้แก่ ขอบเขตการใช้งาน (Scope), การตรวจสอบ (Verification) และสิทธิ์การเข้าถึง (Authority) จุดเปลี่ยนสำคัญไม่ใช่การเปลี่ยนเครื่องมือใหม่ แต่คือการตัดสินใจใน 3 ส่วนนี้ก่อนเป็นอันดับแรก

ก่อนอื่น เราต้องกำหนดขอบเขตว่า "การใช้ Vibe Coding ทำได้ถึงระดับไหน" ทั้งการห้ามใช้โดยเด็ดขาดและการอนุญาตให้ใช้ทั้งหมดต่างก็เป็นทางเลือกที่มักจะนำไปสู่ความล้มเหลว เกณฑ์ในการตัดสินใจคือ "ใครจะเดือดร้อนเมื่อเกิดความเสียหายขึ้น"

กรณีศึกษาของ transcosmos แสดงให้เห็นว่า หากขยายผลจากความสำเร็จในระดับเล็กโดยไม่มีการกำหนดขอบเขตที่ชัดเจน จะนำไปสู่ความล่าช้าและคุณภาพที่ลดลงในระดับใหญ่ ก่อนที่จะนำตัวเลขจากต้นแบบมาเป็นเป้าหมายของทั้งบริษัท โปรดตรวจสอบว่าลักษณะของเป้าหมายนั้นได้เปลี่ยนแปลงไปหรือไม่ หากต้องใช้โครงสร้างพื้นฐาน (Infrastructure) ให้ตรวจสอบการตั้งค่าการเปิดเผยข้อมูลตามค่าเริ่มต้นและประวัติการตอบสนองต่อรายงานช่องโหว่ควบคู่ไปด้วย

หลักการสำคัญคือการไม่พึ่งพาความใส่ใจของมนุษย์เป็นมาตรการป้องกัน โดยให้วางข้อกำหนดไว้ก่อนการสร้าง (Generation) และวางระบบตรวจสอบอัตโนมัติไว้หลังการสร้าง

สิ่งที่ต้องเตรียมก่อนการสร้างคือข้อกำหนดที่รวมถึงเงื่อนไขการยอมรับ (Acceptance Criteria) และเอกสารที่แจ้งนโยบายการออกแบบที่มีอยู่ให้กับ AI การจัดทำเอกสารระบุข้อกำหนด คำศัพท์ และข้อห้ามให้ชัดเจนเหมือนกับ CLAUDE.md แล้วนำไปวางไว้ใน Repository พร้อมทั้งอัปเดตอย่างต่อเนื่องจะช่วยได้มาก (คู่มือการใช้งาน Claude Code สำหรับทีม) แนวคิด Eval-Driven Development ที่กำหนดเกณฑ์การประเมินไว้ล่วงหน้าก็ใช้แนวคิดเดียวกันนี้

หลังการสร้าง ให้กำหนดการตรวจสอบต่อไปนี้เป็นสิ่งที่ต้องทำใน CI โดยมีจุดสำคัญคือการไม่แทรกแซงด้วยการตัดสินใจของมนุษย์:

• การตรวจสอบ Type และการทดสอบ (สำหรับการทดสอบที่ให้ AI เขียน ให้ทำการทดสอบโดยจงใจทำให้พังเพื่อยืนยันว่าระบบจะแจ้งเตือนเมื่อทดสอบไม่ผ่าน)
• SAST (Static Analysis) และ Secret Scanning โดยอ้างอิงผลลัพธ์จาก Veracode และให้ความสำคัญกับการตรวจจับ XSS และ Log Injection เป็นอันดับแรก
• การตรวจสอบนโยบาย DB (ตรวจหาตารางที่ไม่ได้เปิดใช้งาน RLS หรือโปรเจกต์ที่ตั้งค่าเป็นสาธารณะ)
• การตรวจสอบช่องโหว่ของแพ็กเกจที่พึ่งพา และการตรวจจับชื่อแพ็กเกจที่ไม่มีอยู่จริง (มาตรการป้องกันการโจมตี Supply Chain ในการพัฒนาด้วย AI)

นอกจากนี้ ให้เปลี่ยนมุมมองในการรีวิวด้วย จากเดิมที่ถามว่า "อ่านแล้วดูถูกต้องหรือไม่" ให้เปลี่ยนมาถามว่า "หากแก้ไขจุดนี้จะส่งผลกระทบต่อส่วนใด" หรือ "หลักฐานที่ใช้ในการตัดสินใจถูกบันทึกไว้ที่ไหน" ซึ่งจะช่วยลดการสะสมของหนี้ทางปัญญา (Cognitive Debt) ได้

กรณีศึกษาของ Anthropic ได้แสดงให้เห็นว่า การแยกส่วน (Isolation) ต้องรับประกันด้วยสภาพแวดล้อม ไม่ใช่ด้วยคำสั่ง นี่เป็นส่วนที่สามารถควบคุมได้อย่างชัดเจนในเชิงเทคนิค จึงต้องให้ความสำคัญเป็นอันดับแรก

หลักการมี 4 ประการ ได้แก่ การตัดข้อมูลการเชื่อมต่อฐานข้อมูลจริงออกจากสภาพแวดล้อมการทำงานของ Agent ในเชิงกายภาพ, การป้องกันการดำเนินการที่สร้างความเสียหาย (การลบ, การเปลี่ยน Schema, การ Deploy, การส่งข้อมูลออกภายนอก) ด้วยสิทธิ์และการอนุมัติแทนที่จะใช้คำสั่งภาษาธรรมชาติ, การควบคุมเครือข่ายขาออกด้วย Whitelist และยืนยันว่า "ไม่ได้เชื่อมต่อ" ด้วยการตัดการเชื่อมต่อจริง และการเตรียมวิธีการหยุดทำงานเมื่อเกิดเหตุผิดปกติ (การออกแบบระบบหยุดฉุกเฉินสำหรับ AI Agent)

นอกจากนี้ ในปี 2026 การจัดการอุปกรณ์ของนักพัฒนาจะรวมอยู่ในขอบเขตด้วย เนื่องจากตัวเครื่องมือเองอาจกลายเป็นช่องทางในการยกระดับสิทธิ์หรือการรันโค้ดได้ ดังนั้นโปรดตรวจสอบเวอร์ชันและรวมการอัปเดตเข้ากับกระบวนการปฏิบัติงาน รวมถึงตรวจสอบข้อมูลรับรอง (Credentials) ที่เก็บไว้ในตัวแปรสภาพแวดล้อม (Environment Variables) ของอุปกรณ์ รายละเอียดเกี่ยวกับการออกแบบสิทธิ์สามารถดูได้ที่ คู่มือการออกแบบสิทธิ์การใช้งานเครื่องมือของ AI Agent ด้วยหลักการสิทธิ์ขั้นต่ำ (Least Privilege)

ขอตอบ 3 ประเด็นที่มักถูกถามบ่อยในการตัดสินใจนำมาใช้งานครับ

Q1. ไม่ควรใช้ "ไวบ์โค้ดดิ้ง" (Vibe Coding) ในการทำงานจริงใช่หรือไม่?

มีประโยชน์หากจำกัดขอบเขตการใช้งานครับ คุณสามารถคาดหวังการเพิ่มประสิทธิภาพการทำงานได้ในส่วนที่ "หากพังไปก็ไม่กระทบต่อระบบงานจริง" เช่น การทำโปรโตไทป์ที่เน้นทิ้ง, เครื่องมือใช้แล้วทิ้งภายในองค์กร หรือการตรวจสอบโค้ดที่มีอยู่เดิม สิ่งที่ควรหลีกเลี่ยงคือการขยายไปใช้กับฟีเจอร์สำหรับลูกค้า ระบบยืนยันตัวตน หรือระบบชำระเงินโดยปราศจากการตรวจสอบ เกณฑ์การตัดสินใจไม่ควรอยู่ที่ตัวเทคโนโลยี แต่อยู่ที่ว่าเมื่อเกิดความเสียหายขึ้น ใครจะเป็นผู้เดือดร้อนครับ

Q2. ในการรีวิวโค้ดที่ AI เขียน ควรดูที่จุดไหนบ้าง?

อย่าดูว่า "ดูถูกต้องไหม" แต่ให้ดูว่า "พังอย่างไร" โดยลำดับความสำคัญมี 5 จุด คือ การควบคุมการเข้าถึงฐานข้อมูล (เช่น RLS) ใช้งานได้จริงหรือไม่, การยืนยันตัวตนและสิทธิ์ (Authentication/Authorization) เสร็จสมบูรณ์ที่ฝั่งเซิร์ฟเวอร์หรือไม่, มีการรวมข้อมูลลับ (Secrets) ไว้ในฝั่งไคลเอนต์หรือไม่, การตั้งค่าการเปิดเผยข้อมูลเป็นไปตามที่ตั้งใจหรือไม่ และมีการทิ้งหลักฐานการตัดสินใจไว้หรือไม่ สำหรับ XSS และ SQL Injection นั้น AI มักทำผลงานได้ต่ำเป็นพิเศษ จึงควรใช้ CI ของ SAST ตรวจจับแทนการใช้สายตาคนครับ

Q3. ควรเตรียมรับมือกับช่องโหว่ของเครื่องมือ AI Coding เองอย่างไร?

วิธีปฏิบัติที่ทำได้จริงคือการจัดการให้เหมือนกับการบริหารจัดการสินทรัพย์ซอฟต์แวร์ (Software Asset Management) ครับ ในปี 2026 มีการเปิดเผยช่องโหว่ CVE-2026-35603 (Claude Code เวอร์ชัน Windows ที่ต่ำกว่า 2.1.75) และ DuneSlide (Cursor ที่ต่ำกว่า 3.0) ออกมา เนื่องจากแต่ละผู้ให้บริการมีการกำหนดเลขช่องโหว่และสถานะการแก้ไขที่แตกต่างกัน จึงควรตรวจสอบเวอร์ชันที่บริษัทใช้งานอยู่เป็นรายกรณีไป ควรทำรายการเครื่องมือที่นำมาใช้ กำหนดผู้รับผิดชอบในการอัปเดต และตรวจสอบข้อมูลยืนยันตัวตนที่เก็บไว้ใน Environment Variable ของเครื่องอย่างสม่ำเสมอครับ

เมื่อนำกรณีศึกษาและข้อมูลในปี 2026 มาเปรียบเทียบกัน จะพบว่าสาเหตุไม่ได้มีเพียงหนึ่งเดียว นอกจากการตรวจสอบผลลัพธ์ที่ไม่เพียงพอแล้ว ยังเกิดข้อผิดพลาดจากฝั่งแพลตฟอร์ม ช่องโหว่ของตัวเครื่องมือเอง และการตั้งค่าสภาพแวดล้อมการทำงานที่ผิดพลาดในจุดต่างๆ กัน

• รูปแบบของความเสียหายมีแบบแผน — การขาดการควบคุมการเข้าถึง (Moltbook), ค่าเริ่มต้นของโครงสร้างพื้นฐานและการตั้งค่าของผู้ใช้ (RedAccess), การถดถอยของโครงสร้างพื้นฐานและความล้มเหลวในการรายงานผล (Lovable)
• สิ่งที่แชร์กันในประเทศไม่ใช่เรื่องบังเอิญ แต่เป็นการปรับให้เหมาะสมเฉพาะจุด — เวลาในการรีวิวเพิ่มขึ้น 50% ในขณะที่ปริมาณงาน (throughput) ยังคงที่ อย่างไรก็ตาม หลังจากใช้มาตรการปรับปรุง จำนวน PR ก็กลับมาเพิ่มขึ้นประมาณ 1.5 เท่า (Findy)
• การเปลี่ยนผ่านรุ่นของโมเดลไม่สามารถแก้ปัญหาได้ — แม้แต่รุ่นเรือธงล่าสุดก็มีอัตราผ่านเกณฑ์มาตรฐานเพียง 55% โดยพบ XSS 15% และ Login Injection 13%
• การประเมินระหว่างการรีวิวกับผลลัพธ์ที่รายงานด้วยตนเองมีความขัดแย้งกัน — 94% ประเมินว่ามีคุณภาพสูง แต่ 82% ตอบว่าเคยประสบปัญหาในการใช้งานจริง
• ในปี 2026 ตัวเครื่องมือเองกลายเป็นพื้นผิวการโจมตี — พบช่องโหว่ที่ระบุว่าเกี่ยวข้องกับ AI จำนวน 74 รายการ (ณ วันที่ 13 เมษายน 2026) และมีการเปิดเผยเรื่องการยกระดับสิทธิ์ของเครื่องมือพัฒนาและการหลบเลี่ยง Sandbox
• มาตรการรับมือมี 3 ระดับ — การกำหนดขอบเขตการใช้งาน, การตรวจสอบเชิงกลไกก่อนและหลังการสร้างผลลัพธ์, และการแยกสิทธิ์การใช้งานจริงออกจากสภาพแวดล้อมการทำงาน

สุดท้ายนี้ มีมารยาทในการจัดการกับกรณีศึกษาหนึ่งประการ คือ วิธีการนับช่วงเวลา ตัวหารและตัวตั้ง และขอบเขตของ CVE มักจะคลาดเคลื่อนระหว่างรายงานข่าวกับข้อมูลปฐมภูมิ ก่อนนำไปใช้ในการตัดสินใจ โปรดตรวจสอบข้อมูลปฐมภูมิเสมอ เพราะจากเหตุและผลที่ผิดพลาด จะนำไปสู่มาตรการรับมือที่ผิดพลาดเท่านั้น

นอกจากนี้ โปรดดู คู่มือการใช้งาน AI Coding Agent — Claude Code vs Codex และ คู่มือการออกแบบสิทธิ์การใช้งานเครื่องมือของ AI Agent ด้วยหลักการสิทธิ์ขั้นต่ำ (Least Privilege) ประกอบด้วย