Amazon สั่งให้ใช้ AI เขียนโค้ด ออเดอร์หาย 6.3 ล้าน: วิกฤต Vibe Coding ที่ทุกคนต้องรู้
Amazon สั่งให้วิศวกร 80% ใช้ AI coding tool ทุกสัปดาห์ ผลลัพธ์คือออเดอร์หายไป 6.3 ล้านรายการภายในวันเดียว 5 มีนาคม 2026 ระบบ e-commerce ของ Amazon ล่มนาน 5-6 ชั่วโมง ลูกค้าสั่งของไม่ได้ ราคาสินค้าแสดงผิด เข้าดูประวัติออเดอร์ไม่ได้ Downdetector รายงานผู้ใช้ที่ได้รับผลกระทบกว่า 22,000 คน โดย 48% เจอปัญหาตอน checkout ยอดสั่งซื้อทั่ว North America ร่วงลง 99% สามวันก่อนหน้านั้น 2 มีนาคม ระบบเดียวกันเกิดปัญหาจาก AI-generated code ทำให้ออเดอร์หาย 120,000 รายการ และเกิด error บนเว็บไซต์ 1.6 ล้านครั้ง
เมื่อ Amazon ผลักดันให้วิศวกรกว่า 80% ใช้เครื่องมือ AI เขียนโค้ดทุกสัปดาห์ ทว่าผลลัพธ์ที่ตามมาคือยอดคำสั่งซื้อสูญหายไปกว่า 6.3 ล้านรายการในวันเดียว
วันที่ 5 มีนาคม 2026 ระบบ e-commerce ของ Amazon ล่มยาวนานถึง 5 ถึง 6 ชั่วโมง ลูกค้าไม่สามารถสั่งซื้อสินค้าได้ ราคาสินค้าแสดงผลผิดพลาด และไม่สามารถเปิดดูประวัติคำสั่งซื้อได้ ข้อมูลจาก Downdetector ระบุว่ามีผู้ใช้งานที่ได้รับผลกระทบกว่า 22,000 คน โดย 48% ติดปัญหาในขั้นตอนชำระเงิน ส่งผลให้ยอดสั่งซื้อทั่วภูมิภาคอเมริกาเหนือลดฮวบลงถึง 99%
ย้อนกลับไปเพียง 3 วันก่อนหน้านั้น ในวันที่ 2 มีนาคม ระบบเดียวกันนี้ก็เพิ่งสะดุดเพราะโค้ดที่สร้างโดย AI จนทำให้ออเดอร์สูญหายไป 120,000 รายการ และเกิดข้อผิดพลาดบนเว็บไซต์กว่า 1.6 ล้านครั้ง
ยิ่งไปกว่านั้น ในเดือนธันวาคม 2025 Kiro ซึ่งเป็นเครื่องมือ AI Coding ภายในของ Amazon เอง ได้ตัดสินใจสั่งลบสภาพแวดล้อมระบบเดิมแล้วสร้างใหม่ จนส่งผลให้ AWS ล่มยาวนานถึง 13 ชั่วโมง
นี่ไม่ใช่เหตุการณ์ที่เกิดกับสตาร์ตอัปหน้าใหม่ แต่เกิดขึ้นกับ Amazon องค์กรเทคโนโลยีชั้นนำที่มีทีมวิศวกรระดับโลกหลายหมื่นคน และเป็นบริษัทที่ออกนโยบายผลักดันให้วิศวกรกว่า 80% ต้องใช้เครื่องมือ AI เขียนโค้ดเป็นประจำทุกสัปดาห์
Vibe Coding คืออะไร และทำไมจึงกลายเป็นดาบสองคม
Vibe Coding คือแนวทางการพัฒนาโปรแกรมที่ให้นักพัฒนาสื่อสารสิ่งที่ต้องการกับ AI เพื่อให้โมเดลสร้างชุดโค้ดขึ้นมา แล้วนำไปรันใช้งานต่อทันที โดย Andrej Karpathy อดีตผู้อำนวยการฝ่าย AI ของ Tesla เป็นผู้ริเริ่มบัญญัติคำนี้
ทว่าปัญหาเริ่มต้นขึ้นเมื่อผู้พัฒนาจำนวนมากนำโค้ดจาก AI ไปใช้งานโดยไม่ได้ทำความเข้าใจกลไกการทำงานอย่างแท้จริง รายงานจาก Stack Overflow เผยว่านักพัฒนาระดับ Junior กว่า 40% นำโค้ดที่ AI สร้างขึ้นไปขึ้นระบบจริงโดยไม่ได้เข้าใจการทำงานทั้งหมด และ 63% ของนักพัฒนาเคยต้องเสียเวลาดีบักโค้ดจาก AI นานกว่าการลงมือเขียนเองตั้งแต่ต้น
หลายคนอาจมองว่าเป็นเพียงปัญหาของมือใหม่ แต่กรณีของ Amazon ได้พิสูจน์ให้เห็นแล้วว่า แม้แต่องค์กรที่มีระบบตรวจสอบซอฟต์แวร์ระดับโลก ก็ยังเกิดความผิดพลาดครั้งใหญ่ได้เช่นกัน
ตัวเลขที่น่ากังวล: โค้ดจาก AI กับช่องโหว่ด้านความปลอดภัย
ข้อมูลจากงานวิจัยหลายสำนักสะท้อนภาพไปในทิศทางเดียวกันอย่างชัดเจน:
- โค้ดจาก AI เสี่ยงพบช่องโหว่มากกว่าโค้ดที่คนเขียนเองถึง 2.74 เท่า: ข้อมูลจาก Veracode ระบุว่า 45 ถึง 48% ของโค้ดที่ AI สร้างขึ้นมีช่องโหว่ด้านความปลอดภัย และ 68% ของโปรเจกต์ที่พึ่งพา AI เขียนโค้ดพบช่องโหว่ระดับร้ายแรงอย่างน้อย 1 จุด โดยมีค่าเฉลี่ยอยู่ที่ 4.2 จุดต่อโปรเจกต์
- 87% ของ Pull Requests จาก AI Coding Agents มีการนำเข้าช่องโหว่ใหม่: ข้อมูลจาก Help Net Security ชี้ว่าเครื่องมือยอดนิยม ไม่ว่าจะเป็น Claude Code, OpenAI Codex หรือ Google Gemini ต่างพบปัญหาในลักษณะเดียวกัน โดยช่องโหว่ที่พบบ่อยที่สุดได้แก่ SQL Injection (31%), Cross-Site Scripting (27%), Broken Authentication (24%) และ Sensitive Data Exposure (22%)
- 1 ใน 5 ของเหตุการณ์ถูกเจาะระบบมีต้นตอมาจากโค้ด AI: รายงานของ IBM X-Force ระบุว่าการโจมตีผ่านแอปพลิเคชันที่เปิดสู่สาธารณะเพิ่มขึ้น 44% และ 77% ขององค์กรเคยเผชิญกับเหตุการณ์ความปลอดภัยที่เกี่ยวข้องกับ AI โดยสร้างมูลค่าความเสียหายเฉลี่ยสูงถึง 4.88 ล้านดอลลาร์ต่อครั้ง
นอกจากนี้ ข้อผิดพลาดจากการตั้งค่าคอนฟิกในโค้ด AI ยังพบได้บ่อยกว่าโค้ดที่คนเขียนเองถึง 75% และเมื่อทดสอบโมเดล AI ในการป้องกันปัญหา Cross-Site Scripting พบอัตราความล้มเหลวสูงถึง 86%
ชุมชนโอเพนซอร์สตอบโต้: เมื่อ Gentoo และ NetBSD แบนโค้ด AI
ชุมชน Open Source เริ่มตั้งกำแพงรับมือกับโค้ดจาก AI อย่างจริงจัง:
- Gentoo Linux: มีมติแบนโค้ดที่สร้างจาก AI ตั้งแต่เดือนเมษายน 2024 โดยสภาของ Gentoo ลงมติเป็นเอกฉันท์ 6 ต่อ 0 เสียง ห้ามนำโค้ดที่สร้างจากเครื่องมือ NLP AI ทุกรูปแบบเข้ามาในระบบ เนื่องจากกังวลเรื่องลิขสิทธิ์ คุณภาพ และจริยธรรม และในเดือนกุมภาพันธ์ 2026 Gentoo ได้ย้ายคลังโค้ดออกจาก GitHub ไปยัง Codeberg เพื่อเลี่ยงการถูกผลักดันให้ใช้งาน Copilot
- NetBSD: กำหนดสถานะโค้ดจาก AI ให้เป็น "โค้ดที่ต้องสงสัยว่ามีมลทิน" (Presumed to be tainted code) หากต้องการนำเข้าสู่ระบบ จะต้องได้รับความยินยอมเป็นลายลักษณ์อักษรจากทีมผู้พัฒนาหลัก และต้องผ่านการตรวจสอบความปลอดภัยอย่างละเอียด เนื่องจากโมเดลภาษาขนาดใหญ่ผ่านการเรียนรู้จากซอร์สโค้ดมหาศาลบนอินเทอร์เน็ตที่อยู่ภายใต้สัญญาอนุญาตหลากหลาย การนำผลลัพธ์ที่ AI สังเคราะห์ขึ้นมาใช้งาน จึงเสี่ยงต่อการละเมิดลิขสิทธิ์โดยไม่รู้ตัว
Kate Holterhoff นักวิเคราะห์จาก RedMonk ให้คำนิยามปรากฏการณ์นี้ว่า "AI Slopageddon" เมื่อผู้ดูแลโปรเจกต์โอเพนซอร์สต้องแบกรับภาระหนักจากการหลั่งไหลของโค้ดคุณภาพต่ำที่สร้างโดย AI
บทเรียนจากรายงาน DORA ของ Google
Google เผยแพร่รายงาน DORA (DevOps Research and Assessment) เป็นประจำทุกปี ซึ่งถือเป็นงานวิจัยอ้างอิงสำคัญของวงการวิศวกรรมซอฟต์แวร์
รายงานฉบับปี 2025 พบว่า แม้ AI จะช่วยเพิ่มคุณภาพของโค้ดได้ 3.4% และเพิ่มคุณภาพของเอกสารกำกับระบบได้ 7.5% แต่ในทางกลับกัน การพึ่งพา AI มากเกินไปกลับทำให้ความเสถียรของการส่งมอบซอฟต์แวร์ลดลง ส่งผลให้เกิดงานแก้ไขซ้ำซ้อน และอัตราการ deploy ล้มเหลวเพิ่มสูงขึ้น
ข้อมูลที่น่าจับตาที่สุดคือเรื่องความไว้วางใจ มีนักพัฒนาเพียง 3% เท่านั้นที่ระบุว่าตนมีความเชื่อมั่นระดับสูงต่อผลลัพธ์จาก AI ในขณะที่ 30% ระบุว่าแทบไม่ให้ความไว้วางใจเลย
ข้อค้นพบสำคัญจากทีม DORA คือ กุญแจสำคัญอยู่ที่ Platform Engineering หากองค์กรมีโครงสร้างแพลตฟอร์มภายในที่แข็งแกร่งและมีคู่มือคุณภาพสูง AI จะสามารถสร้างโค้ดที่มีประสิทธิภาพขึ้นตามไปด้วย เพราะปัญหาไม่ได้เกิดจากตัว AI เพียงอย่างเดียว แต่ขึ้นอยู่กับบริบทและข้อมูลที่เราป้อนให้มัน
มาตรการรับมือของ Amazon
ภายหลังเหตุการณ์ความเสียหาย Amazon ได้ประกาศมาตรการ 90-day safety reset สำหรับระบบวิกฤต 335 ระบบ โดยกำหนดให้ทุกการเปลี่ยนแปลงโค้ดต้องผ่านการตรวจทานจากวิศวกรอย่างน้อย 2 คนก่อนนำขึ้นระบบจริง พร้อมทั้งกำหนดขั้นตอนการอนุมัติและเอกสารทางการที่รัดกุม รวมถึงเพิ่มระบบการตรวจสอบอัตโนมัติที่เข้มข้นขึ้น
แม้ Amazon จะชี้แจงว่าปัญหาเกิดจาก "ความผิดพลาดของผู้ใช้งาน ไม่ใช่ความผิดพลาดของ AI" แต่ก็ยอมรับอย่างตรงไปตรงมาว่าเริ่มพบแนวโน้มของอุบัติเหตุในระบบเพิ่มขึ้นตั้งแต่ช่วงไตรมาสที่ 3 ของปี 2025 และการเปลี่ยนแปลงโค้ดที่เกิดจากการพึ่งพา Gen-AI มักสร้างผลกระทบเป็นวงกว้างในระดับรุนแรง
ข้อคิดสำคัญสำหรับนักพัฒนา
ประเด็นสำคัญจึงไม่ได้อยู่ที่ว่าเราควรใช้ AI หรือไม่ แต่อยู่ที่ว่าเราจะควบคุมการใช้งานอย่างไรให้ปลอดภัยและมีคุณภาพ:
- อย่า Deploy โค้ดที่ตนเองไม่เข้าใจ: หาก AI สร้างโค้ดขึ้นมาแล้วคุณไม่เข้าใจการทำงานทุกบรรทัด อย่าเพิ่งนำขึ้นระบบจริงเป็นอันขาด นี่คือกฎเหล็กข้อแรกที่ไม่ควรมีข้อยกเว้น
- ตรวจสอบความปลอดภัยเชิงลึกเสมอ: ช่องโหว่ยอดฮิตจาก AI เช่น SQL Injection, XSS, การเผลอฝัง API Key ลงในโค้ด หรือลอจิกการยืนยันตัวตนที่หลุดไปอยู่ฝั่ง Client เพียงแค่เรารู้จุดเสี่ยงและตรวจทานให้รอบคอบ ก็สามารถตัดปัญหาไปได้มากกว่าครึ่ง
- AI เหมาะกับงานพื้นฐาน ไม่ใช่การออกแบบสถาปัตยกรรม: ใช้ AI ในการสร้าง CRUD, ส่วนประกอบ UI หรือฟังก์ชัน Utility ได้อย่างคล่องตัว แต่สำหรับการออกแบบสถาปัตยกรรมระบบ การจัดการ Error Handling ที่ซับซ้อน และลอจิกความปลอดภัย ยังคงต้องการความเชี่ยวชาญจากมนุษย์เป็นหลัก
- กระบวนการ Code Review ทรงคุณค่ากว่าที่เคย: Amazon มีวิศวกรระดับแนวหน้าและมีระบบตรวจทานที่เข้มงวด แต่ก็ยังพลาดได้ เนื่องจากปริมาณโค้ดจาก AI ไหลเข้ามาเร็วกว่ากำลังคนที่ตรวจทาน หากทีมของคุณไม่มีระบบ Review ที่มีคุณภาพ การเร่งใช้ AI อาจกลายเป็นการสะสมหนี้ทางเทคนิคโดยไม่รู้ตัว
Amazon ต้องแลกบทเรียนครั้งนี้ด้วยยอดคำสั่งซื้อที่หายไปกว่า 6.3 ล้านรายการ และคุณไม่จำเป็นต้องปล่อยให้ความผิดพลาดแบบเดียวกันเกิดขึ้นกับโปรเจกต์ของคุณ
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
ChatGPT Work ฉบับเข้าใจง่าย มอบงานให้ AI ทำจนจบ ตั้งแต่งานแรกจนถึงงานอัตโนมัติ พร้อม workflow ใช้ได้จริง 8 แบบ
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
Claude Cowork · The Business Playbook

ฉบับภาษาไทย 15 บท เรียนรู้ผ่านโปรเจกต์จำลองต่อเนื่องทั้งเล่ม ตั้งแต่ตั้งค่า Workspace จัดการไฟล์ เชื่อมแอป ตั้งระบบอัตโนมัติ จนถึงสร้าง Plugin


