Vibe coding: sehr va dahshat oralig'i

Keling, rost bo'laylik: vibe coding ajoyib narsa. Tasavvur qilingan narsani aytasiz, agent uni quradi, testlar o'tadi va jo'natiladi. Bu sehrgarchilik kabi ko'rinadi — toki ko'rinmay qoladi.

O'sha "qoladi" odatda soat 3 da keladi. Ilovangiz yaxshi ishga tushadi, bir necha so'rovni chiroyli qayta ishlaydi, keyin OOM reaper be阴影sha yo'q qiladi. Yoki minglab file descriptor ochib, qulashi mumkin. Yoki test ma'lumotlarida a'lo ishlab, haqiqiy foydalanuvchilar kelganda buzilib ketadi.

Kod to'g'ri edi. Muammoni aniq ko'rsatilgandek hal qildi. Lekin u cheksiz xotira va cheksiz file handle oladi — chunki promtda boshqacha narsa yozilmagan.

Ko'rinmas qotil: aytilmagan taxminlar

Vibe coding haqida hech kim konferensiyada gapirmaydigan qism shu. Kodni o'zingiz yozganda, cheklovlarni ongingizda tushunasiz. Noutbukda 16GB RAM borligini bilasiz. Production serverda file descriptor limit borligini bilasiz. 400GB CSV faylni xotiraga joylashtirib bo'lmasligini bilasiz.

Lekin AI kod yozganda, bu cheklovlar yo'q. AI "faylni och, sarala, natijani yoz" ko'radi va: zo'r, hammasini joylayman, deb o'ylaydi. Testda mukammal ishlaydi. Test fayli 50KB.

Code review ham buni tutmaydi. Muammoli qatorlar to'liq oqilaga ko'rinadi. Hech qanday qizil bayroq ko'rinmaydi — chunki mantiqiy xato yo'q. Xato mantiqda emas; xato ko'rinmas qutida, mantiq shu qutiga moslab yaratilgan.

Agar kompilyator bilganida?

Bu yerda ishlar qiziq bo'lishni boshlaydi. Nicolas Grislain nomli dasturchi g'alati g'oya ustida ishlamoqda: agar resurs cheklovlari comment emas, type bo'ladigan bo'lsa?

AI generatsiya qilingan kod xotira limitlariga rioya qilishini umid qilmasdan, kompilyator literal tarzda raddi etadigan bo'lsa? "Bu funksiya xotirada 100 tadan ko'p record saqlamaydi" va "bu dastur bir vaqtda 3 tadan ko'p fayl ochmaydi" deganlar compiler tekshiradigan fact bo'ladigan bo'lsa?

Bu faqat nazariy emas. Lean 4 dan foydalaniladi — ha, matematika dunyosida shovqin solayotgan o'sha Lean. Resource byudjetlarni to'g'ridan-to'g'ri function typelariga yoziladi. Kompilyator resource auditor bo'lib qoladi — kod ishga tushmasdan oldin limitlarni avtomatik tekshiradi.

Resurslarni sanab ko'rish

Asosiy hiyla bijorak: resource sonlarini type tizimi orqali o'tkazish. "Qancha fayl ochiq" ni runtime variable sifatida kuzatmasdan, type tizimi uni phantom parameter sifatida kuzatadi — va muvozanat bo'lishi shart.

Fayl ochganingizda, type signature o'zgaradi: funksiyaga N ta ochiq fayl bilan kirgasiz, N+1 bilan chiqasiz. Yopganingizda — N+1 dan N ga. Kompilyator har bir qadamda bu hisobni oladi, va siz literal tarzda fayl ochib yopmasdan kod yozolmaysiz, yoki belgilangan chekkadan oshiq fayl ocholmaysiz.

Xotira ham shunga o'xshash, lekin boshqacha. Recordlar erkin suzmabdi — ular cheklangan pool ichida yashaydi, aniq sonli slotlar bor. Siz Event obyektini ushlamaysiz; pool ichidagi reference ushlaysiz. Type har bir daqiqada nechta live reference borligini kuzatadi, va allocation uchun joy borligini isbotlash talab qilinadi.

Sehr kirish nuqtasida bo'ladi: dastur 0 ta ishlatilayotgan resource bilan boshlanib, 0 bilan tugashi shart. Handle yoki ref sizib chiqishi mumkin emas. Chekkalarni oshira olmaysiz. Kompilyator oddiygina qo'ymaydi.

Vibe coding uchun nega muhim

Bu yondashuv AI assistant larni prompt qilish usulimizni o'zgartiradi. Bugun "xotirani tejash kerak" yoki "barcha file handle larni yoping" degan eslatmalar qo'shasiz — AI e'tibor berishini umid qilib. Resource-aware type lar bilan cheklovlarni rasmiy belgilaysiz, va implementatsiya o'zini qoniqtirish uchun qayta tashkil etishi shart.

AI avval cheksiz versiyani oladi. Testlar o'tadi. Keyin limitlarni yo'siz. Kompilyator implementatsiyani darhol rad etadi. AI o'z yondashuvini qayta tuzishi kerak — ehtimol butun faylni bir zumda emas, bo'lak-bo'lak qayta ishlash, yoki fayllarni to'g'ridan-to'g'ri ochmasdan connection pool ishlatish.

Implementatsiya tasodifiy ishlab qolmaydi; u isbotlangan tarzda byudjet ichida ishlaydi.

Amaliy haqiqat

Aniq bo'laylik: bu ko'pchilik uchun hali production tayyor vosita emas. Lean 4 yondashuvi sezilarli o'rnatish talab qiladi, va indexed type larda fikrlash qiyin. Lekin asosiy tushuncha implementatsiyadan qat'iy nazar qimmatli.

Vibe coding qilganda, kod yozishni emas, balki tizimning mental modelini ham topshirasiz. AI assistant ingiz production muhiti haqida bilmaydi. Container da 512MB RAM borligini bilmaydi. Linux kernel file descriptor larni 1024 da cheklashini bilmaydi.

Bu cheklovlarni kodlashning yaxshi usullari bo'lmaguncha, bir necha amaliy variant bor:

1. Promtlarda aniq bo'ling — "Input fayli 10 million qatorgacha bo'lishi mumkin" yozing, "katta fayllarni samarali qayta ishlash" emaski

2. Production hajmidagi ma'lumotlar bilan test qiling — agar training ma'lumotlari kichkina bo'lsa, AI resource patternlarni o'rgana olmaydi

3. Cheklangan API lardan foydalaning — o'z-o'zidan resource ishlatishni cheklaydigan arxitektura (connection pool, loading o'rniga streaming) — xato qilish qiyin

4. Resource-aware vositalarni kuzatib boring — sanoq AI-generatsiya qilingan kodda cheklovlarni aniq qilish yo'llarini o'rganmoqda

Xulosa

Vibe coding sirati bu emaski, u xato kod yozadi — u ko'rinmas cheklov fazosida to'g'ri kod yozadi. O'shbu fazo sizning noutbukingizni, test muhitingizni va ehtimol birinchi ming foydalanuvchingizni o'z ichiga oladi. Albatta production miqyosini emas.

Bunday Lean 4 eksperimenti kabi resource-aware type tizimlar "to'g'ri" degan so'zga yangi ma'no beradi. Bu faqat "mantiqan to'g'ri" emas; bu "haqiqatan mavjud bo'lgan cheklovlar ichida qolishligi isbotlangan" degani.

Bunday kelajak qurishga arziydi. Shunga qadar — test ma'lumotlaringizni production hajmiga yaqin tuting, va promtlaringizga file descriptor limitlari haqida qo'shimcha eslatma qo'shing.

Kelajakdagi on-call dagi o'zingiz rahmat aytadi.