Drie uur, zes ontwikkelaars, 30.000 vermisten. Toen een aardbeving Noord-Venezuela deed schudden, gebruikte een programmeur in Buenos Aires Claude Opus om in drie uur een webportaal voor vermiste personen op te zetten — een taak die normaal gesproken een hele dag zou duren. Een tweede ontwikkelaar in Californië gebruikte Replit om in vier uur een tool voor het matchen van voorraden te lanceren. De snelle ontwikkelingen boden gezinnen een manier om foto's te plaatsen en gezichten te vergelijken met een centrale database, en hielpen ngo's om donateurs met slachtoffers te koppelen terwijl de officiële kanalen achterbleven.

Waarom de inspanning ertoe deed

De noodinfrastructuur van Venezuela was verlamd: stroomuitval, kapotte wegen en overbelaste telefoonnetwerken zorgden ervoor dat de autoriteiten geen gecoördineerde zoekactie konden uitvoeren. In de eerste uren zochten families wanhopig naar elk beschikbaar kanaal om familieleden te melden en hulp te vragen. De door de diaspora gebouwde apps vulden dat gat door functionele, internet-lichte diensten te leveren terwijl de reactie van de staat nog in opbouw was.

Hoe de ontwikkelaars dit bereikten

De programmeur in Buenos Aires gaf Claude Opus een eenvoudige prompt met een beschrijving van een site waar gebruikers een foto konden uploaden, een naam konden toevoegen en een gelijkeniszoekopdracht konden uitvoeren tegen een bestaande lijst. Claude genereerde het front-end formulier, de image-processing pipeline en het databaseschema, en leverde vervolgens een inzetbare codebundel op. De ontwikkelaar paste een paar prompts aan, draaide de code op een cloud-instantie en de site ging in minder dan drie uur live.

Aan de andere kant van de Stille Oceaan opende de ontwikkelaar in Californië een Replit-workspace, typte een korte beschrijving van een "supply-matching dashboard" dat donatieaanbiedingen zou verwerken en nabijgelegen behoeften zou tonen, en liet de AI de back-end API, een kleine admin UI en een eenvoudig authenticatieproces opzetten. Vier uur later was de tool bereikbaar via een mobielvriendelijke URL.

Beide teams hielden de gebruikerservaring lichtgewicht. Ze kozen voor chatinterfaces in de stijl van WhatsApp, omdat de meeste slachtoffers alleen toegang hadden tot 2G-data en een beperkte batterijduur hadden. Er werden geen zware native apps gebouwd; in plaats daarvan vertrouwden ze op HTML 5-pagina's die snel laadden en indien mogelijk offline werkten.

De praktische lessen

  • AI als vermenigvuldiger – Door prompts gestuurde codegeneratie veranderde een sprint van een dag in een kwestie van uren.
  • Beschouw het model als een volatiele laag – API's van taalmodellen kunnen prijzen, limieten of de dienst zelf veranderen of laten verdwijnen. Het bouwen van kernlogica uitsluitend op basis van prompts koppelt het product aan een bewegend doelwit.
  • Veranker op een duurzaam schema – Het datamodel voor vermiste personen — foto, naam, laatst bekende locatie, status — blijft nuttig tijdens verschillende crises. Eenmaal gedefinieerd, kan het worden hergebruikt zonder de AI opnieuw te trainen.
  • Ontwerp rondom beperkingen – Lage bandbreedte, wisselende stroomvoorziening en een gebrek aan e-mailaccounts dwongen de teams om te kiezen voor tekstgebaseerde interfaces en eenvoudige authenticatie via telefoonnummers. Die beperkingen leidden tot software die werkt op plekken waar uitgebreidere oplossingen zouden falen.

Risico's en tegenargumenten

De snelheidswinst gaat gepaard met nadelen. Door AI gegenereerde code kan bugs, onveilige standaardinstellingen of inefficiënte queries verbergen die pas onder zware belasting aan het licht komen. Het vertrouwen op AI-diensten van derden introduceert ook kostenvolatiliteit; een plotselinge prijsverhoging kan een gratis te gebruiken tool van de ene op de andere dag duur maken. Tot slot kan het gebrek aan formele tests bij dergelijke haast ervoor zorgen dat randgevallen onopgemerkt blijven, wat het risico op foutieve matches in een database voor vermiste personen met zich meebrengt — een ernstige ethische kwestie.

Waar u in de toekomst op moet letten

  • Gestandaardiseerde schema's voor rampgegevens – Als humanitaire groepen een gemeenschappelijk formaat adopteren voor personen, voorraden en locaties, kunnen AI-ondersteunde tools gemakkelijker worden aangesloten en gegevens over de grenzen heen delen.
  • Open-source hosting van modellen – Door de community beheerde endpoints voor taalmodellen kunnen het risico op plotselinge API-storingen of prijsstijgingen verminderen.
  • Regulering – Overheden kunnen beginnen met het controleren van door AI gegenereerde noodsoftware op gegevensprivacy en betrouwbaarheid, vooral wanneer het gaat om persoonlijke foto's en locatiegegevens.
  • Community-platforms – Diaspora-netwerken vormen al kanalen voor snelle respons op messaging-apps; het direct integreren van AI-tools in die ruimtes zou de tijd voor toekomstige inzet kunnen verkorten.

De kern voor ontwikkelaars

Als je vandaag een crisis-respons-app moet uitrollen, begin dan met een consumenten-AI-model om de UI te schetsen, boilerplate te genereren en een cloud-instantie op te zetten. Leg vervolgens de onderdelen vast die er echt toe doen: een duidelijk, portabel dataschema, een minimale UI die werkt op het zwakste apparaat dat je verwacht, en authenticatie die niet afhankelijk is van e-mail. Beschouw de AI-output als een concept, niet als een eindproduct, en wees bereid om de model-laag te vervangen als de voorwaarden veranderen. In een rampensituatie redt snelheid levens, maar stabiliteit redt ze later opnieuw.

Bron: dev.to/davekurian/diaspora-coders-assemble-earthquake-response-in-hours-with-ai-4c66