Как нам остановить vibe coding?

Алекс Клос, июль 2026 года. Ответ на вопрос из заголовка: мы не останавливаем его и не должны пытаться - чинить нужно лежащую в его основе проблему доверия. В статье он честно указывает, что один из двух инструментов, которые он в итоге рекомендует, - его собственный.

Его исходная позиция лишена скепсиса. Claude Code взлетел в конце декабря 2025 года, большинство разработчиков за считанные месяцы перенесли кодинг-агентов в свой основной рабочий процесс, а Карпати в марте 2026 года на подкасте No Priors заявил, что не написал вручную ни строчки кода с декабря. Клос верит ему отчасти потому, что сам ничего не писал. Беспокойство, о котором он пишет, разделяют те, кто уже перешёл на новый подход: закончится ли когда-нибудь поток slop'а и что вообще значило бы его остановить.

Агенты абстрагируют код

Он заимствует модель Грейди Буча о трёх золотых веках программной инженерии. Первый, с конца 1940-х до 1970-х годов, был веком алгоритма, когда языки высокого уровня и компиляторы абстрагировали машину. Второй, с 1970-х по 2000-е, стал эпохой объектно-ориентированной абстракции. Третий, начавшийся около 2000 года, - это век систем: библиотеки, платформы и API абстрагируют целые подсистемы. Буч аккуратно отмечает, что ИИ не начал эту эпоху, а лишь ускорил её, но сравнивает кодинг-агентов с появлением компиляторов во времена Грейс Хоппер, и именно это сравнение берёт на вооружение Клос.

Компиляторы абстрагировали машину. Агенты абстрагируют код. Впервые код можно генерировать напрямую из намерения (intent) - именно отсутствие такой возможности погубило model-driven development, и Клос предполагает, что пришло время вернуться к MDD в том или ином виде. Плата за переход на уровень намерений - потеря инструментария, который делал надёжной работу на уровне кода.

Проблема в доверии, сформулированная дважды

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

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

Кроме того, вы почти не видите, что именно изменится. Агент пишет небольшое сочинение с описанием своего плана, но в этом тексте нет зоны поражения (blast radius), не сказано, что будет реализована лишь часть задачи, и не отмечена критически важная деталь, которую агент решил опустить, сочтя очевидной. Даже когда нужная информация формально присутствует, у планов нет устойчивой структуры, так что вовремя заметить проблему не получается.

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

Отсюда он выводит три требования к любому рабочему решению. Агент должен надёжно выполнять то, что требуется, в идеале детерминированно - это вряд ли достижимо в абсолюте, но остаётся правильной целью. Должна быть возможность аудита и отслеживания изменений в кодовой базе, в идеале без чтения самого кода. И уровень трения должен оставаться минимальным: vibe coding побеждает как путь наименьшего сопротивления, поэтому дисциплинированный подход обязан стать простым, а не просто добродетельным.

Почему текущее поколение инструментов терпит неудачу

Спецификации в Markdown - самый частый ответ, который он слышит; он воспроизводит рекламную подачу этого подхода единым предложением на одном дыхании про пайплайны, которые проверяют, внедряют, сверяют и обновляют. Он задаёт вопросы, на которых эта подача всегда сыплется: есть ли структурированный формат у таких спецификаций, как узнать, какие части реально реализованы, как убедиться, что код не делает ничего сверх описанного, и почему бы просто не давать агенту прямые промпты. В качестве лучшего примера он указывает на статью Эдди Османи (Addy Osmani) в O'Reilly Radar за февраль 2026 года - пять принципов, шестисекционный формат, исследование 2500 конфигурационных файлов, упоминание всех существующих инструментов, - и отмечает: проблема не в размытости, а в перегруженности, за которой скрывается всё тот же prompt engineering в агентском контексте. Спецификация служит направляющим промптом, а не источником истины. Механизмов принудительного исполнения и сверки нет, кроме как спросить самого агента, соответствует ли код спецификации, на что тот может ответить что угодно из-за отсутствия общего синтаксиса.

Skills - это условно подмешиваемый контекст, и они проваливаются ровно так же: всё по-прежнему зависит от желания агента им следовать. В качестве примера он берёт раздутый QA skill из gstack и предполагает, что промпт "find and fix bugs plz" сработает примерно с тем же успехом.

Spec Kit и OpenSpec представляют собой попытки выстроить процесс. Spec Kit раскидывает по проекту шаблоны в Markdown и заставляет последовательно выполнять шесть команд: specify, clarify, plan, tasks, analyze, implement, сохраняя их результаты как контекст для последующих промптов. Клос называет это неплохим началом, поскольку здесь задаётся хоть какая-то структура, однако она слишком рыхлая, процессом целиком управляет разработчик, одна команда превратилась в шесть, а видимости по-прежнему нет. OpenSpec - более лёгкий вариант: explore, propose, apply, archive со сценариями WHEN/THEN в обычном Markdown вместо EARS. Та же ставка, тот же провал. Вы ведёте процесс, агент сам проверяет свою домашнюю работу, и никакой механизм не сопоставляет спецификацию с кодом.

К Kiro он относится с наибольшим сочувствием. Инструмент направляет агентов к Markdown-спецификациям с требованиями в формате EARS с помощью hook'ов, и Клос считает обе эти идеи действительно удачными. EARS (Easy Approach to Requirements Syntax) превращает фразу "пользователей нужно разлогинивать через некоторое время при неактивности" в "WHEN a user session has been inactive for 15 minutes, the system SHALL terminate the session and redirect the user to the login page", что помогает и агенту, и человеку, поскольку неструктурированный текст нельзя сканировать взглядом так же быстро, как код. Hook'и заставляют агента реагировать на триггеры и следовать шагам, задавая структуру даже без детерминизма. Но Kiro всё равно спотыкается в двух местах: спецификации возможностей накапливаются, а не композируются, из-за чего нет проверяемого графа, и никто не сверяет требования с готовым кодом. Его вердикт: Kiro строит зал суда, но никогда не проводит сам судебный процесс.

Test-driven development - единственный пункт в списке с настоящим детерминированным контролем. Название теста формулирует намерение на естественном языке, сам тест привязывает это намерение к реальному коду, а тесты более высокого уровня могут выступать в роли функциональных графов зависимостей. Загвоздка в том, кто их пишет. Разработчики поручают написание тестов агенту, потому что так проще, что возвращает ровно ту же проблему. Писать их вручную - значит знать детали реализации и писать код, а это откат с уровня намерений, к которому стремится вся затея. Он отмечает, что CodeSpeak столкнулся с этим напрямую: их исходный тезис заключался в том, что разработчики будут писать файлы спецификаций вручную, однако большинство альфа-тестеров переложили это на своих агентов, и компании пришлось развернуться в сторону автоматического извлечения структурированных намерений из промптов на естественном языке.

Заодно он приводит один факт с рынка. Стартап Tessl привлёк $125M на обещаниях spec-driven development и по-тихому сместился от продажи SDD разработчикам в сторону слогана "skills are the new code".

Два инструмента, выбравших правильное направление

CodeSpeak, основанный Андреем Бреславом (создателем Kotlin), делает ставку на то, что потребность в доверии можно устранить компиляцией. Вы пишете лаконичные Markdown-спецификации, организованные в модули с импортами, а codespeak build компилирует их в Python, Golang или TypeScript, код на которых вам на самом деле не предполагается ревьюить. Метафора компилятора воспринимается всерьёз: перед сборкой спецификации проверяются на согласованность, после неё запускаются тесты, а codespeak takeover генерирует спецификации на основе существующей кодовой базы. После смены курса они добавили слой требований, где диалоги с агентом дистиллируются в структурированные требования, привязанные к реализующим их файлам, с фиксацией расхождений, когда изменения расходятся; команда всё ещё работает над формализацией языка спецификаций в сторону детерминированных или почти детерминированных сборок.

Scryer, собственный проект Клоса за последние полгода, делает противоположную ставку: доверие к агенту несводимо, поэтому расходовать его нужно с минимальными затратами. Это model-driven development для кодинг-агентов. Вы и агент разделяете общую модель системы - иерархию в стиле C4, где каждый узел описывает свою зону ответственности в виде коротких, независимых от языка утверждений, привязанных к строкам исходного кода и подтверждающим тестам. Агент читает и модифицирует модель через MCP; вы просматриваете её в виде wiki-страниц и диаграмм вместо чтения кода. Модель ведёт, а код следует за ней, поэтому планирование изменений порождает git-подобный diff по всей модели, показывая ту самую зону поражения, которую никогда не давало текстовое описание плана от агента. Под капотом работает детерминированный слой наблюдаемости, отслеживающий соотношение реализованного и запланированного, закреплённость утверждений тестами и расхождения кода с моделью с момента последней сверки.

Какое место эта позиция занимает среди остальных

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

Это отводит ему вполне определённое место в кластере страниц vault'а о vibe coding. cult-of-vibe-coding (Брэм Коэн) видит проблему в отказе от чтения кода и настаивает на нём: аудит, обсуждение, затем выполнение. control-the-ideas-not-the-code (antirez) утверждает, что чтение кода - в основном пустая трата сил, и предлагает сосредоточиться на контроле архитектурного замысла. Клос согласен с antirez в том, что чтение отдельных строк - неправильный уровень абстракции, но не согласен с тем, что достаточно держать дизайн в голове, ведь суть как раз в том, что собственной ментальной модели больше нельзя доверять. Его ответ - вынести архитектурный замысел во внешний артефакт, который можно механически проверять относительно кода, чего не требует ни одна из двух позиций. simonw-vibe-coding-agentic - честный отчёт из середины спектра, где граница между vibe coding и agentic engineering на практике уже стёрлась.

Аргумент о детерминизме связывает ещё две страницы. testing-heavy-no-review-workflow представляет позицию, к которой Клос отчасти приходит другим путём: доверять рандомизированному тестированию вместо ревью по модели верификации процессоров. short-leash-ai-method - противоположная крайность, чтение каждого diff'а на этапе подтверждения прав, то есть вариант с максимальным трением, который исключается третьим требованием Клоса. reviewing-ai-code даёт данные по пропускной способности, объясняющие, почему подход с тотальным ревью нежизнеспособен.

Ближе всего к общему тезису подходит slicer-agents-guess-code, где та же проблема зоны поражения решается со стороны кода, а не спецификаций: строится граф с оценкой достоверности того, чего реально касаются изменения, с разметкой участков, которые анализатор не может доказать. Diff модели в Scryer и срез влияния в CodeSlicer - два ответа на один и тот же вопрос, и ни один из них не требует от человека читать больше кода.