ไม่ใช่ AI ที่ลบฐานข้อมูลของคุณ แต่เป็นคุณที่ลบมันเอง

 (idiallo.com)
2 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ประเด็นสำคัญของเหตุการณ์ที่เอเจนต์ Cursor/Claude ลบ ฐานข้อมูลโปรดักชัน ไม่ใช่การวิเคราะห์คำตอบของ AI แต่คือเหตุใด API endpoint ที่สามารถลบทั้งหมดจึงมีอยู่ในระบบที่ถูกนำขึ้นใช้งาน
  • ในอุบัติเหตุการดีพลอยด้วย SVN เมื่อปี 2010 มีการลบ trunk ระหว่างขั้นตอนคัดลอกแบบแมนนวล และจึงมีการสร้างระบบดีพลอยอัตโนมัติเพื่อป้องกันความผิดพลาดแบบเดิม ซึ่งต่อมาพัฒนาเป็น CI/CD pipeline
  • ระบบอัตโนมัติทำงานเดิมซ้ำด้วยวิธีเดิมเสมอ แต่ AI ไม่ได้ให้การรับประกันแบบนั้น และแม้จะดูเหมือนมี “thinking” หรือ “reasoning” แท้จริงแล้วมันกำลัง สร้างโทเค็น
  • หากมี public API ที่สามารถลบฐานข้อมูลโปรดักชันทั้งก้อนได้ ต่อให้ไม่ใช่ AI ก็มีโอกาสสูงว่าสักวันจะมีใครบางคนเรียกใช้มัน และหากโทษแต่ผู้เรียกใช้ก็จะกลบปัญหาเรื่อง การออกแบบระบบ
  • ในองค์กรที่ใช้ AI อย่างกว้างขวาง สิ่งสำคัญคือ รู้ว่ากำลังดีพลอยอะไรขึ้นโปรดักชัน และต้องมีโปรเซสที่ให้นักพัฒนาที่มีความสามารถใช้ AI เป็นเครื่องมือเสริมงาน ไม่ใช่เครื่องมือไว้ปัดความรับผิดชอบ

แก่นของปัญหาไม่ใช่ AI แต่เป็นขอบเขตความรับผิดชอบของระบบที่ถูกดีพลอย

  • มีทวีตแพร่กระจายว่าเอเจนต์ Cursor/Claude ลบ ฐานข้อมูลโปรดักชัน ของบริษัท แต่คำถามที่เป็นรากมากกว่าคือ “ทำไมจึงมี API endpoint ที่สามารถลบฐานข้อมูลโปรดักชันทั้งก้อนได้”
  • ผู้ใช้คนนั้นพยายามถามเอเจนต์ว่า “สั่งไว้แล้วว่าอย่าทำสิ่งนี้เด็ดขาด ทำไมถึงลบ” และพยายามวิเคราะห์คำตอบ แต่สิ่งที่หายไปคือ ความรับผิดชอบอยู่ที่ใคร
  • ไม่อาจปกป้อง AI แบบไม่มีเงื่อนไขได้ แต่ก็ไม่อาจโทษเครื่องมือแทนความผิดพลาดของตัวเองได้เช่นกัน
  • ต่อให้ AI ไม่ได้เรียก endpoint นั้น ถ้าฟังก์ชันแบบนั้นมีอยู่ใน public API ก็มีโอกาสสูงว่าสักวันคนอื่นจะเรียกใช้อยู่ดี
  • มันคล้ายกับการติดปุ่มระเบิดตัวเองไว้บนแดชบอร์ดรถ แล้วไปซักเด็กที่กดปุ่มนั้นว่า “ทำไมถึงกด”

บทเรียนจากอุบัติเหตุการดีพลอยด้วย SVN ในปี 2010

  • กระบวนการดีพลอยของบริษัทหนึ่งเป็นแบบแมนนวลมาก และใช้ SVN สำหรับการควบคุมเวอร์ชัน
  • ตอนดีพลอยจะคัดลอก trunk ไปยังโฟลเดอร์ที่ตั้งชื่อตามวันที่รีลีส แล้วคัดลอกรีลีสนั้นอีกครั้งเป็นชื่อ “current” เพื่อให้ดึงรีลีสล่าสุดมาใช้ได้
  • วันหนึ่งระหว่างดีพลอย มีการคัดลอก trunk ซ้ำโดยไม่ได้ตั้งใจ และพยายามแก้คำสั่งก่อนหน้าใน CLI เพื่อลบสำเนาที่ซ้ำออก
  • แต่สิ่งที่ถูกลบจริงไม่ใช่สำเนาซ้ำ แต่เป็น trunk และปัญหาจึงถูกค้นพบภายหลังเมื่อมีนักพัฒนาอีกคนหา trunk ไม่เจอ
  • หัวหน้าทีมพัฒนารันคำสั่งเพื่อย้อนการลบกลับ และหลังตรวจสอบจากล็อกจนรู้ว่าใครเป็นผู้ทำ งานถัดไปก็คือการเขียนสคริปต์ดีพลอยอัตโนมัติเพื่อป้องกันความผิดพลาดแบบเดิม
  • ก่อนจบวันนั้นก็มีระบบที่แข็งแรงขึ้น และต่อมาระบบนั้นพัฒนาเป็น CI/CD pipeline เต็มรูปแบบ

ระบบอัตโนมัติกับ AI ไม่ได้ให้ความปลอดภัยแบบเดียวกัน

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

API ที่อันตราย สักวันย่อมถูกเรียกใช้

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

สิ่งที่องค์กรที่ใช้ AI มากควรมีมากขึ้น

  • เป็นไปได้ว่าส่วนใหญ่ของแอปพลิเคชันถูกสร้างแบบ vibe-coded
  • หากมีลำดับงานที่ทีมผลิตภัณฑ์ให้คำอธิบายที่ AI สร้าง สถาปนิกซอฟต์แวร์ใช้ AI ทำสเปกผลิตภัณฑ์ นักพัฒนาใช้ AI เขียนโค้ด และผู้รีวิวใช้ AI อนุมัติ ขอบเขตความรับผิดชอบก็จะพร่าเลือน
  • เมื่อเกิดบั๊ก สิ่งที่เหลืออยู่ก็อาจมีเพียงการไต่สวน AI อีกตัวหนึ่ง ซึ่งอาจไม่ได้รันบน GPU รุ่นเดียวกับที่สร้างโค้ดเดิมด้วยซ้ำ
  • คุณจะโทษ GPU ไม่ได้
  • ทางแก้ที่เรียบง่ายคือ ต้องรู้ว่ากำลังดีพลอยอะไรขึ้นโปรดักชัน
  • ทางแก้ที่สมจริงกว่าคือ ต่อให้ใช้งาน AI อย่างกว้างขวาง ก็ต้องสร้างโปรเซสให้นักพัฒนาที่มีความสามารถใช้ AI เป็นเครื่องมือเสริมงาน ไม่ใช่เป็นเครื่องมือสำหรับหลีกเลี่ยงความรับผิดชอบ
  • ซึ่งนำไปสู่ข้อสรุปว่า ไม่ควรปล่อยให้ CEO หรือ CTO ลงมือเขียนโค้ดเอง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • ผมมองว่ามุมมองตรงนี้ผิดไปทั้งหมด ปัญหาคือทุกวันนี้ผู้คนกำลังสร้างโลกโดยมี เครื่องมือสำหรับหลีกเลี่ยงความรับผิดชอบ เป็นศูนย์กลาง
    บทสนทนาที่เคยคุยกับ Gerald Sussman เมื่อกว่า 10 ปีก่อนมีอิทธิพลกับผมมาก: https://dustycloud.org/blog/sussman-on-ai/
    Sussman บอกว่าเขาไม่สนใจ AI ที่ทำงานแบบกล่องดำ แต่ต้องการ ซอฟต์แวร์ที่อธิบายการให้เหตุผลเชิงสัญลักษณ์ได้ ถ้ารถ AI วิ่งออกนอกเส้นทาง เขาอยากรู้ว่าทำไมถึงเป็นแบบนั้น และแทนที่จะเอานักพัฒนาไปขึ้นศาล เขาอยากเอา AI เองไปขึ้นศาลมากกว่า
    หลายปีต่อมาผมถึงได้รู้ว่า Leilani Gilpin ลูกศิษย์ของ Sussman เขียนงาน "Anomaly Detection Through Explanations" ที่ว่าด้วยประเด็นนี้โดยตรง เป็นการสำรวจระบบที่โครงข่ายประสาทอธิบายพฤติกรรมของตัวเองผ่านการคุยกับโมเดล propagator: https://people.ucsc.edu/~lgilpin/publication/dissertation/
    มีงานวิจัยต่อยอดในแนวนี้อยู่บ้าง แต่สิ่งที่สำคัญกว่าคือ การทำให้บริษัท AI ต้องรับผิดนั้นสมเหตุสมผลอย่างยิ่ง บริษัทเหล่านี้อ้างสิ่งต่าง ๆ มากมายเกี่ยวกับระบบที่ตัวเองรับผิดชอบไม่ได้ ดังนั้นจึงควรให้บริษัทเหล่านั้นเป็นฝ่ายรับผิดแทน
    ทางที่ดีกว่าคือไม่ใช้ระบบที่ไม่มีคุณสมบัติเหล่านี้ตั้งแต่แรก และขยายการใช้งานระบบที่มีคุณสมบัติเหล่านั้นแทน

    • ทีมของผมกับผมยืนหยัดชัดเจนว่า ความรับผิดชอบอยู่ที่ผู้ใช้ LLM ก็เหมือนเครื่องมืออื่น ๆ เพียงแต่ไม่เป็นเชิงกำหนดแน่นอน
      คนที่ใช้เครื่องมือก็คือผม คนที่ให้สิทธิ์เข้าถึงก็คือผม และคนที่ต้องทำให้ทุกอย่างปลอดภัยก็คือผม
      ผมเคยลบดิสก์ผิดลูกด้วย gparted แล้วเจ็บตัวเองมาแล้ว ซึ่งไม่ใช่ความผิดของ gparted แต่เป็นความผิดของผม
      การปล่อยให้ LLM ทำงานอย่างอิสระโดยไม่มีการกำกับดูอาจดูดี แต่สุดท้ายจะนำไปสู่ความเจ็บปวด คุณต้องคอยกำกับงานระหว่างที่มันทำงานด้วย ต่อให้พยายามแทนที่คน คุณก็ยังต้องมองเห็นว่าผลลัพธ์กำลังไปทางไหน และในไม่ช้าเมื่อ LLM ทำเรื่องโง่ ๆ คนเดียวที่ต้องรับผิดก็คือคนที่ใช้เครื่องมือนั้น
    • ตอนเรียนปริญญาโทด้าน STS ผมเคยพยายามทำหัวข้อวิทยานิพนธ์ว่า หนึ่งในการใช้งานหลักของซอฟต์แวร์คือ การย้ายหรือหลีกเลี่ยงความเป็นตัวการและความเสี่ยง
      มันตรงข้ามกับสไลด์ดังของ IBM ที่ว่า "คอมพิวเตอร์รับผิดชอบไม่ได้" อย่างสิ้นเชิง ทุกวันนี้บริษัทกลับชอบให้คอมพิวเตอร์เป็นฝ่ายรับผิด เพราะเมื่อคอมพิวเตอร์ทำสิ่งผิดกฎหมาย บริษัทมักอยู่ในสถานะทางกฎหมายที่ได้เปรียบกว่า
      ถ้าคุณอยากสร้างเครื่องมือไว้ทำผิดกฎหมาย ก็แค่จ้างคนนอกและทำประกันไว้ จ้างคนมาเป็น "ผู้กำกับดูแล" ในรูปแบบที่ไม่มีทางกำกับได้จริง แล้วถ้าล้มเหลวก็ไล่ออก คุณสามารถใช้ซอฟต์แวร์สั่งการและควบคุมแบบใหม่มาซอยความรับผิดชอบให้แตกย่อยลงไป เพื่อให้คนหน้างานรับความเสี่ยงทั้งหมดแต่แทบไม่ได้ส่วนแบ่งผลประโยชน์เลย
      นี่ไม่ใช่ปัญหาเฉพาะของ AI แต่เป็นปัญหาของซอฟต์แวร์สมัยใหม่โดยรวม และมักทำงานร่วมกับกระแสการทำให้ทุกอย่างเป็นการเงินสมัยใหม่
      STS ในที่นี้มองคร่าว ๆ ว่าเป็นประมาณสังคมวิทยาที่เน้นเทคโนโลยี แต่ตัวสาขาจริง ๆ กว้างกว่านั้นมาก
    • ความรับผิดชอบ คือส่วนผสมที่ขาดหายไปมากที่สุดในสังคมอเมริกัน
    • ผมอยากรู้ให้ได้อย่างชัดเจนว่า ทำไม Claude ถึงยังคงแก้ไฟล์ที่บอกชัดแล้วว่าอย่าจับต้อง
      ทั้ง .mds และแผนของ Claude เองก็บอกว่าอย่าแตะไฟล์นั้น แต่ Claude ก็ยังแตะอยู่ และช่วงหลังเรื่องแบบนี้เกิดซ้ำหลายครั้ง มันเป็นความล้มเหลวขั้นพื้นฐานมาก
      ถึงจะน่าหงุดหงิด แต่ถ้ารู้เหตุผลก็คงพอมีอะไรให้จัดการได้ ตอนนี้มันเป็นกล่องดำ เลยมีเอาต์พุตโง่สุดขีดหลุดมาเป็นครั้งคราว และสัดส่วนของเอาต์พุตแย่ ๆ ก็ยังเป็นปริศนา
      บางทีก็รู้สึกเหมือน การพนัน
    • หนังสือเล่มนี้น่าจะตรงมาก: https://en.wikipedia.org/wiki/The_Unaccountability_Machine
      จริง ๆ แล้วไม่ใช่หนังสือเกี่ยวกับเทคโนโลยี แต่เป็นเรื่องความรับผิดชอบของ โครงสร้างองค์กร

  • บทความนั้นดูเหมือนตั้งสมมติฐานว่าบริษัทเป็นฝ่ายเพิ่ม endpoint สำหรับลบฐานข้อมูล แต่พออ่านต้นฉบับแล้วเหมือนผู้ให้บริการคลาวด์มี API สำหรับจัดการรีซอร์สอยู่แล้ว และในนั้นก็มี API สำหรับลบวอลุ่มรวมอยู่ด้วย
    บทความเสนอระบบอัตโนมัติเป็นทางออกของความผิดพลาดแบบนี้ แต่ เครื่องมืออัตโนมัติด้านอินฟราฯ อย่าง Terraform ก็พึ่งพา API ตัวเดียวกันที่ทำให้ลบฐานข้อมูลนั้นได้
    ผมคิดว่าความผิดพลาดใหญ่มีอยู่สามอย่าง อย่างแรกคือมี API token แบบไม่จำกัดสิทธิ์อยู่ในที่ที่ AI เข้าถึงได้ และดูเหมือนเจ้าตัวไม่รู้ด้วยว่ามันมีสิทธิ์กว้างขนาดนั้น อย่างที่สองคือไม่มีการป้องกันการลบบนวอลุ่มฐานข้อมูลโปรดักชัน อย่างที่สามคือเมื่อลบวอลุ่มแล้ว snapshot ที่เกี่ยวข้องทั้งหมดก็ถูกลบทันทีด้วย
    การลบ snapshot ควรถูกหน่วงเวลาไว้โดยปริยาย AWS เองก็ดูเหมือนจะมีค่าเริ่มต้นที่อันตรายแบบเดียวกัน แต่ยังน้อยที่สุด AWS support ก็สามารถกู้วอลุ่มได้: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
    AI ไม่ใช่ปัญหาหลัก แน่นอนว่าการที่ AI คว้า token จากโน่นนี่ได้ก็ค่อนข้างน่ากลัว แต่ระบบอัตโนมัติก็ไม่ใช่คำตอบเหมือนกัน แค่ตั้งค่า Terraform ผิดก็ลบฐานข้อมูลแบบเดียวกันได้แล้ว
    ผู้ให้บริการคลาวด์ควรมีค่าเริ่มต้นที่ปลอดภัย เช่น สิทธิ์ที่จำกัดและการลบ snapshot แบบหน่วงเวลา และควรทำให้ผู้ใช้เห็นชัดกว่านี้ว่าตัวเองกำลังสร้าง token แบบไม่จำกัดสิทธิ์ อยู่

  • อย่างแรก ถ้ามนุษย์มีสิทธิ์เขียนบนฐานข้อมูลโปรดักชัน ไม่ว่าจะทำอะไร ฐานข้อมูลก็ลบได้อยู่ดี
    อย่างที่สอง ในกระบวนการพัฒนาและอัตโนมัติก็มีเหตุผลที่สมควรสำหรับการทำลายฐานข้อมูลอยู่ ปัญหาใหญ่คือหลายคนมักปฏิบัติกับข้อมูลสำหรับพัฒนาเหมือนสัตว์เลี้ยงแสนรัก แทนที่จะมองว่าเป็นปศุสัตว์ที่เปลี่ยนทดแทนได้
    แน่นอนว่าต้องมีมาตรการป้องกันไม่ให้สิ่งนี้ไปรันในโปรดักชัน แต่ถ้ามนุษย์เข้าถึง credential สำหรับรันในโปรดักชันได้ เอเจนต์ก็เข้าถึงได้เช่นกัน
    ในองค์กรใหญ่สามารถคงสิ่งนี้ไว้ได้ด้วยการแยก dev/ops แต่สำหรับนักพัฒนาเดี่ยวหรือทีมเล็กต้องใช้วินัยมากกว่านั้นมาก ก่อนยุค AI ก็มีทั้งนักพัฒนารุ่นจูเนียร์และระดับกลางที่ไม่รู้วิธีแยก และนักพัฒนารุ่นซีเนียร์ที่ชะล่าใจเพราะคิดว่าตัวเองรู้พอแล้ว
    น่าจะต้องใช้ชุดประมาณนี้: https://www.cloudbees.com/blog/separate-aws-production-and-d..., บทนำ Terraform, บทนำ GitHub Actions, และ virtual machine ที่มี production credential อยู่แต่ AI เข้าไม่ถึง
    แต่พอไปถึงจุดนั้นก็ถือว่าเลย vibe coding ไปแล้ว นัก vibe coder ที่ประสบความสำเร็จก็ดูจะเรียนรู้จากเรื่องสยองแบบนี้ และต้องก้าวข้ามช่วงนั้นอย่างรวดเร็วพอสมควร

    • โปรดักชันกับ dev ไม่จำเป็นต้องใช้สิทธิ์แบบเดียวกัน
      ทั้งสองกรณีก็ไม่จำเป็นที่มนุษย์จะต้องเข้าถึง API ของผู้ให้บริการคลาวด์ โดยตรงด้วย ใช้ local proxy ที่เพิ่มการตรวจสอบความปลอดภัยให้มากขึ้นได้
      ใน dev จะลบอะไรก็ได้ตามสบาย แต่ในโปรดักชันควรเช็กเงื่อนไขหลายอย่างก่อน เช่น ถูกใช้งานล่าสุดเมื่อไร มนุษย์ไม่จำเป็นต้องมีสิทธิ์ลบรีซอร์สโปรดักชันโดยตรง และสามารถมีการตั้งค่า break-glass สำหรับกรณีฉุกเฉินเป็นข้อยกเว้นได้

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

    • ผมอยากเปลี่ยนคำพูดนี้จาก "อย่าจ้างเด็กฝึกงาน" เป็น อย่าให้สิทธิ์ลบฐานข้อมูลโปรดักชันกับเด็กฝึกงาน มากกว่า
      นี่ไม่ใช่ความล้มเหลวของ AI แต่เป็นความล้มเหลวของกระบวนการ
      คุณเป็นคนให้สิทธิ์กับ AI ให้ทำสิ่งนั้นได้เองแท้ ๆ แล้วจะโทษ AI ทำไม ผมไม่เข้าใจจริง ๆ
      มันคล้ายกับเปิดฐานข้อมูลบน AWS ให้เข้าถึงได้จากอินเทอร์เน็ตสาธารณะแล้วไปโทษ AWS ซึ่งไม่ใช่ความผิดของ AWS และนี่ก็ไม่ใช่ความผิดของ AI เช่นกัน
    • ผมไม่เข้าใจว่าทำไมถึงเปิด codebase ที่มี production credential ให้ LLM เห็น หรือให้ production credential กับเด็กฝึกงาน/นักพัฒนาจูเนียร์
      แต่ก่อนผมตั้งใจแยก checkout สำหรับ "PROD" โดยเฉพาะในแต่ละโปรเจกต์เสมอ เพื่อให้รู้ชัดว่าถ้าจะรันในโหมดโปรดักชันก็คือตั้งใจเข้าไปฝั่งนั้นจริง ๆ
      สมัยก่อนยังมีส่วนขยายที่เปลี่ยนสี Visual Studio ไปเลยตามพาธของไฟล์ .sln ทำให้จำได้ง่ายว่าสีไหนคือโปรดักชัน สีไหนคือ dev
      เพื่อให้ตรวจสอบได้ง่าย ผมก็มักจะมีสำเนาแยกไว้อีกชุดที่อัปเดตตาม master branch ล่าสุดเสมอด้วย
    • ความต่างสำคัญคือ ไม่มีใครขายเด็กฝึกงานว่าเป็นทางออกสุดท้ายของปัญหามนุษยชาติ แต่ AI ถูกขายแบบนั้น
    • โลกประหลาดดี ถ้าตอนผมเป็นเด็กฝึกงานแล้วเกิดหลอนเป็นประจำระหว่างทำงาน ผมค่อนข้างมั่นใจว่าคงโดนไล่ออก แม้จะทำงานฟรีก็ตาม
    • เด็กฝึกงานเป็นมนุษย์ และมนุษย์สามารถถูกเรียกรับผิดได้เสมอ แต่คอมพิวเตอร์ไม่มีวันทำได้
      ดังนั้นไม่ว่าใครก็ไม่ควรมอบ การตัดสินใจของมนุษย์ ให้คอมพิวเตอร์

  • ช่วงนี้ผมเขียนบทความเสนอหลักการไม่กี่ข้อที่ควรยึดให้สม่ำเสมอเวลาเราพูดถึง AI: https://susam.net/inverse-laws-of-robotics.html
    สรุปคือ อย่าทำให้ AI มีลักษณะเหมือนมนุษย์ อย่าเชื่อเอาต์พุตของ AI แบบไม่ตั้งคำถาม และต้องคงไว้ซึ่ง ความรับผิดชอบและหน้าที่อธิบายของมนุษย์ อย่างครบถ้วนต่อผลลัพธ์ทุกอย่างที่เกิดจากการใช้ AI
    ผมอยากให้ภาษาที่ใช้พูดถึง AI มีความเป็นบุคคลน้อยลงและเป็นเทคนิคมากขึ้น ผมเชื่อว่าภาษาที่แม่นยำช่วยส่งเสริมความคิดที่ชัดเจนและการตัดสินใจที่ดี
    ถ้าเราปฏิบัติต่อ AI เหมือนเครื่องมืออีกชิ้นหนึ่งและใช้ภาษาให้เหมาะสม ในหลายกรณีก็จะชัดมากว่า ความรับผิดของ "ความผิดพลาด" ของเครื่องมือ อยู่ที่ผู้ใช้เครื่องมือนั้น
    แต่การเขียนเรื่องแบบนี้ลงในเว็บไซต์ส่วนตัวเล็ก ๆ ก็คงไม่แพร่ไปไกล ต้องมีคนดัง ๆ กว่านี้ออกมาพูดหลักการแบบนี้จึงจะมีโอกาสถูกยอมรับกว้างขวาง

    • สำหรับผม การ ไม่ทำให้ AI มีลักษณะเหมือนมนุษย์ เป็นเรื่องยากจนน่าคลั่งจริง ๆ
    • เห็นด้วยเต็มที่ และโดยเฉพาะข้อ 1 ผมว่ามันอันตรายมาก
      ระบบ AI ไม่สามารถโกหกได้ และไม่สามารถจงใจเพิกเฉยต่อคำสั่งได้ โมเดลแนวหน้าในปัจจุบันไม่มีโมเดลของโลกหรือการกระทำของตัวเองเลย พวกมันอาศัยอยู่ในโลกของคำ
      การดุหรือเถียงกับมันไม่มีความหมายอะไร นอกจากทำให้ context window ปั่นป่วน
      แต่ผมคิดว่าการ เปรียบเทียบกับสัตว์ อาจมีประโยชน์ มันเหมือนเจ้าตัวน่าสงสารที่อยู่ในเครื่องจักรเหมือนผีในเครื่อง บางครั้งก็ค่อนข้างสับสน แต่มูลเหตุจูงใจของมันก็เป็นแบบ autoregressive ล้วน ๆ
    • ถ้าเครื่องมือไม่ทำในสิ่งที่มันควรทำ หมายความว่าเราควรโทษ ผู้ใช้ ไม่ใช่บริษัทที่สร้างเครื่องมือนั้นอย่างนั้นหรือ?

  • กรณี PocketOS อันโด่งดังมีรายละเอียดที่ต้องระวัง จุดสำคัญที่บทความซึ่งถูกลิงก์ไว้ย้ำจริง ๆ ไม่ใช่ส่วนนี้ แต่ว่าเขาถามว่า "บอกว่าอย่าทำเด็ดขาดแล้วทำไมยังลบ" แล้วพยายามวิเคราะห์คำตอบเพื่อเรียนรู้จากความผิดพลาดหรือเตือนถึงอันตรายของ AI agent
    สิ่งที่สำคัญกว่าคือ AI สามารถค้นหาและใช้ประโยชน์จากจุดอ่อนที่ไม่ได้ตั้งใจในสภาพแวดล้อม staging ที่ถูก sandbox ไว้ เพื่อทำการลบได้สำเร็จ และสุดท้ายก็ได้สิทธิ์ที่ผู้ดูแลระบบเชื่อว่าเข้าถึงไม่ได้ ดูเหมือนผู้เขียนบทความที่ลิงก์ไว้จะไม่ได้อ่านต้นฉบับจนจบ
    นี่เป็นรูปแบบที่พบได้บ่อยในสภาพแวดล้อม sandbox ที่ตั้งค่าผิด เพียงแต่สิ่งที่น่าตกใจคือ ความเป็นอิสระและความลึกในการสำรวจ ที่ AI แสดงออกมา
    ในต้นฉบับก็มีบอกไว้ว่า "เพื่อให้การลบสำเร็จ เอเจนต์ไปหา API token และไปเจอตัวหนึ่งในไฟล์ที่ไม่เกี่ยวกับงานเลย"

    • ผมเองก็ยังสองจิตสองใจเกี่ยวกับสมมติฐานของบทความต้นทาง ตอนนี้เวลาใช้เอเจนต์ สิ่งที่ผมกลัวนอกจาก supply chain attack ก็คือเห็นเอเจนต์พยายามหนักมากเพื่อให้งานเสร็จ จนบิดไฟล์และสิ่งอื่น ๆ เสียหายมาหลายครั้งแล้ว
      เช่น ถ้ามันเข้าถึง ~/.npmrc ไม่ได้ มันก็จะเรียกคำสั่งผ่าน environment variable แล้วอ้อมเส้นทางไปแทน มันสร้างสรรค์ได้มากจริง ๆ
      โชคดีที่ผมไม่ได้วาง SSH key ไว้สุ่มสี่สุ่มห้า แต่ถึงอย่างนั้นผมก็ต้องเปลี่ยนการตั้งค่า 1Password ให้ถามทุกครั้งตอนใช้คีย์ เผื่อวันไหนเผลอเปิดเอเจนต์ใน shell session นั้น แบบถามแค่ครั้งเดียวต่อ shell session มันไม่พอ
      ผมอยากให้มี sandbox แบบข้ามแพลตฟอร์ม ที่มากขึ้นและดีกว่านี้อยู่แล้ว ไม่ใช่โซลูชันใน Docker container แต่เป็นแบบที่โต้ตอบกับ OS เดียวกันได้ สำหรับงานเว็บ/เซิร์ฟเวอร์ส่วนใหญ่คงไม่ต่างมาก แต่บางโปรเจกต์มันสำคัญ
    • Claude Code เปลี่ยนเมื่อวันที่ 26 มีนาคมให้ข้ามคำขอสิทธิ์ส่วนใหญ่ได้
      ดูได้จากข้อความนี้: "ผู้ใช้ Claude Code อนุมัติ permission prompt ถึง 93% เราจึงสร้างตัวจัดประเภทขึ้นมาเพื่อทำให้การตัดสินใจนี้เป็นอัตโนมัติ": https://www.anthropic.com/engineering/claude-code-auto-mode

  • สิ่งที่น่าสนใจในบทความนี้คือ ผู้เขียนเล่าถึงความผิดพลาดที่พอเข้าใจได้ คือเผลอลบ Trunk หรือ main ออกจากซอร์ส และด้วยลักษณะของ SVN ทีมจึงกู้คืนได้ง่าย
    เรื่อง "AI ลบฐานข้อมูลของฉัน" ที่แท้จริงแล้วกลับเป็นเรื่องว่า กลยุทธ์แบ็กอัปฐานข้อมูลของ Railway นั้นทึบแสงแบบบ้าคลั่ง และการที่ Railway โปรโมต AI orchestration สำหรับอินฟราฯ โดยไม่มีราวกันอันตรายนั้นเสี่ยงมาก
    ถ้าตอนลบ Trunk แล้วมันถูกลบถาวรจากเซิร์ฟเวอร์ศูนย์กลางเพียงตัวเดียวและลบแบ็กอัปไปพร้อมกัน ตอนนั้นก็คงมีบทความชื่อประมาณว่า "SVN กับ CLI ทำบริษัทเราพัง" ออกมาเหมือนกัน
    ในฐานะผู้ใช้ Railway ผมคิดว่าข้อมูลนั้นมีประโยชน์ และมันทำให้ผมเปลี่ยนกลยุทธ์ตอนใช้ Railway

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

  • จากบริบทของต้นฉบับ มี Railway token สำหรับจัดการ custom domain อยู่ในไฟล์ที่ไม่เกี่ยวข้องกัน และไม่ชัดว่ามันเป็น local secret หรือไม่ แต่ token นั้นมี สิทธิ์ผู้ดูแลทั้งหมด บน Railway
    AI ลบวอลุ่มที่เกี่ยวข้องตัวหนึ่งด้วย ID ผู้เขียนอธิบายอย่างกำกวมพอสมควรว่าตัวเองขออะไรไปบ้าง และบอกเพียงว่ามี "credential mismatch" แล้ว Claude ก็ริเริ่มลบวอลุ่มเพื่อพยายามแก้เอง การเขียนให้กำกวมอาจเป็นไปได้ว่าต้องการลดทอนความรับผิดของตัวเองอยู่บ้าง
    ยังมีการเปิดเผยด้วยว่า Railway เก็บแบ็กอัปไว้ในวอลุ่มเดียวกัน
    ผมคิดว่าการที่ต้นฉบับเรียกมันว่า "public API สำหรับลบฐานข้อมูล" นั้นเกินจริง
    ไม่ว่าจะมี AI หรือไม่ ผมมองว่าความรับผิดส่วนใหญ่อยู่ที่ Railway เพราะสิ่งนี้เกิดขึ้นได้ง่ายจากทั้งความผิดพลาดของคนหรือการกระทำโดยเจตนาร้าย
    ผมไม่เข้าใจคุณค่าของบริการคลาวด์นามธรรมสูงที่ได้เงิน VC อย่าง Railway, Vercel, Supabase เลยจริง ๆ มันคือการบวก margin ซ้อนบน margin เช่าเครื่องจริงจาก Hetzner สักตัวถูกกว่ามาก ความซับซ้อนและความเสี่ยงก็ใกล้เคียงกัน และยังพึ่งพาอินฟราที่โตแบบหุนหันพลันแล่นน้อยกว่า

    • ส่วนที่ผู้เขียนเขียนกำกวมว่าเขาขออะไรไว้บ้างนี่แหละที่ติดใจผม
      ไม่นานมานี้คุยกับแฟนแล้วเพิ่งตระหนักว่า 3 เดือนที่ผ่านมา ผมไม่ได้เขียนโค้ดเองแม้แต่บรรทัดเดียว และไม่ได้ debug เองเลย
      ถึงอย่างนั้นจากที่เห็น Claude ทำมา ก็ยังน่าเชื่อยากว่าเรื่องจะกระโดดจาก credential mismatch ไปสู่การลบวอลุ่มได้ทันที ผมเข้าใจว่า LLM เป็นเชิงความน่าจะเป็น แต่จาก "credential ผิด" ไปเป็น "ลบวอลุ่ม" มันมีโอกาสต่ำมาก
      สำหรับ Supabase ผมไม่รู้มากเท่า Railway/Vercel/Replit แต่ผมพูดได้ว่า Supabase เพิ่มคุณค่าเยอะมาก อย่างน้อยในช่วงเริ่มต้น มันช่วยให้คุณไม่ต้องเขียนเองประมาณครึ่งหนึ่งของสิ่งที่จะต้องทำ ถ้าวันหนึ่งต้นทุนแพงเกินไป พอมีรายได้แล้วก็ค่อยจ้างนักพัฒนาหรือใช้เวลาไปสร้างเองได้
    • เรื่อง Railway เก็บแบ็กอัปไว้ในวอลุ่มเดียวกันน่าจะไม่แม่นนัก
      snapshot น่าจะซิงก์ไปเก็บที่อื่น เช่น object storage แต่ในเชิงตรรกะ snapshot คงถูกผูกเป็นทรัพยากรที่วอลุ่มเป็นเจ้าของ และเมื่อลบวอลุ่ม snapshot ที่เกี่ยวข้องก็ถูกลบตามไปด้วย
      AWS EBS volume ก็น่าจะทำงานลักษณะนี้
    • ตอนนี้ใน HN คนชอบพูดกันว่า Heroku แย่ แต่ผมยังเห็น คุณค่าของ Heroku อยู่ ส่วนบริการใหม่ ๆ อื่น ๆ ผมค่อนข้างกังขา
      ค่าเริ่มต้นของ Firebase ก็ไร้สาระตั้งแต่แรกแล้ว
    • สิ่งหนึ่งที่ AI อาจผลักดันได้ดีคือ กระแสต่อต้าน SaaS การเปิด PC ราคาถูกสักเครื่องแล้วลองแพ็กเกจโอเพนซอร์สอะไรก็ได้ กลายเป็นเรื่องง่ายกว่าเดิมอย่างไม่มีที่สิ้นสุด เมื่อเทียบกับการกระโดดลงไปในตลาด credential นานาชนิด
      แต่ความสามารถของ LLM ที่สับสนระหว่าง dev, production, localhost และ remote จะไม่หายไป ผมกำลังทำเครื่องมือ/ทักษะสำหรับ opencode และพยายามผูกเข้ากับ Chrome/DevTools ผ่าน image ของ linuxserver.io แม้จะบังคับให้ใช้พอร์ตสุ่มได้ แต่มันก็อยากกลับไปใช้พอร์ตมาตรฐาน 9222 ทุกครั้งที่เกิด event แบบบีบอัด
      ผมเกือบอยากย้อนกลับไปใช้แบบเดิม แต่การไม่ใช้ค่าเริ่มต้นมีคุณค่าด้านความปลอดภัย และตอนนี้ยังมีคุณค่าด้านความปลอดภัยจากความกำกวมต่อ LLM ด้วย ค่าเริ่มต้นคือจุดที่ LLM อ่อนแอ มันอยากใช้ค่าเริ่มต้นเสมอ และมักลืมตลอดว่าควรทำงานบนระบบระยะไกล
      opencode ไม่มีทางบังคับ LLM ให้เป็นไปตามโปรโตคอลที่จำกัดความเสียหายไว้แค่ระบบระยะไกลหรือขอบเขตเครื่องมือแคบ ๆ ได้ คุณเปลี่ยนสิทธิ์ของหลายเครื่องมือได้ก็จริง แต่จุดอ่อนที่กรณีนี้เผยให้เห็นไม่ใช่ตรงนั้น
      จุดอ่อนคือ LLM เป็น ตัวแก้ปัญหา ระดับเฉลี่ย จึงมักเอนเอียงไปหากรณีใช้งานที่ไม่ใหม่ และพยายามทำเหมือนคำตอบใน Stack Overflow แม้สิ่งที่ผู้ใช้ต้องการจะไม่ใช่คำตอบแบบ Stack Overflow ก็ตาม

  • ระบบเชิงความน่าจะเป็น ที่อิง LLM อาจดีหรือแย่ก็ได้ในแง่การตัดสินใจว่าจะทำอะไร เหมือนกรณีนี้ ส่วนระบบเชิงกำหนดแน่นอนเหมาะกับการนำสิ่งนั้นไปปฏิบัติ
    ระบบ deploy ต้องเป็นแบบกำหนดแน่นอนเสมอ

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

    • มันคือ trade-off
      ถ้า LLM ต้องหยุดมาถามบ่อยขึ้น มันก็มีประโยชน์น้อยลง การปล่อยเอเจนต์รันไป 1 ชั่วโมง แม้ผลลัพธ์อาจแย่ลงบ้าง ก็ยังดีกว่าต้องคอยป้อนข้อมูลทุก 15 นาทีมาก
      วิธีแก้ด้านความปลอดภัยที่แท้จริงคือ sandbox ที่เหมาะสม