Вайбкодинг: полный разбор ошибок — от процесса до архитектуры (2026)

Когда базовые навыки работы с агентом уже есть — задачи формулируются внятно, агент в Kilo Code или Cline бойко генерирует рабочий код — узким местом становится не генерация, а всё, что вокруг неё. Типичный профиль ошибок опытного пользователя: высокая скорость при запаздывающей проверке и неотстроенном процессе.

Эта статья — два уровня разбора. Сначала ошибки процесса, которые проявляются в любом достаточно длинном проекте. Затем продвинутые группы ошибок, которые отличают «уверенного середняка» от инженера: параллелизм, MCP, детерминированное принуждение, выбор модели, дрейф спецификации и границы самого подхода.

Часть 1. Ошибки процесса

Корень проблемы: одна бесконечная сессия

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

Из этой корневой ошибки растёт половина остальных: к концу длинной сессии агент работает на «отравленном» контексте.

Правило: новая несвязанная задача — новая сессия и /clear. Длинную задачу сжимать вручную и заранее, на середине заполнения, а не ждать автоматического срабатывания на пределе:

/compact Сохрани: текущую задачу, какие файлы уже изменены,
какие решения приняты и что осталось доделать.

Чинить баги наслоением

Связанная с длинной сессией проблема — исправлять баги поверх предыдущего состояния. Упал модуль, починили, всплыл второй баг, починили поверх, третий. Всё в той же сессии, без отката к чистой рабочей точке.

После двух-трёх неудачных попыток агент тащит за собой неверные гипотезы, и каждая следующая правка строится на мусоре. В Kilo Code и Cline есть контрольные точки, плюс обычные git-коммиты как точки возврата.

Доверие зелёным тестам

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

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

Проверка постфактум и рапорт вместо подтверждения

Две близкие ошибки. Первая — схема «запушил → запустил → посмотрел логи → ой» вместо «увидел корректный результат → запушил». При таком порядке баг, который тесты не поймали, обнаруживается уже после того, как код в основной ветке.

Вторая — принимать объяснение агента за результат. Агент пишет «всё валидно, запасной вариант даже не понадобился» — но это пересказ его логики, а не реальный вывод.

Пуш в основную ветку и забытое развёртывание

«Пушь в main» сразу после тестов — между «код готов» и «код в основной ветке» нет ступени проверки на реальных данных. И отдельная типичная боль self-hosted: код вшивается в Docker-образ при сборке, поэтому обновить репозиторий недостаточно — нужна пересборка образа. Этот факт легко забыть и потом ломать голову, почему «изменения не применились».

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

«Почини» вместо «разберись»

Несколько багов нередко живут в одном куске кода и видны сразу — но всплывают по очереди, потому что агенту дали команду чинить симптом, а не анализировать причины. «Почини эту ошибку» лечит ровно то, что в логе. «Разберись во всём этом куске и найди все слабые места» находит причины разом и экономит заходы в прод.

Модуль падает с ошибкой: [лог].
Не пиши код. Прочитай весь связанный код целиком.
Найди ВСЕ слабые места: что ещё может сломаться при большом
объёме данных, при медленном или обрезанном ответе, при обрыве связи.
Перечисли проблемы и предложи план — без реализации.

Повторяющиеся требования не становятся правилами

Одно и то же требование — например, «решение должно быть универсальным, не жёстко зашитым под мой конкретный случай» — повторяется в каждом промпте вместо одной записи в CLAUDE.md (в Cline — .clinerules). То же с повторяющимися багами: один класс проблемы выстреливает в разных местах, потому что не зафиксирован как системное правило. Сюда же относятся базовые свойства работы с языковой моделью — обрезанный JSON, некорректный ответ, упёртое ограничение длины. Это не сюрпризы, а данность, которую стоит заложить в правила заранее.

## Работа с языковой моделью
- Ответ модели всегда может обрезаться по ограничению длины.
  Любой разбор ответа должен переживать обрезанный/некорректный результат.
- Большие списки слать частями, а не одним запросом.
- Если ответ пустой — собирать результат из запасных данных, а не падать.
- Текст, уходящий пользователю, обрезать по границе предложения.

## Развёртывание
- Код вшит в Docker-образ при сборке.
- После изменений кода нужна ПЕРЕСБОРКА образа, не только обновление кода.

Часть 2. Продвинутые группы ошибок

Следующие шесть групп отличают уверенного пользователя от инженера. Главный сдвиг 2026 года прост: правила в текстовом файле — это «просьба», которую агент выполняет лишь часть времени; хуки и изоляция через git — это «гарантия». Зрелый процесс переносит инварианты из текста в детерминированные механизмы.

Параллелизм без изоляции

Освоив одного агента, опытный пользователь запускает два-три одновременно в одном рабочем каталоге — «чтобы быстрее». Результат: агенты редактируют одни файлы, гонятся за файлами блокировки, перезаписывают незакоммиченные правки друг друга. Хуже всего то, что провал тихий — тест падает не из-за твоей ветки, а из-за взаимных помех другого агента.

Корень в том, что среды разработки спроектированы под одного человека: одно рабочее дерево, один dev-сервер на порту, одна локальная БД. Агенты же исполняют параллельно на полной скорости, и единый каталог перестаёт работать, как только два агента редактируют репозиторий дольше десяти минут.

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

# по одному worktree на агента/фичу, каждый на своей ветке
git worktree add ../proj-feature-auth -b feature/auth
git worktree add ../proj-fix-nav      -b fix/nav-layout
git worktree list
git worktree remove ../proj-feature-auth   # после merge

Перед запуском задачи оценивай «радиус поражения» — сколько файлов и зависимостей затронет изменение. У агента нет накопленного знания проекта: он видит редактируемый файл, но не шесть файлов, которые из него импортируют. Канонический случай — инцидент Replit в июле 2025, когда агент во время code freeze удалил рабочую боевую базу данных и затем сфабриковал тысячи поддельных записей. Для изменений с большим радиусом — общие интерфейсы, контракты API, миграции БД — обязательно ручное ревью и поэтапное развёртывание.

Kilo Code. Режим Orchestrator (бывш. Boomerang Tasks) разбивает задачу на субзадачи в изолированных контекстах: родитель ставится на паузу, субзадача исполняется в своём режиме и возвращает только результат. Изоляция контекста здесь — главное: оркестратор намеренно ограничен, чтобы его контекст не отравлялся деталями исполнения. В новых версиях расширения и CLI выделенный режим-оркестратор помечен как устаревший — агенты с полным доступом делегируют субагентам напрямую, которым можно задать свою модель и права.

Cline. Штатные субагенты получают собственное контекстное окно и возвращают отчёт главному агенту, оставляя основной контекст чистым. Критическое ограничение: субагенты работают только на чтение — они не редактируют файлы и не обращаются к MCP. Отдельно есть Focus Chain — самоуправляемый список задач, который переживает сбросы контекстного окна. Это защита от дрейфа для одной длинной задачи, а не изоляция параллельных агентов.

Перегрузка MCP-серверов

Освоив MCP, опытный пользователь подключает «на всякий случай» десяток серверов. Но каждый подключённый MCP-сервер вливает полные схемы своих инструментов в контекстное окно при старте сессии — до того, как набран первый символ. Чем больше инструментов, тем сильнее деградирует поведение: инструкции игнорируются, агент кажется «поглупевшим» при той же модели.

Масштаб проблемы измерим. По замеру EclipseSource, стандартный набор Playwright, GitHub и IDE-интеграции съедает свыше 20% контекстного окна до начала работы. Замер Scalekit против сервера с 43 инструментами зафиксировал расход в 4–32 раза больше токенов, чем у CLI-эквивалента, при заметно меньшей надёжности: запрос «какой язык в репозитории» стоил ~1 400 токенов через CLI против ~44 000 через MCP — и почти всё это добавленные схемы инструментов, из которых агент использует один-два.

Claude Code решает это функцией MCP Tool Search: вместо загрузки всех схем заранее инструменты подгружаются по запросу, что резко сокращает накладные токены. В VS Code Copilot есть обратная сторона той же проблемы — жёсткое ограничение в 128 инструментов, блокирующее агентный режим при множестве серверов.

Недетерминированные правила вместо хуков

Опытный пользователь раз за разом дописывает в правила «всегда форматируй код», «никогда не коммить в main без тестов» — и удивляется, что агент то слушается, то нет. Корень в том, что текстовое правило — это вероятностная инструкция, которую быстрый агент выполняет непостоянно, особенно по мере роста контекста. Хук же выполняется всегда, без исключений.

Эвристика выбора простая. Если формулируешь «агент обязан всегда…» или «никогда не должен…» — это хук. Если «при работе над X предпочитай Y» — это правило. Хуки нужны для инвариантов, привязанных к событию жизненного цикла: форматирование, блокировка опасных команд, запуск тестов, защита секретов.

В Claude Code хуки выросли в полноценную платформу с событиями PreToolUse (срабатывает до инструмента, может блокировать), PostToolUse (после успеха — формат, линт, тесты) и другими. Конфигурация в settings.json:

{ "hooks": { "PostToolUse": [{ "matcher": "Write|Edit|MultiEdit",
  "hooks": [{ "type": "command",
    "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\"" }] }] } }

Блокировка деструктивных команд через PreToolUse (код возврата 2 означает блок):

{ "hooks": { "PreToolUse": [{ "matcher": "Bash",
  "hooks": [{ "type": "command",
    "command": "echo \"$CLAUDE_TOOL_INPUT\" | grep -qE 'rm -rf|DROP TABLE' && exit 2 || exit 0" }] }] } }

В Cline хуки появились в недавних версиях и кладутся в .clinerules/hooks/ как исполняемые файлы: хук получает JSON по stdin и возвращает JSON, где поле cancel блокирует операцию, а contextModification вставляет текст в разговор. Важное ограничение: на момент выхода функции хуки Cline поддерживались только на macOS и Linux. Для проверок уровня репозитория практики также используют стандартные git pre-commit хуки и CI — они не зависят от настроения модели вообще.

Неверная модель под фазу задачи

Две зеркальные ошибки: гонять дорогую флагманскую модель на рутине (переименования, тривиальные правки) — жжёт деньги и время; ставить слабую модель на архитектуру и планирование — где цена ошибки максимальна. Зрелый паттерн: планируй на сильной рассуждающей модели, исполняй на быстрой и дешёвой.

Уровни «усилия» и мышления тоже часть выбора. В Claude Code расширенное мышление (триггер вроде ultrathink или постоянная настройка /effort high) оправдано для архитектурных решений, гонок данных и многофайловых багов. Для переименования переменной оно только жжёт токены — высокий уровень усилия даёт кратно больше расхода. Типовая эффективная связка — сильная модель в режиме планирования с расширенным мышлением, затем исполнение на быстрой модели.

Переключение по фазе встроено в оба инструмента. В Cline — раздельные модели для режимов Plan и Act: при переключении режима модель меняется автоматически. В Kilo Code — Sticky Models: каждый режим (Architect, Code, Debug) запоминает свою последнюю модель, так что планирование и исполнение держат разные модели без перенастройки.

Дрейф спецификации между сессиями

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

Первое лечение — паттерн Memory Bank в Cline: структурированная документация, которую агент читает в начале каждой задачи. Иерархия markdown-файлов:

memory-bank/
├── projectbrief.md      # требования и цели — источник правды по объёму работ
├── productContext.md    # зачем продукт существует
├── systemPatterns.md    # архитектура, ключевые техрешения
├── techContext.md       # стек, окружение, ограничения
├── activeContext.md     # текущий фокус, недавние изменения, следующие шаги
└── progress.md          # что работает, что осталось, известные баги

Стратегия памяти: activeContext.md и progress.md — короткая память, детальная и часто обновляемая; остальные файлы — долгая, сжатая и редкая. Команды-триггеры: «initialize memory bank» создаёт структуру, «update memory bank» пересматривает все файлы. Через условные правила в .clinerules инструкции Memory Bank можно активировать только при работе с этими файлами.

Второе лечение — spec-driven development, где спецификация становится исполняемым источником правды, а код — её регенерируемым выводом по циклу «specify → plan → tasks → implement». Ключевые фреймворки 2026: GitHub Spec Kit — агент-нейтральный CLI, работающий с Claude Code, Copilot, Gemini и Cursor; BMAD-METHOD с мульти-агентными ролями для сложных проектов с нуля (greenfield); OpenSpec с дельта-спеками и строгим автоматом propose → apply → archive для существующих проектов (brownfield). Лёгкая альтернатива — собственные SPEC.md и TASKS.md.

Границы вайбкодинга

Через год после того, как ввёл термин «вайбкодинг», Андрей Карпатый на чате Sequoia AI Ascent в апреле 2026 провёл черту: вайбкодинг поднимает доступный всем потолок возможностей в софте, тогда как агентная инженерия сохраняет планку качества профессионального ПО. Внесение уязвимости нельзя оправдать тем, что «я вайбкодил» — ответственность за софт остаётся на разработчике.

Вайбкодинг перестаёт быть уместным для кода, который пойдёт к множеству пользователей, должен пройти аудит безопасности или будет сопровождаться командой, не писавшей его. По метафоре Карпатого, вайбкодинг производит софт как кулинарный мастер-класс на выходных — настоящую еду, иногда вкусную, но не ресторанного уровня.

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

Практический индикатор «остановись и проверь руками»: радиус поражения изменения велик (общие интерфейсы, контракты, миграции); тесты зелёные, но ты не можешь ответить, какой реальный артефакт это сломает; задача требует продуктового суждения, а не верифицируемого вывода. Данные подтверждают разрыв: по опросу State of Agent Engineering 2026, около 89% команд внедрили наблюдаемость агентов, опережая внедрение циклов оценки (eval) на уровне 52%. Именно этот разрыв между «вижу, что происходит» и «проверяю, что верно» и есть зона агентной инженерии.

Итоговый чек-лист процесса

1. Новая несвязанная задача — новая сессия. Длинную задачу сжимать вручную и заранее.
2. Два провала подряд — откат к рабочему состоянию, а не правка поверх мусора.
3. Перед исправлением — фаза разбора без кода, поиск всех слабых мест разом.
4. Проверять конечный артефакт целиком, а не вывод тестов и не рапорт агента.
5. Коммит и пуш только после проверки на реальных данных, с учётом шагов развёртывания.
6. Повторяющиеся требования, грабли LLM и проверки безопасности — в CLAUDE.md, один раз.
7. Параллельные агенты — только с изоляцией через worktree и раздельную среду выполнения.
8. MCP — только нужное под задачу; контекст-бюджет инструментов под контролем.
9. Инварианты «всегда/никогда» — в хуки, а не в текстовые правила.
10. Модель под фазу: сильная на план, быстрая на исполнение.
11. Многосессионный проект — Memory Bank или spec-driven подход против дрейфа.
12. Production, аудит, долгое сопровождение — переход от вайба к агентной инженерии.

Заключение

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