Wakala wa AI Wanapoandika Msimbo, Kitufe cha Kuidhinisha Kinaacha Kuwa na Maana

Dhana iliyovunjika kimya kimya

Ukaguzi wa msimbo (code review) unategemea dhana ya zamani sana hata hakuna anayeitamka waziwazi: mhandisi mwingine ndiye aliyeandika msimbo. Insha iliyochapishwa kwenye DEV.to inasema dhana hiyo haiaminiki tena. Wakala wa kuandika msimbo (coding agent) sasa anaweza kutekeleza kipengele, kuendesha majaribio, kurekebisha kasoro zilizoonekana, kuboresha muundo wa msimbo (refactor) na kuandaa pull request (PR, ombi la kuunganisha mabadiliko). Binadamu anayefungua PR hiyo huenda alitumia muda wake kumwelekeza na kumkagua wakala badala ya kuandika chochote mwenyewe.

Hitimisho la mwandishi si kwamba ukaguzi umepitwa na wakati. Ni kinyume chake: uthibitishaji una umuhimu mkubwa kuliko wakati wowote. Kilichovunjika ni hesabu. Katika mtiririko wa zamani, Mhandisi A anaandika, Mhandisi B anakagua, mabadiliko yanaunganishwa. Katika mtiririko wa mawakala, wakala anaandika, Mhandisi A anakagua, Mhandisi A anafungua PR. Kama Mhandisi A alichunguza mabadiliko hayo kikweli na yuko tayari kuyamiliki, insha inauliza: idhini ya pili ya kawaida ya binadamu inaongeza nini hasa? Kufungua PR hakufanyi msimbo kuaminika zaidi. Tukio la maana lilitokea kabla ya kitufe hicho kuwepo.

Ukaguzi ulikuwa unanunua nini hasa

Ukaguzi daima umefanya kazi mbili kwa wakati mmoja. Ya kwanza ni kutafuta kasoro: mtu wa pili anakamata hitilafu, anaona dhana isiyofaa ya muundo, au anahoji uamuzi wa usanifu. Ya pili ni ya kijamii: umiliki wa pamoja na kusambaza maarifa, ili msimbo usiwe mali ya mtu mmoja. Insha inakubali kwamba zote mbili bado zina thamani. Lakini inasema hazihudumiwi kwa usawa pale mwandishi wa msimbo ni mashine.

Mfano wa kufikirika unaotolewa ni mwenzako mwenye mapungufu (flawed peer): fikiria mwenzako ambaye ni mwepesi sana, anajua mambo mengi mno kuhusu programu, lakini hana uzoefu na mfumo wako mahususi, na mara kwa mara hufanya makosa yanayoonekana wazi baada ya kutokea. Hungeunganisha kazi yake bila kuikagua. Ungeweka vikwazo, ungeendesha ukaguzi wa kiotomatiki, na ungemwita mtaalamu kwa mabadiliko yanayohusika sana. Mwandishi anabainisha kuwa hivyo ndivyo mitiririko ya kazi ya mawakala inavyoonekana tayari.

Hivyo basi, sentensi ambayo inaweza kuwafanya mameneja wa uhandisi wasijisikie vizuri: idadi ya vitufe vya kuidhinisha vilivyobonyezwa si sawa na kiasi cha uthibitishaji kilichofanyika. Timu zilizohitaji ukaguzi mmoja zinaweza kuona ni sawa kuchukulia mabadiliko ya wakala yaliyokaguliwa kikamilifu kuwa yamekamilika. Timu zinazohitaji wawili zinaweza kubakiza mkaguzi mmoja baada ya PR. Sera inapaswa kufuata kiwango cha hatari: uhamishaji wa hifadhidata (database migration), mabadiliko ya uthibitishaji wa mtumiaji (authentication) au mtiririko wa malipo si lebo ya kitufe.

Kikwazo kinahamia; hakipotei

Hatari kubwa zaidi ni wingi. Kuzalisha msimbo kumekuwa nafuu kuliko ilivyowahi kuwa. Kuukagua hakujawa nafuu. Kama wakala anazalisha msimbo mara kumi zaidi na jibu ni kuwafanya binadamu wakague msimbo mara kumi zaidi, kikwazo kinahama tu kutoka kuandika programu hadi kuithibitisha. Makini ya binadamu ndiyo rasilimali adimu, na haiwezi kununuliwa kwa bei za mawakala.

Jibu la insha ni kupunguza kile kinachohitaji macho ya binadamu kabisa. Baadhi ya aina za kasoro hazipaswi kutegemea mkaguzi kuziona. Zinapaswa kuwa haziwezekani kuandikwa. Kikwazo cha hifadhidata (database constraint) hutekeleza kanuni ili msanidi asilazimike kuikumbuka. Mtiririko unaoweza kutoka tu kutoka Pending hadi Approved au Rejected unapaswa kuundwa kama hali dhahiri, si maandishi holela ambayo kila njia ya msimbo inatumaini kuyashughulikia. Finite state machines (mashine za hali zenye ukomo), aina za data (types), mikataba (contracts), mipaka ya API, uchambuzi tuli (static analysis) na msimbo unaozalishwa kiotomatiki vyote hufanya kazi ileile: lengo si kuwafanya wasanidi wawe makini zaidi, ni kufanya makosa fulani yasiwezekane.

Juu ya hayo kuna uthibitishaji wa kiotomatiki, kisha mhandisi anayechukua umiliki, kisha safu ya hiari ambayo mwandishi anaiita mawakala wapinzani (adversarial agents): wataalamu ambao kazi yao si kusema LGTM (inaonekana sawa kwangu) bali kushambulia. Wakala wa usalama anayewinda njia za kukwepa uidhinishaji na uingizaji wa msimbo hatari (injection). Wakala wa utendaji anayetafuta hoja za N+1 (maswali ya hifadhidata yanayojirudia bila sababu), mgongano wa rasilimali na miito mingi mno ya mtandao. Wengine kwa ajili ya uaminifu wa mfumo, utangamano wa nyuma, muundo wa API, majaribio na ufikivu. Hawathibitishi chochote; nao pia ni wenzako wenye mapungufu. Wanachotoa ni jaribio jingine huru la kutafuta tatizo, linaloundwa kwa kila mabadiliko badala ya kutumika kwa usawa kwa yote. Uthibitishaji unakuwa wa kuunganishwa vipande: ukaguzi zaidi bila mzunguko mrefu wa utoaji au binadamu zaidi kwenye foleni.

Nani yuko hatarini kutokana na hili? Timu yoyote ambayo hadithi yake ya ubora kwa kweli ni hadithi ya kufuata taratibu (compliance): idhini mbili kwa kila PR, bila kujali hatari. Sera hiyo itaendelea kutoa alama za kijani huku kiasi cha msimbo ambao haujachunguzwa kikikua chini yake. Na kazi ya kijamii ya ukaguzi, sehemu ya kusambaza maarifa ambayo insha inasema bado ni muhimu, haina mbadala dhahiri ikiwa mkaguzi wa pili ataondolewa kwa ajili ya ufanisi na hakuna kinachowekwa mahali pake.

Maswali Unayopaswa Kujiuliza

• Mhandisi wako anapofungua PR kwa msimbo ulioandikwa na wakala, je, anaweza kueleza kwa nini utekelezaji umeundwa hivyo, au anaweza kusema tu kwamba majaribio yalipita?
• Ni sheria zipi za ukaguzi zilizopo kwa sasa zipo kwa sababu zinakamata kasoro, na zipi zipo kwa sababu mkaguzi wa hesabu au ripoti ya tukio ilidai nambari fulani?
• Ni kiasi gani cha kile wakaguzi wako wanachokagua kwa macho kingeweza kutekelezwa kwa kikwazo cha schema, aina ya data, au mashine ya hali dhahiri badala yake, na nani anamiliki kazi hiyo?
• Ukiondoa mkaguzi wa pili wa binadamu, ni nini kinachochukua nafasi ya kusambaza maarifa ambako ukaguzi ulikuwa unafanya kimya kimya kwa timu yako?
• Wakala mpinzani wa usalama au utendaji anaposema hakuna tatizo, timu yako inaamini hiyo inamaanisha nini, na imani hiyo imeandikwa mahali popote?

Cha Kufuatilia Baadaye

Fuatilia kama timu zitaanza kutofautisha sera yao ya ukaguzi kulingana na aina ya mabadiliko badala ya kutumia idadi moja ya idhini kwa kila kitu. Dalili ni uhamishaji wa hifadhidata, mabadiliko ya uthibitishaji wa mtumiaji au njia ya malipo kupewa mfumo mzito zaidi wa uthibitishaji kuliko mabadiliko madogo ya kiolesura. Kama idadi ya idhini itabaki ileile huku wingi wa miunganisho ukipanda, sera hiyo imekuwa maigizo tu, na tukio la kwanza litakalofuatiliwa hadi msimbo ambao hakuna aliyeusoma kikweli ndilo litakalolithibitisha hilo.