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

Почему это было важно

Инфраструктура чрезвычайных ситуаций в Венесуэле была парализована: перебои с электричеством, разрушенные дороги и перегруженные телефонные сети не позволяли властям координировать единые поисковые операции. В первые часы семьи отчаянно искали любые каналы связи, чтобы сообщить о пропавших родственниках и запросить помощь. Приложения, созданные диаспорой, заполнили этот пробел, предоставляя функциональные сервисы с низким потреблением трафика, пока государственные ответные меры еще только формировались.

Как разработчики этого добились

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

На другом конце Тихого океана разработчик из Калифорнии открыл рабочее пространство Replit, ввел краткое описание «панели управления распределением ресурсов» (supply-matching dashboard), которая должна была принимать предложения от доноров и отображать ближайшие потребности, и позволил ИИ создать каркас back-end API, небольшой интерфейс администратора и простую систему аутентификации. Через четыре часа инструмент стал доступен по URL-адресу, оптимизированному для мобильных устройств.

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

Практические выводы

  • ИИ как множитель эффективности — генерация кода на основе промптов превратила многочасовой спринт в дело нескольких часов.
  • Рассматривайте модель как нестабильный слой — API языковых моделей могут менять цены, лимиты запросов или вовсе исчезать. Построение основной логики исключительно на промптах привязывает продукт к постоянно меняющейся цели.
  • Опирайтесь на устойчивую схему данных — модель данных для пропавших без вести (фото, имя, последнее известное местоположение, статус) остается полезной в условиях любых кризисов. Однажды определив её, вы сможете использовать повторно без переобучения ИИ.
  • Проектируйте с учетом ограничений — низкая пропускная способность сети, перебои с электричеством и отсутствие учетных записей электронной почты вынудили команды выбрать текстовые интерфейсы и простую аутентификацию по номеру телефона. Эти ограничения позволили создать программное обеспечение, которое работает там, где более сложные решения терпят неудачу.

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

Ускорение темпов работы сопряжено с компромиссами. Сгенерированный ИИ код может скрывать баги, небезопасные настройки по умолчанию или неэффективные запросы, которые проявляются только под нагрузкой. Использование сторонних ИИ-сервисов также вносит волатильность в расходы: внезапное повышение цен может в одночасье сделать бесплатный инструмент дорогим. Наконец, отсутствие формального тестирования в условиях такой спешки может оставить нераскрытыми пограничные случаи, что создает риск ложных совпадений в базе данных пропавших без вести — серьезная этическая проблема.

На что стоит обратить внимание

  • Стандартизированные схемы данных для чрезвычайных ситуаций — если гуманитарные группы примут общий формат для данных о людях, припасах и местоположениях, инструменты с поддержкой ИИ смогут легче интегрироваться и обмениваться данными через границы.
  • Хостинг моделей с открытым исходным кодом — эндпоинты языковых моделей, управляемые сообществом, могли бы снизить риск внезапного отключения API или скачков цен.
  • Внимание регуляторов — правительства могут начать проверять программное обеспечение для чрезвычайных ситуаций, созданное ИИ, на предмет конфиденциальности данных и надежности, особенно когда речь идет о личных фотографиях и данных о местоположении.
  • Комьюнити-платформы — сети диаспор уже формируют каналы быстрого реагирования в мессенджерах; интеграция инструментов ИИ непосредственно в эти пространства могла бы сократить время развертывания в будущем на несколько драгоценных минут.

Главный вывод для разработчиков

Если вам нужно выпустить приложение для реагирования на кризисные ситуации прямо сейчас, начните с потребительской модели ИИ, чтобы набросать интерфейс, сгенерировать шаблонный код и развернуть облачный инстанс. Затем зафиксируйте критически важные компоненты: четкую, переносимую схему данных, минималистичный интерфейс, работающий на самом слабом из ожидаемых устройств, и аутентификацию, не зависящую от электронной почты. Относитесь к результату работы ИИ как к черновику, а не как к готовому продукту, и будьте готовы заменить слой модели, если условия её использования изменятся. В условиях катастрофы скорость спасает жизни, но стабильность спасает их снова, когда наступит время.

Источник: dev.to/davekurian/diaspora-coders-assemble-earthquake-response-in-hours-with-ai-4c66