Проблема со скриншотами

Давай нарисуем картину. Два часа ночи. Ты уже час бьёшься над одной и той же CSS-проблемой. Наконец сдаёшься — делаешь скриншот, вставляешь в терминал и пишешь: «почини эту кнопку».

ИИ-ассистент смотрит на пиксели, пытается их интерпретировать и — если повезёт — выдаёт что-то полезное. Но вот что на самом деле происходит: модель тратит токены на распознавание картинки, потом ещё токены на интерпретацию увиденного, а потом гадает, какой из 47 элементов на твоём 1440p-экране ты имел в виду.

Многовато гаданий для двух ночи.

Математика токенов, о которой все молчат

Вот что не афишируют создатели ИИ-помощников для кода: каждый скриншот — это реальные деньги и потерянное место в контексте. Типичный ретина-скриншот в Claude стоит примерно 1500+ токенов только на визуальную обработку. У GPT-4o — около 1100. Gemini 2.5? Примерно 1550.

А теперь умножь на итеративную сессию. Показываешь состояние экрана каждые несколько запросов — а если ты, как и я, разбираешься со сложной UI-багой, это может быть 15-20 раз за сессию.

Неожиданно ты потратил 22 000–31 000 токенов только на зрение, и это до того, как ассистент сделал хоть что-то полезное. В контексте на 200k — это реальная территория, которую ты не вернёшь. А если работаешь с Opus 4.7 или 4.8? Приготовься к примерно 96 000 визуальных токенов за ту же сессию.

Альтернатива? Структурированный JSON с описанием UI-элементов: позиции, цвета, текст, семантическая роль. То же состояние экрана в JSON? Около 700 токенов. За 20 запросов — примерно 14 000 токенов.

Это не небольшое улучшение. Это разница между тем, закончишь ли ты рефакторинг или тебя выкинет из контекста на полпути.

Структура побеждает пиксели: настоящий выигрыш

Но вот что действительно важно, помимо математики токенов — и об этом я всё время думаю.

Когда отправляешь скриншот, ассистент вынужден заново интерпретировать всё каждый раз. Голые пиксели — это не устойчивое состояние для рассуждений. Задашь уточняющий вопрос через шесть сообщений — и модель снова смотрит на пиксели, снова интерпретирует, снова гадает.

Структурированный JSON меняет всю динамику. Вместо «вот что могут означать эти пиксели» ты даёшь ассистенту факты, на которые он может ссылаться и которые может развивать: «Элемент e4 — кнопка в позиции [0.34, 0.60, 0.32, 0.07], цвета #3B82F6, с надписью 'Зарегистрироваться'».

Ассистенту не нужно гадать, на какой инпут ты показываешь. Схема уже знает. Рассуждения строятся на тех же примитивах, которые будут использованы в следующем шаге. Ты не показываешь — ты объясняешь.

Почему это важно для вайб-кодинга

Вот где это пересекается с более широким сдвигом в ИИ-ассистируемой разработке — тем, что некоторые называют «вайб-кодингом».

Суть вайб-кодинга в том, что ты описываешь, чего хочешь, быстро итерируешься и доверяешь ИИ разбираться с деталями реализации. Но вайб-кодинг работает только тогда, когда у ИИ есть точная информация о том, с чем он работает.

Скриншот — это lossy-формат. Аннотация в PNG — просто красные пиксели на прямоугольнике. А аннотация в структурированном JSON несёт намерение: какой элемент выделен, что именно ты хочешь подчеркнуть, что просишь ассистента сделать.

Когда убираешь гадания — убираешь трение. А убрать трение — это и есть настоящая цель вайб-кодинга.

Практический вывод

Не пойми неправильно: я не говорю, что скриншоты нельзя использовать никогда. Иногда нужно просто быстро что-то показать. Но если занимаешься серьёзной итеративной работой с ИИ-помощником — рефакторинг, отладка, фичи со сложным UI — структурированные данные это путь.

Инструменты, которые это понимают, становятся умнее. Которые нет — скоро отстанут. Потому что в итоге твой ИИ-ассистент не видит по-настоящему, когда ты отправляешь картинку. Он интерпретирует. А интерпретация — это дорого, неточно и непоследовательно.

Дай ему лучше то, что он может прочитать.