Trzy godziny, sześciu programistów, 30 000 osób zaginionych. Gdy trzęsienie ziemi wstrząsnęło północną Wenezuelą, programista z Buenos Aires użył Claude Opus, aby w trzy godziny stworzyć portal internetowy dla osób zaginionych – zadanie, które normalnie zajęłoby cały dzień. Drugi programista z Kalifornii użył Replit, aby w cztery godziny uruchomić narzędzie do dopasowywania zapasów. Szybkie budowanie rozwiązań dało rodzinom możliwość publikowania zdjęć i porównywania twarzy z centralną bazą danych, a organizacjom pozarządowym pomogło łączyć darczyńców z ofiarami, podczas gdy oficjalne kanały działały z opóźnieniem.

Dlaczego ten wysiłek był ważny

Infrastruktura kryzysowa Wenezueli była sparaliżowana: przerwy w dostawie prądu, zniszczone drogi i przeciążone sieci telefoniczne uniemożliwiły władzom koordynację zjednoczonych działań poszukiwawczych. W pierwszych godzinach rodziny desperacko szukały jakiegokolwiek kanału, aby zgłosić zaginięcie bliskich i poprosić o pomoc. Aplikacje zbudowane przez diasporę wypełniły tę lukę, dostarczając funkcjonalne usługi o niskim zapotrzebowaniu na transfer danych, podczas gdy reakcja państwa dopiero się kształtowała.

Jak programiści to osiągnęli

Programista z Buenos Aires podał Claude Opus prosty prompt opisujący stronę, na której użytkownicy mogliby przesyłać zdjęcia, dodawać imiona i przeprowadzać wyszukiwanie podobieństwa w istniejącej liście. Claude wygenerował formularz front-end, potok przetwarzania obrazów oraz schemat bazy danych, a następnie zwrócił gotowy do wdrożenia pakiet kodu. Programista dopracował kilka promptów, uruchomił kod na instancji chmurowej, a strona ruszyła w mniej niż trzy godziny.

Po drugiej stronie Pacyfiku programista z Kalifornii otworzył obszar roboczy Replit, wpisał krótki opis „panelu dopasowywania zapasów” (supply-matching dashboard), który miał przyjmować oferty darczyńców i wyświetlać pobliskie potrzeby, i pozwolił AI na stworzenie szkieletu API back-endowego, małego interfejsu administracyjnego oraz prostego przepływu uwierzytelniania. Cztery godziny później narzędzie było dostępne pod adresem URL zoptymalizowanym pod urządzenia mobilne.

Obie grupy zadbały o to, aby doświadczenie użytkownika było lekkie. Wybrali interfejsy czatu w stylu WhatsApp, ponieważ większość ofiar miała dostęp jedynie do danych 2G i ograniczoną żywotność baterii. Nie budowano ciężkich aplikacji natywnych; zamiast tego postawiono na strony HTML 5, które szybko się ładowały i w miarę możliwości działały offline.

Praktyczne wnioski

  • AI jako mnożnik – Generowanie kodu sterowane promptami zmieniło całodniowy sprint w kwestię kilku godzin.
  • Traktuj model jako warstwę zmienną – API modeli językowych mogą zmieniać ceny, limity zapytań lub znikać. Budowanie logiki rdzeniowej wyłącznie w oparciu o prompty uzależnia produkt od nieprzewidywalnego celu.
  • Opieraj się na trwałym schemacie – Model danych dla osób zaginionych — zdjęcie, imię, ostatnia znana lokalizacja, status — pozostaje użyteczny w różnych kryzysach. Po zdefiniowaniu można go ponownie wykorzystać bez konieczności ponownego trenowania AI.
  • Projektuj z uwzględnieniem ograniczeń – Niska przepustowość łącza, przerywane dostawy prądu i brak kont e-mail zmusiły zespoły do wyboru interfejsów tekstowych i prostego uwierzytelniania numerem telefonu. Te ograniczenia zaowocowały oprogramowaniem, które działa tam, gdzie bardziej rozbudowane rozwiązania by zawiodły.

Ryzyka i kontrargumenty

Zwiększona prędkość wiąże się z pewnymi kompromisami. Kod wygenerowany przez AI może ukrywać błędy, niebezpieczne ustawienia domyślne lub nieefektywne zapytania, które ujawniają się dopiero pod obciążeniem. Poleganie na zewnętrznych usługach AI wprowadza również zmienność kosztów; nagła podwyżka cen może sprawić, że narzędzie, które dotychczas było darmowe w utrzymaniu, z dnia na dzień stanie się kosztowne. Wreszcie, brak formalnych testów w tak pośpiesznym trybie może pozostawić nieobsłużone przypadki brzegowe, co niesie ryzyko błędnych dopasowań w bazie danych osób zaginionych — co stanowi poważną kwestię etyczną.

Na co warto zwrócić uwagę w przyszłości

  • Ustandaryzowane schematy danych katastroficznych – Jeśli grupy humanitarne przyjmą wspólny format dla danych o ludziach, zapasach i lokalizacjach, narzędzia wspomagane przez AI będą mogły łatwiej się w nie włączać i wymieniać danymi ponad granicami.
  • Hosting modeli open-source – Punkty końcowe (endpoints) modeli językowych zarządzane przez społeczność mogłyby złagodzić ryzyko nagłego wyłączenia API lub skoków cen.
  • Uwaga regulatorów – Rządy mogą zacząć badać oprogramowanie ratunkowe generowane przez AI pod kątem prywatności danych i niezawodności, zwłaszcza gdy w grę wchodzą osobiste zdjęcia i dane o lokalizacji.
  • Platformy społecznościowe – Sieci diaspory już teraz tworzą kanały szybkiego reagowania w aplikacjach do przesyłania wiadomości; integracja narzędzi AI bezpośrednio w tych przestrzeniach mogłaby skrócić czas przyszłych wdrożeń o cenne minuty.

Podsumowanie dla programistów

Jeśli musisz dziś wdrożyć aplikację do reagowania kryzysowego, zacznij od konsumenckiego modelu AI, aby naszkicować interfejs użytkownika (UI), wygenerować kod bazowy (boilerplate) i uruchomić instancję w chmurze. Następnie zabezpiecz kluczowe elementy: przejrzysty, przenośny schemat danych, minimalistyczny interfejs UI, który działa na najsłabszym urządzeniu, jakiego możesz się spodziewać, oraz uwierzytelnianie, które nie zależy od adresu e-mail. Traktuj wyniki pracy AI jako szkic, a nie gotowy produkt, i bądź gotowy na zastąpienie warstwy modelu, jeśli zmienią się jego warunki użytkowania. W obliczu katastrofy szybkość ratuje życie, ale stabilność ratuje je ponownie w późniejszym czasie.

Źródło: dev.to/davekurian/diaspora-coders-assemble-earthquake-response-in-hours-with-ai-4c66