Herdr asosidagi ko‘p agentli ish jarayonini yaratish

1. Bitta prompt yetarli bo‘ladi degan xayol va men duch kelgan to‘siq

Claude Code, Antigravity, Cursor va Codex kabi a’lo darajadagi AI kodlash vositalari odatiy holga aylanib borar ekan, ehtimol, har kim bir qatorli promptda "Men uchun shu funksiyani qo‘sh" deb so‘raganida, kodning bir zumda tayyor bo‘lishi kabi hayratlanarli holatni boshdan kechirgan.

O‘yinchoq loyihalar yoki oddiy skriptlar uchun bitta AI agentni ishga tushirib, suhbat orqali kod yozish to‘liq yetarli. Biroq bir nechta dasturchi hamkorlik qiladigan, murakkab biznes qoidalari, qat’iy DDD arxitekturasi va tranzaksiya chegaralari bir-biriga chambarchas bog‘langan haqiqiy enterprise backend muhitiga kirishingiz bilan yagona agent yondashuvining jiddiy cheklovlari va kamchiliklari namoyon bo‘la boshlaydi.

Jamoaviy loyihada menga biriktirilgan murakkab feature ticket bilan ishlaganimda, DB migratsiyasi DDL va JPA repozitoriylaridan tortib, domen entitetlari, servis mantiqi, REST API'lar va test kodigacha bo‘lgan butun jarayonni bitta agent sessiyasiga topshirish tez orada jiddiy muammolarga olib kelganini ko‘rdim. Suhbat 15–20 ta navbatdan oshgach, u boshida ta’kidlangan framework konvensiyalari va domen invariantlarini unutib, kodni o‘zboshimchalik bilan ustidan yozardi. Dasturchilar agent yozgan kodni qatorma-qator ko‘zdan kechirib, sintaksis xatolari va biznes istisnolarini qayta ishlash yetishmayotganini qo‘lda ko‘rsatganlari sababli, charchatadigan savol-javob jarayoni cheksiz takrorlanardi. Ba’zida u o‘z dizayni va kodidagi kamchiliklarni aniqlay olmas, aksincha, "Hammasi mukammal" deb aytib, o‘zining ko‘r nuqtalarini oqlardi.

Ushbu muammolarga duch kelgach, savolim yo‘nalishini o‘zgartirdim.
"Hamma narsani bitta AI'ga ishonib topshirish o‘rniga, har bir sohadagi ixtisoslashgan agentlar bir-birini tekshiradigan va takomillashtiradigan avtonom agentlar jamoasini tuzsak-chi?"

2. Nega bitta agent emas, balki 'Multi-Agent'?

Multi-agent tizimi bitta agent amalga oshiradigan ishlab chiqish jarayonida mavjud bo‘lmagan bir nechta afzalliklarni taqdim etadi.

① Kognitiv yukni taqsimlash va rollar sofligini saqlash

Agar bitta agentga "Mavjud kodni tahlil qil, dizaynni yoz, keyin amalga oshir va test qil" desangiz, LLM'ning ichki mexanizmlari kognitiv ortiqcha yuklamaga duch keladi.

Bitta prompt doirasida unga bir vaqtning o‘zida tadqiqotchi, dizayner, dasturchi va tester rollari yuklansa, u eng ko‘p vaqt va kuch talab qiladigan kod bazasini o‘rganish bosqichini o‘tkazib yuborishga va qisqa yo‘lni tanlashga moyil bo‘ladi: yetarli Context'siz ko‘rinishidan mos kod yozadi.

Aksincha, multi-agent tizimida agentga bitta maqsad beriladi: "Sizning yagona vazifangiz faktlarni (Domain aloqalari, DB sxemasi va chaqiruv oqimi) o‘rganishdan iborat bo‘lgan tadqiqotchisiz. Hech qanday holatda kod yozmang." Har bir agent bitta personaga 100% e’tibor qaratganda, uning chiqishi zichligi va aniqligi maksimal darajaga yetadi.

② Mustaqil tekshiruv orqali o‘zini tasdiqlash og‘ishlarini bartaraf etish

Hatto odamlar ham o‘zlari yozgan hisobotlardagi imlo xatolari yoki mantiqiy xatolarni aniqlashni nihoyatda qiyin deb hisoblaydi. LLM'lar ham xuddi shunday, o‘zlari shakllantirgan taxminlar va dizaynlarga nisbatan o‘zini tasdiqlash og‘ishini namoyon qiladi.

Agar bitta agent sessiyasida "Men yozgan kodda xatolar bormi?" deb so‘rasangiz, u odatda endigina yozgan mantiqning asosiy shartlarini meros qilib oladi va "Hech qanday muammo yo‘q, u mukammal" deb javob beradi.

Multi-agent tizimida dizaynerning rejasi u haqda hech narsa bilmaydigan mustaqil tekshiruvchiga topshiriladi. "Bu dizayn/kodda albatta jiddiy kamchilik bo‘lishi kerak" degan tamoyil asosida ishlaydigan tekshiruvchi haqiqiy manba kodini bevosita ochadi va uni real holat bilan taqqoslaydi, shu orqali ko‘plab ehtimoliy runtime istisnolari va race condition'larni oldindan filtrlaydi.

③ Context oynasini toza saqlash va unumdorlik pasayishining oldini olish

LLM context oynalari 1 million token'dan oshib kengaygan bo‘lsa-da, 'Lost in the Middle' hodisasi — dastlabki ko‘rsatmalarni unutish yoki oraliq ma’lumotlarni o‘tkazib yuborish — hamda suhbatlar uzaygani sari fikrlash unumdorligining pasayishi hanuzgacha real muammolar bo‘lib qolmoqda.

Bitta agent 30 ta faylni ochishdan hosil bo‘lgan o‘n minglab qator matnni, Gradle build xatolari jurnallarini va batafsil stack trace'larni bitta sessiya konteksti ichida olib yuradi.

Multi-agent muhitida har bir ish bosqichi yakunlanganda keyingi agentga faqat takomillashtirilgan, muhim natijalar topshiriladi. Tekshiruv va build jurnallarining minglab qatorlari tegishli Pane ichida izolyatsiya qilingan holda qoladi, shu sababli orchestrator va dizayner context'lari har doim toza va aniq bo‘lib qoladi.

④ Geterogen modellar o‘rtasidagi sinergiya va ko‘r nuqtalarni to‘ldirish

Har bir vazifa uchun eng yuqori darajadagi modeldan foydalanish API xarajatlarini keskin oshiradi va tezda token limitlariga olib keladi. Aksincha, barcha vazifalar uchun faqat yengil modellardan foydalanish murakkab domen arxitekturasi bo‘yicha fikrlashning yemirilishiga sabab bo‘ladi.

Katta ko‘lamli o‘rganish hamda oddiy, takroriy kodlash/testlash arzon, keng token kontekstlarini taqdim etadigan va tez ishlaydigan modellarga topshiriladi, yuqori darajada murakkab domen va arxitektura dizayni esa chuqur fikrlash qobiliyatiga ega top-darajadagi modellarga jamlanadi.

Gemini Claude yozgan kodni tekshiradi, Claude esa Gemini yozgan kodni tekshiradi. Turli o‘quv ma’lumotlari va arxitekturalarga ega ushbu ikki model bir-birining ko‘r nuqtalarini to‘ldiradi.

3. Amaliy boshlash: Antigravity va Claude Code'ning geterogen juftligi

Bularning barchasi juda oddiy tajriba sifatida boshlandi.
"Anthropic'ning Claude Code'i va Google'ning Antigravity'sini yonma-yon ishga tushirib, ularni birga ishlatsak-chi?"

Ikki modelni amalda juftlaganimda, sinergiya kutganimdan ham yuqori bo‘ldi.

Claude Code'ning Opus modeli murakkab biznes mantiqi, obyektga yo‘naltirilgan mas’uliyatlarni ajratish va use-case dizaynida misli ko‘rilmagan kuchini namoyish etdi. Antigravity'ning Gemini 3.6 Flash modeli esa katta kontekst va qo‘rqinchli tezlik yordamida haqiqiy fayl tizimini qidirib, DB ustun turlari, Spring bean bog‘liqliklari va legacy tranzaksiya qoidalarini o‘rganishda tengsiz bo‘ldi.

Butunlay turli o‘quv arxitekturalari va nuqtayi nazarlariga ega ushbu ikki Big Tech modeli bir-birini o‘zaro tekshirdi va bir xil model yordamida tekshirishda e’tibordan chetda qolgan ko‘r nuqtalarni uzluksiz to‘ldirdi, natijada kodning to‘liqligi yaxshilandi.

4. 'Copy-and-paste shuttle'ning yakuni: terminal multipleksori Herdr bilan tanishuv

Geterogen model juftligi ajoyib edi, biroq tez orada yangi jismoniy to‘siqqa duch keldim.

Men 1-terminaldagi (Claude) dizaynni nusxalab, 2-terminalga (Antigravity) o‘tardim, uni joylashtirib, "Buni men uchun tekshir" deb so‘rardim… keyin natijani yana nusxalab, 1-terminalga joylashtirib, "Bu yerda muammo bor. Tekshirib ko‘r" derdim…. Xuddi shu jarayon qayta-qayta takrorlanardi.

Agent rollari ajratilgan bo‘lsa-da, men — dasturchi — terminallar o‘rtasida u yoqdan bu yoqqa qatnaydigan 'copy-and-paste shuttle'ga aylanib qolgandim.

Qo‘lda almashishdan iborat bu jahannamga barham berish uchun bir nechta yondashuvni sinab ko‘rdim va oxir-oqibat Herdr'ni kashf etdim.

Herdr ekranni shunchaki bir nechta bo‘limga ajratuvchi oddiy terminal vositalaridan tubdan farq qilardi. U agentlarning hayotiy sikllari va xabarlar yetkazilishini boshqaradigan 'agentlarga xos fon orkestratsiya mexanizmi'ga yaqinroq edi.

• Herdr har bir Pane'ning chiqish oqimini real vaqt rejimida kuzatadi va agent ishlayotganini (Working), bloklanganini (Blocked) yoki tugaganini (Done) mustaqil ravishda aniqlaydi. Endi terminal oldida o‘tirib, Enter tugmasini qachon bosishni odam kutib baholashiga hojat qolmadi.

• Biror Pane dizaynini yakunlab, Done holatini ko‘rsatishi bilanoq, Herdr daemon chiqish Markdown'ini JSON-over-Socket IPC orqali ushlab oladi va uni prompt bilan birga darhol keyingi Pane'ning standart kirish oqimiga (stdin) bevosita kiritadi. Nusxalash va joylashtirishdan charchash tom ma’noda nolga tushdi.

• Bitta sessiyada uzoq davom etadigan build yoki to‘liq testlar to‘plami ishga tushirilganda, hatto dasturchining prompt oynasi ham ko‘pincha butunlay qotib qolardi. Herdr'da har bir Pane o‘zining alohida jarayoni va virtual TTY'sida izolyatsiya qilingan, shuning uchun bitta Pane fonda yuzlab testlarni ishga tushirayotgan bo‘lsa ham, istalgan vaqtda boshqa Pane terminalida ishlashni davom ettirish mumkin edi.

5. Herdr'ning multi-Pane sozlamasi evolyutsiyasi: kodlash Pane'ini ajratishdan 8 ta Agent Pane'ini to‘liq shakllantirishgacha

Men boshidanoq mukammal sozlangan 8 ta Pane bilan boshlamaganman. Murakkab ishlab chiqish vazifalarini birma-bir bajardim, son-sanoqsiz nosozliklar va to‘siqlarga duch keldim hamda yangi muammo paydo bo‘lganda alohida Pane ajratish orqali sozlamani takomillashtirdim.

1-bosqich: Birinchi ajratish — one-to-one ping-pong (coding Pane)dan boshlash

Dastlab asosiy sessiya (Claude Code) hamma narsani yolg‘iz bajardi: talablarni tahlil qilish, arxitektura dizayni, kod yozish va kompilyatsiya. Biroq o‘nlab fayl tahrirlash tarixlari va keng ko‘lamli kompilyatsiya xatolari jurnallari to‘g‘ridan-to‘g‘ri asosiy sessiyada to‘plana boshlagach, context ifloslanishi yuz berdi: atigi 10 ta navbatdan keyin u boshidagi domen qoidalarini unutardi.

Buni hal qilish uchun coding Pane'ini birinchi marta ajratdim. Asosiy orchestrator faqat umumiy dizayn va ko‘rsatmalar bilan shug‘ullandi, katta hajmdagi kod terish va kompilyatsiya xatolarini tuzatishni esa Gemini Flash'ga topshirdi. Uning mislsiz tezligi asosiy context'ni toza va himoyalangan holda saqlay boshladi.

2-bosqich: "Men yozgan kod mukammal" degan ishonchni parchalagan geterogen ikki tomonlama tekshiruvchilar

Coding Pane'ini ajratgan bo‘lsam-da, tez orada yana bir muammoga duch keldim. Kodlash tugagach, kodni yozgan agent yoki bitta dasturchidan uni "tekshirishni" so‘rash o‘zini tasdiqlash og‘ishi sababli faqat jonsiz — "Barcha talablar mukammal bajarildi" — degan javobga olib kelardi. Oxir-oqibat xatolar asosiy branch'ga kirib borardi.

Buni hal qilish uchun turli modellardan foydalanadigan ikkita mustaqil review Pane'ini yaratdim. Ular "bu kodda yashirin kamchilik bo‘lishi shart" degan taxmin asosida destruktiv tekshiruvlar o‘tkazdi. claude-review'ga arxitektura buzilishlari va domen invariantlarini aniqlashni, antigravity-review'ga esa Null xavfsizligi, SQL N+1 va tranzaksiyani rollback qilishni o‘rganishni topshirdim. Ayniqsa, ikkala tekshiruvchini ketma-ket emas, bir vaqtning o‘zida (Parallel) ishga tushirdim. Shu tariqa kutish vaqtini ikki baravar qisqartirib, o‘zaro mustaqil va ko‘p yo‘nalishli cross-verification tarmog‘ini yaratdim.

3-bosqich: Kodlash tugagach hamma narsani qayta ko‘rib chiqish juda kech — design verification'ni (design-verify) joriy etish

Biroq kodlash va tekshiruvlar mukammal bo‘lgan taqdirda ham, yana bir katta vaqt isrofi manbai qoldi. Ba’zida faqat kodlash to‘liq tugab, review bosqichi boshlangandan keyingina "asosiy domen modellashtirishi noto‘g‘ri" yoki "tranzaksiya chegarasi dizayni mos kelmagan" kabi fundamental kamchiliklarni aniqlardik. Har safar shunday bo‘lganda, mashaqqat bilan yozilgan yuzlab qator production kodini to‘liq rollback qilib, boshidan boshlashimizga to‘g‘ri kelardi.

Ushbu ulkan qayta ishlashning oldini tubdan olish uchun xatolarni aniqlashni kodlash boshlanishidan oldinga ko‘chirish strategiyasini qabul qildim. Design-verify Pane'ini qo‘shdim: hujjat yozilishi bilan u darhol haqiqiy manba kodini ochib, uni dizayn hujjati bilan taqqoslaydi. Kod yozishni boshlashdan oldin dizayn bosqichida edge case'lar va arxitektura kamchiliklarini 100% bartaraf etish orqali umumiy ishlab chiqish siklidagi iteratsiyalar soni kamaydi va ishlab chiqish vaqti ikki baravar qisqardi.

4-bosqich: Commander va Designer’ni ajratish — mustaqil design Pane

Dizaynni tekshirish sikli yo‘lga qo‘yilgach, yangi to‘siq paydo bo‘ldi. Asosiy orchestrator yuzlab qatorlardan iborat batafsil domen dizayni hujjatlarini yozish uchun bevosita mas’ul bo‘lgani sababli, chuqur dizayn mulohazalari jarayonida uning kontekst oynasi tezda to‘lib qolardi. Bir nechta Pane’larni muvofiqlashtirishi va nazorat qilishi, shu bilan birga developer bilan muloqot qilishi kerak bo‘lgan commander’ning kognitiv salohiyati pasayib borardi.

Bunga javoban biz "orchestrator hujjatlarni bevosita yozmasligi va faqat buyruq berish hamda nazoratga e’tibor qaratishi kerak" degan tamoyilni joriy qildik va chuqur obyektga yo‘naltirilgan mulohaza hamda dizaynga bag‘ishlangan alohida design Pane’ni mustaqil ravishda ajratdik.

5-bosqich: Tasavvurdan kelib chiqib dizayn qilmang — research Pane’ni ajrating

Hatto dizaynga bag‘ishlangan Pane ajratilgandan keyin ham vaqti-vaqti bilan noto‘g‘ri dizaynlar paydo bo‘lardi. Dizayn agentidan tadqiqot va dizaynni bir vaqtning o‘zida bajarish so‘ralganda, u keng kod bazasini o‘rganishni tashlab, o‘z xotirasiga asoslangan holda dizayn boshlay boshladi.

Buning oldini boshidan olish uchun biz dizayn boshlanishidan avval faqat paket bog‘liqliklari, DB sxemasi turlari, asinxron hodisalar oqimlari va kod bazasidagi mavjud implementatsiya andozalarini o‘rganadigan hamda ularni faktlar jadvaliga jamlaydigan alohida research Pane’ni tashkil etdik. Biz mehnatni qat’iy taqsimlash qoidasini joriy qildik: "Designer kodni taxminlarga asoslanib qidirmasligi kerak; u faqat investigator taqdim etgan obyektiv faktlar jadvali asosida dizayn qilishi shart."

6-bosqich: Loglarning qarshi hujumi — test Pane’ni ajratish

Qolgan so‘nggi to‘siq to‘liq test to‘plamini ishga tushirish edi. Har safar gradle test ishga tushirilganda, boshqa agentlar tomonidan allaqachon aniqlangan minglab qatorlik build chiqishi va bazaviy xatolik loglari terminalni to‘ldirib yuborar, asosiy orchestrator’ning suhbat oynasi va Context’ini jiddiy darajada egallab qo‘yardi.

Buning oldini olish uchun to‘liq test to‘plamini ishga tushirish va nuqsonlarni aniqlashga bag‘ishlangan test Pane’ni (Gemini Flash) ajratdik va katta hajmdagi log chiqishini quyi Pane ichida izolyatsiya qildik. Gemini Flash modelida ishlaydigan Agent cheksiz uzun test loglarini bir vaqtning o‘zida yuqori tezlikda qayta ishladi.

7-bosqich: Sessiya boshlanishi bilanoq tayyor — hook asosidagi avtomatik ta’minlashni yakunlash

7 ta ixtisoslashgan Pane’dan iborat tizim endi to‘liq shakllangan edi, biroq Herdr har safar ishga tushirilganda 7 ta oynani qo‘lda ajratish va ularga tegishli vositalar hamda prompt’larni kiritish yana bir noqulaylik tug‘dirdi.

Buni session-start hook’dagi skript yordamida avtomatlashtirdik. Endi Herdr sessiyasi ochilishi bilanoq 1 ta Main Orchestrator va 7 ta ixtisoslashgan Specialist Pane’dan tashkil topgan, organik tarzda joylashtirilgan to‘liq ish muhiti bir soniya ichida avtomatik ravishda ochiladi.

6. 1 ta Orchestrator + 7 ta Specialist

Yuqorida tasvirlangan bosqichma-bosqich ajratish jarayoni orqali tizim nihoyat jami 8 ta Pane’dan iborat tuzilmaga keldi: faqat buyruq berish va sifat nazoratiga bag‘ishlangan 1 ta asosiy orchestrator hamda 7 ta ixtisoslashgan quyi darajadagi Agent Pane.

Endi har bir Pane’da ortiqcha yoki noaniq rol mavjud emas. Yagona mas’uliyat tamoyiliga muvofiq, har biriga o‘ziga xos maxsus vazifa va shu vazifaga optimallashtirilgan LLM engine biriktirilgan hamda ular mustaqil ishlaydi.

Asosiy orchestrator Pane kodni bevosita o‘qimaydi yoki yozmaydi. U faqat quyida belgilangan 7 ta ixtisoslashgan Pane’ga aniq protokollar orqali vazifalar beradi, so‘ng ularning natijalarini tekshiradi va birlashtiradi.

Pane nomi	Maxsus vazifa	Model	Tanlash sababi va asosiy roli
main	Umumiy pipeline buyruqlari va nazorati	Claude Sonnet	Developer bilan muloqot qilish, bosqichlar bo‘yicha vazifalarni taqsimlash va Git commit/merge jarayonlarini nazorat qilish
research	Kod bazasi faktlarini empirik o‘rganish	Gemini 3.7 Flash	Paketlar, DB sxemalari va chaqiruv oqimlarini yuqori tezlikda hamda keng kontekst bilan o‘rganish
design	Arxitektura va batafsil dizayn hujjatlarini yozish	Claude 3.7 Opus	Chuqur mulohaza qilish qobiliyatlari asosida dizayn hujjatlarini yozish
design-verify	Adversarial dizayn tekshiruvi	Gemini 3.7 Flash	"Bu dizayn noto‘g‘ri" degan taxmin asosida nuqsonlar va chekka holatlarga hujum qilish
coding	Kod implementatsiyasi va kompilyatsiya	Gemini 3.7 Flash	Yuqori tezlikda kod yozish hamda framework konvensiyalariga qat’iy rioya qilish
claude-review	Birinchi kod ko‘rigi (tuzilma/DDD)	Claude Sonnet	Arxitektura qatlamlari buzilishi, bog‘liqlik, tranzaksiya chegaralari va biznes invariantlarini ko‘rib chiqish
antigravity-review	Ikkinchi kod ko‘rigi (xatolar/barqarorlik)	Gemini 3.7 Flash	Null xavfsizligi, SQL/N+1 muammolari, yetishmayotgan exception’lar, idempotentlik va kodlash konvensiyalarini ko‘rib chiqish
test	To‘liq test to‘plami orqali regressiyani tekshirish	Gemini 3.7 Flash	Barcha Gradle testlarini ishga tushirish

7. Boshi-oxirigacha ko‘p agentli ish jarayoni

Qancha ko‘p ixtisoslashgan agentlarni ishga tushirmang, qat’iy va deterministik ish jarayoni qoidalarisiz ko‘p agentli tizim tezda tartibsizlik va samarasizlikka yuz tutishi mumkin. Agentlar bilan ishlash davomida men anglagan ish jarayonlari uchun asosiy ehtiyojlar quyidagilardan iborat.

1. «Laissez-faire avtonomiyasi» muvaffaqiyatsizligining oldini olish: Agar agentlarga «o‘zaro maslahatlashib, funksiyani ishlab chiqing» desangiz, ular kod yozishga muddatidan oldin kirishib ketishi yoki cheksiz oldi-qochdi suhbatlarda tokenlarni isrof qilishi mumkin. Har bir agent uchun aniq kirish va chiqish shartlarini belgilaydigan pipeline juda muhim.

2. Dasturiy ta’minot muhandisligidagi «Shift-Left» tamoyilini amalga oshirish: Nuqson qanchalik kech aniqlansa, uni tuzatish qiymati shunchalik eksponensial ravishda oshadi. Kod yozish boshlanishidan oldin, dizayn hujjatlari bosqichida imkon qadar ko‘p nuqsonlarni bartaraf etish umumiy ishlab chiqish muddatini qisqartirish va kodni ortga qaytarishlarning oldini olishning eng yaxshi usulidir.

3. Sifat nazorat nuqtalari orqali deterministik yaqinlashuv: «Muammolar qolmaguncha tekshiruvni takrorlash» va «testlarda nol marta xatolik yuz berganini tasdiqlash» kabi qat’iy nazoratlar orqali LLM holati yoki ehtimoliy o‘zgarishlaridan qat’i nazar, chiqish natijasi har doim ishlab chiqarish darajasidagi, nuqsonsiz sifatga yaqinlashadi.

4. Inson dasturchilarining kognitiv energiyasini asrash: Jarayon aniq belgilanganida, dasturchilar agentlar ishining har bir tafsilotiga xavotir bilan aralashishlari shart bo‘lmaydi.

Dasturchilar o‘z kuchini faqat eng muhim nazorat nuqtalariga qaratishi mumkin: «dizayn tekshiruvi yakunlangach, yakuniy tasdiqlash» va «yakuniy birlashtirish».

Bunga erishish uchun men orkestrator agent ostida yettita ixtisoslashgan Agent Pane’ni joylashtirdim va ularni quyidagi ish jarayoni asosida ishlashga sozladim. Ish jarayoni davom etar ekan, agentlar o‘rtasidagi mas’uliyatlar tobora aniqroq bo‘ldi va dasturchi aralashuvi talab qilinadigan dizayn tekshiruvlari hamda yakuniy verifikatsiyadan tashqari barcha jarayonlar dasturchi ishtirokisiz tabiiy ravishda davom eta oladigan tuzilma shakllandi. Bundan tashqari, dasturchining aralashuvi shu tarzda kamaygani sababli, men muhim tekshiruv va verifikatsiya jarayonlariga ko‘proq e’tibor qarata oldim.

8. Ko‘p agentli ish jarayonini joriy qilganimdan keyin boshdan kechirgan to‘rtta o‘zgarish

Jamoaviy backend loyihasi muhitida menga biriktirilgan murakkab funksional vazifalarni bajarish uchun ushbu ish jarayonini yaratib, qo‘llaganimdan so‘ng keskin o‘zgarishlarni bevosita boshdan kechirdim.

Birinchidan, ruhiy charchog‘im va xavotirim kamaydi. Ilgari yuzlab qator kod ichida yashirin xatolar bo‘lishi mumkinligidan xavotirlanib, sun’iy intellekt yaratgan kodni qatorma-qator tuzatishga juda ko‘p kuch sarflardim. Endi tadqiqot, dizayn-verifikatsiya va ikki nafar mustaqil tekshiruvchi ko‘p bosqichli tekshiruvlarni amalga oshirgani sababli, dasturchilar butun kognitiv energiyasini asosiy biznes dizaynlarini tasdiqlash va arxitektura bo‘yicha qarorlar qabul qilishga bag‘ishlashi mumkin.

Ikkinchidan, nuqsonlar dizayn bosqichida erta to‘sib qolingani sababli, keng ko‘lamli qayta ishlashlar kamaydi. Domenni modellashtirishdagi xatolarni AI kod yozib bo‘lgandan keyingina aniqlash va shundan so‘ng butun kod bazasini almashtirishga to‘g‘ri kelishi bilan bog‘liq isrofgarchilik yo‘qoldi. Dizayn bosqichida nuqsonlarni oldindan saralab tashlash orqali kod yozish boshlanganidan keyin keraksiz sinov va xatolarsiz, amalga oshirish ishlarini yuqori darajada yakunlash mumkin bo‘ldi.

Uchinchidan, men tezlik va sifatga bir vaqtning o‘zida erisha oladigan bo‘ldim. Vazifani yolg‘iz bajarayotgan bo‘lsam-da, endi jamoaning kod bazasiga eng yuqori sifat darajasida hissa qo‘shmoqdaman — go‘yo maxsus katta dasturchilar jamoasi dastlabki tadqiqot, batafsil Markdown dizayn hujjati, ikki bosqichli o‘zaro tekshiruv, koreys tilidagi Javadoc va to‘liq regressiya testlarini puxta yakunlagandek.

To‘rtinchidan, avtomatlashtirilgan dizayn hujjatlari va shaffof qaror qabul qilish tarixi tashkilot aktivlariga aylandi. Ilgari tig‘iz jadvallar sababli hujjatlar qoldirib ketilgan bo‘lsa, endi ish jarayonini shunchaki ishga tushirishning o‘zi o‘lchangan faktlar jadvali, domen dizayni hujjati va adversarial verifikatsiya fikr-mulohazalarini fayllar ko‘rinishida saqlab qoladi. Natijada ular jamoaning doimiy bilim aktivlari sifatida to‘planib boradi.

9. Xulosa: O‘zim uchun optimallashtirilgan ko‘p agentli ish jarayonini topish

Ushbu maqolada taqdim etilgan 1 Orchestrator + 7 Specialists konfiguratsiyasi taxminan ikki hafta davomida qayta-qayta sinab ko‘rish va xatolar orqali ishlab chiqilgan shaxsiy natijamdir. Bu konfiguratsiya har bir dasturchi va har bir loyiha uchun «barcha holatlarga mos yagona yechim» emas. UI’ga yo‘naltirilgan frontend muhitida vizual regressiya testi agenti markaziy o‘rinda bo‘ladi, tezkor gipoteza tekshiruvi muhim bo‘lgan dastlabki bosqichdagi startap uchun esa 2–3 ta Pane’dan iborat yengil konfiguratsiya ma’qulroq bo‘lishi mumkin.

Muhimi soni emas, balki «tamoyillar»dir.

1. Rollar sofligi: Bitta agentga haddan tashqari ko‘p rol yuklamang; diqqatni maksimal darajada jamlash uchun tadqiqot, dizayn, amalga oshirish va verifikatsiya ishlarini ajrating.

2. O‘zini tasdiqlash og‘ishlarini bartaraf etadigan adversarial o‘zaro tekshiruv: O‘z dizayningizga ko‘r-ko‘rona ishonmang; turli nuqtayi nazarga ega agentlardan undagi nuqsonlarni izlab, unga qarshi chiqishni so‘rang.

3. Ixcham kontekst: Batafsil xom jurnallarni alohida agentlar ichida ajrating va faqat takomillashtirilgan natijalardan foydalanib muloqot qiling.

4. Dasturchining yakuniy nazorati: Har bir qarorni AI’ga topshirmang; dasturchi dizaynni tasdiqlash va yakuniy tekshiruv kabi muhim nazorat nuqtalarini o‘zida saqlab qolishi kerak.

Ko‘p agentli ish jarayonini yaratganimdan so‘ng, mening rolim o‘z avtonom agentlar jamoasiga yo‘nalish beradigan va sifat nazorat nuqtalariga yakuniy tasdiq beradigan agent yetakchisi roliga aylandi. AI yordamida kod yozishning haqiqiy kelajagi «yanada kattaroq yagona prompt»ga tayanishda emas, balki o‘z loyihangiz va ehtiyojlaringiz uchun eng ishonchli hamkorlik pipeline’ini bevosita loyihalash va takomillashtirishdadir. Endi siz ham o‘z texnologik stekingiz va ishlab chiqish muhitingizga aniq moslashtirilgan AI avtonom hamkorlik jamoasini yaratishingizga umid qilaman.

informalife