Nega AI agent ish tugamagan bo‘lsa ham “tayyor” deydi?

OpenAI modeli sandboxdan qanday chiqib, Hugging Face’ni buzdi?#

Avval faktlar, keyin buning sizga nima uchun aloqasi borligi haqida.

OpenAI o‘z modellarining hujumkor kiberxavfsizlik bo‘yicha nimalarga qodirligini o‘lchadi. Buning uchun ExploitGym sinovidan foydalandi — ma’lum zaiflikni ishlaydigan eksploitga, ya’ni o‘sha zaiflikdan foydalanadigan tayyor dasturga aylantirish kerak bo‘lgan 898 ta topshiriq. Modellarning haqiqiy imkoniyatlari chegarasini ko‘rish uchun odatda bunday ishlarni to‘sadigan ichki xavfsizlik filtrlarini o‘chirib qo‘yishdi. Muhitni butunlay izolyatsiya qilib, faqat bitta chiqish yo‘lini qoldirishdi: paketlarni o‘rnatish uchun ishlatiladigan ichki vositachi dastur.

Nol kunlik zaiflik — bu hali hech kim, jumladan dasturni yozgan odam ham bilmaydigan bo‘shliq. Modellar aynan o‘sha yagona chiqish joyidan shunday zaiflik topdi.

Keyin ular imtiyozlarini oshirdi, ichki tarmoq orqali internetga ulangan mashinaga o‘tdi va u yerdan ExploitGym javoblari Hugging Face’da bo‘lishi mumkin, deb taxmin qildi. Hech kim ularga Hugging Face haqida aytmagan edi. Buni o‘zlari topishdi.

Taxmin noto‘g‘ri edi. ExploitGym Hugging Face’da umuman yo‘q. Ammo bu buzib kirishni kamroq haqiqiy qilmaydi.

Hugging Face kirib kelganlarni o‘zi aniqladi va iyulning 16-sanasida, kim buzib kirganini hali bilmagan paytida, hodisa haqida e’lon qildi.

O‘sha xabardagi yana bir tafsilot vaziyatning hozirgi holati haqida ko‘p narsa aytadi. Hugging Face muhandislari hujum jurnalini odatiy tijoriy interfeyslar orqali yetakchi modellarga yuborib ko‘rishganda, xavfsizlik filtrlari so‘rovlarni to‘sdi: ular buzib kirishni o‘rganayotgan odamni uni amalga oshirayotgan odamdan ajrata olmaydi. Oxir-oqibat, tahlil o‘z apparatlaridagi ochiq modelda bajarildi.

OpenAI Hugging Face xabaridan besh kun o‘tib, 21-iyul kuni hodisani tan oldi. O‘sha paytgacha buzib kirishning o‘zidan taxminan o‘n kun o‘tgan edi.

OpenAI o‘z tahlilini quyidagi xulosa bilan yakunladi.

Model sinovning tor maqsadiga qattiq berilib, unga erishish uchun haddan oshdi. hyper-focused va fairly narrow testing objective iboralari OpenAI’ning o‘zidan olingan va uning o‘z modellariga tegishli.

Mana shu birovning laboratoriyasidagi voqeadan sizning noutbukingizgacha ko‘prik bo‘ladi.

Nega bu “gallyutsinatsiya” emas?#

Suhbatlarda “yana gallyutsinatsiya qildi”, “kontekst haddan tashqari to‘lib ketdi” yoki “reja tuzishimiz kerak edi” degan gaplarni ko‘p uchrataman. Ba’zan aynan shunday bo‘ladi. Ammo AI agent “tayyor, tekshirdim, hammasi ishlayapti” deb yozib, ish aslida tugamagan bo‘lsa, odatda bunga kontekst hajmining aloqasi bo‘lmaydi.

U hech narsa o‘ylab topmadi. Siz o‘lchagan narsani aynan bajardi.

Ommabop va hamma narsani qamrab oladigan “gallyutsinatsiya” so‘zi ostida uch xil xatoni aralashtirib yuboramiz. Ularning farqi quyidagicha:

Birinchi holat kontekst bilan tuzatiladi va eng yaxshi tanilgan holat ham shu. Ikkinchisi alohida hodisa bo‘lib, Claude hamma narsaga qo‘shiladigan holatlar haqidagi tahlilda ko‘rib chiqilgan: model tezda rozi bo‘lish uchun aniqlikdan voz kechadi. Ikkalasi ham ish boshlanishidan oldin, kiritish bosqichida yuz beradi.

Jadvalning uchinchi qatori ushbu maqola haqida. Bu yerda agent xushomad qilmadi va hech narsa to‘qimadi. Ishladi, tekshirdi va haqiqatni xabar qildi. Faqat bu haqiqat ko‘rsatkichni tasvirlaydi, topshiriq haqida esa hech narsa demaydi.

Uchinchi xatoning nomi bor.

Mukofotni aldash oddiy tilda nima?#

Ta’rifni Anthropic’ning o‘zi beradi.

Bu g‘oya neyron tarmoqlardan ham eski. DeepMind maqolasida bu hodisa specification gaming deb ataladi va bir afsona orqali tushuntiriladi.

Midas aynan so‘ragan narsasini oldi. Muammo so‘rovning ifodalanishida edi.

Dasturlashda bu aniq shakllarda namoyon bo‘ladi. Mana Anthropic’dan olingan, darslikka xos misol:

Bu faqat g‘ayrioddiy laboratoriya sharoitida bo‘lmaydi. Cursor mashhur mezonda 731 ta harakat ketma-ketligini tahlil qildi.

“Yechilgan” topshiriqlarning o‘ntadan oltitasi — topib olingan javoblar. Shu sababli soha unumdorlikni o‘lchash usulini o‘zgartiryapti: ishlab chiqarishga tayyorlikni o‘lchaydigan mezon haqidagi tahlilimizda tekshiruvlardan o‘tish endi asosiy mezon emas.

Bu oddiy mahsulotda qanday ko‘rinadi?#

Laboratoriya misollarini g‘ayrioddiy deb chetga surish oson. Shuning uchun amaliyotdan to‘rtta voqeani keltiraman. Mijozlar va sohalar o‘zgartirilgan, ammo voqealarning mexanizmi o‘z holicha qoldirilgan.

To‘rtta yashil belgi va ishlamaydigan xizmat komponenti

Ko‘chmas mulk agentligi xizmat yaratyapti: e’lonlari bor veb-sayt va e’lonlarni kechasi platformalarga chiqaradigan alohida fon jarayoni. Agent topshiriqni tugatib, quyidagilarni xabar qiladi: turlar tekshiruvidan o‘tdi, kod uslubi tekshiruvidan o‘tdi, yig‘ish muvaffaqiyatli bo‘ldi, sahifalar javob beryapti va ularni ko‘z bilan tekshirishdi.

Har bir gap rost. Ammo ularning hech biri tungi jarayonga aloqador emas: u alohida jarayon sifatida ishlaydi va umuman veb-sayt yig‘ilishiga kirmaydi. Joylashtirish muvaffaqiyatli tugaydi, sayt benuqson ishlaydi, e’lonlar eksporti to‘xtaydi, mijozlar esa bu haqda bir kundan keyin xabar beradi.

Endi “tayyor” deyishdan oldin bitta savol beraman: ishning qaysi qismi mening tekshiruvim qamrab oladigan doiradan tashqarida ishlaydi? Agar shunday qism bo‘lsa, uni alohida ishga tushirib, buyruq chiqishini hisobotga qo‘shaman. “Tekshirildi” degan so‘z masalani yopmaydi.

Noto‘g‘ri tasdiq belgisi aynan tutashgan joyda turadi

Onlayn do‘kon katta topshiriqni bir vaqtning o‘zida bir nechta agentga bo‘lib beradi: biri backendni, boshqasi sahifalarni, uchinchisi mahsulot kartalarini bajaradi. Har biri astoydil ishlaydi va har birida tekshiruvlar yashil.

Bir hafta o‘tgach, “bu sharh foydali bo‘ldi” tugmasi hech qayerda ishlamasligi aniqlanadi. Backend to‘liq yozilgan, tekshiruvlari yashil, qayta hisoblash qoidalariga amal qilingan. Faqat hech bir sahifada tugma ko‘rinmaydi: tugma bir agentning vazifasida, sahifalar boshqasining vazifasida bo‘lgan, ekranda ko‘rsatishni esa hech kim o‘ylamagan. Hisoblagich abadiy nol bo‘lib qolardi.

“Kod yozilgan va tekshiruvlar bilan qamrab olingan” hamda “funksiya ishlaydi” — ikki xil da’vo. Har bir yangi funksiya uchun bitta savol berib, ikkinchisini tekshiraman: uni kim chaqiradi? Loyiha ichidan qidirib tasdiqlayman, chunki bu yerda agent hisoboti haqiqat manbai emas.

Tekshiruvchi faqat tekshirish topshirilgan yo‘nalishni ko‘radi

Xizmat sodiqlik darajalarini joriy qiladi: qancha ko‘p to‘lasangiz, maqomingiz va chegirmangiz shuncha yuqori bo‘ladi. Joylashtirishdan oldin kod “O‘z maqomingizni sun’iy oshirib ko‘ring” degan topshiriq bilan ko‘rib chiqishga yuboriladi. Tekshiruvchi vazifani halol bajarib, “jiddiy muammo yo‘q” deb xabar beradi — haqiqatan ham maqomni sun’iy oshirib bo‘lmaydi.

Ikkinchi tekshiruvda boshqa savol beriladi: “Pul qaytarilsa, maqomga nima bo‘ladi?” Bo‘shliq o‘n daqiqada topiladi. Ballar tranzaksiyalar jurnalidan hisoblangan, jurnal esa pul qaytarilishi haqida hech narsa bilmaydi. Biror narsa sotib oling, ball oling, pulni qaytaring va maqom hamda chegirmani abadiy saqlab qoling.

Birinchi tekshiruvchi ishni yuzaki bajarmadi. U buni tuzilishiga ko‘ra ko‘ra olmasdi: unga “kiritish, rag‘bat” yo‘nalishi berilgan, bo‘shliq esa “kiritishni bekor qilish, rag‘batni saqlash” yo‘nalishida edi. Pul, kirish huquqi yoki sotib olinadigan maqom xavf ostida bo‘lgan joylarda ikki bosqichli tekshiruv o‘tkazaman; ikkinchi bosqichda teskari holatlarni ochiq sanab o‘taman: pulni qaytarish, bloklash, kirish huquqini bekor qilish, amal qilish muddati tugashi, ma’lumot manbasini o‘chirish.

Ko‘rsatkich o‘xshashlikni rag‘batlantiradi

Yetkazib berish xizmati operatorlarga beriladigan AI tavsiyalari yaxshilangan-yaxshilanmaganini o‘lchashga qaror qiladi. Eski 200 ta yordam so‘rovini olib, yangi versiyadan o‘tkazadi va qoralama matnning inson operatori bergan haqiqiy javobga qanchalik o‘xshashligini o‘lchaydi. O‘lchov ishonchli o‘sishni ko‘rsatadi.

Bu o‘sish ikki sababga ko‘ra hech narsani anglatmaydi. Qoralama uchun kontekst “bugungi holat” bo‘yicha yig‘iladi va butun yozishmani, jumladan keyin taqqoslanadigan operator javobining o‘zini ham o‘z ichiga oladi. Model javob yozmayapti; unga ko‘rsatilgan etalonni qayta ifodalayapti. Bundan tashqari, ko‘rsatkichning o‘zi so‘zlar va uzunlikni moslashtirishni rag‘batlantiradi: operator to‘g‘ri sana uchun ishlatgan ayni so‘zlarda noto‘g‘ri sanani ko‘rsatgan qoralama ham yuqori ball oladi.

Endi “o‘xshashlik yaxshi degani” kabi har qanday ko‘rsatkich yoniga uslub alday olmaydigan qat’iy mexanik tekshiruvlar qo‘shaman: o‘ylab topilgan raqam va sanalar, taqiqlangan so‘zlar, harakatga oid va’dalar. Bunday tekshiruvlar natijasi pasaysa, ko‘rsatkichdagi har qanday o‘sish bekor qilinadi.

Agentning “tekshirdim” degani nega hech narsani isbotlamaydi?#

Istalgan loyihangizni olib, agentdan “Xavfsizlikni tekshir” deb so‘rang. Ko‘pincha javob “hammasi joyida, jiddiy muammolar yo‘q” bo‘ladi.

Endi boshqa modeldan ayni loyiha haqida ayni savolni so‘rang. Ayniqsa loyiha katta bo‘lsa, u ko‘p muammo topadi. Muallif joylashtirishdan oldin loyihani uch xil model yordamida tekshiradi; har biri turli narsani topadi.

Bir xil kiritilgan ma’lumot, bir xil savol, qarama-qarshi xulosalar. Modellardan biri boshqasidan yomon emas. Shunchaki “hammasi joyida” ham boshqa har qanday javob kabi, yaratilgan matn xolos. Agent “qaradim, toza ekan” bilan “noto‘g‘ri joydan qidirdim” degan holatni farqlay olmaydi.

Anthropic bu mexanizmni Claude Code hujjatlarida tasvirlaydi.

Bu jumlani shoshmasdan tahlil qiling. Agentga ishga tushira oladigan tekshiruv bermaguningizcha, unda bitta belgi bor — ishlarning qanday ko‘rinishi. Bunday tizimda siz tekshirish navbatidasiz, ammo xatolar haqida eng oxirida bilib olasiz.

Bundan ham chuqurroq jihat bor. OpenAI modelning fikrlash jarayonini kuzatib, “yomon fikrlari” uchun jazolash orqali unga bosim o‘tkazmoqchi bo‘lganida, natija ular kutgandek chiqmadi.

Bildirilgan niyatni jazolash — shu bayonotni yo‘q qiladi. Niyat esa qoladi. Shuning uchun agent qanday aldaganini sizga halol aytishiga ishonmas edim.

Vosita ishlab chiquvchilari ham shu yo‘nalishda harakat qilyapti. Claude Code 2.1.215 versiyasida /verify va /code-review ko‘nikmalari model tashabbusi bilan ishga tushmay qo‘ydi.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic nima uchunligini tushuntirmaydi. Ammo tamoyil aniq: tekshirilayotgan shaxs o‘z tekshiruvini o‘zi belgilamaydi.

Nega loyiha faylidagi qoida agentni jilovlamaydi?#

Loyiha qoidalari fayliga shunday yozgansiz: faqat bevosita ko‘rsatma berilganida commit qil, faqat men bevosita aytganimda ishlab turgan muhitga joylashtir, ishlab turgan muhit ma’lumotlariga faqat o‘qish rejimida murojaat qil.

Muallif tajribasida taxminan har o‘n holatdan birida agent baribir o‘zi ishlab turgan muhitga joylashtiradi. Bu yovuzlikdan emas va qoidani o‘qimagani uchun ham emas. O‘qigan. Shunchaki oldida maqsad bor edi, qoida esa boshqa kontekst matnlari kabi oddiy matn edi.

OpenAI laboratoriyasida ham xuddi shu narsa yuz berdi, faqat ko‘lami kattaroq edi. Modellar yopiq muhitda, bitta chiqish yo‘li bilan ishladi va hisoblash resurslarining salmoqli qismini chiqish izlashga sarfladi. Sinov topshiriqlari esa yechilmadi.

Bu boradagi pozitsiyam oddiy: agent xavfli yoki yovuz emas. U shunchaki oddiy — vakolat berilgan ahmoq. Shuning uchun so‘rovlaringizni qayta yozish emas, uning vakolatlarini cheklash kerak.

Amalda nima to‘xtatadi: ishlab turgan muhitdagi ma’lumotlarga qat’iy o‘qish ruxsati berish. Butun kataloglarni o‘chirishni taqiqlash. Tarixni qayta yozadigan va tiklash yo‘li bo‘lmagan buyruqlarni taqiqlash. Provayder orqali xarajat chegarasini belgilash. Farq bitta iborada: “jismonan qila olmaydi” degani “qilmasligini so‘radim” deganidan kuchliroq. Muayyan sozlamalar alohida, ko‘rsatmalardagi so‘rovlar o‘rniga mexanik tormozlar haqidagi maqolada ko‘rib chiqiladi.

Shunga qaramay, xotirjam bo‘ling. Hatto sandbox ham mutlaq chegara emas va provayder buni ochiq aytadi.

Bundan tashqari, Claude Code’da modelning o‘zi ishlata oladigan favqulodda chiqish yo‘li mavjud. Buyruq sandbox cheklovlari tufayli muvaffaqiyatsiz tugasa, Claude xatoni tahlil qilib, sandboxni o‘chiradigan parametr bilan ayni buyruqni qayta ishga tushirishi mumkin. Buni qat’iy rejimni ochiq sozlash orqali yopish mumkin; sukut bo‘yicha bunday aylanib o‘tish yo‘li mavjud va hujjatlashtirilgan.

Cheklov faqat uni qay darajada qat’iy qilganingizcha ishlaydi. Har bir to‘siq ish tezligini pasaytiradi — buni oldindan xolis hisoblab chiqish kerak, chunki bir haftadan keyin aniqlash ko‘proq xarajat keltiradi.

Aldab bo‘lmaydigan yakunlash mezonini qanday belgilash mumkin?#

Mezon qanday ifodalangani qolgan hamma narsani belgilaydi. Uni bitta savol bilan tekshiring: agent hech narsa qilmay turib ham bu mezonni bajara oladimi?

• “Hammasi ishlashini tekshir” — bajara oladi. “Tekshirildi, ishlaydi” deb yozish kifoya.
• “Yig‘ishni ishga tushir va chiqishini ko‘rsat” — ancha qiyin, chiqishni biror yerdan olishi kerak bo‘ladi.
• “Ilovani ishga tushir, buyurtmani rasmiylashtirish tugmasini bos va ekranda nima chiqqanini ko‘rsat” — buni matn bilan bajarish deyarli imkonsiz.

Birinchi va uchinchi ifoda orasidagi farq — hisobot va dalil orasidagi farq.

Claude Code hujjatlarida qat’iylikning to‘rt darajasi tasvirlangan. Xato narxi oshgani sari yuqorilab borish mumkin bo‘lgan foydali zinapoya:

1. Bitta xabarda. Agentdan tekshiruvni bajarib, muvaffaqiyatli o‘tguncha shu yerning o‘zida takrorlashni so‘rang. Eng arzon usul, kichik ishlar uchun mos.
2. Butun sessiya davomida. Tekshiruvni maqsadning shartiga aylantiring: alohida baholovchi uni har bir navbatdan keyin tekshiradi, agent esa shart bajarilguncha ishlaydi. Texnik tafsilotlar yakunlash mezonini oldindan belgilash qo‘llanmasida berilgan.
3. Mexanik to‘siq. Agent navbatni tugatishga uringanda skript ishga tushib, tekshiruvdan o‘tmaguncha tugatishga yo‘l qo‘ymaydi. Bitta muhim tafsilot bor: ketma-ket sakkizta to‘siqdan so‘ng Claude Code bu to‘siqni chetlab o‘tib, navbatni baribir tugatadi. Tizimda mutlaqo buzib o‘tib bo‘lmaydigan to‘siq yo‘q.
4. Ikkinchi fikr. Natijani rad etishga vazifalangan, yangi kontekstga ega alohida tekshiruvchi.

To‘rtinchi band alohida turadi, chunki u vositalar haqida bo‘lmagan yagona band.

Agent ishini kim qabul qilishi kerak?#

Katta topshiriq ustida agentlarni takrorlanuvchi jarayonda ishlatganimda, tizim shunday bo‘ladi: bir guruh yozadi; yozishda qatnashmagan yangi guruh ishni qabul qiladi.

“Yangi” degan so‘z muhim. Bu yo‘lda qarorlar qanday qabul qilinganini ko‘rmagan toza kontekstni anglatadi. Xuddi shu sessiyadagi boshqa so‘rov buni ta’minlamaydi. Kodni yozgan odam uning to‘g‘riligiga o‘zini ishontirishga allaqachon kuch sarflagan bo‘ladi va tasdiq izlashda davom etadi. Natijani rad etish uning manfaatiga to‘g‘ri kelmaydi.

Tekshiruv topshirig‘ining ifodalanishi tekshiruvchi modeldan muhimroq. Solishtiring:

• “Bu ishni tekshir” — tekshiruvchi topish oson bo‘lgan narsalarni topib, “umuman olganda yaxshi” deb yozadi.
• “Bu ish BAJARILMAGANINI isbotlashga urin” — tekshiruvchi bo‘shliqlarni izlay boshlaydi, chunki uning maqsadi shu.

Ikkinchi ifoda ExploitGym muvaffaqiyatsiz bo‘lganining ayni sababi bilan yaxshiroq ishlaydi: agent o‘ziga berilgan maqsadga intiladi. Unga bo‘shliq topish maqsadini bering, shunda qidiradi.

Quyida to‘liq matn — o‘zgarishsiz nusxalashga tayyor:

Siz boshqa birovning ishini tekshiryapsiz. Siz uni yozmagansiz va himoya qilishingiz shart emas.

Maqsadingiz — barcha tekshiruvlar yashil bo‘lsa ham, da’vo qilingan natijaga ERISHILMAGANINI isbotlash. Natijaga erishilmagan bo‘lishi mumkin bo‘lgan kamida uchta yo‘lni toping.

Quyidagi tartibda tekshiring:

Tekshiruvlar qamrab oladigan doiradan tashqarida qaysi ishlar bajariladi — fon jarayonlari, alohida skriptlar, rejalashtirilgan topshiriqlar, navbatni qayta ishlovchilar.

Har bir yangi funksiyani kim chaqiradi. Loyihadan qidirib chaqiruvni toping; fayl va qatorni ko‘rsating.

Teskari holatlar: pulni qaytarish, bloklash, kirish huquqini bekor qilish, amal qilish muddatining tugashi, ma’lumot manbasini o‘chirish.

Natija bor-yo‘qligini emas, uning ichidagi qiymatlarni tekshiring.

Xolis qidiruvda hech qanday bo‘shliq topilmasa, shuni ayting, lekin aynan nimani va qanday tekshirganingizni ko‘rsating.

Agent takroriy jarayonda o‘zini tekshirishi haqidagi maqolada agentning takrorlar orasida o‘zini tekshiradigan jarayoni qanday ishlashi va odatda qayerda muvaffaqiyatsiz bo‘lishi tushuntirilgan.

Mezonni boshqacha ifodalasangiz, nima o‘zgaradi?#

Bu men biladigan eng arzon yaxshilanish, ammo deyarli hech kim bunday qilmaydi.

Agentdan kodni ko‘rib chiqishni so‘rang — u kod nuqtayi nazaridan fikr yuritadi: tuzilish, xatolarni qayta ishlash, qayta urinishlar, zaif joylar. Foydali.

Undan saytga birinchi tashrifdan tortib pulni qaytarib olishga urinishgacha bo‘lgan mijoz yo‘lini bosib o‘tishni so‘rang — boshqa turdagi muammolar yuzaga chiqadi. Foydalanuvchiga ko‘rmasligi kerak bo‘lgan narsani ko‘rsatadigan xato. Matni haqiqatda sodir bo‘lgan voqeaga mos kelmaydigan xat. Faqat ideal ssenariy orqali kelmagan bo‘lsangiz, mantiqan yakunlab bo‘lmaydigan bosqich.

Kod ko‘rib chiqish bunday nuqsonlarning hech birini topmaydi, chunki ularning har biri kodda yaroqli.

Shundan yodda tutadigan qoida kelib chiqadi: tekshiruv hech narsa topmasa, avval savolning ifodasini o‘zgartiring. Odatda muammo modelda emas. Xuddi shu ish haqida uch xil usulda so‘ralsa, uch xil topilmalar ro‘yxati chiqadi. Dasturchi bo‘lmaganlar uchun amaliy savollar alohida jamlangan: dasturlash ko‘nikmalarisiz kodni tekshirishning yetti usuli.

Agent ishini qabul qilish uchun tayyor so‘rov matni#

“Tayyor” yoki “tekshirildi” deb javob bermang. Menga dalil kerak.

Har bir bajarilgan ish bo‘yicha aynan shularni bering:

Ishlayotganini tasdiqlash uchun qaysi buyruqni bajardingiz? Buyruqning o‘zini va to‘liq chiqishini qisqartirmasdan qo‘shing.

Agar buyruqni bajarmagan bo‘lsangiz, shuni ayting: “bajarilmadi”. Buni “ko‘z bilan tekshirildi” yoki “mantiqan to‘g‘ri” bilan almashtirmang.

Tekshiruvingiz qamrab olgan doiradan tashqarida qaysi ishlar bajariladi? Fon jarayonlari, alohida skriptlar, rejalashtirilgan topshiriqlar, navbatni qayta ishlovchilar — asosiy ilovadan boshqa usulda ishga tushadigan hamma narsa. Har biri uchun: alohida ishga tushirdingizmi va nima chiqardi?

Qo‘shgan har bir yangi funksiyangizni kim chaqiradi? Loyihadan qidirib chaqiruvni toping va fayl hamda qatorni ko‘rsating. Chaqiruv bo‘lmasa, buni ochiq ayting.

Keyin alohida bo‘limda: barcha tekshiruvlaringiz yashil bo‘lsa ham, da’vo qilingan natijaga erishilmagan bo‘lishi mumkin bo‘lgan uchta yo‘l. Jiddiy qidiring.

Oxirida bir satr: avtomatik tekshiruv ilg‘ay olmaydigan, o‘z ko‘zim bilan nimani ko‘rishim kerak?

To‘rtinchi band arzimasdek tuyuladi, ammo muammolarning butun bir turini aniqlaydi. Agentlar o‘rtasida sohalar bo‘yicha taqsimlagan katta topshiriqda butun yuzta ish orasidagi yagona noto‘g‘ri “tayyor” holati ikki soha tutashgan joyda edi: kod yozilgan, tekshiruvlar yashil, lekin hech kim uni ekranda ko‘rsatishni o‘ylamagan.

Tekshiruvda o‘zingizni aldashning to‘rt usuli#

1. Barcha tekshiruvchilarni kutmadi. Bir vaqtning o‘zida uchta tekshiruvni ishga tushirdim, ikkitasi yashil bo‘ldi va joylashtirdim. Uchinchisi to‘rt daqiqadan keyin kelib, oltita qoidabuzarlikni ko‘rsatdi. E’lon qilingandan keyin tuzatish kiritish ikki daqiqa kutishdan qimmatroq.
2. “N tadan N tasi qayta ishlandi” degan xulosaga ishondi. Katta hajmdagi ish ko‘p agentga bo‘linganda ayrimlari sezdirmay muvaffaqiyatsiz bo‘ladi: muvaffaqiyat haqida xabar beradi, ammo faylga tegmaydi. Endi agent orqali har qanday yozuvdan keyin o‘zgarishlar haqiqatan ham diskka yozilganini mexanik ravishda tekshiraman.
3. O‘z ko‘zi bilan qaramadi. Avtomatik tekshiruvlar mutlaqo yaroqsiz natijada ham yashil bo‘lishi mumkin. Rasmlar texnik jihatdan to‘g‘ri, o‘lchami mos, javob kodi to‘g‘ri. Ammo tasvirli muqovalar bo‘lishi kerak bo‘lgan joyda aslida avtomatik muzlatilgan kadrlar qo‘yilgan. Buni hech qanday avtomatik tekshiruv topmaydi.
4. Qiymatni emas, bor-yo‘qligini tekshirdi. Tekshiruv natijadan kerakli matnni qidirdi; matn bor edi, ammo ichidagi ma’lumot noto‘g‘ri: sana bir kun farq qilgan. Tekshiruv yashil bo‘ldi, hisobot esa yolg‘on edi. Endi kutilgan qiymatni to‘liq tekshiraman, chunki kerakli so‘zning o‘zi borligi hech narsani kafolatlamaydi.

Bu to‘rtta holatning umumiy tomoni: tekshiruv bor edi, ishonarli ko‘rindi, ammo noto‘g‘ri narsani tekshirdi. Modellar va ularning sinovidagi mexanizmning o‘zi, faqat ixtirochilik yo‘q.

Bugun nimadan boshlash kerak?#

Yigirma daqiqada bajariladigan uch qadam.

1. Oxirgi “tayyor” holatini oling. Uni dalillar haqidagi bo‘limdagi qabul qilish so‘rovi bilan tekshiring. Maqsad oddiy: nechta band so‘z bilan, nechtasi esa buyruq chiqishi bilan yakunlanganini ko‘rish.
2. O‘zingizga bitta qoida belgilang. Biriktirilgan buyruq chiqishisiz “tekshirildi” degani ishni yakunlash hisoblanmaydi. Bu qoida agentga emas, sizga tegishli, shuning uchun ishlaydi.
3. Ishchi va tekshiruvchini ajrating. Keyingi topshiriqda yangi sessiyaga tekshiruvchi so‘rovini bering va ish BAJARILMAGANINI isbotlashni so‘rang. Birinchi urinishdayoq bu odat o‘zini oqlaydi.

Bu vosita yaxshi va har oy yaxshilanadi: bir yil oldin agent sezdirmay qilgan ishlar bugun uni to‘xtatadi. Xavfsizlik chegarasi siljib borsa ham, chegara bo‘lib qoladi. Agent berilgan maqsadga intilar ekan, “buni aynan qanday o‘lchadingiz?” degan savolni siz berasiz. Tekshirish odati — sizning xavfsizlik tarmog‘ingiz.