Mwandishi wa jukwaa la bima la miaka 20 alipitisha tiketi 108 za msaada kupitia mfumo maalum wa AI-agent na matokeo yake ni mtiririko wa kazi (workflow) unaobadilisha kazi ya saa nyingi ya mhandisi mwandamizi kuwa dakika chache, mabadiliko ambayo yanaweza kubadilisha jinsi makampuni makubwa yanavyohifadhi kodi za zamani (legacy code).

Kwa nini mifumo ya zamani (legacy systems) ni muhimu zaidi kuliko kodi mpya

Programu ya bima inayozungumziwa ni monolith yenye mistari 2.3 milioni ya kodi na takriban vifurushi (packages) 1,000 vya PL/SQL. Ukubwa wake pekee unaufanya uwe haiwezekani kwa mtu mmoja kumiliki msingi mzima wa kodi (codebase). Ongeza kwenye hilo mkanganyiko wa vigezo vya usanidi (configuration parameters) vya mteja, nyaraka zilizotawanyika, na kumbukumbu ya tiketi zinazoanzia mwaka 2017, na kikwazo halisi kinakuwa “kutafuta muktadha” (finding context), siyo kuandika kodi.

Sifa nyingi za kisasa za AI hujikita katika kutengeneza kodi mpya kwa ajili ya miradi mipya (greenfield projects). Katika hali hii, sehemu ngumu siyo sintaksia ya PL/SQL bali ni kupata sehemu sahihi ya mantiki (logic), usanidi husika, na tiketi ya kihistoria iliyoelezea tatizo kwa mara ya kwanza. Mhandisi mzoefu anaweza kutumia saa nyingi kuunganisha vidokezo kutoka GitLab, SVN, wikis, na tiketi za zamani za msaada. AI agent hufanya kazi hiyo hiyo kwa dakika chache.

Mtiririko wa kazi katika vitendo

Tiketi mpya inapowasilishwa, mwandishi huendesha amri moja tu. Kisha, AI agent hufanya yafuatayo:

  • Huchukua maandishi ya tiketi na faili zozote zilizounganishwa kupitia API ya mfumo wa tiketi.
  • Huendesha utafutaji wa maneno muhimu (keyword) na vector kwenye kumbukumbu nzima ya tiketi ili kuibua kesi zilizopita zinazofanana.
  • Huuliza maktaba binafsi ya skripti za SQL zinazoweza kutumika tena.
  • Huchunguza historia ya kodi katika mifumo ya udhibiti wa matoleo (GitLab au SVN).

Matokeo yote huunganishwa katika faili moja ambayo pia inapendekeza hatua inayofuata—kawaida ni marekebisho ya kodi, rasimu ya jibu kwa mteja, au ombi la uchunguzi zaidi.

Uwezo uliomo ndani

Mwandishi amefafanua “ujuzi” (skills) 24 kwa ajili ya agent huyu, yaliyogawanywa katika makundi manne:

  • Ufikiaji wa muktadha – kusoma API, miongozo, na kanzidata ili kupata ukweli muhimu.
  • Ujuzi wa nyanja (Domain knowledge) – kutafsiri sheria za uhasibu wa bima na usanifu wa mfumo.
  • Uandishi – kutengeneza vipande vya PL/SQL (snippets) na kuvipanga kwa ajili ya kuweka (deployment).
  • Meta – kutambua mifumo na kutengeneza ujuzi mpya kiotomatiki inapohitajika.

Ujuzi huu unamruhusu agent kufanya kazi kama mhandisi msaidizi (junior engineer) ambaye halali, akionyesha mstari sahihi wa kodi au usanidi unaorejelewa kwenye tiketi.

Njia za usalama zilizojengwa ndani ya mzunguko

Uendeshaji wa kiotomatiki katika mazingira ya uzalishaji (production environment) unahitaji kinga. Mwandishi anafuata sheria mbili rahisi:

  1. Static validation – kila skripti inayotengenezwa huendeshwa kupitia EXPLAIN PLAN dhidi ya schema hai. Hii hukagua makosa ya sintaksia au mantiki bila kuendesha kodi yenyewe.
  2. Dual-model confirmation – AI agent wa pili, anayejitegemea, hukagua mabadiliko yoyote yanayoonekana kuwa na hatari. Ikiwa mifano yote miwili itafikia hitimisho lile lile, mwandishi huendelea; vinginevyo, tiketi hupelekwa kwa ajili ya mapitio ya kibinadamu.

Vipimo hivi vinazuia mchakato huo kuwa "black box" ambayo inaweza kuharibu muamala muhimu wa bima bila kukusudia.

Faida zinazoongezeka

Matokeo ya kila tiketi huunganishwa tena kwenye rekodi ya tiketi, na kutengeneza msingi wa maarifa (knowledge base) unaokua. Tatizo linalofanana linapotokea miezi au miaka baadaye, agent anaweza kusoma siyo tu suluhisho la awali bali pia mantiki iliyopelekea suluhisho hilo. Kwa hakika, kila tiketi iliyotatuliwa inakuwa data ya mafunzo kwa tiketi za baadaye, ikiharakisha mzunguko zaidi.

Mapungufu ya kweli

  • Majaribio ya kibinadamu bado yapo – mwandishi bado anathibitisha mabadiliko katika mazingira ya majaribio kabla ya kuyaweka kwenye mfumo mkuu.
  • Hakuna vipimo vya mwisho vilivyowekwa – ingawa muda unaookolewa unaonekana kuwa mkubwa, mwandishi hajapima kwa usahihi upungufu wa saa.
  • Mpangilio wa binafsi – utekelezaji wa sasa upo kwenye kituo kimoja cha kazi (workstation); kuupanua kwa timu nzima kutahitaji uhandisi wa ziada.

Vikwazo hivi vinazuia mbinu hii kuwa bidhaa iliyo tayari kutumika (turnkey product), lakini havipunguzi hoja kuu: AI inaweza kupunguza muda wa kukusanya muktadha kutoka saa nyingi hadi dakika chache.

Nini cha kufuatilia baadaye

Jaribio la mwandishi ni uthibitisho wa dhana (proof-of-concept) badala ya bidhaa ya kibiashara. Hatua zinazofuata za kimantiki ni pamoja na:

  • Kurasimisha vipimo – kufuatilia muda wa utatuzi wa tiketi kabla na baada ya AI pipeline ili kuunda hoja ya kibiashara.
  • Usambazaji wa timu – kuifunga agent kama huduma ya pamoja ili wahandisi wengi waweze kufaidika na msingi wa maarifa uleule.
  • Ujumuishaji na CI/CD – kuingiza skripti zilizothibitishwa moja kwa moja kwenye mfumo wa continuous-integration pipeline kunaweza kukamilisha mzunguko kutoka kwenye tiketi hadi uzalishaji bila uhamishaji wa mikono.

Ikiwa upanuzi huu utafanikiwa, mfumo huu unaweza kuwa kielelezo kwa mashirika mengine yanayopambana na codebases kubwa na zilizokita mizizi.

Muhtasari

Thamani halisi ya AI katika mazingira ya legacy si katika kuandika kodi mpya kiotomatiki, bali katika kutoa muktadha sahihi papo hapo. Kwa kubadilisha saa nyingi za kazi za uchunguzi za mhandisi mwandamizi kuwa dakika chache, mfumo wa kazi wa AI-agent unaweza kuweka mifumo ya zamani ikiwa katika hali ya kufanya kazi, kupunguza gharama za usaidizi, na kujenga kidogo kidogo hifadhi ya maarifa inayojijenga yenyewe. Jaribio linaonyesha kuwa, kwa legacy software, ongezeko kubwa la tija linatokana na kurahisisha utafutaji wa majibu, na si kutokana na kutengeneza kodi mpya.