سه ساعت، شش توسعه‌دهنده، ۳۰,۰۰۰ مفقود. وقتی زلزله‌ای شمال ونزوئلا را لرزاند، یک برنامه‌نویس در بوئنوس آیرس از Claude Opus استفاده کرد تا تنها در سه ساعت یک پورتال وب برای افراد مفقود شده راه‌اندازی کند؛ کاری که به طور معمول یک روز کامل زمان می‌برد. توسعه‌دهنده دوم در کالیفرنیا از Replit استفاده کرد تا در چهار ساعت یک ابزار تطبیق منابع راه‌اندازی کند. این ساخت‌های سریع به خانواده‌ها راهی داد تا عکس‌ها را منتشر کنند و چهره‌ها را با یک پایگاه داده مرکزی مقایسه کنند، و همچنین به سازمان‌های غیردولتی (NGOs) کمک کرد تا در حالی که کانال‌های رسمی با تأخیر عمل می‌کردند، اهداکنندگان را با قربانیان پیوند دهند.

چرا این تلاش اهمیت داشت

زیرساخت‌های اضطراری ونزوئلا فلج شده بود: قطعی برق، جاده‌های تخریب‌شده و شبکه‌های تلفنی بیش از حد بارگذاری‌شده، مقامات را از هماهنگ کردن یک جستجوی واحد باز داشت. در ساعات اولیه، خانواده‌ها برای یافتن هر کانالی جهت گزارش وضعیت بستگان و درخواست کمک دست‌وپا می‌زدند. اپلیکیشن‌هایی که توسط مهاجران ساخته شده بودند، این شکاف را پر کردند و در حالی که پاسخ دولت هنوز در حال شکل‌گیری بود، خدماتی کاربردی و کم‌حجم (internet-light) ارائه دادند.

توسعه‌دهندگان چگونه به این مرحله رسیدند

برنامه‌نویس بوئنوس آیرس یک پرامپت ساده به Claude Opus داد که سایتی را توصیف می‌کرد که در آن کاربران بتوانند عکس آپلود کنند، نامی را برچسب‌گذاری کنند و یک جستجوی شباهت را در لیست موجود انجام دهند. Claude فرم فرانت‌اند، خط لوله پردازش تصویر و طرح‌واره (schema) پایگاه داده را تولید کرد و سپس یک بسته کد قابل استقرار را بازگرداند. توسعه‌دهنده چند پرامپت را اصلاح کرد، کد را روی یک نمونه ابری (cloud instance) اجرا کرد و سایت در کمتر از سه ساعت آنلاین شد.

در آن سوی اقیانوس آرام، توسعه‌دهنده کالیفرنیا یک فضای کاری Replit را باز کرد، توضیحات کوتاهی از یک «داشبورد تطبیق منابع» نوشت که پیشنهادهای اهداکنندگان را دریافت کرده و نیازهای نزدیک را نمایش دهد، و اجازه داد هوش مصنوعی ساختار (scaffold) API بک‌اند، یک رابط کاربری ادمین کوچک و یک جریان احراز هویت ساده را ایجاد کند. چهار ساعت بعد، این ابزار از طریق یک URL سازگار با موبایل در دسترس بود.

هر دو تیم تجربه کاربری را سبک نگه داشتند. آن‌ها رابط‌های چت به سبک WhatsApp را انتخاب کردند زیرا اکثر قربانیان فقط به داده‌های 2G دسترسی داشتند و عمر باتری محدودی داشتند. هیچ اپلیکیشن بومی (native) سنگینی ساخته نشد؛ در عوض، آن‌ها بر صفحات HTML 5 تکیه کردند که سریع بارگذاری می‌شدند و در صورت امکان به‌صورت آفلاین کار می‌کردند.

درس‌های کاربردی

  • هوش مصنوعی به عنوان یک ضریب توان – تولید کد مبتنی بر پرامپت، یک فعالیت روزانه را به چند ساعت کاهش داد.
  • با مدل به عنوان یک لایه ناپایدار برخورد کنید – APIهای مدل‌های زبانی می‌توانند قیمت‌گذاری، محدودیت نرخ (rate limits) یا خودشان را تغییر دهند یا ناپدید شوند. ساخت منطق اصلی صرفاً در پرامپت‌ها، محصول را به هدفی متغیر وابسته می‌کند.
  • بر یک طرح‌واره (schema) بادوام تکیه کنید – مدل داده برای افراد مفقود شده — عکس، نام، آخرین مکان شناخته شده، وضعیت — در طول بحران‌ها مفید باقی می‌ماند. پس از تعریف شدن، می‌توان بدون آموزش مجدد هوش مصنوعی از آن استفاده کرد.
  • طراحی بر اساس محدودیت‌ها – پهنای باند کم، برق متناوب و نبود حساب‌های ایمیل، تیم‌ها را مجبور کرد تا رابط‌های متنی و احراز هویت ساده با شماره تلفن را انتخاب کنند. این محدودیت‌ها نرم‌افزاری تولید کردند که در جاهایی که راهکارهای غنی‌تر شکست می‌خورند، کار می‌کند.

ریسک‌ها و نکات متقابل

افزایش سرعت با هزینه‌هایی همراه است. کدهای تولید شده توسط هوش مصنوعی می‌توانند باگ‌ها، تنظیمات پیش‌فرض ناامن یا پرس‌وجوهای (queries) ناکارآمدی را پنهان کنند که تنها تحت فشار بار کاری خود را نشان می‌دهند. تکیه بر سرویس‌های هوش مصنوعی شخص ثالث نیز باعث نوسان هزینه می‌شود؛ یک افزایش قیمت ناگهانی می‌تواند ابزاری را که اجرای آن رایگان بود، یک‌شبه گران کند. در نهایت، نبود تست‌های رسمی در چنین عجله‌هایی ممکن است موارد خاص (edge cases) را پوشش ندهد و خطر تطبیق‌های اشتباه در پایگاه داده افراد مفقود شده را به همراه داشته باشد — که یک نگرانی اخلاقی جدی است.

آنچه باید در آینده زیر نظر داشت

  • طرح‌واره‌های استاندارد داده‌های بلایا – اگر گروه‌های بشردوستانه قالب مشترکی برای افراد، منابع و مکان‌ها اتخاذ کنند، ابزارهای کمکی هوش مصنوعی می‌توانند راحت‌تر متصل شده و داده‌ها را در فراتر از مرزها به اشتراک بگذارند.
  • میزبانی مدل‌های متن‌باز – نقاط پایانی (endpoints) مدل‌های زبانی که توسط جامعه مدیریت می‌شوند، می‌توانند خطر خاموشی ناگهانی API یا جهش قیمت‌ها را کاهش دهند.
  • توجه نظارتی – دولت‌ها ممکن است بررسی نرم‌افزارهای اضطراری تولید شده توسط هوش مصنوعی را از نظر حریم خصوصی داده‌ها و قابلیت اطمینان، به‌ویژه زمانی که عکس‌های شخصی و داده‌های مکان در میان است، آغاز کنند.
  • پلتفرم‌های اجتماعی – شبکه‌های مهاجران در حال حاضر در حال تشکیل کانال‌های پاسخ سریع در اپلیکیشن‌های پیام‌رسان هستند؛ ادغام ابزارهای هوش مصنوعی مستقیماً در آن فضاها می‌تواند زمان استقرار در آینده را کاهش دهد.

خلاصه برای توسعه‌دهندگان

اگر امروز نیاز دارید یک اپلیکیشن پاسخ به بحران را عرضه کنید، با یک مدل هوش مصنوعی عمومی شروع کنید تا رابط کاربری (UI) را طراحی اولیه کنید، کدهای پایه (boilerplate) را تولید کنید و یک نمونه ابری (cloud instance) را راه‌اندازی کنید. سپس بخش‌های حیاتی را تثبیت کنید: یک طرحواره داده‌ای (data schema) شفاف و قابل انتقال، یک رابط کاربری حداقلی که روی ضعیف‌ترین دستگاه مورد انتظار شما کار کند، و احراز هویتی که به ایمیل وابسته نباشد. با خروجی هوش مصنوعی مانند یک پیش‌نویس برخورد کنید، نه یک محصول نهایی، و آماده باشید که در صورت تغییر شرایط، لایه مدل را جایگزین کنید. در یک فاجعه، سرعت جان‌ها را نجات می‌دهد، اما پایداری دوباره آن‌ها را در آینده نجات خواهد داد.

منبع: dev.to/davekurian/diaspora-coders-assemble-earthquake-response-in-hours-with-ai-4c66