Mahalliy AI kodlash agentlari bilan tajriba: DevOps discipline nima uchun muhim

Ba'zan aql bovar qilmaydigan sabablarga ko'ra aqlli tizim ishdan chiqadi. Men buni yaqinda mahalliy AI kodlash agentlari bilan tajriba qilayotganda boshdan kechirdim. Open-weight modellar kuchayib, privacy-conscious development muhim bo'layotgan bir davrda bu trend o'sib bormoqda.

Tajriba oddiy edi: mahalliy hardware'da ishlaydigan coding agent to'liq ishlaydigan o'yin yaratishi mumkinmi? Trivial demo emas, balki real state management, rendering logic, input handling va playable UI bo'lgan narsa. Javob — ha, lekin buning oldida AI tooling ecosystem yaxshi boshqarmaydigan muammolar borligini ko'rdim.

Ishlamashi kerak bo'lgan konfiguratsiya

Uchta komponent bor edi: provider-agnostic coding agent CLI, localhost'dan OpenAI-compatible API serv qiladigan Ollama, va mahalliy mashinada Qwen3.8 27B. Bu kuchsiz setup emas — 27B model 17GB, 32GB unified memory'da qulay joylashadi, tool calling va yaxshi reasoning qobiliyatini qo'llab-quvvatlaydi.

Dastlabki natijalar umidli edi. 15 daqiqada agent to'liq HTML structure va 200 yaqin qator NES-uslubdagi CSS yozdi. Beveled cabinet styling va to'g'ri rang palitrasi bor edi. Bundan ham muhimroqi — agent o'zi xatosini tuzatdi: fayl yozdi, qayta o'qidi, niyat bilan diskdagi narsa mos kelmasligini payqadi va prompting'siz tuzatdi. Bu haqiqiy agentic behavior edi.

Keyin agent o'yin logic faylini yozishga harakat qildi. Va hamma narsa to'xtadi.

O'lim spirali

Keyin ketma-ket 13 ta urinish bo'ldi. Har biri o'rtada to'xtadi. Stream hech qanday xato bermasdan, hech qanday tushuntirishsiz o'ldi.

Eng asabi qiladigan narsa bu muvaffaqiyatsizlikning o'zi emasdi — agentning reasoning jarayonini kuzatish edi. Har bir urinish yangidan boshlanardi, shuning uchun model bir xil design decisions'ni qayta chiqarardi. Uchtala retry — uchta turli javob bir xil architectural savolga. Agent bir soat o'ylab, hech narsa yetkazmasdi.

Aniq sabab — memory pressure bo'ldi. Browser tab'larini yopish bir necha GB RAM bo'shatdi va narsa biroz yaxshilandi. Bu diagnoz to'g'ri deb o'yladim. Lekin bu noto'g'ri xulosa edi.

Log'larda haqiqat nima edi

Server log'larini qayta o'qib, boshqacha tariqifa ko'rdim. Hech qanday out-of-memory error yo'q edi. Sistema 21 dan 27 gigabayt bo'sh memory bilan ishlab turdi — 17 gigabayt model ustida. Memory muammo emas edi.

Haqiqiy muammo — konfiguratsiya mos kelmasligi edi. Va bu hech qanday ko'rinadigan xato bermasdi. Agentning config'i 32,768 token context window ekanini aytar edi. Lekin Ollama server 8,192 token ceiling bilan qayta ishga tushirilgandi. Bu farq sezilmasdan qoldi. Agent 800 qatorli faylni bir shotda yozishni rejalashtirardi — chunki uning fikricha 32k headroom bor edi. Generation 8k devorda to'xtaganda, connection uzilardi va agent tushuna oladigan xabar yo'q edi.

Ikkinchi muammo ham bor edi: startup log'larida Ollama context-shifting enabled bilan ishga tushgan. Bu model out of room bo'lganda oynani siljitishga, eski token'larni tashlab yangilarni qo'shishga imkon berar edi. Lekin model's architecture bu feature'ni qo'llab-quvvatlamasdi, shuning uchun silent ravishda o'chirilgandi. Soft limit qattiq devorga aylandi.

AI rivojlantirish talab qiladigan DevOps discipline

Bu tajriba mahalliy AI rivojlantirish haqida muhim bir narsani aniq ko'rsatdi. Open-weight modellar atrofidagi enthusiasm buni yashiradi. O'zingizning hardware'da modellarni ishlatayotganda, kod yozmayapsiz — infrastructure boshqarayapsiz. Va infrastructure production tizimlar talab qiladigan diagnostic discipline, configuration management, operational parameters'ga e'tibor talab qiladi.

Context window'lar — abstract model property emas, o'rnatib unutadigan narsa emas. Ular tooling chain bilan no-intuitiv tarzda interact qiladigan operational parameter'lardir. Agent's configured context server's actual ceiling bilan mos kelmasa, ogohlantirish olmaysiz — model incompetent ko'rinadigan silent failures olasiz. Lekin aslida bu operational misconfiguration.

Mahalliy AI coding agent'lar bilan tajriba qilayotgan developer'larga amaliy tavsiya: environment'ni production deployment kabi puxta tekshiring. Agent's configuration runtime parameters bilan mos kelishini tekshiring. Server log'larini o'qing — faqat agent output'ni emas. Model architecture qaysi feature'larni real support qilishini tushuning — tooling qaysilarni enable qilishga harakat qilishidan farqli o'laroq.

Modellar yaxshilanmoqda. Tooling yetuklanmoqda. Lekin "demo'da ishlaydi" va "kunlik foydalanishda ishonchli ishlaydi" orasidagi farqni to'ldirish uchun hali insoniy judgment kerak. Va bu judgment — yangi class infrastructure'ga qo'llaniladigan traditsion DevOps discipline'ga o'xshaydi.

Tetris build oxir-oqibat muvaffaqiyatli bo'ldi. Ikki kunda to'rt yarim soat davom etdi. Uchta fayl bo'ylab toza kod chiqdi va to'g'ri ishlaydi. Lekin saboqlar muvaffaqiyatdan emas, muvaffaqiyatsizliklar nega bo'lganini tushunganimdan keldi. Va shuni tan olish kerakki, ba'zan eng qimmat muammolar — intelligence bilan hech qanday aloqasi yo'q.