База от вайбкодера: пока всё работает — можно не разбираться

Сейчас можно открыть Cursor, Claude Code или ChatGPT, написать:

И через несколько минут получить код.

Красота.

Проблема начинается чуть позже. Когда агент полез не туда. Когда «забыл» важное требование. Когда внезапно использовал старую документацию. Когда уверенно написал ерунду. И вот в этот момент вайбкодинг заканчивается.

Начинаются вопросы:

Чтобы отвечать на них, достаточно понимать несколько базовых вещей.

Начнём с главного заблуждения.

LLM не «знает ответ» в привычном смысле. Она строит его по кусочкам.

Пишем:

С высокой вероятностью дальше будет:

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

И первая полезная мысль для любого вайбкодера: если AI ответил уверенно, это вообще не означает, что он ответил правильно.

Для нас текст состоит из слов. Для модели — из маленьких кусочков. Одно слово может быть одним токеном. Другое — несколькими.

Представь LEGO. Ты видишь машинку. Модель — отдельные детали.

Токенами считается:

Поэтому фраза «я просто дал ему весь проект» иногда оказывается довольно дорогой. И не обязательно полезной.

Вот тут начинается одна из главных причин странного поведения AI. Представь рабочий стол.

На нём лежат:

Но стол не бесконечный. В какой-то момент что-то придётся убрать, сократить или заменить кратким пересказом. Это и есть контекстное окно.

Поэтому AI не обязательно «помнит всё, что мы обсуждали». Он работает с тем, что находится перед ним прямо сейчас.

И здесь популярная ошибка:

Нет.

Если завалить человека двумястами документами, работать ему легче не станет. С моделью так же. Нужен не максимальный контекст. Нужен правильный.

Вайбкодинг часто выглядит примерно так:

А потом начинается удивление.

Потому что она угадывала.

Можно сказать человеку:

А можно:

Вторая задача просто лучше определена. С prompt то же самое.

Нужно обозначить:

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

Теперь ты просишь AI:

Сама LLM не умеет читать твои файлы или запускать команды. Для неё это внешний мир.

Представь умного помощника без компьютера. Обсуждать код он может. Открыть репозиторий — нет.

Tools дают ему руки:

Но модель обычно не выполняет действие сама.

Она говорит системе:

И система выполняет действие.

Поэтому когда кажется, что «Claude сам запустил тесты», полезно помнить: LLM решила, что тесты надо запустить. Запустил их обычный код вокруг неё.

А вот это уже особенно важно для вайбкодинга. Допустим, две IDE используют одну и ту же модель. Но работают совершенно по-разному.

Почему?

Потому что модель — только часть вайбкодинга.

Ещё кто-то должен решить:

Вся эта среда вокруг модели и есть harness.

Представь двух одинаково умных сотрудников.

Одному дали ноутбук и сказали:

Второму дали доступы, документацию, инструкции, инструменты и нормальное рабочее место. Формально интеллект одинаковый. Результат будет разный. Поэтому вопрос «какая модель внутри?» уже объясняет далеко не всё.

Вот мы и добрались до любимого слова последних лет.

Обычный чат:

Агент может делать несколько шагов подряд.

Например:

Он:

После каждого действия появляется новая информация. И модель решает, что делать дальше.

Вот и вся агентность:

посмотрел → сделал → увидел результат → выбрал следующий шаг.

Звучит отлично.

Но здесь есть неприятная особенность. Если на третьем шаге модель приняла плохое решение, четвёртый шаг уже строится поверх него. А потом пятый. Поэтому чем больше автономности мы даём AI, тем важнее понимать, что происходит внутри этого цикла. Иначе это уже не вайбкодинг. Это вайбдебаггинг.

Почти в каждом проекте есть вещи, которые AI не должен придумывать заново.

Например:

Повторять это в каждом запросе бессмысленно. Для этого существуют Rules. Это постоянные правила работы. Примерно как договорённости в команде, которые не обсуждаются заново на каждой задаче.

А есть инструкции, которые нужны только иногда.

Например:

Это Skills.

Разница простая:

Зачем это вообще нужно?

Чтобы не тащить в контекст инструкцию по релизу, пока агент чинит маленький unit-тест. Рабочий стол и так-то не резиновый.

Ещё одна классическая ситуация:

С чего вдруг?

Если внутренние документы компании не попали в обучение модели и сейчас не лежат в контексте, она их не знает. Тогда нужен RAG.

Представь библиотекаря. У тебя миллион страниц документов.

Ты спрашиваешь:

Нормальный библиотекарь не приносит тебе всю библиотеку. Он находит несколько нужных страниц. И уже по ним ты отвечаешь.

RAG делает примерно это: сначала поиск → потом ответ LLM.

Но здесь тоже есть грабли. Если поиск принёс не тот документ, модель прекрасно ответит по нему. Уверенно. Красиво. Неправильно. Поэтому наличие RAG ещё не означает наличие правильных ответов.

Ты пишешь:

Добавь новую ручку API и покрой тестами.

Что происходит дальше?

И вот здесь фраза:

становится довольно сильным упрощением.

Код получился не только потому, что модель хорошая. На результат повлияли контекст, инструкции, инструменты, поиск и вся система вокруг неё. Поэтому вайбкодить можно вообще без понимания этих вещей. Пока всё работает.

Но когда AI начинает делать что-то странное, вопрос уже не:

Почему GPT тупит?

А: что он видел, какие инструкции получил, какими инструментами пользовался, и где именно система свернула не туда.

Вот с этого момента вайбкодинг превращается в инженерию.