Три години, шість розробників, 30 000 зниклих безвісти. Коли землетрус сколихнув північну Венесуелу, програміст із Буенос-Айреса використав Claude Opus, щоб за три години створити вебпортал для пошуку зниклих безвісти — завдання, яке зазвичай займає цілий день. Другий розробник із Каліфорнії використав Replit, щоб за чотири години запустити інструмент для розподілу ресурсів. Швидка розробка дала сім'ям можливість публікувати фотографії та порівнювати обличчя з центральною базою даних, а також допомогла НУО поєднувати донорів із постраждалими, поки офіційні канали запізнювалися.

Чому ці зусилля мали значення

Екстрена інфраструктура Венесуели була паралізована: відключення електроенергії, зруйновані дороги та перевантажені телефонні мережі позбавили владу можливості координувати єдиний пошук. У перші години сім'ї намагалися знайти будь-який канал, щоб повідомити про родичів і попросити про допомогу. Додатки, створені діаспорою, заповнили цю прогалину, надаючи функціональні сервіси з низькою вимогою до інтернету, поки державна відповідь ще тільки формувалася.

Як розробникам це вдалося

Кодер із Буенос-Айреса надав Claude Opus простий промпт, що описував сайт, де користувачі могли б завантажувати фото, додавати ім'я та запускати пошук за схожістю у наявному списку. Claude згенерував фронтенд-форму, конвеєр обробки зображень та схему бази даних, а потім повернув готовий до розгортання пакет коду. Розробник підправив кілька промптів, запустив код на хмарному інстансі, і сайт запрацював менш ніж за три години.

По інший бік Тихого океану розробник із Каліфорнії відкрив робоче середовище Replit, ввів короткий опис «панелі керування розподілом ресурсів», яка б приймала пропозиції донорів і відображала потреби поблизу, і дозволив ШІ побудувати каркас back-end API, невеликий admin UI та простий процес автентифікації. Через чотири години інструмент став доступним за мобільним URL.

Обидві команди зробили користувацький досвід максимально легким. Вони обрали інтерфейси чатів у стилі WhatsApp, оскільки більшість постраждалих мали доступ лише до мережі 2G і мали обмежений заряд батареї. Жодних важких нативних додатків не створювалося; натомість вони покладалися на сторінки HTML 5, які швидко завантажувалися і працювали офлайн, коли це було можливо.

Практичні висновки

  • ШІ як множник – Генерація коду за допомогою промптів перетворила тривалий спринт на справу кількох годин.
  • Ставтеся до моделі як до нестабільного рівня – API мовних моделей можуть змінювати ціни, ліміти запитів або зникати. Побудова основної логіки виключно на промптах прив'язує продукт до мінливої цілі.
  • Спирайтеся на стійку схему – Модель даних для зниклих безвісти (фото, ім'я, останнє відоме місцезнаходження, статус) залишається корисною під час різних криз. Після визначення її можна використовувати повторно без перенавчання ШІ.
  • Проектуйте з урахуванням обмежень – Низька пропускна здатність мережі, перебої з електроенергією та відсутність електронних пошт змусили команди обрати текстові інтерфейси та просту автентифікацію за номером телефону. Ці обмеження дозволили створити програмне забезпечення, яке працює там, де складніші рішення зазнали б невдачі.

Ризики та контраргументи

Прискорення розробки має свої компроміси. Код, згенерований ШІ, може приховувати помилки, небезпечні налаштування за замовчуванням або неефективні запити, які проявляються лише під навантаженням. Використання сторонніх сервісів ШІ також вносить волатильність витрат; раптове підвищення цін може в одну мить зробити безкоштовний інструмент дорогим. Нарешті, відсутність формального тестування під час такої поспішності може залишити неврахованими граничні випадки, що створює ризик помилкових збігів у базі даних зниклих безвісти — серйозна етична проблема.

На що варто звернути увагу далі

  • Стандартизовані схеми даних для стихійних лих – Якщо гуманітарні групи приймуть спільний формат для людей, ресурсів і локацій, інструменти з підтримкою ШІ зможуть легше підключатися та обмінюватися даними через кордони.
  • Хостинг моделей з відкритим кодом – Ендпоінти мовних моделей, керовані спільнотою, могли б пом'якшити ризик раптового відключення API або стрибків цін.
  • Увага регуляторів – Уряди можуть почати ретельно перевіряти програмне забезпечення для надзвичайних ситуацій, створене ШІ, на предмет конфіденційності даних і надійності, особливо коли йдеться про особисті фотографії та дані про місцезнаходження.
  • Спільнотні платформи – Мережі діаспор уже створюють канали швидкого реагування в месенджерах; інтеграція інструментів ШІ безпосередньо в ці простори могла б скоротити час розгортання в майбутньому на кілька хвилин.

Підсумок для розробників

Якщо вам потрібно випустити додаток для реагування на кризи вже сьогодні, почніть із споживча моделі ШІ, щоб накидати UI, згенерувати шаблонний код і розгорнути хмарний екземпляр. Потім закріпіть ключові компоненти: чітку, портативну схему даних, мінімалістичний UI, що працює на найслабшому з очікуваних пристроїв, та автентифікацію, яка не залежить від електронної пошти. Ставтеся до результатів роботи ШІ як до чернетки, а не до готового продукту, і будьте готові замінити рівень моделі, якщо її умови використання зміняться. У разі катастрофи швидкість рятує життя, але стабільність рятує їх знову згодом.

Джерело: dev.to/davekurian/diaspora-coders-assemble-earthquake-response-in-hours-with-ai-4c66