The AI Era Needs a Better Review Workflow

Keling, muammoga oldingi va hozirgi development jarayonini solishtirish orqali boramiz.

Ilgari development'da eng ko'p vaqt talab qiladigan qism - kod yozish edi. Murakkab feature'lar bir necha kun, ba'zan esa bir necha hafta olardi. Shuning uchun jamoalar butun e'tiborini coding jarayonini tezlashtirishga qaratardi.

Hozir esa AI agentlar tomonidan minglab change'lar qilingan giant PR'larni review qilish engineerlar uchun haqiqiy bosh og'rig'iga aylana boshladi.

Katta PR'lar nima uchun muammo?

Tasavvur qiling: AI yordamida bitta feature ustida ishladingiz va oxirida 1500–2000 qatorlik Pull Request ochdingiz. Texnik jihatdan hammasi to'g'ri bo'lishi mumkin. Ammo reviewer uchun bu oson emas.

Bir vaqtning o'zida biznes logikasi, API o'zgarishlari, database, UI va refactor'larni ko'rib chiqish katta mental yuk talab qiladi. Natijada:

• review kechikadi;
• merge kechikadi;
• branch eskiradi;
• konfliktlar ko'payadi.

Oxir-oqibat AI sizga vaqt tejagan bo'lsa ham, jamoa umumiy hisobda yutmaydi.

Muammo AI sabablimi?

Men buni AI muammosi deb o'ylamagan bo'lardim. Aslida esa AI faqat allaqachon mavjud bo'lgan muammoni tezroq yuzaga chiqardi.

Shuning uchun katta PR'lar kamroq uchrardi. Endi esa AI bunday PR'larni bir necha daqiqada tayyorlay oladi. Review jarayoni esa hali ham inson tezligida ishlaydi.

To'g'ri, "PR reviewer agentlardan foydalansak-chi?" degan fikr tug'ilishi mumkin. Lekin review jarayonini to'liqligicha AI'ga topshirish katta xatolarga olib kelishi mumkin. Hech bo'lmaganda hozircha men AI agentlarga review jarayonini to'liq ishonib topshirmagan bo'lardim.

Yechim: Stacked PR nima?

Sizga bir taklif: bitta katta feature'ni bitta ulkan Pull Request sifatida yuborish o'rniga, uni mantiqiy qismlarga bo'lsak-chi?

Har bir PR oldingisiga tayanadi, lekin alohida review qilinadi. Reviewer butun feature'ni birdaniga emas, bosqichma-bosqich tushunadi. Natijada review'ning sifati ham, tezligi ham oshadi.

AI + Stacked PR

Mening fikrimcha, AI va Stacked PR bir-birini juda yaxshi to'ldiradi.

Kelajakdagi workflow taxminan quyidagicha bo'lishi mumkin: bir agent API qatlamini yozadi, ikkinchisi business logic ustida ishlaydi, uchinchisi UI yaratadi. Har biri alohida Pull Request ochadi va review ham qatlamlar bo'yicha ketadi.

Bir vaqtning o'zida bir nechta kichik PR'ni ko'rib chiqish 2000 qatorlik bitta PR'ni review qilishdan ancha oson.

Qanday ishlaydi?

GitHub endi Stacked Pull Request'larni native tarzda qo'llab-quvvatlaydi. Uni GitHub'ning Pull Request interfeysi orqali ham, terminaldagi gh stack CLI yordamida ham boshqarish mumkin.

Agar gh CLI ishlatayotgan bo'lsangiz, extension'ni quyidagicha o'rnatasiz:

Skill'lar bilan esa bu jarayon yanada osonlashadi:

Bu yondashuvda har bir AI agent faqat o'ziga biriktirilgan vazifa ustida ishlaydi. Natijada har bir Pull Request bitta aniq vazifani bajaradi va review jarayoni ancha soddalashadi.

Qatlamlarga ajratib ko'ramiz

Endi faqat CI tayyor ekanini tasdiqlash qoladi. Stack ichidagi har bir Pull Request stack base bilan solishtiriladi va har bir layer uchun CI tekshiruvlari alohida bajariladi. Shu sababli har bir bosqich mustaqil tekshiriladi va muammolar erta aniqlanadi.

1-layer — Data Catalog Foundation

Data Modeler agenti yangi stack yaratadi, birinchi branch'ni ochadi va data layer ustida ishlaydi. Kod yozilgach, test va validatsiyalar ishga tushadi. Hammasi muvaffaqiyatli o'tsa, layer commit qilinadi. Aks holda agent muammolarni tuzatib, qayta urinadi.

2-layer — Product Search API

Backend agenti ikkinchi layer'ni yaratadi va birinchi layer ustiga API qismini qo'shadi. API to'g'ri ishlab, barcha tekshiruvlardan o'tsa, layer commit qilinadi.

3-layer — Chat Integration

Frontend agenti chat va API integratsiyasini amalga oshiradi. Testlardan muvaffaqiyatli o'tgach, layer commit qilinadi. Reviewer esa faqat API integratsiyasi va fallback holatlarini ko'rib chiqadi.

4-layer — Grounded UI

Oxirgi layer'da frontend agenti UI va citation komponentlarini yaratadi. Browser testlari muvaffaqiyatli o'tgach, layer commit qilinadi.

Bu layer alohida ajratilganining sababi shundaki, UI'ni review qilayotgan odam data flow'ni tekshirishi shart emas. Xuddi shunday, data owner ham UI tafsilotlariga kirib o'tirmaydi. Reviewer faqat UI, loading, empty va error holatlarini hamda har bir citation to'g'ri mahsulotga bog'langanini tekshiradi.

Stack'ni submit qilish

Barcha layer'lar tayyor. Endi ularni GitHub'ga yuborish va Stacked Pull Request sifatida ochish kerak.

So'ng Pull Request'larni yaratamiz:

Stack Map va CI

GitHub'da barcha Pull Request'lar ochilgach, har birining yuqori qismida Stack Map ko'rinadi. U stack ichidagi PR'lar o'rtasida bir marta bosish orqali harakatlanish imkonini beradi. Har bir layer esa o'zining CI tekshiruvlaridan mustaqil ravishda o'tadi.

Review jarayoni

Endi reviewer nuqtai nazaridan qaraymiz. Stack Map stack ichidagi barcha Pull Request'lar orasida osongina harakatlanishga yordam beradi.

Natijada 1700+ qatorlik bitta ulkan Pull Request o'rniga, bir nechta kichik va mustaqil PR'ni review qilasiz. Bu esa jarayonni ancha sodda va samarali qiladi.

Review'dan keyingi o'zgarishlar

Faraz qilaylik, reviewer birinchi layer'da ikkita muammoni topdi va ularni tuzatishni so'radi. Data Modeler agenti feedback asosida kodni yangilaydi, testlarni qayta ishga tushiradi va o'zgarishlarni push qiladi.

Biroq birinchi layer o'zgargani sababli, undan keyingi barcha layer'lar eski commit'ga tayanib qoladi. GitHub buni avtomatik aniqlaydi va stack'ni qayta rebase qilish kerakligini bildiradi.

Stack'ni yangilash

Agar pastki layer o'zgarsa, stack'dagi qolgan layer'larni ham yangilash kerak bo'ladi. GitHub'da buni Rebase Stack tugmasi orqali qilish mumkin.

Rebase tugagach, barcha layer'larni GitHub bilan sinxronlaymiz:

Natijada stack'dagi barcha Pull Request'lar yangilanadi, CI qayta ishga tushadi va barcha tekshiruvlardan muvaffaqiyatli o'tgach, stack yana merge qilishga tayyor holatga keladi.

Xulosa

Menimcha, yaqin kelajakda "bitta feature - bitta PR" odati asta-sekin o'rnini "bitta feature - bitta stack" yondashuviga bo'shatib berishi mumkin.

---

Yangiliklarni Telegram kanalimda kuzatib borishingiz mumkin: @Diyorbek_dev