Это третья часть моей мини‑саги про вайбкодинг, LLM и здравый смысл в разработке. В первой статье я уже рассказывал, как по совету ИИ едва не снёс себе БД, а во второй — разбирался, страшен ли этот самый вайбкодинг или это просто инерция мышления перед лицом прогресса.
Сегодня я хочу поговорить о «священном граале» текущего AI-хайпа — полной автономности кодинг-агентов. О том, почему вера в то, что нейросеть «сама всё напишет, пока я пью кофе», — это опасное заблуждение, которое лишь усиливает скепсис профильного сообщества.
Как нам продают автономность
Если открыть YouTube или ленту новостей, посыл везде один: «ИИ стал настолько крутым, что можно просто поставить ему задачу, и он напишет полностью рабочее приложение».
В топах расширений для IDE и CLI-инструментов киллер-фичей объявляется именно Agentic Workflow (агентская автономность), а условный Claude Code описывается как «мощный, но душный, потому что на все просит разрешения».
Да и будем честны, сами провайдеры LLM активно соревнуются в метриках: сколько минут агент может работать без вмешательства человека.
Но что на самом деле скрывается за этими цифрами?
LLM — не инженер, а статистический попугай
Давайте называть вещи своими именами. Современные LLM, несмотря на маркетинговый ярлык «ИИ», интеллектом в человеческом понимании не обладают. Они не «думают» об архитектуре, не оценивают риски миграции данных и не понимают бизнес-логику так, как это делает инженер.
LLM — это предсказатели следующего токена, обученные минимизировать ошибку на огромном корпусе текстов и кода. Они продолжают строку так, как это статистически наиболее вероятно выглядело бы в обучающей выборке.
К чему это приводит на практике?
Типовая задача: Если паттерн многократно встречался в датасете (CRUD на Python, базовый React-компонент), LLM выдаст уверенный, качественный, возможно, идеальный код.
Нестандартная задача: Если контекст уникален, LLM начинает «галлюциниро��ать». Она изобретает решение, которое выглядит правдоподобно (синтаксически верно), но логически может быть полной чушью.
В режиме автономности это превращается в русскую рулетку. Чем сложнее задача, тем выше шанс, что агент выберет «статистически близкий», но неверный путь.
Автономный агент в режиме «сломай, но с уверенностью»
Что же произойдет на практике, при использовании так активно продвигаемого полностью автономного агента?
Агент получает задачу: «Пофикси баг с падением сервиса».
Он анализирует логи, находит (или придумывает) причину.
Пишет фикс, запускает тесты.
Тесты падают в другом месте.
Агент бросается чинить новые ошибки, меняя соседние модули.
Итог:
В простых проектах агент, скорее всего, справится. Это, обычно, и показывают в демо-роликах.
Но в реальном проекте со сложным легаси агент, запущенный бесконтрольно, превращается в обезьяну с гранатой. Он может удалить «лишние» проверки, переписать сложный SQL-запрос на «упрощенную версию» (которая не учитывает граничные случаи) или зациклиться на исправлении собственных багов.
Именно поэтому «душный» Claude Code, требующий подтверждения каждого шага, — это фича. Он оставляет человека в петле управления (Human-in-the-Loop), позволяя заметить момент, когда модель свернула не туда.
Примеры
Прошлую мою публикацию ругали за графоманство и отсутствие технических деталей, поэтому давайте добавим примеры из моего опыта работы с LLM.
Пример №1
Дано: Python-скрипт 2-месячной давности, ~100 строк кода.
Инструмент: VSCode + GLM-4.6 (SOTA-модель).
Ситуация: IDE подсвечивает синтаксическую ошибку в блоке с двумя условиями. Модель верно диагностирует: «проблема с отступами».
Попытка 1: Удаляет строки, пишет то же самое. Скрипт падает.
Попытка 2: Повторяет действие. Скрипт падает.
Попытка 3: Решает переписать весь блок целиком, чтобы «избежать коллизий». По итогу — логика та же, ошибка та же.
Финал: Модель предлагает удалить этот кусок кода и написать «новую упрощенную версию скрипта».
Автономный агент в такой ситуации просто снес бы рабочий инструмент и заменил его на «Hello World», который зато компилируется без ошибок.
Пример №2
Инструмент: Claude Code + GLM-4.6.
Ситуация: Агент составил план из 6 пунктов. На подготовку плана и анализ ушло 60% контекстного окна. Я включаю режим авто-подтверждения.
На 5-м пункте возникает сложная ошибка. Агент долго дебажит, генерирует много текста/кода. Контекстное окно переполняется, включается auto-compact до того, как модель успевает отметить 5 пункт выполнены.
В процессе сжатия модель «забывает», что она уже починила пробелмы в пункте 5, еще и видит, что пункт 5 не был отмечен как выполненный. Она видит в саммари после сжатия: «были проблемы, мы их решали».
Итог: Агент идет править код, который он же сам минуту назад успешно исправил и протестировал. Он ломает рабочее, тесты снова проваливаются, цикл замыкается.
Где же кончилась магия?
Магия может кончиться по многим причинам:
Предел контекста. Даже 200к токенов забиваются логами и диффами моментально.
Эффект «Снежного кома». Одна маленькая галлюцинация в начале тянет за собой цепочку неверных решений.
Слабый Tool Calling. Модель может неправильно распарсить вывод линтера или не так понять ошибку компилятора.
Отсутствие «взгляда сверху». Модель видит файлы, но не «понимает» архитектуру проекта целиком.
Есть огромное множество причин, по которым даже топовая SOTA модель вдруг может оступиться на даже элементарной задаче.
И тут я хочу донести самую важную на мой взгляд мысль обо всем этом:
LLM для написания кода, это как джун, имеющий доступ к миллионам репозиториев для анализа и копирования кода. Она действительно может писать вменяемый и порой даже качественный код. Но все это до тех пор, пока это не выходит за рамки обыденности и пока это происходит под строгим контролем «сверху».
Не стоит давать даже самым дорогим и продвинутым LLM полный доступ. Они могут написать 10 000 строк идеального кода, но на 10 001 все запороть и в «панике» просто все удалить в попытках исправить ошибку.
Так игрушка ли это, или все же инструмент?
В комментариях к моей второй публикации было озвучена следующая мысль:
Это никакой не инструмент. Вы же не стали бы называть инструментом линейку, на которой риски нанесены в непредсказуемом порядке, на разных расстояниях и могут менять свое расположение при каждом измерении? Так что хватит называть эту штуку инструментом, это пока еще игрушка.
Вайбкодинг не лекарство от лени, невежества и безалаберности а их стимулятор. Увы.
И по большей части с этим сложно несогласиться. Но я бы применил здесь принцип, схожий с «эффектом наблюдателя» из квантовой физики:
Если не следить за тем, что делает LLM, она рано или поздно начнет творить «дичь». Это игрушка, в которую ты закинул промпт «сделай за меня программу, которая...» и сидишь наблюдаешь за результатом. Само собой такой подход не способствует какому-либо развитию.
Если поставить над LLM опытного «наблюдателя» и вовремя останавливать ее там, где она начинает галлюцинировать, то это становится инструментом, которому можно доверить решение части своих задач. Но лишь до тех пор, пока именно ты управляешь процессом.
Автономный кодинг, который нам продают как «новый стандарт», — это пока чистый маркетинг. А вот контролируемый вайбкодинг (или AI-Assisted Development) — это мощнейший инструмент. Эта схема начинает работать тогда, когда мы вводим в систему «вторую линейку» (человека), чтобы сверять показания первой.