Saa tatu, watengenezaji sita, watu 30,000 hawajulikani walipo. Tetemeko la ardhi lilipotikisa kaskazini mwa Venezuela, mwanaprogramu mmoja huko Buenos Aires alitumia Claude Opus kutengeneza tovuti ya kutafuta watu waliopotea ndani ya saa tatu—kazi ambayo kwa kawaida ingechukua siku nzima. Mtengenezaji mwingine huko California alitumia Replit kuzindua zana ya kuoanisha mahitaji na vifaa ndani ya saa nne. Ujenzi huo wa haraka uliwapa familia njia ya kupakia picha na kulinganisha nyuso dhidi ya kanzi data kuu, na kusaidia mashirika yasiyo ya kiserikali (NGOs) kuunganisha wafadhili na wahanga wakati njia rasmi zilikuwa zikichelewa.

Kwa nini juhudi hizo zilikuwa muhimu

Miundombinu ya dharura ya Venezuela ilikuwa imeparara: kukatika kwa umeme, barabara zilizoharibika na mitandao ya simu iliyozidiwa ilizifanya mamlaka kushindwa kuratibu utafutaji mmoja uliounganishwa. Katika saa za mapema, familia zilijitahidi kutafuta njia yoyote ya kutoa taarifa kuhusu jamaa zao na kuomba msaada. Programu zilizoundwa na watu wa diaspora zilijaza pengo hilo, zikitoa huduma zinazofanya kazi vizuri hata kwa intaneti ndogo wakati majibu ya serikali yalikuwa bado yanajipanga.

Jinsi watengenezaji walivyofika hapo

Msimboji (coder) wa Buenos Aires alimpa Claude Opus maelekezo (prompt) rahisi yakielezea tovuti ambapo watumiaji wangeweza kupakia picha, kuweka jina na kufanya utafutaji wa ufanano dhidi ya orodha iliyopo. Claude ilitengeneza fomu ya upande wa mbele (front-end), mfumo wa usindikaji wa picha (image-processing pipeline) na muundo wa kanzi data (database schema), kisha ikarudisha kifurushi cha msimbo (code bundle) kinachoweza kutumika. Mtengenezaji aliboresha maelekezo machache, akaendesha msimbo kwenye mfumo wa wingu (cloud instance), na tovuti ikawa hai ndani ya saa tatu.

Upande wa pili wa Pasifiki, mtengenezaji wa California alifungua nafasi ya kazi ya Replit, akaandika maelezo mafupi ya “dashibodi ya kuoanisha mahitaji” ambayo ingepokea ofa za wafadhili na kuonyesha mahitaji ya karibu, na kuruhusu AI kutengeneza muundo wa back-end API, UI ndogo ya usimamizi (admin UI) na mtiririko rahisi wa uthibitishaji (authentication flow). Saa nne baadaye, zana hiyo ilipatikana kupitia URL inayofaa simu.

Timu zote mbili zilifanya uzoefu wa mtumiaji uwe mwepesi. Walichagua miongozo ya mazungumzo inayofanana na WhatsApp kwa sababu wahanga wengi wangeweza tu kupata data ya 2G na walikuwa na uwezo mdogo wa betri. Hakuna programu nzito za asili (native apps) zilizoundwa; badala yake, walitegemea kurasa za HTML 5 ambazo zilipakia haraka na kufanya kazi bila mtandao inapowezekana.

Mafunzo ya vitendo

  • AI kama kigeuzi (multiplier) – Uundaji wa msimbo unaoendeshwa na maelekezo (prompts) ulibadilisha kazi ya siku nzima kuwa ya saa chache tu.
  • Chukulia modeli kama tabaka linalobadilika (volatile layer) – API za modeli za lugha zinaweza kubadilisha bei, mipaka ya kasi (rate limits) au kutoweka. Kujenga mantiki ya msingi kwa kutegemea maelekezo pekee kunaunganisha bidhaa kwenye lengo linalobadilika kila wakati.
  • Simamia muundo thabiti (durable schema) – Muundo wa data kwa ajili ya watu waliopotea—picha, jina, eneo la mwisho lilijulikana, hali—unabaki kuwa muhimu katika majanga mbalimbali. Ikishafafanuliwa, inaweza kutumika tena bila kuhitaji kuifundisha AI upya.
  • Sanifu kulingana na vikwazo – Bandwidth ndogo, umeme usio thabiti na ukosefu wa akaunti za barua pepe uliwalazimu timu kuchagua miongozo inayotegemea maandishi na uthibitishaji rahisi wa namba ya simu. Vikwazo hivyo vilizalisha programu inayofanya kazi pale ambapo suluhisho bora zaidi zingeshindwa.

Riski na hoja za kinyume

Ongezeko la kasi huja na mabadiliko ya kutoa na kuchukua (trade-offs). Msimbo unaozalishwa na AI unaweza kuficha hitilafu (bugs), mipangilio isiyo salama au maswali yasiyo na ufanisi ambayo hujitokeza tu wakati wa mzigo mkubwa wa kazi. Kutegemea huduma za AI za upande wa tatu pia huleta mabadiliko ya gharama; ongezeko la ghafla la bei linaweza kufanya zana inayofanya kazi bure kuwa ghali usiku mmoja. Hatimaye, ukosefu wa majaribio rasmi katika haraka kama hiyo unaweza kuacha matukio ya pembeni (edge cases) bila kushughulikiwa, jambo linaloweza kusababisha utambuzi wa uongo katika kanzi data ya watu waliopotea—changamoto kubwa ya kimaadili.

Nini cha kufuatilia baadaye

  • Miundo ya data ya majanga iliyosanifishwa – Ikiwa makundi ya kibinadamu yatatumia muundo wa pamoja kwa watu, vifaa na maeneo, zana zinazosaidiwa na AI zinaweza kuunganishwa kwa urahisi zaidi na kushiriki data kuvuka mipaka.
  • Uwekaji wa modeli wa chanzo huru (open-source) – Miunganisho (endpoints) ya modeli za lugha inayosimamiwa na jamii inaweza kupunguza hatari ya kuzimwa kwa ghafla kwa API au ongezeko la bei.
  • Uangalizi wa kisheria – Serikali zinaweza kuanza kukagua programu za dharura zinazozalishwa na AI kwa ajili ya faragha ya data na uaminifu, hasa wakati picha za kibinafsi na data za eneo zinapohusika.
  • Majukwaa ya jamii – Mitandao ya diaspora tayari inaunda njia za mwitikio wa haraka kwenye programu za ujumbe; kuunganisha zana za AI moja kwa moja kwenye maeneo hayo kunaweza kupunguza muda wa utekelezaji katika siku zijazo.

Hitimisho kwa watengenezaji

Ikiwa unahitaji kuachia programu ya kuitikia majanga leo, anza kwa kutumia modeli ya AI ya watumiaji ili kuchora muundo wa UI, kutengeneza kodi ya msingi (boilerplate), na kuanzisha mfumo wa wingu (cloud instance). Kisha imarisha sehemu muhimu: mpangilio wa data (data schema) ulio wazi na unaoweza kuhamishwa, UI rahisi inayofanya kazi kwenye kifaa dhaifu zaidi unachotegemea, na uthibitishaji (authentication) usiotegemea barua pepe. Chukulia matokeo ya AI kama rasimu, si bidhaa ya mwisho, na uwe tayari kubadilisha tabaka la modeli (model layer) ikiwa masharti yake yatabadilika. Katika janga, kasi huokoa maisha, lakini uimara huokoa maisha tena baadaye.

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