Защо структурираните данни печелят винаги срещу екранните снимки в разговора с AI асистент

Защо пикселите не са най-добрият ти приятел

Представи си следното: 2 часа през нощта, вече третата си чаша кафе, и се бориш с изместен бутон в CSS. Накрая решаваш да снимаш екрана, пействаш в терминала и питаш: "Поправи този бутон."

AI асистентът ти поглежда пикселите, прави предположение какво вижда, и ти дава някакво решение. Звучи добре на хартия. Само че всичко това е достатъчно сложно, за да те ядоса в 2 сутринта.

Математиката на токените

Нещо, за което компаниите зад AI асистентите не обичат да говорят: всяка снимка на екрана струва пари и заема място от контекста. Една ретина снимка в Claude е около 1500+ токена само за визуална обработка. GPT-4o изяжда около 1100 токена. Gemini 2.5? Приблизително 1550.

Сега умножи това по интерактивна сесия. Ако показваш състоянието на екрана на всеки няколко prompt-а — а при мен това се случва 15-20 пъти — изведнъж си похарчил 22 000 до 31 000 токена само заради картинките, преди AI-ът да е свършил каквато и да е полезна работа. На 200k контекст прозорец това си е чиста загуба.

А ако ползваш Opus 4.7 или 4.8? Подготви се за около 96 000 vision токена в същата сесия.

Алтернативата? JSON с описание на UI елементите: позиции, цветове, текст, семантична роля. Същото състояние на екрана в JSON? Около 700 токена. За 20 стъпки — приблизително 14 000 токена общо.

Това не е малко подобрение. Това е разликата между това да довършиш рефакторинга си и да те изхвърлят навън заради препълнен контекст.

Структурата печели

Но ето какво наистина има значение — и това е нещото, върху което не спирам да мисля.

Когато пействаш снимка, AI-ът трябва да преинтерпретира всичко на всяка стъпка. Суровите пиксели не са постоянно състояние за разсъждение. Питаш нещо шест prompt-а по-късно и моделът пак се връща да гледа пикселите, пак прави предположения.

Структурираният JSON променя цялата динамика. Вместо "ето какво може би представляват тези пиксели", даваш на AI-а факти, върху които може да гради: "Елемент e4 е бутон на позиция [0.34, 0.60, 0.32, 0.07], с цвят #3B82F6, с надпис 'Регистрация'."

Не трябва да гадае кое поле за въвеждане имаш предвид. Схемата вече знае. Разсъжденията са базирани на едни и същи примитиви, които ще се ползват и на следващата стъпка. Не показваш — казваш.

Какво общо има това с vibe coding

Тук нещата се свързват с по-голямата промяна в AI-assisted разработката — това, което някои наричат "vibe coding".

Цялата идея на vibe coding е да можеш да опишеш какво искаш, да итерираш бързо и да се довериш на AI-а за детайлите по имплементацията. Но vibe coding работи само когато AI-ът разполага с точна информация за това, с което работи.

Една снимка губи информация. Анотация в PNG e просто червени пиксели върху правоъгълник. Но анотация в структуриран JSON носи намерение: кой елемент цели, какво се опитваш да подчертаеш, какво искаш AI-ът да направи по въпроса.

Когато премахнеш гадаенето, премахваш и триенето. А премахването на триенето е всъщност целта на vibe coding.

Практическият съвет

Не, не казвам да не ползваш снимки никога. Понякога просто трябва да покажеш нещо бързо. Но ако правиш сериозна итеративна работа с AI coding асистент — рефакторинг, дебъгване, build-ване на функционалности със сложен UI — структурираните данни са правилният път.

Инструментите, които разбират това, стават все по-умни. Тези, които не разбират, тепърва ще изостават. Защото в крайна сметка твоят AI асистент не "вижда" в истински смисъл, когато пействаш картинка. Той интерпретира. А интерпретацията е скъпа, губи данни и е непостоянна.

Дай му нещо, което може наистина да прочете.

А ти какво мислиш? Усещал ли си натиска върху контекстния прозорец в дълги AI сесии за писане на код? Сподели в коментарите — строим това в реално време и твоят опит има значение.