Timu za uhandisi zinazofanya tathmini ya coding agents kwa kawaida huanza na swali lisilo sahihi. Wanataka kujua ni kiasi gani wakala (agent) anaweza kuwa huru. Je, anaweza kumiliki sehemu gani ya pipeline? Je, anaweza kuandika spec, kuhariri repository, na kupeleka kwenye production bila kumsumbua mtu yeyote? Maonyesho (demos) hufanya uraibu huu kuwa rahisi. Unaona mtiririko wa kazi uliopangwa vizuri ambapo prompt moja huchochea mfululizo wa marekebisho na usambazaji, na silika ni kutafuta uwezo huo huo ndani ya shirika lako. Lakini mvuto wa nje ni kanuni mbaya ya usanifu. Maswali bora ni machache na hayavutii sana: nani alimpa kitu hiki mamlaka, ni mifumo gani inaweza kuigusa kweli, na nini kinatokea wakati bila shaka unapoandika kitu kisicho sahihi?

Mtego wa Uhuru (The Autonomy Trap)

Uhuru unaovutia ni mtego. Unatufundisha kusherehekea bots zinazozalisha maelezo ya kiufundi, zinazobadilisha repositories, na kusambaza kodi huku zikidai kwa utulivu kuwa kazi imekamilika. Hiyo si uhandisi. Ni kuweka imani bila uhakika ukiwa na shell access. Kazi yenyewe inakuwa rahisi sana kuzalisha. Model yoyote inaweza kutoa kodi, nyaraka, au mipango ya usanifu (architecture plans) ndani ya sekunde chache. Lakini gharama halisi katika uundaji wa programu haijawahi kuwa kasi ya kuchapa. Daima imekuwa ni validation, review, na uamuzi wa makini wa kusema ndiyo, hii ni sahihi na salama kusambazwa. Kazi iliyozalishwa ni rahisi. Idhini (approval) ni ghali. Makampuni yatakayogundua jinsi ya kushughulikia idhini kwa usafi na uthabiti ndiyo yatakuwa yale yanayozalisha mifumo ya kuaminika.

Kwa Nini Uhakiki wa Kujitegemea Unafeli

Hatari huonekana katika mifumo inayotabirika. Model inaandaa mpango na kisha inatathmini ikiwa mpango huo ni mzuri. Agent unafanya marekebisho kwenye codebase yako na kukueleza kwa nini mabadiliko yake ni salama. Chombo kinatekeleza amri na kuomba msamaha badala ya ruhusa. Kila moja kati ya hizi inawakilisha hitilafu ile ile ya msingi. Ikiwa agent anazalisha specification, kitu nje ya agent huyo lazima kikiidhinishe kabla haijawa ukweli. Ikiwa agent anabadilisha kodi, mchakato tofauti lazima ukague diff. Kumruhusu mzalishaji (generator) kufanya kazi kama mhakiki wake mwenyewe si njia ya mkato. Ni hitilafu ya kimuundo iliyofichwa kama urahisi.

Prompt Si Mifumo ya Ruhusa

Huwezi kulinda agent kwa maneno ya ujanja. Kumwambia model awe mwangalifu au aombe ruhusa kabla ya kufuta kitu hakutengenezi mpaka. Prompt si mifumo ya ruhusa. Kabla ya kumruhusu agent akaribie sehemu ya production, unahitaji orodha ya kweli ya uwezo wake. Je, inaweza kusoma repository nzima? Je, inaweza kutekeleza shell commands? Je, inaweza kufungua browser? Je, inaweza kuvuta data za wateja kwenye context window yake? Timu nyingi hazijui majibu kamili. Wanadhani chombo hicho kimefungwa kwenye sandbox wakati kwa kweli kina ufikiaji wa kuandika (write access) kwenye njia muhimu. Chora eneo la hatari kwanza. Kisha jenga kuta.

Jenga Mfumo wa Udhibiti wa Ngazi mbalimbali

Mara tu unapoelewa kile agent anachoweza kufanya, unda mfumo wa udhibiti unaolinganisha hatari na vikwazo (friction). Vitendo vya hatari ndogo, kama vile kusasisha nyaraka za ndani au kupanga kodi kwa utaratibu, vinaweza kufanya kazi kiotomatiki. Vitendo vya hatari ya kati, kama vile refactoring ya module au kuongeza dependency mpya, vinapaswa kufika kwenye checkpoint ambapo binadamu au test suite iliyothibitishwa inahakikisha hatua hiyo. Vitendo vya hatari kubwa, kama vile kupeleka kwenye production, kubadilisha miundombinu, au kufikia data nyeti, vinahitaji muidhinishaji tofauti ambaye hakuhusika katika uzalishaji. Kila kitendo lazima kitoe audit trail. Unapaswa kuweza kurudia kuona ni faili gani zilisomwa, ni zana gani zilitumika, na ni maamuzi gani yalifanywa. Agentic development si leseni ya kuruka reviews. Vikwazo vya kuchosha ni sehemu ya mfumo (feature). Lango la idhini lililofaa hufanya kazi kama circuit breaker wakati mambo yanapoanza kwenda kinyume.

Linganisha Mpaka na Hatari

Rekebisha mipaka yako kulingana na hatari halisi. Kugeuza kila marekebisho madogo ya Markdown kuwa sherehe ya uzingatiaji sheria kutazuia timu yako kufanya kazi. Lakini kuchukulia vitendo vya hatari kubwa kama visivyo na madhara kwa sababu agent anaonekana kuwa na ujasiri ni upumbavu vivyo hivyo. Lengo ni udhibiti unaolingana na hali, si kizuizi la maigizo.

Weka

Mifumo ya wakala yenye manufaa zaidi haijaribu kukuvutia kwa awamu kubwa za kiotomatiki. Inazalisha artifacts ndogo zinazoweza kuhakikiwa. Mpango madhubuti. Diff inayolenga jambo fulani. Log inayosomeka. Utekelezaji mkubwa wa kiotomatiki ni jinamizi wakati wa kutatua hitilafu. Kitu kinapoharibika baada ya kikao cha wakala cha faili hamsini, lazima utatue nia, utekelezaji, na athari za pembeni zote kwa wakati mmoja. Weka eneo la athari (blast radius) kuwa dogo. Sisitiza kujua ni faili zipi wakala alizisoma na ni zana zipi alizotumia. Mifumo inayoweza kufuatiliwa (observable) ni mifumo inayoweza kudumishwa. Black-box autonomy ni deni la kiufundi tu lenye masoko bora zaidi.

Maswali Sita Kabla ya Kutoa Ufikiaji

Kabla ya kumkabidhi wakala jukumu lolote halisi, jaribu uimara wa mpangilio wako kwa maswali sita magumu.

  • Mfumo una uwezo gani hasa?
  • Ni vitendo gani vinavyozuiwa kiasili, vikizuiwa katika ngazi ya miundombinu badala ya kukatishwa tamaa kwa sentensi ya adabu kwenye system prompt?
  • Ni vitendo gani vinavyohitaji idhini ya wazi?
  • Ni artifacts gani zinazogandishwa kabla ya wakala kuzitumia, ili asiweze kubadilisha viingizio (inputs) vyake kimyakimya?
  • Ni mhakiki (validator) gani, aliye tofauti kabisa na mzalishaji (generator), anayetoa hukumu ya matokeo ya mwisho?
  • Ni log gani inayothibitisha, bila utata, kile kilichotokea hasa?

Hii ni usafi wa msingi wa uhandisi. Tenganisha mzalishaji na mhakiki. Weka mamlaka ya binadamu kwenye mpaka.

Jaribio Halisi

Kuna