Kod yaratishdan tortib, ishlab chiqishning butun hayotiy sikli davomida AX

-AI yordamida kod yozishdan tortib testlash va ekspluatatsiyagacha — ishlab chiqish jarayoni qanday oʻzgarishi kerak?- 1. Kod yozishni AIga topshirish usulimiz oʻzgardi

Ishlab chiqishda AI’dan jiddiy foydalana boshlaganimdan atigi bir necha oy oʻtib, kodni bevosita oʻzim yozish deyarli toʻxtadi. Avvaliga menga kerak boʻlgan funksionallikni tushuntirib, AI’dan kod yaratishni soʻrardim. Endi esa AI bilan birga ishlab chiqish maqsadlarini rejalashtiraman, batafsil reja tuzaman va amalga oshirish hamda tekshirish bosqichlaridan oʻtaman.

Shuningdek, loyiha tuzilmasi va qoidalarini oldindan tushuntirish hamda AI’ni shu qoidalar doirasida ishlatish uchun AGENTS.md’dan foydalanaman. SKILL.md orqali har bir vazifa uchun faqat kerakli kontekstni beraman va AI’ga shu vazifaga eʼtibor qaratish imkonini yarataman. AGENTS.md butun loyiha boʻylab doimo amal qiladigan umumiy qoidalarni oʻz ichiga olsa, SKILL.md joriy vazifa uchun zarur bilim va ish usullarini tanlab taqdim etishga koʻproq yoʻnaltirilgan. Bitta vazifa uchun bir nechta Skill’dan ham birgalikda foydalanish mumkin.

Vaziyatga qarab, baʼzan bir nechta modelni rollarga ajrataman. Murakkab tahlil va loyihalashni yuqori unumdor modellarga topshiraman, koʻp token sarflaydigan kod yaratishni esa nisbatan arzon modellarga beraman. Keyin boshqa modeldan kamchiliklarni aniqlash va amalga oshirishning toʻliqligini baholash uchun oʻzaro tekshiruv oʻtkazishni soʻrashim mumkin. Bir nechta modeldan foydalanishdan maqsad — natijalarni turli nuqtayi nazarlardan tekshirish bilan birga xarajatlarni kamaytirish. Albatta, mablagʻ muammo boʻlmasa, faqat eng yuqori darajadagi modeldan foydalanish ham yaxshi variant.

2. Juda katta miqdordagi kod testlardan oʻtdi — endi xotirjam boʻlsak boʻladimi?

AI avvalgidan ancha qisqa vaqt ichida juda koʻp kod yaratishi mumkin. Muammo shundaki, kod miqdori oshgani sari odamlar uchun har bir satrni qoʻlda koʻrib chiqish qiyinlashadi. AI’dan biror funksiyani amalga oshirishni soʻraganingizda, u endi faqat kod yozmaydi. Kerakli test kodini ham yaratadi. Build muvaffaqiyatli bajariladi. Barcha JUnit testlari oʻtadi. Hatto boshqa AI’dan kodni tekshirishni soʻraganimda ham, u muayyan muammolar yoʻqligini aytadi.

Xoʻsh, endi xotirjam boʻlishimiz mumkinmi? Biroz oʻylab koʻrsak, aslida yoʻq. Kodni AI yaratdi va qaysi testlar kerakligini ham AI belgiladi. Dastur AI zarur deb hisoblagan bir nechta testdan oʻtgani uning yetarlicha xavfsiz ekanini anglatmaydi. Albatta, bu muammo faqat AI yaratgan kodga xos emas. Dasturlarni oʻzimiz yaratganimizda ham 100% mukammal dasturiy taʼminot boʻlmagan. Yetarlicha testlash va joriy etishdan keyin ham biz kutmagan muammolar production muhitida yuzaga kelgan, shunda loglarni tekshirib, sababni tahlil qilib, kodni oʻzgartirganmiz. Keyin xuddi shu muammo yana takrorlanmasligi uchun testlar qoʻshganmiz.

Bu — biz uzoq vaqtdan beri qoʻllab kelayotgan dasturiy taʼminot muhandisligi jarayonidir. Kodni AI yaratgani uchungina tamoyil oʻzgarmaydi. Biroq kod endi ancha tez yaratilishi mumkin boʻlgani sababli, tekshirish usullarimiz ham shu tezlikka mos ravishda oʻzgarishi kerak, deb oʻylayman. Xususan, oddiy ekran xatosiga quyidagi kabi muammolar bilan bir xil darajada munosabatda boʻlmaslik kerak:

Boshqa foydalanuvchining maʼlumotlariga kirish imkonini beradigan avtorizatsiya muammolari

• Noodatiy kiritish maʼlumotlaridan foydalanadigan hujumlar

• Bir xil soʻrovning bir necha marta qayta ishlanishi

• Bir nechta soʻrov bir vaqtning oʻzida kelganda yuzaga keladigan maʼlumotlar xatolari

• Toʻlov yoki hisob-kitob summalari notoʻgʻri qayta ishlanadigan muammolar

• Ishlab chiquvchi hech qachon koʻrib chiqmagan bajarilish tartibi

• Agar kod yaratish usulimiz AI davriga moslashish uchun oʻzgarayotgan boʻlsa, uni tekshirish usuli ham oʻzgarishi kerak.

3. Testlarni avtomatlashtirishga ham AI’ni qoʻshaylik

Masalan, aʼzolar maʼlumotlarini oʻzgartirish uchun API yaratdik, deb faraz qilaylik. Odatda quyidagiga oʻxshash testlarni oʻylashimiz mumkin. Odam bir nechta holatni tekshirib, keyingi ishga oʻtishi mumkin, ammo AI’dan ushbu ssenariylarning yana koʻplab variantlarini yaratishni soʻrashimiz mumkin.

Bu noldan ulkan, alohida testlash tizimini yaratishimiz kerak degani emas. AI kod yozish vositalari allaqachon loyiha kodini oʻqishi, buyruqlarni bajarishi, test natijalari va xatolik loglarini tekshirishi mumkin. Avval ulardan biz allaqachon foydalanayotgan JUnit testlarini ishga tushirishni, muvaffaqiyatsiz natijalarni tahlil qilishni va yangi test holatlarini qoʻshishni soʻrashimiz mumkin. Veb-interfeyslar uchun Playwright yoki Selenium kabi mavjud brauzerlarni avtomatlashtirish vositalaridan, xavfsizlikni tekshirish uchun esa ZAP kabi vositalardan foydalanishimiz mumkin. Yaqinda chiqarilgan Playwright versiyalari kabi AI asosida testlarni oʻzi yaratadigan va oʻzgartiradigan vositalar ham paydo boʻlmoqda.

Oxir-oqibat, yangi testlash vositalarini noldan yaratish oʻrniga, JUnit, Playwright, Selenium va ZAP kabi mavjud vositalarning oldi va ortiga AI’ni ulaymiz. Bugun kod yaratishda qilayotganimiz kabi, testlash jarayonida ham ssenariylarni qayta-qayta yaratish → bajarish → natijalarni tekshirish → qamrov yetarli boʻlmagan joylarga qoʻshimcha testlar kiritish mumkin.

Hatto buning oʻzi ham ishlab chiquvchilar avval oʻzlari oʻylab chiqishi va yozishi kerak boʻlgan testlar miqdorini sezilarli darajada kamaytirishi mumkin. Biroq bitta cheklov saqlanib qoladi. Qancha koʻp test yaratmaylik, ular baribir ishlab chiqish vaqtida koʻrib chiqilgan doira ichida ishlaydi. Xoʻsh, oldindan koʻra olmagan muammolarni qayerdan topishimiz mumkin?

4. Production muhitidagi maʼlumotlarni testlarga qaytadan uzatishimiz mumkinmi?

Qancha koʻp test ishga tushirmaylik, haqiqiy production muhitida kutilmagan muammolar yuzaga keladi. Bu ham yangi tushuncha emas. Biz har doim production loglari va monitoring maʼlumotlarini tekshirib, muammolarning sababini topganmiz, ularni tuzatganmiz va xuddi shu muammolar yana yuzaga kelmasligi uchun testlar qoʻshganmiz.

AI davrida bu jarayonni yana biroz avtomatlashtira olmaymizmi?

Aslida, bu ham mutlaqo yangi yondashuv emas. Biz undan uzoq vaqtdan beri foydalanib kelamiz. AI davrida yashayotganimiz uchun mavjud dasturiy taʼminot muhandisligi yoʻqolib ketmaydi. Aksincha, gap shakllangan usullar ustiga AI’ni qoʻshish va ilgari odamlar koʻp bajargan vazifalarni bosqichma-bosqich avtomatlashtirish haqida bormoqda: muammolarni tahlil qilish, yangi test holatlarini oʻylab topish va production muhitida aniqlangan muammolarni testlash jarayoniga qaytarish.

5. Ishni boshlashdan oldin ulkan yechim kerakmi?

Men bu tuzilmaning barchasini hali oʻzim amalga oshirib koʻrganim yoʻq. Shuning uchun aniq amalga oshirish usullari haqida qatʼiy fikr bildirishimdan oldin hali koʻp narsani oʻrganishim kerak. Biroq bizga kerak boʻladigan koʻplab texnologiyalar allaqachon mavjud.

Java testlari uchun JUnit

• Brauzer testlarini avtomatlashtirish uchun Selenium yoki Playwright

• Xavfsizlik testlari uchun ZAP

• Ish jarayonini ulash uchun avtomatlashtirish vositasi sifatida n8n

• Ichki kod yoki production maʼlumotlarini tashqi muhitga yuborish qiyin boʻlganda mahalliy LLM

• Masalan, juda sodda sozlamada mahalliy LLM test ssenariylarini yaratadi, JUnit, Playwright, Selenium yoki ZAP kabi vositalar esa ularni bajaradi. Keyin AI natijalar va loglarni tahlil qilib, yangi testlar qoʻshadi. Agar muhit ichki kod yoki production maʼlumotlarini tashqariga yuborishni qiyinlashtirsa, bu AI’ni mahalliy LLM sifatida sozlash mumkin. n8n kabi vosita ushbu bosqichlarni ulashi mumkin.

Masalan, nihoyatda sodda diagramma quyidagicha koʻrinishi mumkin.

Boshidanoq ulkan tizim yaratish shart emas. Bugun kod yaratishda qilayotganimiz kabi, avval AI’ga bitta vazifani topshirib, natija samarali boʻlsa, avtomatlashtirish doirasini bosqichma-bosqich kengaytirishimiz mumkin.

Xulosa

Bugungi kunda koʻplab kompaniyalar AX (AI Transformation) haqida gapirmoqda. Ammo mijozlarimizning ishlari va tizimlarini AI atrofida oʻzgartiramiz, deb turib, oʻzimizning ishlab chiqish amaliyotlarimizni avvalgidek qoldirsak, bu biroz gʻalati emasmi? Menimcha, kod yaratish uchun AI’dan foydalanish bu oʻzgarishning boshlanishidagina. Agar AI kod yaratish usulimizni oʻzgartirgan boʻlsa, testlash va test natijalarini tahlil qilish usulimizni ham AI oʻzgartirishi kerak.

Albatta, hamma narsani birdaniga oʻzgartira olmaymiz. Biror narsani ketma-ket oʻzgartirar ekanmiz, dasturiy taʼminot yaratishning butun jarayoni oxir-oqibat AI davriga moslashadi. Menimcha, hozir muhimi bir urinishda mukammal kod yaratish emas, balki nomukammal dasturiy taʼminotdagi muammolarni tezroq aniqlash, tezroq tekshirish va olingan tajribani keyingi ishlab chiqish sikliga qaytarish imkonini beradigan tuzilmani yaratishdir.

Kod yaratishdan boshlangan oʻzgarish bosqichma-bosqich tekshirish va ekspluatatsiyagacha kengaysa, ishlab chiqish jarayonining oʻzi ham nihoyat AX davriga kirmaydimi?

zacca

zacca