Вайб-кодинг и ИИ: как это работает на самом деле

Понимание механики меняет способ работы сильнее, чем знание кнопок. Разберём, что происходит, когда вы просите модель написать код.

Что происходит под капотом

Модель порождает продолжение текста. Ей на вход подаётся всё, что она должна учитывать - ваш запрос, прочитанные файлы, вывод команд, историю разговора, - и она выдаёт наиболее правдоподобное продолжение.

Из этого следуют три вещи, объясняющие почти всё поведение:

Она не проверяет истинность. Несуществующий метод библиотеки выглядит для неё так же уместно, как существующий: оба вписываются в контекст.

Она не помнит ничего между вызовами. Всё, что она «знает» в момент ответа, отправлено ей в этом же запросе. Отсюда стоимость длинного разговора: каждый шаг отправляет всю историю заново.

Она отвечает по тому, что видит. Не увидела нужный файл - будет опираться на общие знания и напишет правдоподобное.

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

Контекст решает

Практический вывод из механики: большая часть плохих ответов объясняется не формулировкой, а тем, что модель не видела нужного.

Что это значит в работе:

• Точный адрес лучше описания проблемы. «Посмотри функцию разбора в этом файле» работает лучше, чем «разберись, почему не работает парсер»: во втором случае она прочитает пол-репозитория и заполнит контекст мусором.
• Чем больше мусора в контексте, тем хуже ответы. Логи, большие выгрузки и длинная история вытесняют полезное.
• Длинная сессия работает хуже короткой. Когда контекст переполняется, ранняя часть сворачивается в пересказ, детали теряются, а модель продолжает работать так, будто помнит их. Подробно - лимиты и контекст.

Отсюда практика, которая даёт больше всего: одна сессия - одна задача.

Почему модель ошибается

Четыре типовых механизма, которые полезно узнавать в лицо:

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

Симптом вместо причины. Тест падает - модель правит тест. Формально задача закрыта.

Дубликат вместо переиспользования. Не увидела существующую функцию и написала вторую такую же под другим именем.

Отчёт об успехе при неудаче. Команда вернула ошибку, модель написала, что всё готово. Это не редкость, а поведение по умолчанию: диалоги обычно так и заканчиваются.

Общее у всех четырёх: результат выглядит правильным. Именно поэтому беглый просмотр их не ловит.

Как это компенсировать

Пять приёмов, покрывающих большую часть проблем:

1. Давайте проверяемый критерий. Тест, который должен пройти, а не «сделай хорошо». Это единственное, что позволяет модели исправить себя без вас.
2. Читайте диф, а не отчёт. Отчёт описывает намерение, диф показывает факт.
3. Держите контекст чистым. Новая задача - новая сессия.
4. Давайте точный адрес. Экономит и качество, и деньги.
5. Не принимайте утверждения без источника. «Эта функция не используется» должно сопровождаться тем, где искали.

И шестой, для важного: проверяйте другой моделью или другим прогоном. Тот же прогон повторит то же неверное предположение - это тот же принцип, что и слой верификации в агентных системах.

Что из этого следует про границы

Механика объясняет, почему подход хорошо работает там, где есть однозначная проверка, и плохо там, где её нет. Это не недостаток конкретного инструмента, а свойство самого способа: модель оптимизирует правдоподобность, а не истинность, и единственный доступный ей ориентир на истинность - то, что можно запустить.

Обзор инструментов - нейросети для кода. Про агентный режим и разрешения - агенты в вайб-кодинге. Развёрнуто про подход - что такое вайб-кодинг. Общая картина - гид по вайб-кодингу.