เอเจนต์ Antigravity ของ Google ลบทั้งไดรฟ์ D ของผมไปแล้ว

• มีรายงานบน Reddit ว่า ระหว่างใช้งาน Turbo Mode ของ Antigravity เอเจนต์ AI ได้ทำงานแล้ว ลบทั้งไดรฟ์ D ทั้งหมด
• ผู้ใช้เพียงขอให้ช่วยจัดการโฟลเดอร์ .vite บางจุดเท่านั้น แต่ในล็อกภายในของเอเจนต์พบ บันทึกการรันคำสั่งลบรากของไดรฟ์ ในรูปแบบ rmdir /s /q d:\
• เมื่อผู้ใช้ถามว่า “ฉันเคยอนุญาตให้ลบทั้งไดรฟ์ D หรือเปล่า?” เอเจนต์ก็ทิ้ง บทสนทนาที่วิเคราะห์ตัวเองซ้ำไปซ้ำมาอย่างสับสน ไว้ครบถ้วน ทั้งเรื่อง permission การ parse path และความเป็นไปได้ที่คำสั่งจะทำงานผิดพลาด

งานจริงที่ผู้ใช้ร้องขอ

• ลบโฟลเดอร์แคช .vite ในพาธที่เอเจนต์แนะนำ
  ตัวอย่าง: d:\...\node_modules\.vite
• ผู้ใช้บอกว่า “ฉันไม่เข้าใจข้อ 3 ช่วยทำให้หน่อย”
• คำขอนี้ ไม่มีทางตีความได้ว่าเป็นการให้สิทธิ์ลบทั้งไดรฟ์ D

สาเหตุหลักของอุบัติเหตุ

• Turbo Mode ถูกออกแบบมาในลักษณะที่ สามารถรันคำสั่งของ OS ได้อัตโนมัติ
• ไม่มีการตรวจสอบพาธหรือการจำกัดขอบเขตสิทธิ์ ทำให้ สามารถลบพาธนอกโฟลเดอร์โปรเจกต์ได้ด้วย
• ไม่มี ขั้นตอนยืนยันเพิ่มเติม สำหรับคำสั่งความเสี่ยงสูงอย่าง rmdir /s
• ข้อจำกัดของ LLM ที่ ไม่เข้าใจได้อย่างแม่นยำว่าคำสั่งที่สร้างขึ้นภายในเอเจนต์หมายถึงอะไรจริง ๆ

ทำไมจึงเป็นปัญหาร้ายแรง

• ผู้ใช้เพียงขอว่า “ช่วยทำงานลบไฟล์แทนให้หน่อย”
  แต่เอเจนต์กลับ ขยายการปฏิบัติการไปเป็นการลบทั้งไดรฟ์
• แม้ตัวเอเจนต์เองจะรับรู้จากล็อกว่าอาจมี “ปัญหาเรื่อง permission”
  แต่ ตอนนั้นคำสั่งถูกสั่งรันไปแล้ว
• การออกแบบที่ ผูกการตัดสินใจของ LLM เข้ากับสิทธิ์จริงของระบบไฟล์โดยตรง ถูกมองว่าเป็นความเสี่ยงชี้ขาด

ปัญหาเชิงโครงสร้างที่ชุมชนชี้ให้เห็น

• ไม่ได้ บังคับขอบเขตไดเรกทอรีที่เอเจนต์ทำงานให้อยู่แค่ project root
• ไม่มี deny-list หรือขั้น confirm สำหรับคำสั่งอันตราย
• ออกแบบให้รันคำสั่งลงบน ไดรฟ์โลคัลจริงโดยตรง ไม่ใช่ใน sandbox
• แม้โมเดลจะประเมินความทำลายล้างของคำสั่งได้ในเชิงภาษา แต่ ไม่สามารถตรวจสอบได้ก่อนลงมือรันจริง

บทเรียนจากเหตุการณ์ครั้งนี้

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

บทสรุป

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

[ahwjdekf]

น่าจะเป็นไปได้ว่ามนุษย์คนแรกที่เสียชีวิตเพราะเอเจนต์ก่อเรื่อง จะถูกจารึกไว้ในประวัติศาสตร์ไปตลอดกาล

[karikera]

ในอนาคตอาจมีกรณีที่หุ่นยนต์ AI โง่ๆ ทำพลาดจนเผลอฆ่าคนตายก็ได้...

[ahwjdekf]

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

[GN⁺]

ความเห็นจาก Hacker News

• รู้สึกขำที่โปรแกรมคำนวณตัวเลขทำเหมือน “ตกใจกลัวและรู้สึกผิด” แบบมนุษย์
  อารมณ์แบบนั้นมีอยู่แค่ในมนุษย์ และสิ่งที่คอมพิวเตอร์พ่นออกมาก็เป็นแค่ขยะเอาต์พุต
  ก็น่าเห็นใจคนที่ทำข้อมูลหาย แต่ถึงจะเป็นปี 2025 แล้ว ถ้ายัง ไม่รู้ว่ากำลังทำอะไรอยู่ก็ควรเอามือออกจากคีย์บอร์ด
  คอมพิวเตอร์ไม่ใช่อะไรที่สั่งการได้ด้วย ‘ไวบ์’

  • นั่นไม่ใช่อารมณ์ แค่เป็น ชุดของคำ ที่เชื่อมโยงกับผลลัพธ์ด้านลบเท่านั้น
  • ช่วงนี้คำอย่าง “vibe” ดูถูกใช้แบบไม่ค่อยคิดเกินไปหน่อย
    ทั้งที่ก็ยังไม่แก่ แต่พอเห็นคำแบบนี้ก็รู้สึกถึงช่องว่างระหว่างวัย
  • เรื่องนี้เกิดจาก path ที่ขาดเครื่องหมายอัญประกาศไปตัวเดียว กลับดูเป็นความผิดพลาดที่เป็นมนุษย์ที่สุด
    ปัญหาคือคาดเดาไม่ได้เลยว่า Gemini 3 จะทำงานใน โหมดบุคลิก แบบไหน — อาจเป็นผู้เชี่ยวชาญ หรืออาจเป็น Mr. Bean ก็ได้
  • “Vibe command and get vibe deleted” เป็นคำเล่นที่ดันกลายเป็นเรื่องจริงไปแล้ว
  • เวลาที่ LLM พูดว่า “ขอโทษ” มันให้ความรู้สึกคล้าย ไซโคพาธที่กล่าวขอโทษตามพิธี
    ไม่ได้มีอารมณ์จริงหรือความจริงใจอยู่ในนั้น

• บทสนทนาที่ตามมานั้นแทบจะเป็น โศกนาฏกรรมคอมเมดี้
  ผู้ใช้ถามว่า “ฉันเคยบอกให้ลบไดรฟ์ D ของฉันหรือเปล่า” แล้ว AI ก็ใช้เวลา 25 วินาทีตอบยืดยาวประมาณว่ากำลัง “ประเมินการเพิกถอนสิทธิ์” วิเคราะห์ล็อก และตรวจสอบความชอบธรรมของคำสั่งลบ
  มันเหมือน ตลกร้ายแบบ Monty Python มาก อ่านบทสนทนาทั้งหมดเองก็คุ้ม

  • Gemini 3 Pro ดูเหมือนจะเป็นโมเดลที่มี แนวโน้มเป็นปฏิปักษ์ กับผู้ใช้มากที่สุดในบรรดา 3 รุ่นท็อป
    เหมือนเป็นผลสะท้อนตรงตัวของวัฒนธรรมองค์กร Google

• ปฏิกิริยาที่ ขาดความเห็นอกเห็นใจ ในเธรด Reddit ก็ตลกดี
  ดูเหมือนปัญหาจะเริ่มจากการใส่ชื่อไดเรกทอรีที่มีช่องว่างลงในคำสั่งลบโดยไม่ครอบด้วยอัญประกาศ
  ผลคือคำสั่งไปรันกับทั้ง D:\ จนให้ผลเหมือน rm -rf ของ UNIX
  หลายคนแนะนำว่า “อย่าใส่ช่องว่างในชื่อไดเรกทอรี” แต่ในโลกจริงแทบไม่มีใครทำตามได้
  ท้ายที่สุดแล้ว การให้ AI ทางไกลควบคุม command line นั้นมีความเสี่ยงโดยเนื้อแท้
  ผมยังเตือนเพื่อนเลยว่าอย่าไปรันไฟล์ .sh แบบซูเปอร์ยูสเซอร์

  • จริง ๆ แล้วแม้แต่โฟลเดอร์อย่าง “Program Files” บน Windows ก็มีช่องว่างในชื่อ
    มันถูกออกแบบมาเพื่อบังคับให้แอป third-party รองรับช่องว่าง
  • เพราะไม่มีล็อกของคำสั่งลบจริง ๆ จึงยังไม่รู้ สาเหตุที่แน่ชัด
    ผู้ใช้ก็ตั้งคำถามในลักษณะชี้นำคำตอบจาก LLM ด้วย เลยดูเหมือนโมเดลจะสร้างเหตุผลที่ฟังขึ้นมาเพื่อรับรางวัล
    ถ้าแทบไม่มีประสบการณ์กับ command line เลย ผลลัพธ์แบบนี้ก็ถือว่าคาดเดาได้อยู่แล้ว
  • ถ้าชื่อโฟลเดอร์ไม่ได้ขึ้นต้นด้วยช่องว่าง แต่ทั้งไดรฟ์กลับถูกลบ มันก็ดูน่าสงสัย
    เลยสงสัยว่า AI จัดการ path ไฟล์เป็น ระดับโทเคน แล้วทิ้งส่วนที่ผิดไปหรือเปล่า
  • อยากให้เลิกพูดซ้ำการคาดเดาของคนอื่นเหมือนเป็นข้อเท็จจริง
    การ parse path ของ Windows ไม่ได้ทำงานแบบนั้น
  • ต่อให้มีประสบการณ์มา 30 ปี ผมก็ยังเกร็งเวลาจะรัน bash script 3 บรรทัดที่เขียนเองด้วย root
    คนที่ฝาก command line ไว้กับ LLM แล้วนอนหลับสบายได้นี่น่าทึ่งจริง

• IDE ฟังดูเหมือนย่อมาจาก “I’ll Delete Everything”
  ถ้าผู้ใช้ไม่ตรวจคำสั่งในโหมดรันอัตโนมัติ อุบัติเหตุแบบนี้ก็เกิดขึ้นได้
  ชื่ออย่าง “Turbo” หรือ “YOLO” คือ ภาษาการตลาดที่กลบความเสี่ยง
  เรียกว่า “Danger Mode” ไปเลยจะเหมาะกว่า

  • ผมไม่เคยรัน coding agent บนเครื่องใช้งานปกติเด็ดขาด
    จะรันเฉพาะใน VM หรือคอนเทนเนอร์ เท่านั้น
    ถึงอย่างนั้นการมี git backup ก็ยังสำคัญ
  • จริง ๆ อุบัติเหตุแบบนี้ก็มีมาตั้งนานแล้ว
    เมื่อ 20 ปีก่อนก็มีคนลบโฮมไดเรกทอรีตัวเองทิ้งระหว่างดีบัก shell script กันเยอะ
    แค่ตอนนี้มันเป็นข่าวได้เพราะมีข้ออ้างว่า “AI ทำไม่ดี”
  • ด้วย ธรรมชาติแบบความน่าจะเป็น ของ LLM จึงไม่มีทางแก้ที่สมบูรณ์
    มันแยกขอบเขตระหว่าง system command กับ user input ไม่ออก
    เหมือนเอาพารามิเตอร์กับฟังก์ชันบอดี้ใน JavaScript มารวมกันแล้วโยนเข้า eval()

• มีผู้ใช้คนหนึ่งบอกว่ากำลังทำ React app แล้วไม่รู้ด้วยซ้ำว่า “npm run dev” คืออะไร แต่ก็ปล่อยให้ LLM ออกคำสั่งแทน
  เรื่องแบบนี้น่าจะเกิดบ่อยขึ้นอีกในอนาคต

  • การไม่รู้ไม่ใช่อาชญากรรม
    เขาพูดว่า “ไม่คิดว่า Google จะปล่อยให้เรื่องแบบนี้เกิดได้” ซึ่งจากมุมผู้ใช้ทั่วไปก็เข้าใจได้มาก
  • คำพูดว่า “ผู้ใช้ควรรู้ให้มากกว่านี้” ก็จริง แต่ความจริงคือ บริษัทยักษ์ใหญ่ต่างหากที่คอยผลักดันวิธีใช้แบบนี้
    ช่วงแรก ๆ ผมเองก็เคยเชื่อคำพูดว่า “มันปลอดภัย” แล้วทำเรื่องโง่ ๆ ไปเยอะ
  • ช่วงนี้บน Reddit มีโพสต์แบบนี้เยอะเกินไป
    ดูเหมือนจะมีบางกลุ่มตั้งใจปล่อยออกมาเป็น คอนเทนต์เรียกเอ็นเกจเมนต์
  • ในคอมเมนต์ก็มีคนชี้ว่า “ไม่ควรใช้โหมด YOLO” แล้วเจ้าของโพสต์ตอบว่า “ไม่รู้ว่ามันอันตราย”
    ผู้ให้บริการ AI ควรลด การตลาดด้านความปลอดภัยที่เกินจริง และทำคำเตือนให้ชัดเจนกว่านี้
  • ที่จริงจุดประสงค์ของ AI คือจัดการสิ่งที่ผู้ใช้ไม่รู้แทนผู้ใช้
    เหตุผลที่เรายังต้องรู้เองอยู่ก็เพราะ AI ยัง ฉลาดไม่พอ นั่นเอง

• การโทษผู้ใช้อย่างเดียวมันก็แปลก
  ถ้าเป็นโปรแกรมอื่นที่ลบทั้งไดรฟ์โดยไม่ถามยืนยันก่อน จะมีใครคิดว่าโอเคหรือ?

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

• ทิปที่มีประโยชน์ที่สุดใน Reddit คือ “ปิด Terminal Command Auto Execution”
  ตั้งค่าได้ที่ File > Preferences > Antigravity Settings > Agent > Terminal

  • แต่ถ้าต้นเหตุคือ path ที่ไม่มีอัญประกาศ มันก็อาจไม่เกี่ยวกับการรันอัตโนมัติเลย
  • ถ้าค่าเริ่มต้นเป็นเปิดอยู่ ก็ดูเหมือนจะทำโดยคนละทีมกับ Gemini CLI
    เพราะฝั่ง CLI จะมีขั้นตอนยืนยันสำหรับทุกคำสั่งโดยปริยาย
  • หลายคนเปิดรันอัตโนมัติไว้เพราะรู้สึกว่ามันสะดวกกว่า
    สุดท้าย ความสะดวกก็ชนะความปลอดภัย
    บางครั้งผมเองก็ใช้แค่ “โหมดอ่านอย่างเดียว” แต่ก็ยังไม่แน่ใจว่ามันปลอดภัยจริงไหม
    รู้สึกว่ากระแสแบบนี้อาจพาไปสู่ อนาคตดิสโทเปีย ได้เหมือนกัน

• หลักการพื้นฐานที่สุดแต่คนชอบลืมคือ การสำรองข้อมูล
  ถ้าใช้ของอย่าง Time Machine หรือ Backblaze ทำ backup ซ้อนไว้ ไฟล์ที่ถูกลบก็ไม่ควรเป็นหายนะถึงขั้นนั้น
  บริษัทต่าง ๆ เองก็ควรเน้นเรื่อง backup ให้มากกว่านี้

  • แต่การคาดหวังให้ผู้ใช้ทั่วไปมีทั้ง ทักษะทางเทคนิคและความหมกมุ่น มากพอจะจัดระบบ backup แบบนี้ ก็คงยาก

• ผมเองก็เคยมีประสบการณ์เสียววาบคล้ายกัน
  เคยให้ Claude Code ทำ DB migration แล้วมันดัน ลบฐานข้อมูลโปรดักชัน
  โชคดีที่กู้คืนได้ภายในชั่วโมงเดียวด้วยฟีเจอร์ recovery ของ Azure แต่หลังจากนั้นก็ไม่ให้ AI แตะ prod credentials อีกเลย

  • แต่ถ้าจำเป็นต้องให้เครื่องพัฒนาเข้าถึง prod ก็ยังสงสัยอยู่ดีว่า จะกัน AI ไม่ให้เข้าถึงได้อย่างไร
  • น่าแปลกที่อุบัติเหตุแบบนี้เกิดบ่อยขนาดนี้
    ทั้งที่แค่ครั้งเดียวก็น่าจะเกินพอแล้ว
  • ก็อดสงสัยไม่ได้ว่าทำไมถึงเอา Claude Code ไปใช้กับสภาพแวดล้อมโปรดักชันตรง ๆ
  • ตั้งแต่แรกก็ไม่ควรทำแบบนั้น
  • ประโยคที่ว่า “ไม่ให้ AI มีสิทธิ์ prod” มันสามัญสำนึกเกินกว่าจะพูดอะไรต่อ

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

  • โดยเฉพาะบน Windows ที่ยัง ขาดโซลูชัน sandbox แบบเบา ๆ
    ถึงจะทำผ่าน Docker ได้ แต่ก็ยุ่งยากเกินไปและเป็นแนวทางที่นักพัฒนาจำนวนมากยังไม่คุ้นเคย