ثلاث ساعات، ستة مطورين، و30,000 مفقود. عندما هز زلزال شمال فنزويلا، استخدم مبرمج في بوينس آيرس نموذج Claude Opus لإنشاء بوابة إلكترونية للمفقودين في ثلاث ساعات فقط—وهي مهمة كانت تستغرق عادةً يوماً كاملاً. واستخدم مطور ثانٍ في كاليفورنيا منصة Replit لإطلاق أداة لمطابقة الإمدادات في أربع ساعات. وفرت هذه البناءات السريعة للعائلات وسيلة لنشر الصور ومقارنة الوجوه بقاعدة بيانات مركزية، وساعدت المنظمات غير الحكومية في الربط بين المتبرعين والضحايا بينما كانت القنوات الرسمية متأخرة.

لماذا كان لهذا الجهد أهمية

كانت البنية التحتية للطوارئ في فنزويلا مشلولة: انقطاع التيار الكهربائي، والطرق المقطوعة، وشبكات الهاتف المثقلة بالأعباء، جعلت السلطات غير قادرة على تنسيق عملية بحث موحدة. في الساعات الأولى، سارعت العائلات للبحث عن أي وسيلة للإبلاغ عن أقاربهم وطلب المساعدة. وقد سدت التطبيقات التي طورها المغتربون تلك الفجوة، حيث قدمت خدمات وظيفية خفيفة على الإنترنت بينما كانت استجابة الدولة لا تزال في طور التشكيل.

كيف وصل المطورون إلى هذه النتيجة

قام المبرمج في بوينس آيرس بتزويد Claude Opus بأمر نصي (prompt) بسيط يصف موقعاً يمكن للمستخدمين من خلاله تحميل صورة، ووسم اسم، وإجراء بحث عن التشابه مقابل قائمة موجودة. قام Claude بإنشاء نموذج الواجهة الأمامية (front-end)، ومسار معالجة الصور، ومخطط قاعدة البيانات (database schema)، ثم أعاد حزمة برمجية جاهزة للنشر. قام المطور بتعديل بعض الأوامر، وشغل الكود على مثيل سحابي (cloud instance)، وأصبح الموقع متاحاً في أقل من ثلاث ساعات.

وعبر المحيط الهادئ، فتح المطور في كاليفورنيا مساحة عمل في Replit، وكتب وصفاً موجزاً لـ "لوحة تحكم لمطابقة الإمدادات" (supply-matching dashboard) التي ستستقبل عروض المتبرعين وتعرض الاحتياجات القريبة، وترك للذكاء الاصطناعي بناء الهيكل الأساسي لـ API الخلفية (back-end API)، وواجهة مستخدم إدارية صغيرة، وتدفق مصادقة بسيط. وبعد أربع ساعات، أصبح الوصول إلى الأداة متاحاً عبر رابط (URL) متوافق مع الهاتف المحمول.

حافظ كلا الفريقين على تجربة مستخدم خفيفة. اختاروا واجهات دردشة بأسلوب WhatsApp لأن معظم الضحايا لم يكن بإمكانهم الوصول إلا إلى بيانات 2G وكان لديهم عمر بطارية محدود. لم يتم بناء تطبيقات أصلية (native apps) ثقيلة؛ وبدلاً من ذلك، اعتمدوا على صفحات HTML 5 التي يتم تحميلها بسرعة وتعمل دون اتصال بالإنترنت كلما أمكن ذلك.

الدروس العملية المستفادة

  • الذكاء الاصطناعي كمضاعف للقدرات – حول توليد الكود المعتمد على الأوامر النصية (prompt-driven) سباقاً يستغرق يوماً كاملاً إلى مسألة ساعات.
  • تعامل مع النموذج كطبقة متقلبة – يمكن أن تغير واجهات برمجة تطبيقات (APIs) النماذج اللغوية أسعارها، أو حدود المعدل، أو قد تختفي تماماً. إن بناء المنطق الأساسي اعتماداً كلياً على الأوامر النصية يربط المنتج بهدف متحرك.
  • الارتكاز على مخطط بيانات مستدام – يظل نموذج البيانات للمفقودين—الصورة، الاسم، آخر موقع معروف، الحالة—مفيداً عبر الأزمات المختلفة. وبمجرد تحديده، يمكن إعادة استخدامه دون الحاجة لإعادة تدريب الذكاء الاصطناعي.
  • التصميم وفقاً للقيود – أجبرت محدودية النطاق الترددي، وانقطاع التيار الكهربائي، وعدم توفر حسابات بريد إلكتروني الفرقَ على اختيار واجهات نصية ومصادقة بسيطة عبر رقم الهاتف. أنتجت تلك القيود برمجيات تعمل في الأماكن التي قد تفشل فيها الحلول الأكثر تعقيداً.

المخاطر والنقاط المقابلة

تأتي زيادة السرعة مع وجود مقايضات. يمكن للكود المولد بواسطة الذكاء الاصطناعي أن يخفي أخطاء برمجية (bugs)، أو إعدادات افتراضية غير آمنة، أو استعلامات غير فعالة لا تظهر إلا تحت ضغط العمل. كما أن الاعتماد على خدمات الذكاء الاصطناعي التابعة لجهات خارجية يؤدي أيضاً إلى تقلب التكاليف؛ فقد يؤدي ارتفاع مفاجئ في الأسعار إلى جعل أداة مجانية التشغيل باهظة الثمن بين عشية وضحاها. وأخيراً، قد يؤدي نقص الاختبار الرسمي في مثل هذه الاندفاعات إلى ترك حالات استثنائية دون تغطية، مما يخاطر بحدوث تطابقات خاطئة في قاعدة بيانات المفقودين—وهو مصدر قلق أخلاقي خطير.

ما يجب مراقبته مستقبلاً

  • مخططات بيانات موحدة للكوارث – إذا اعتمدت المجموعات الإنسانية تنسيقاً مشتركاً للأشخاص والإمدادات والمواقع، فستتمكن الأدوات المدعومة بالذكاء الاصطناعي من الاتصال بسهولة أكبر ومشاركة البيانات عبر الحدود.
  • استضافة النماذج مفتوحة المصدر – يمكن لنقاط نهاية (endpoints) النماذج اللغوية التي تديرها المجتمعات أن تخفف من خطر الإغلاق المفاجئ لـ API أو ارتفاع الأسعار.
  • الاهتمام التنظيمي – قد تبدأ الحكومات في فحص برمجيات الطوارئ المولدة بالذكاء الاصطناعي من حيث خصوصية البيانات والموثوقية، خاصة عندما يتعلق الأمر بالصور الشخصية وبيانات الموقع.
  • المنصات المجتمعية – تشكل شبكات المغتربين بالفعل قنوات استجابة سريعة على تطبيقات المراسلة؛ ودمج أدوات الذكاء الاصطناعي مباشرة في تلك المساحات قد يختصر دقائق ثمينة في عمليات النشر المستقبلية.

الخلاصة للمطورين

إذا كنت بحاجة إلى إطلاق تطبيق للاستجابة للأزمات اليوم، فابدأ باستخدام نموذج ذكاء اصطناعي استهلاكي لرسم واجهة المستخدم، وإنشاء الأكواد الأساسية (boilerplate)، وتشغيل مثيل سحابي (cloud instance). ثم قم بتثبيت الأجزاء المهمة: مخطط بيانات (data schema) واضح وقابل للنقل، وواجهة مستخدم بسيطة تعمل على أضعف جهاز تتوقعه، ونظام مصادقة لا يعتمد على البريد الإلكتروني. تعامل مع مخرجات الذكاء الاصطناعي كمسودة، وليس كمنتج نهائي، وكن مستعداً لاستبدال طبقة النموذج (model layer) إذا تغيرت شروطه. في حالات الكوارث، تنقذ السرعة الأرواح، لكن الاستقرار ينقذها مرة أخرى لاحقاً.

المصدر: dev.to/davekurian/diaspora-coders-assemble-earthquake-response-in-hours-with-ai-4c66