Kirish
Ish uchun AI kodlash agentidan foydalanishga qaror qilish bitta vositani o‘rnatishdan iborat emas edi. Bu bizning ishlash usulimizni qayta belgilashni anglatardi. Dastlab promptlardan yoki skilllardan yaxshi foydalanishning o‘zi yetarli deb o‘yladim. Ammo bir necha oydan keyin saqlanib qolgan narsa promptlar emas edi. Bu qoidalar hujjatlari, xatolar qaydlari va xatolarni qoidalarga aylantirishning takroriy jarayoni edi.
Ushbu maqolada hozir foydalanayotgan agent oqimimning tuzilishi va asosiy sabablarini, shuningdek, nimalar yaxshi ishlayotgani va nimalar hali yetishmayotganini jamlayman. Barcha sanalar va raqamlar saqlanib qolgan qaydlardan olingan.
Muammo nimada edi?
Sozlama ichki platformadan iborat. Unda autentifikatsiya, tashkilotlar, event broker va bilimlarni boshqarish kabi xizmatlar backend, frontend va GitOps repozitoriylariga ajratilgan MSA tuzilmasi mavjud. Bu tuzilmani agent uchun boshqarish qiyin bo‘lishining sababi shundaki, bitta funksiya uchta repozitoriyni qamrab oladi. Odamlar tuzilmani o‘rganib olgach, uni yangi loyihaga katta qiyinchiliksiz qo‘llay oladi, ammo agent sessiya o‘zgarganida har safar hammasini boshidan boshlashi kerak bo‘ladi.
Dastlab ishni oddiy tarzda olib bordik. Men talablarni tushuntirardim, agent ularni amalga oshirardi, men esa ishni vaqti-vaqti bilan tekshirib, keyingi bosqichni tushuntirardim. Bu yondashuv uzoq davom eta olmadi. Inson aralashishi kerak bo‘lgan nuqtalar to‘siqqa aylandi. Har safar mikroservis backendiga domen modeli qo‘shganimizda, platforma tuzilmasiga mos kod generatorini ishga tushirishimiz va agentga ish tugaganini aytishimiz kerak edi, shundan keyingina u davom eta olardi. Backend va frontendning bir nechta bosqichlarida shunga o‘xshash to‘xtashlar yuz berdi. Aralashuv juda kech ham sodir bo‘lardi. Amalga oshirish paytida noto‘g‘ri yo‘nalishni tuzatishga urinish shu paytgacha sarflangan barcha tokenlar va vaqtni behuda ketkazishni anglatardi.
Shundan so‘ng ikkita tamoyilni belgiladim: "Vazifani boshlashdan oldin qabul qilinishi kerak bo‘lgan har bir qarorni qabul qiling va odatiy bajarish oqimiga odamni jalb qilmang" hamda "Vazifa tugagach, hisobot oling va keyingi qarorni shu asosda qabul qiling." Faqat bajarish davomida yangi qaror zarur bo‘lgan yoki tiklab bo‘lmaydigan muammo yuzaga kelgan holatlar bundan mustasno edi. Keyin tashkil qilgan skilllarimning aksariyati shu tamoyillarni qo‘llab-quvvatlash uchun mavjud.
Joriy tuzilma
Bitta ish maydonidagi uchta repozitoriy
Har bir xizmatning o‘z ish maydoni bor; unda backend, frontend va GitOps repozitoriylari symlinklar orqali o‘zaro ulangan. Repozitoriyalarning o‘zida agentga oid kataloglar mavjud emas. Qoidalar, agentlar, skilllar va docs hamda tasks kabi ish hujjatlari faqat shu ish maydonida boshqariladi.
Uchta repozitoriyni bitta ish maydoniga guruhlashdan maqsad ish tarixini bir joyda kuzatishdir. Funksiyani yaratish backend API kontraktidan boshlanadi, frontend stub orqali o‘tadi va deployment manifestlari bilan davom etadi. Repozitoriylar alohida boshqarilganda, bu oqim uchta commit tarixiga tarqalib ketadi va qaysi frontend o‘zgarishi qaysi backend o‘zgarishi sababli yuz berganini odam eslab qolishi kerak bo‘ladi. Agar bitta ish maydonida User Story bo‘yicha reja tuzib, har bir wave vaqtida har bir repozitoriyni commit qilsak, uchala repozitoriy commitlarini bitta US hujjatidan birgalikda topishimiz mumkin.
rules/ va lanes/ ni ajratish ham muhim qaror edi. rules/ har bir kontekstga avtomatik qo‘shilgani uchun u kichik bo‘lib qolishi va muayyan loyihaga bog‘liq bo‘lmasligi kerak. lanes/ repozitoriyga xos steklar, andozalar, cheklovlar va e’tibor beriladigan jihatlarni o‘z ichiga oladi; agent ularni zarur bo‘lganda bevosita o‘qiydi. Bir oy avval o‘lchaganimda, rules/ ostidagi lane hujjatlari har bir kontekstga 245KB — taxminan 60 000 token — hajmda qo‘shilayotgan edi. lanes/ mazmuniga umuman ehtiyoj sezmagan coder chaqiruvlari 175 000 token bilan boshlanayotganini aniqladim, shuning uchun ularni o‘sha kunning o‘zida ajratdim.
Beshta rol va umumiy qoidalar
Beshta sub-agent mavjud bo‘lib, har birining o‘ziga xos roli bor. planner backlog elementini Tasks ga ajratadi va o‘zini baholaydi; balli 95 dan oshmaguncha rejani takomillashtiradi. coder bitta Task ni amalga oshiradi va test yozmaydi. test-writer faqat spetsifikatsiya va interfeys kontrakti asosida testlar yozadi. reviewer testlarning sifati va to‘liqligini reja bilan solishtirib baholaydi hamda PASS, CONCERNS yoki FAIL qiymatlaridan birini belgilaydi. self-improver muammolar yuzaga kelgan sikllarni tahlil qiladi va qoidalar hujjatlariga yaxshilanishlarni taklif etadi, ammo tasdiqlanmaguncha ularni qo‘llamaydi.
test-writer ga implementatsiya kodini ko‘rishga ruxsat berilmasligining sababi bor. Dastlab biz TDD uslubidagi jarayonda avval testlar yozadigan sub-agentga ega edik. Biroq testlar muvaffaqiyatsiz tugaganda, bu agent ular o‘tguncha implementatsiya kodini bevosita o‘zgartirardi. Barcha testlar o‘tganligi sababli hisobotda hech qanday muammo ko‘rinmasdi, aslida esa testlar implementatsiyani tekshirmayotgan, implementatsiya testlarga moslab o‘zgartirilayotgan edi. Shuning uchun tartibni o‘zgartirdik. Avval implementatsiya yoziladi. Keyin testlar implementatsiya kodini o‘qimasdan yoziladi. Bu qoida test-writer promptining birinchi qatorida ko‘rsatilgan, Hook esa implementatsiya fayllariga kirishni ham bloklaydi.
Barcha beshta sub-agent uchun umumiy qoidalar bitta faylda jamlangan: "Belgilangan fayllaringizdan tashqaridagi fayllarni o‘zgartirmang", "Commitlarni faqat orchestrator amalga oshiradi", "Javob yozishdan oldin hisobotni faylga saqlang", "Javobni o‘n qatordan oshirmang" va "Vazifa tugashi bilan darhol chiqing". Oxirgi qoidani ishini tugatgan agent yana uch marta uyg‘onib, token sarfini 320 000 dan 370 000 gacha oshirganidan keyin qo‘shdik.
run Skill: Bitta backlog elementini boshidan oxirigacha yakunlash
Orchestrator bitta backlog elementini qabul qiladi va quyidagi tartibda ishlaydi.
Bajarish jarayoni o‘rtada to‘xtaydigan ikkita holat mavjud. Agar biror narsani hal qilish kerak bo‘lsa, u tavsiya bilan birga savol beradi. Agar muammoni hech qanday javob bilan hal qilib bo‘lmasa, backlog elementini kutishga qo‘yadi va keyingisiga o‘tadi. O‘zgartiriladigan fayllari bir-biriga to‘g‘ri kelmaydigan backlog elementlari bir vaqtda qayta ishlanadi va har bir wave oxirida checkpoint commit qoldiriladi. Qarorlar va bajarish jurnallari darhol fayllarga yoziladi. Ushbu qaydlar asosida yakuniy hisobot vaqt va token sarfini ko‘rsatuvchi Gantt diagrammasini yaratadi. Faqat kontekstda qolgan ma’lumotlar summarization paytida yo‘qoladi.
Interview skill run skill dan oldin keladi. U talablarni tinglaydi va backlogni Tasks ga ajratadi, ammo haqiqatan muhim qism bundan oldin sodir bo‘ladi. Agar talablar noaniq yoki ikki xil talqinga ochiq bo‘lsa, u avval ducking ni ishga tushiradi. Rubber Duck Debugging — muammoni tushuntirayotgan odam uni rezina o‘rdakka tushuntirish jarayonida mantiqiy bo‘shliqlarni aniqlaydigan debugging usuli. Keyin majburiy tasdiqlash bosqichidan o‘tadi. Har bir noaniq nuqta uchun u tavsiya va muqobillarni taqdim etadi hamda javob olmaguncha hech narsa yozmaydi. Bo‘shliqlarni taxminlar bilan to‘ldirish eng qimmat xato ekanini biz qayta-qayta angladik.
vigen Skill: Oxirgi qo‘lda bajariladigan bosqichni yo‘q qilish
vigen skill ni yaratishdan maqsad tokenlarni tejash emas edi. Maqsad interview tugashi bilan completion report olinishi oralig‘ida odam bajarishi kerak bo‘lgan ishni yo‘q qilish edi. Token tejalishi natija sifatida yuzaga keldi.
Platforma backendida aggregate va entity aniqlangach, Event, Logic, Store va Jpo kabi sakkiz turdagi fayl belgilangan shakllarga muvofiq tuzilishi kerak. Facade qatlami ham command, fetch va query uchun xuddi shunday mexanik formatga ega, frontend stub esa facade kontraktini bevosita ko‘chirish orqali yaratiladi. Shakl qoidalar bilan to‘liq belgilanganligi sababli qaror qabul qilishga hojat yo‘q. Dastlab odamlar bu kodni plugin shaklidagi maxsus generatorni ishga tushirish orqali yaratardi, bu esa avval aytib o‘tilgan bir nechta to‘xtashlarga sabab bo‘lardi.
Birinchi avtomatlashtirish bosqichini olti hafta oldin bajardik. Maxsus generatorni odam ishga tushirishi o‘rniga, agent qoidalar hujjatlarini o‘qib, fayllarni bevosita yozadigan bo‘ldi. Yaratilgan natijani reference code bilan byte-by-byte solishtirib tekshirdik va generatsiya bosqichida inson aralashuvini yo‘q qildik. Biroq qoidalar bilan belgilangan ishni agentga topshirganimizdan so‘ng markerlar yoki field mapping larni qoldirib ketish kabi xatolar yuz bera boshladi. Ba’zan review vaqtida kodni qayta generatsiya qilishga to‘g‘ri kelar, bu esa ko‘plab tokenlarning behuda sarflanishiga olib kelardi.
Avtomatlashtirishning ikkinchi bosqichi to‘rt hafta oldin amalga oshirildi. Qoidalarni faqat Python standard library dan foydalanadigan to‘rtta skriptga ko‘chirdik. Endi entity va facade odamlar avval maxsus generator bilan qo‘llagan qoidalarning o‘zi asosida, token sarflamasdan, bir necha soniyada generatsiya qilinadi. planner ushbu qoidalar orqali generatsiya qilingan kodni coder ning ish doirasidan chiqarib tashlaydi. Shu vaqtdan boshlab odatiy oqimda interview va completion report ni olish oralig‘ida hech bir odam aralashmaydi.
Nimalar yaxshi ishlaydi va nimalar ishlamaydi
Yaxshi ishlayotgan jihat — qarorlar ish boshida jamlanadi. Ilgari bajarish jarayonining turli nuqtalarida agentni yo‘naltirishimiz yoki keyingi vazifani tashkil qilishimiz kerak edi. Endi zarur qarorlarni ishni boshlashdan oldin qabul qilamiz. Muvaffaqiyatsizliklarni qoidalarga aylantirish jarayoni haqiqatan ham ishlayotganidan va kontekst hajmi xarajat sifatida boshqarilayotganidan ham mamnunman. Tekshiruv natijalari agentning o‘z hisobotiga tayanish o‘rniga Hooks va ledger orqali tasdiqlanadi.
Asosiy kamchilik — qoidalar hujjatlarining o‘zi haddan tashqari kattalashib ketgan. run skill tanasi 33KB, INCIDENTS esa 37KB hajmda. Ularni qo‘shganimizcha o‘chirish tamoyili va sig‘imni o‘lchash skripti yordamida boshqaramiz, ammo hajmi o‘sishda davom etmoqda. Qoidalar soni ko‘paygani sari agentlar ularni o‘qib, lekin bajarmaydigan holatlar ham ko‘paymoqda. Orchestrator hamon yagona nosozlik nuqtasi bo‘lib qolmoqda. Holatni faqat fayllarga yozish qoidasi bu muammoni yumshatadi, ammo hal qilmaydi. Qat’iy qoidalar odamlar uchun ham og‘ir. 204 daqiqa davom etgan yaqindagi siklda umumiy vaqtning deyarli yarmi bekor turgan test-writer ni kutishga sarflandi. Bu muammolarni uzluksiz self-improvement loop orqali hal qilish kerak.
Xulosa
Bu jarayon avtomatlashtirish chegarasini ham aniqlashtirdi. Odam maxsus generatorni uch yoki to‘rt marta ishga tushirishini talab qilgan ish avval qoidalarga aylantirildi, keyin esa LLM dan bu qoidalarni talqin qilishni talab qilgan ish deterministik skriptlarga ko‘chirildi. Agentlar o‘z rollari chegarasidan chiqib ketadigan muammolar faqat promptlarga topshirilmaydi; ular qat’iy bajarish tartibi va Hooks orqali oldi olinadi.
Oxir-oqibat muhim bo‘lgan narsa agentlar yoki skilllar soni emas, balki odamning qachon aralashgani edi. Oddiy bajarish agentlar va skriptlarga topshiriladi, dasturchilar esa vaqtini ish boshlanishidan oldin qaror qabul qilish va natijalarni baholashga qaratishi mumkin.
Qolgan vazifalar — qoidalar hujjatlari hajmini amalda kamaytirish, umumiy vaqtni tejash uchun wave gate lardagi buildlar sonini tizimli ravishda qisqartirish va sikllar orasidagi tendensiyalarni avtomatik qayd etib, ulardan yaxshilanish materiali sifatida foydalanish.
dnine