AI agentlari vazifalarini kuzatiladigan qilish

1. Kirish: Commit jurnallari endi nimalarni tushuntira olmaydi

Jamoaga AI orqali kod yozish vositalari joriy etilgach, kod tez o‘sadi, biroq bu kod qanday yaratilgani jarayonini ko‘rish yanada qiyinlashadi. Ilgari commit jurnalini tezda ko‘zdan kechirish orqali kim nima ustida va qancha vaqt ishlaganini taxminan tushunish mumkin edi. Endi esa xuddi shu jurnalga qarab ham natija insonning bir soatlik mulohazasidan kelib chiqqanmi yoki agent uni uch daqiqada yaratganmi — buni aniqlab bo‘lmaydi. Repozitoriy o‘zgarmagan, ammo uning ichida nimalar sodir bo‘layotgani ko‘rinmay qolgan.

Biz oldimizga ikki maqsad qo‘ydik. Birinchidan, kod agent tomonidan yaratilgan bo‘lsa ham, keyinroq qo‘shilgan kishi faqat repozitoriyni qabul qilib, uni darhol tushunishi va ishni davom ettira olishi kerak. Ikkinchidan, repozitoriy qaysi loyihaga tegishli bo‘lishidan qat’i nazar, tahlil uchun ro‘yxatdan o‘tkazilgan zahoti hech qanday qo‘shimcha konfiguratsiyasiz metrikalar va trendlar mavjud bo‘lishi kerak. Keyingi barcha qarorlarimizni aynan shu ikki maqsad belgiladi.

2. Nimani hisoblash kerak?

2.1 Aniqlash emas, hisobot berish

Dastlab koddagi o‘zgarishlarni tahlil qilib, AI tomonidan yozilgan qismlarni aniqlashga urindik, ammo tez orada bu yondashuvdan voz kechdik. Commit tarkibida muallif, vaqt belgisi, o‘zgarishlar va xabar bor, ammo unda “bu qator qanday yaratilgani”ni qayd etish uchun joy yo‘q. AI tomonidan tayyorlanib, keyin inson tomonidan takomillashtirilib commit qilingan kod qo‘lda terilgan kod bilan baytma-bayt bir xil bo‘lishi mumkin. Muammo aniqlash aniqligining pastligida emas; ma’lumotlarda aniqlash mumkin bo‘lgan obyektning o‘zi yo‘q.

Shuning uchun aniqlashdan voz kechib, uning o‘rniga hisobotlarni yig‘ishga qaror qildik. Biz faqat vosita qayd etgan yoki inson aniq bildirgan narsalarni hisoblaymiz. Buning evaziga metrikani “AI’dan foydalanish darajasi” emas, qat’iy ravishda “qayd etilgan AI” deb nomladik. Bu odamlar hisobot bermasa nima bo‘lishi haqida savol tug‘diradi, ammo biz buni kamchilik emas, balki boshqa bir metrika sifatida ko‘rishga qaror qildik. Hisobot berish darajasining pastligi o‘ziyoq kelishilgan qoidaga amal qilinmayotganidan darak beradi.

2.2 Birlik sifatida commitlar emas, sessiyalardan foydalanish

Bundan ham muhimroq qaror bitta ish bo‘lagi sifatida nimani ko‘rish kerakligi edi. Agent bilan ishlash bir qadamda tugamaydi. Siz ko‘rsatma berasiz, natijani ko‘rib chiqasiz, o‘zgartirishlar so‘raysiz va uni yana qabul qilasiz. Jarayon uch yoki to‘rtta commitga bo‘linib ketadi.

Agar birlik sifatida commitlar hisoblanadigan bo‘lsa, “agent uchta commit yaratdi” degan faktning o‘zi qoladi. Aslida esa biz “bu ishni yakunlash uchun nechta urinish kerak bo‘ldi?” degan savolga javob olishni istaymiz. Bir urinishda yakunlangan vazifa bilan besh marta ortga qaytarilgan vazifa, ikkalasi ham uchta commitdan iborat bo‘lsa ham, mutlaqo boshqa voqeani anglatadi. Shuning uchun commitlarga sessiya identifikatorini kiritib, bir sessiyadagi commitlarni bitta ish sifatida guruhlashga qaror qildik.

3. Biz qabul qilgan yondashuv

3.1 Commit xabarlaridan interfeys sifatida foydalanish

Inson yozgan kodni tushunmasangiz, undan so‘rashingiz mumkin. Agent yozgan kod bilan esa bunday qila olmaysiz. Sessiya tugagach, uning konteksti yo‘qoladi, hatto keyinroq o‘sha vositani chaqirsangiz ham, u avvalgi safar nega aynan shunday qaror qilganini tushuntira olmaydi. Shuning uchun agent kodga qanchalik ko‘p jalb etilsa, uning izohi kodning o‘zi bilan birga shunchalik ko‘proq saqlanib qolishi kerak. Keyinroq qo‘shilgan kishi loyihani faqat repozitoriyga ega bo‘lgan holda tushunishi uchun bu yagona yo‘ldir.

Yozuvlarni alohida repozitoriyda to‘plashimiz yoki ularni vosita API’si orqali olishimiz mumkin edi, ammo biz commit xabarlarini tanladik. Qaysi vositadan foydalanilishidan qat’i nazar, commitlar saqlanadi, shuning uchun bu yondashuv vositaga bog‘liq emas; yozuvlar kod bilan birga ko‘chadi va nusxalash yoki aks ettirish jarayonlaridan keyin ham saqlanib qoladi; bundan tashqari, asl nusxa o‘z holicha saqlangani uchun talqin qilish qoidalari o‘zgarsa ham, keyinchalik uni qayta o‘qishimiz mumkin. Format uchun Git’ning mavjud trailer kelishuvini o‘z holicha ishlatdik.

[SPEC-008] feat(member): 세션에서 사용자 신원을 읽도록 변경

X-Agent: dev
X-Agent-Session: 3ae7dbc4
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Bitta tuzoq bor edi. Co-authored-by dastlab odamlar o‘rtasidagi hamkorlikni ko‘rsatish uchun mo‘ljallangan kelishuv bo‘lgani sababli, undan o‘z holicha foydalanish ikki kishi birgalikda yaratgan commitlarni ham AI commitlari sifatida tasniflashga olib kelardi. Keng qo‘llanadigan kelishuvni boshqa maqsadda ishlatishda bu keng tarqalgan muammo, shuning uchun agentni faqat uning email domeni ma’lum vositaga tegishli bo‘lgandagina agent sifatida tanidik.

3.2 Kelishuvni odamlarga emas, vositaga joylashtirish

Bu eng kutilmagan qism bo‘ldi. Commit kelishuvlariga odatda izchil amal qilinmaydi. Ular hujjatlashtirilib, ishga kirish jarayonida tushuntirilgan taqdirda ham, bir necha haftadan keyin unutiladi. Bu, odatda, odamlarning tirishqoqligiga bog‘liq qoidalar bilan sodir bo‘ladi. Agentlar esa har safar loyiha kelishuvlari faylini o‘qiydi va unga aniq amal qiladi. Ular xotiraga tayanmaydi; har safar ishlashdan oldin faylni qayta o‘qigani uchun, vaqt o‘tishi bilan bu qoida unutilmaydi.

## 커밋 메시지 규약

[<백로그>] <type>(<scope>): <제목>

X-Agent: <역할>              # dev · review · test · fix · chore 중 하나
X-Agent-Session: <식별자>    # 세션 내내 같은 값을 쓴다

- 제목 한 줄이면 끝이다. 본문을 쓰지 않는다.
- 한 커밋에 역할 두 개를 담지 않는다.

Commit kelishuvi tushunchasining o‘zi yangilik emas. Uning muhimligini hamma bilardi, ammo unga shunchaki amal qilinmasdi. O‘zgargan narsa kelishuvning o‘zi emas, balki uni ijro ettiruvchi tomon edi. Shu sababli kelishuv faylini qayerga joylashtirish muhim. Agar u repozitoriy ichida saqlansa, kelishuvni o‘zgartirish xuddi koddagi o‘zgarish kabi ko‘rib chiqishdan o‘tadi va versiyalar tarixida saqlanadi; kod o‘zgargan, kelishuv esa o‘zgarishsiz qolgan bo‘lsa, bu nomuvofiqlik o‘sha commitning o‘zida ko‘rinadi. Agar u wiki’da bo‘lganida, hech kim sezmagan holda kod bilan mosligi buzilib ketishi mumkin edi.

Biroq amal qilinishi shart bo‘lgan bitta qoida bor: bevosita insonlar tomonidan yaratilgan commitlarga hisobot berish trailer’ini qo‘shmang. Agar odamlar qulaylik uchun uni qo‘sha boshlasa, inson ishi bilan agent ishi aralashib ketadi va shu zahoti bu ma’lumot javob berishi kerak bo‘lgan savollar butunlay ma’nosiz bo‘lib qoladi. Kelishuv yaratishda nafaqat nimani qayd etishni, balki nimani qayd etmaslikni ham belgilash kerak.

Rollarni beshta bilan cheklash va har bir commitga faqat bitta rolga ruxsat berish ham xuddi shu tamoyilga asoslanadi. Agar ikkitasini qayd etishni istayotganingizni sezsangiz, bu commitni bo‘lish kerakligidan darak beradi. Ro‘yxatga kiritilmagan qiymatlar tashlab yuborilmaydi; ular qanday bo‘lsa, shundayligicha hisoblanadi. Kelishuvga amal qilinmayotganining o‘zi kuzatishga arziydigan signaldir, uning ulushi esa kelishuvga rioya qilish metrikasiga aylanadi.

3.3 Tasniflarni saqlash o‘rniga hosil qilish

Amalga oshirishni tugatgach, dashboard’ni ochdik va raqamlar kutilganidan ancha kichik ekanini ko‘rdik. Sabab ma’lumotlarda emas, dizaynda edi. Commit obyektlari o‘zgarmas qilib loyihalashtirilgan: yuklangandan keyin ularning qiymatlarini o‘zgartirib bo‘lmasdi. Biroq biz tasniflash natijasini shu obyekt maydonida saqlayotgan edik. Shuning uchun parser qo‘shilishidan oldin qabul qilingan commitlarda bu maydon butunlay bo‘sh qolgan.

Uchinchi variantni tanladik. Tasniflash qoidalari o‘zgarishda davom etadi, qoidalar har safar o‘zgarganda avvalgi ma’lumotlarni migratsiya qilishni talab qiladigan tuzilma esa uzoq muddatda bardosh bermaydi. Agar natija hosil qilinsa, bitta qayta agregatsiya yangi qoidalarni avvalgi ma’lumotlarga ham qo‘llaydi. Biz xavotirlangan parsing xarajatlarini qayta tekshirganimizda, ular agregatsiya vaqtiga sezilarli ta’sir ko‘rsatmasligi aniqlandi. Natijani saqlash orqali tejashni umid qilgan xarajatimizni aslida tejashga arzimagan ekan.

4. Natijalar

4.1 Yangi repozitoriy qo‘shilganda ham o‘z holicha ishlashda davom etadi

Yuqoridagi tanlovlar alohida qarorlardek ko‘rinishi mumkin, ammo ular bitta savol atrofida birlashadi: repozitoriy yangi tahlil maqsadi sifatida ro‘yxatdan o‘tkazilganda yana nima qilish kerak?

Natijada yangi repozitoriyni roʻyxatdan oʻtkazishda maxsus tayyorgarlik koʻrishning hojati qolmaydi. Jamoa commit konvensiyalariga amal qilib kelgan boʻlsa, repozitoriy roʻyxatdan oʻtkazilgan zahoti koʻrsatkichlar paydo boʻladi, avvalgi commitlar ham hisoblanadi, shuning uchun birinchi ekranoq tendensiyani darhol koʻrishingiz mumkin. Aksincha, agar yozuvlar alohida repozitoriyda toʻplanib borganida, har bir repozitoriy uchun integratsiya ishlari talab qilinardi, aniqlangan qiymatlar saqlanganida esa yangi ulangan repozitoriyning tarixi abadiy boʻsh qolardi.

4.2 Ekran 0 nima sababdan hosil boʻlganini farqlaydigan boʻlsin

Shuningdek, AI’dan foydalanishi haqida nol hisobot berilgan aʼzolarni roʻyxatdan yashirish yoki ularni mavjud holicha koʻrsatish haqida qaror qabul qilishimiz kerak edi. Ularni yashirish ekranni tozaroq koʻrsatadi. Biroq ular yashirilgach, “undan foydalanmaydi” va “undan foydalanadi, lekin bu haqda hisobot bermaydi” holatlari ekranda bir xil koʻrinadi. Avvalroq hisobot berish darajasining oʻzidan koʻrsatkich sifatida foydalanishga qaror qilgan edik, ammo ekran bu ikki holatni aralashtirib yuborsa, bu qaror oʻz maʼnosini yoʻqotadi. Shuning uchun nolni yashirish oʻrniga, ekranda uning nima sababdan nol ekanini bevosita koʻrsatadigan qildik.

No AI use was reported in this period.
Commits alone cannot tell not-used from not-declared.

Koʻrsatkichni yuklab boʻlmaganda ham xuddi shu tamoyilni qoʻlladik. Soʻrov muvaffaqiyatsiz tugasa, 0 ni koʻrsatmaymiz; qiymatni yuklab boʻlmaganini bildiramiз. 36.5 ni koʻrsatayotgan termometr bilan buzilgani sababli shkalasi ishlamay qolgan termometr butunlay boshqa holatlarni ifodalaydi, ammo ularni faqat sonning oʻzi orqali farqlab boʻlmaydi. Muvaffaqiyatsiz soʻrov va 0 qiymatida ham xuddi shunday.

5. Xulosa

Agentni jamoaga olib kirish shunchaki yana bir vositadan foydalanishdan farq qiladi. Bu ishlab chiqish jarayoniga yangi ishtirokchini qoʻshishni anglatadi va shu ishtirokchi nima qilganini qayd etish uchun yangi joy yaratishni talab qiladi. Ishlarning aksariyati maʼlumotlarni tahlil qilish yoki jamlashga emas, balki nimani qayd etish va nimani qayd etmaslikni hal qilishga sarflandi.

Eng amaliy kashfiyot shundan iborat boʻldiki, konvensiyalarni odamlarga qoldirish oʻrniga vositalarga singdirish mumkin. Odamlar konvensiyalar muhimligini uzoq vaqtdan beri aytib kelishgan, ammo bu gʻoya har doim individual masʼuliyatga tayanib kelgan va natijada konvensiyalarga odatda amal qilinmagan. Aslida, eʼtibor konvensiyalarning oʻzidan ularning qayerda majburiy qoʻllanilishiga koʻchdi. Biroq odamlar hali ham amal qilishi kerak boʻlgan yagona qoida — inson mehnatini agent mehnati bilan aralashtirmaslik.

Oxir-oqibat, biz xohlagan narsa oddiy edi: kod agent tomonidan yaratilgan boʻlsa ham, keyinroq kelgan kishi faqat repozitoriyni olgach, ishni darhol davom ettira olishi, repozitoriy tahlilga ulangan zahoti esa hech qanday tayyorgarliksiz natijalar va tendensiyalar koʻrinishi kerak edi. Buni amalga oshirish uchun tushuntirishlar kod yonida joylashishi, konvensiyalar repozitoriy ichida saqlanishi va talqin repozitoriydan tashqarida istalgan vaqtda qayta tiklanadigan boʻlishi kerak.

Manbalar

Git – git-interpret-trailers — https://git-scm.com/docs/git-interpret-trailers

GitHub Docs – Bir nechta muallif bilan commit yaratish — https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors

Conventional Commits 1.0.0 — https://www.conventionalcommits.org/ko/v1.0.0/

toffeeman