3 ชั่วโมง, นักพัฒนา 6 คน, ผู้สูญหาย 30,000 คน เมื่อแผ่นดินไหวสั่นสะเทือนทางตอนเหนือของเวเนซุเอลา โปรแกรมเมอร์ในบัวโนสไอเรสได้ใช้ Claude Opus เพื่อสร้างพอร์ทัลเว็บสำหรับค้นหาผู้สูญหายภายในเวลาเพียง 3 ชั่วโมง ซึ่งเป็นงานที่ปกติจะต้องใช้เวลาเต็มวัน นักพัฒนาอีกคนในแคลิฟอร์เนียใช้ Replit เพื่อเปิดตัวเครื่องมือจับคู่สิ่งของบรรเทาทุกข์ภายใน 4 ชั่วโมง การสร้างเครื่องมืออย่างรวดเร็วนี้ช่วยให้ครอบครัวต่างๆ สามารถโพสต์รูปภาพและเปรียบเทียบใบหน้ากับฐานข้อมูลกลางได้ อีกทั้งยังช่วยให้ NGO จับคู่ผู้บริจาคกับผู้ประสบภัยได้ ในขณะที่ช่องทางทางการยังทำงานล่าช้า

ทำไมความพยายามนี้ถึงสำคัญ

โครงสร้างพื้นฐานด้านฉุกเฉินของเวเนซุเอลาอยู่ในสภาพวิกฤต: ไฟฟ้าดับ ถนนขาด และเครือข่ายโทรศัพท์ที่ทำงานหนักเกินไป ทำให้เจ้าหน้าที่ไม่สามารถประสานงานการค้นหาที่เป็นเอกภาพได้ ในช่วงชั่วโมงแรกๆ ครอบครัวต่างๆ ต่างพยายามหาทุกช่องทางเพื่อรายงานข้อมูลญาติและขอความช่วยเหลือ แอปพลิเคชันที่สร้างโดยกลุ่มคนเวเนซุเอลาในต่างแดนได้เข้ามาเติมเต็มช่องว่างนั้น โดยให้บริการที่ใช้งานได้จริงและใช้ปริมาณอินเทอร์เน็ตน้อย ในขณะที่การตอบสนองของภาครัฐยังอยู่ในช่วงเริ่มต้น

นักพัฒนาทำได้อย่างไร

นักเขียนโค้ดในบัวโนสไอเรสป้อน prompt แบบธรรมดาให้แก่ Claude Opus โดยอธิบายถึงเว็บไซต์ที่ผู้ใช้สามารถอัปโหลดรูปภาพ ติดแท็กชื่อ และทำการค้นหาความคล้ายคลึงกับรายการที่มีอยู่เดิม Claude สร้างฟอร์ม front-end, กระบวนการประมวลผลรูปภาพ (image-processing pipeline) และโครงสร้างฐานข้อมูล (database schema) จากนั้นจึงส่งชุดโค้ดที่พร้อมใช้งานกลับมา นักพัฒนาปรับแต่ง prompt อีกเล็กน้อย รันโค้ดบน cloud instance และเว็บไซต์ก็ออนไลน์ได้ภายในเวลาไม่ถึง 3 ชั่วโมง

ข้ามมหาสมุทรแปซิฟิก นักพัฒนาในแคลิฟอร์เนียเปิดพื้นที่ทำงานใน Replit พิมพ์คำอธิบายสั้นๆ เกี่ยวกับ “supply-matching dashboard” ที่จะรับข้อมูลข้อเสนอจากผู้บริจาคและแสดงความต้องการในพื้นที่ใกล้เคียง และปล่อยให้ AI สร้างโครงสร้าง back-end API, ส่วนติดต่อผู้ใช้สำหรับผู้ดูแลระบบ (admin UI) ขนาดเล็ก และขั้นตอนการยืนยันตัวตนแบบง่าย สี่ชั่วโมงต่อมา เครื่องมือนี้ก็สามารถเข้าถึงได้ผ่าน URL ที่รองรับการใช้งานบนมือถือ

ทั้งสองทีมเน้นประสบการณ์ผู้ใช้ที่เบาและเรียบง่าย พวกเขาเลือกใช้หน้าจอแชทสไตล์ WhatsApp เนื่องจากผู้ประสบภัยส่วนใหญ่เข้าถึงได้เพียงข้อมูล 2G และมีแบตเตอรี่ที่จำกัด ไม่มีการสร้างแอปพลิเคชันแบบ native ที่หนักเครื่อง แต่หันไปใช้หน้าเว็บ HTML 5 ที่โหลดได้อย่างรวดเร็วและทำงานแบบออฟไลน์ได้เมื่อเป็นไปได้

บทเรียนที่นำไปใช้ได้จริง

  • AI ในฐานะตัวคูณประสิทธิภาพ – การสร้างโค้ดที่ขับเคลื่อนด้วย prompt เปลี่ยนงานที่ต้องใช้เวลาทั้งวันให้เหลือเพียงไม่กี่ชั่วโมง
  • มองว่าโมเดลเป็นเลเยอร์ที่มีความผันผวน – API ของโมเดลภาษาอาจมีการเปลี่ยนแปลงราคา ข้อจำกัดด้านอัตราการใช้งาน (rate limits) หรือหายไปได้ การสร้างตรรกะหลัก (core logic) โดยพึ่งพาเพียง prompt จะทำให้ผลิตภัณฑ์ผูกติดกับเป้าหมายที่เปลี่ยนแปลงตลอดเวลา
  • ยึดโยงกับโครงสร้างข้อมูล (schema) ที่ยั่งยืน – โมเดลข้อมูลสำหรับผู้สูญหาย เช่น รูปถ่าย, ชื่อ, สถานที่ล่าสุดที่พบ และสถานะ เป็นสิ่งที่ยังมีประโยชน์ในทุกวิกฤต เมื่อกำหนดไว้แล้ว ก็สามารถนำกลับมาใช้ใหม่ได้โดยไม่ต้องฝึกฝน AI ใหม่
  • ออกแบบภายใต้ข้อจำกัด – แบนด์วิดท์ต่ำ ไฟฟ้าที่ไม่เสถียร และการขาดบัญชีอีเมล บีบให้ทีมต้องเลือกใช้หน้าจอแบบข้อความและการยืนยันตัวตนผ่านหมายเลขโทรศัพท์แบบง่าย ข้อจำกัดเหล่านี้ทำให้เกิดซอฟต์แวร์ที่ใช้งานได้จริงในจุดที่โซลูชันที่ซับซ้อนกว่าอาจล้มเหลว

ความเสี่ยงและข้อโต้แย้ง

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

สิ่งที่ต้องจับตามองต่อไป

  • โครงสร้างข้อมูลภัยพิบัติที่เป็นมาตรฐาน – หากกลุ่มบรรเทาทุกข์นำรูปแบบมาตรฐานมาใช้สำหรับข้อมูลบุคคล สิ่งของ และสถานที่ เครื่องมือที่ใช้ AI ช่วยจะสามารถเชื่อมต่อได้ง่ายขึ้นและแชร์ข้อมูลข้ามพรมแดนได้
  • การโฮสต์โมเดลแบบโอเพนซอร์ส – เอนด์พอยต์ (endpoints) ของโมเดลภาษาที่ดูแลโดยชุมชนอาจช่วยลดความเสี่ยงจากการปิดบริการ API หรือการพุ่งสูงขึ้นของราคาอย่างกะทันหัน
  • การตรวจสอบจากหน่วยงานกำกับดูแล – รัฐบาลอาจเริ่มตรวจสอบซอฟต์แวร์ฉุกเฉินที่สร้างโดย AI ในด้านความเป็นส่วนตัวของข้อมูลและความน่าเชื่อถือ โดยเฉพาะเมื่อเกี่ยวข้องกับรูปถ่ายส่วนบุคคลและข้อมูลตำแหน่งที่ตั้ง
  • แพลตฟอร์มชุมชน – เครือข่ายกลุ่มคนในต่างแดนกำลังสร้างช่องทางตอบโต้ที่รวดเร็วบนแอปส่งข้อความ การรวมเครื่องมือ AI เข้ากับพื้นที่เหล่านั้นโดยตรงอาจช่วยลดเวลาในการติดตั้งใช้งานในอนาคตได้อีกหลายนาที

บทสรุปสำหรับนักพัฒนา

หากคุณจำเป็นต้องปล่อยแอปพลิเคชันสำหรับตอบโต้ภาวะวิกฤตในวันนี้ ให้เริ่มจากการใช้โมเดล AI สำหรับผู้ใช้งานทั่วไปเพื่อร่าง UI, สร้างโค้ดพื้นฐาน (boilerplate) และเริ่มใช้งานอินสแตนซ์บนคลาวด์ (cloud instance) จากนั้นให้กำหนดส่วนสำคัญต่างๆ ให้ชัดเจน: โครงสร้างข้อมูล (data schema) ที่ชัดเจนและเคลื่อนย้ายได้ง่าย, UI ที่เรียบง่ายที่สุดซึ่งสามารถทำงานได้บนอุปกรณ์ที่สเปกต่ำที่สุดที่คุณคาดการณ์ไว้ และระบบยืนยันตัวตนที่ไม่ต้องพึ่งพาอีเมล ให้มองว่าผลลัพธ์จาก AI เป็นเพียงร่างเบื้องต้น ไม่ใช่ผลิตภัณฑ์สำเร็จรูป และเตรียมพร้อมที่จะเปลี่ยนเลเยอร์ของโมเดลหากเงื่อนไขการใช้งานมีการเปลี่ยนแปลง ในสถานการณ์ภัยพิบัติ ความรวดเร็วช่วยรักษาชีวิตคน แต่ความเสถียรจะช่วยรักษาชีวิตพวกเขาไว้ได้อีกครั้งในภายหลัง

ที่มา: dev.to/davekurian/diaspora-coders-assemble-earthquake-response-in-hours-with-ai-4c66