Kila wakala wa AI wa uandishi wa kodi unaweza kutoa diff. Tatizo halisi ni kujua ikiwa diff hiyo imetokana na mchakato uliolenga na wa makusudi—au ni ukaguzi wa haraka na wa vurugu kwenye repozitori yako ambao kwa bahati mbaya umefika kwenye usahihi. Kwa sasa, timu nyingi haziwezi kutofautisha.

Hili si tatizo la kiufundi. Ni tatizo la kuonekana (visibility).

Wakala anapoandika mistari mitatu ya kodi ya uzalishaji (production code), huenda amesoma faili tatu na kuendesha majaribio. Au huenda amegusa faili arobaini zisizohusiana, akatekeleza amri kadhaa zilizofeli, akapita kwenye seti yako ya majaribio kwa sababu ufungaji wa utegemezi (dependency) ulikwama, na kukulipisha kwa huduma hiyo. Diff inaonekana sawa kwa njia zote mbili. Bila rekodi ya safari hiyo, unabakiwa ukikisia kuhusu ubora wa matokeo ya mwisho.

Kwa Nini Kumbukumbu za Mazungumzo (Chat Logs) Si Risiti

Zana nyingi hutoa nakala ya mazungumzo (chat transcript) kama ushahidi wa kazi. Nakala si risiti. Ni sanduku la vipuri lililomwagwa mezani pako. Ina kila mzunguko wa mawazo, kila jaribio lililofeli, kila amri ya mfumo (system prompt), na kila wito wa zana usiohusika. Ikiwa unahitaji kusoma maelfu ya mistari ya mazungumzo ili kuthibitisha marekebisho (patch) ya mistari mitatu, mfumo wako wa ukaguzi tayari umeharibika.

Umakini wa binadamu una kikomo. Lengo la wakala ni kuokoa juhudi za kiakili, si kutengeneza kazi ya ziada. Nakala inamfanya mkaguzi kuwa mpelelezi. Risiti inampa jibu kwa mtazamo wa haraka.

Risiti inayofaa ni muhtasari wa vitendo. Inakuambia wakala aliombwa kufanya nini, alichofanya hasa, na jinsi alivyofikia hitimisho lake. Haifichi kushindwa. Inaliangazia.

Risiti Nzuri Inavyoonekana

Risiti inayoweza kukaguliwa inapaswa kujibu maswali mahususi bila kuchimba sana:

  • Kazi ilikuwa nini? Maelezo ya wazi ya mabadiliko yaliyokusudiwa, siyo kurudia amri (prompt) isiyo wazi.
  • Faili zipi zilisomwa? Ili uweze kuamua ikiwa wakala alijenga muktadha kutoka vyanzo sahihi.
  • Faili zipi zilihaririwa? Alama ya mwisho ya mabadiliko.
  • Amri zipi zilitekelezwa? Hatua za ujenzi (build steps), linters, formatters, au skripti maalum ambazo wakala alizitumia.
  • Amri zipi zilifeli? Sio tu zile zilizofanikiwa. Kushindwa kunaonyesha mahali ambapo wakala alilazimika kubuni mbinu mpya au mahali alipokata tamaa.
  • Majaribio gani yalifanikiwa au yalirukwa? Majaribio yaliyorukwa ni ishara ya hatari. Risiti inapaswa kusema kwa nini yalirukwa.
  • Gharama ya jumla ilikuwa nini? Tokeni, simu za API, na muda wa kompyuta (compute time). Hii inajumuisha gharama ya usanifu wako, siyo tu modeli.

Muundo huu unageuza ukaguzi kutoka kuwa kama uchimbaji wa mabaki ya kale kuwa ukaguzi wa haraka wa uhakika. Mhandisi mwandamizi anapaswa kuweza kuangalia risiti na kusema "hii ina mantiki" au "hii inaonekana inayotia shaka" kwa chini ya dakika moja.

Soma Alama (Footprint), Sio Historia Pekee

Alama ya utendaji wa wakala inaonyesha umbo la kazi. Je, wakala alibaki ndani ya mipaka ya tiketi? Au alitangatanga kwenye moduli zisizohusiana na kubadilisha vitu ambavyo hakuna aliyeviomba? Risiti inayoorodhesha "Faili Zilizohaririwa" pamoja na "Faili Zilizosomwa" inafanya hili kuwa dhahiri.

Alama pia inaonyesha marudio. Wakala anayeendelea kukwama sehemu moja ileile—kusoma faili moja ya usanidi (config file) mara tatu, au kuendesha jaribio linalofeli mara kwa mara—anapoteza nguvu ya kompyuta (compute) na dirisha la muktadha (context window). Mtindo huo unapaswa kuonekana. Ikiwa wakala alichukua majaribio tisa kuendesha skripti ya uhamiaji (migration script), risiti inapaswa kusema hivyo. Taarifa hiyo inabadilisha jinsi unavyotathmini matokeo. Diff "sahihi" iliyotolewa kupitia vurugu za nguvu kubwa si sawa na diff sahihi iliyotolewa kwa usafi.

Gharama Iliyofichika ya Usanifu Mbaya

Gharama si bei ya kila tokeni pekee. Mtindo wa kazi ulioundwa vibaya unafanya wakala kuwa ghali kabla hata hajatengeneza herufi moja. Miundo ya zana iliyovimba (bloated tool schemas), uwekaji wa faili kwenye indeksi usiohitajika, na amri za mfumo (system prompts) zilizo pana sana vyote huongeza ukubwa wa dirisha la muktadha. Risiti inapaswa kuonyesha gharama hii ya ziada.

Ikiwa uzalishaji unakuwa rahisi lakini ukaguzi unakuwa mgumu, huna chochote ulichopata. Umehamisha tu tatizo (bottleneck). Muda wa mhandisi mara nyingi ndio rasilimali adimu zaidi kwenye timu. Kuokoa dola tano katika gharama za API huku ukiongeza dakika tatu mapindi ya ukaguzi kwa kila pull request ni biashara mbaya. Risiti inakusaidia kukagua biashara hii moja kwa moja.

Ukweli ni Kipengele (Feature)

Risiti inayofaa inapaswa kuleta hali ya kutokuwa na raha inapohitajika. Inapaswa kuripoti ukweli unaomfanya wakala aonekane hana ufanisi, kwa sababu ukweli huo unafanya uamuzi wa binadamu unaofuata kuwa wa haraka na bora zaidi.

Mifano ni muhimu:

  • "Read 37 files for a one-line change."
  • "Skipped tests because npm install failed with a peer dependency conflict."
  • "Edited utils.py outside the requested scope to fix an import the agent introduced."
  • "Ran the linter 4 times; first three failed due to path misconfiguration."

These are not bugs in the receipt. They are signals. They tell the reviewer where to focus skepticism. They also tell the platform team where the workflow itself needs tightening.

Smaller Runs, Clearer Oversight

There is a natural temptation to let agents run wild across large surfaces. One giant prompt to refactor an entire service feels fast. It is not. It creates an unreviewable lump of work. Your afternoon disappears into tracing which of eighty changed files were intentional.

Small, inspectable runs are better. Define clear boundaries for the task. Separate the list of files the agent may read from the list it may write. Capture a history of failed commands so the dead ends are visible. Flag skipped verifications explicitly. Note every external tool use, from search APIs to test runners.

The goal is not total autonomy. Total autonomy that no human can verify is just automation with liability. The real goal is reviewability. Every agent output should be easy to approve or easy to reject. There should be no ambiguous middle ground where you accept code because you are too tired to investigate.

The Test for Any Coding Agent

Before adopting any agent or platform, ask one question: Can it leave enough evidence for a human to approve the next step confidently?

If the answer is yes, the tool fits into a professional workflow. If the answer is no, you are not buying productivity. You are buying a mystery that occasionally compiles. That is fine for a weekend side project. It is unacceptable for production engineering.

Teams that treat agent outputs as unexamined gifts will eventually ship a subtle bug introduced by an undetected scope creep. The diff will look innocent. The receipt would have told the truth.

Require receipts. Design for review. Trust is not a strategy. Evidence is.

For more hands-on discussions around AI tooling and developer workflows, you can join the community at GyaanSetu on Telegram.