Agenti Yangu Ilituma PR 3 Katika Jioni Moja. 40% ya Ujumbe Wangu Yalikuwa Marekebisho.

Agenti yangu ya uandishi wa kodi inayojiendesha kwa AI ilituma pull requests tatu katika jioni moja, lakini 40% ya ujumbe 30 niliyotuma yalikuwa marekebisho.

Kikao hicho kilitoa MCP client, Azure AI Agent, na M365 Copilot Agent. Ukaguzi wa kiotomatiki uliidhinisha PR zote tatu, na sikuwahi kuhariri mstari wowote wa kodi. Hata hivyo, nakala ya mazungumzo inatoa simulizi tofauti: kati ya jumla ya ujumbe 710, niliandika ujumbe 30, na 12 kati ya hayo yalimrudisha agenti kwenye njia sahihi. "Kiwango cha uongozi" (steering rate) – sehemu ya ujumbe wangu ambayo ilikuwa marekebisho – kiko katika 40%.

Jinsi mfumo (pipeline) ulivyoundwa

  • Claude aliandaa mpango wa juu wa utekelezaji.
  • DeepSeek V4-Flash ilifanya kazi kama mratibu (orchestrator), ikipitia mpango huo.
  • Codex ilitengeneza kodi halisi.
  • Mratibu alikagua kodi na kufungua pull requests.

Wajibu uliokusudiwa wa mratibu ulikuwa wa kuunganisha tu – unapaswa kutatua migongano kati ya vipengele, si kuandika kodi yenyewe. Katika vitendo, agenti ilitengeneza mistari 3,500 ya kodi katika PR tatu ndani ya takriban dakika 40, lakini pia ilifanya makosa katika aina mbili za hitilafu zinazojirudia.

Aina mbili za hitilafu

  1. Ukiukaji wa mtiririko wa kazi (workflow violations) – mratibu mara kwa mara ulichukua hatua ya uandishi wa kodi, ukipuuza wajibu wake wa "kiungo" na kuandika maelezo ya utekelezaji wenyewe.
  2. Kushindwa kupata muktadha (context-retrieval failures) – licha ya maelekezo ya wazi, agenti ilichagua SDK au toleo lisilo sahihi. Taarifa sahihi zilikuwepo kwenye muktadha wa prompt, lakini modeli ilishindwa kuzitoa wakati sahihi.

Hizi si mapungufu katika uwezo wa kufikiri; ni hitilafu za kihandisi (engineering bugs) katika jinsi mtiririko wa kazi unavyodhibitiwa. Hata modeli ya lugha yenye uwezo mkubwa zaidi ingehitaji sheria kali isiyoweza kupuuzwa inayomfunga mratibu kwenye majukumu yake yasiyo ya uandishi wa kodi na kulazimisha uteuzi sahihi wa SDK.

Nilichobadilisha ili kuidhibiti agenti

Niliacha kudhania kuwa mfumo ungejielewa wajibu wake kutokana na orodha ya hatua. Niliongeza tamko la moja kwa moja: “Wewe ni mratibu. Hufanyi utekelezaji.” Ilichukua ujumbe mitano ya marekebisho ili maelekezo hayo yakubalike, baada ya hapo agenti ilizingatia mipaka hiyo.

Pia niliboresha mantiki ya upatikanaji wa muktadha. Chombo kisicho sahihi kilipotokea, nilichukulia kama hitilafu katika mfumo wa upatikanaji (retrieval pipeline) badala ya "hallucination", na niliandika upya prompt inayotoa maelezo ya SDK ili kufanya toleo sahihi lisiweze kupuuzwa.

Mafunzo ya vitendo kwa maendeleo yanayosaidiwa na AI

  • Hesabu ujumbe wako mwenyewe. Idadi kubwa ya PR zilizokubaliwa inaweza kuficha mchakato uliovunjika. Idadi ya marekebisho yako ni kiashiria cha mapema cha mahali ambapo mfumo unavuja.
  • Taja wajibu waziwazi. Agenti haziwezi kujitambua kutokana na orodha ya kazi; zinahitaji maelekezo ya wazi na yaliyofungwa kuhusu wao ni nani na nini wanaweza kufanya.
  • Chukulia makosa ya uchaguzi wa chombo kama hitilafu za kihandisi. Ikiwa agenti itapuuza SDK iliyoelezwa, kosa liko katika mfumo wa uwasilishaji wa muktadha, si katika "ujuzi" wa modeli.
  • Badili makosa kuwa ujuzi unaoweza kutumika tena. Niliruhusu agenti itengeneze utaratibu wa uhakiki (validation routine) kutokana na makosa yake yenyewe, nikigeuza kushindwa kuwa kinga ya baadaye.

Athari pana zaidi