Нужно перестать называть всё «vibe coding»

Я вернулся к программированию после долгого перерыва, и Lovable стал тем местом, где я снова взялся за дело. Приложения выглядели отлично, на первый взгляд работали и собирались за несколько часов. Сначала это казалось замечательным. Но этого стало недостаточно в тот момент, когда я захотел понять, что делает код — и почему. Именно тогда мой подход начал меняться.

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

Vibe coding в оригинальном смысле означает принятие программного обеспечения, сгенерированного ИИ, без надлежащего изучения или понимания того, что находится под ним. AI‑ассистированная разработка отличается. Модель всё ещё может писать большую часть кода, но человек, создающий систему, остаётся ответственным за понимание её поведения, проверку предположений и решение, готово ли оно к выпуску.

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

Как «vibe coding» потеряло смысл

Термин «vibe coding» был введён в феврале 2025 года Андреем Карпати, соучредителем OpenAI. Его пример был преднамеренно неформальным: «одноразовый уикенд‑проект», созданный автоматическим нажатием «Accept All», игнорируя различия и позволяя коду расти за пределами его понимания.

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

Примечательно, что Карпати в конечном итоге согласился. Через год он ввёл другой термин для более дисциплинированной работы с кодирующими агентами. Он описал «agentic engineering» как рабочий процесс, в котором разработчики управляют и контролируют агентов, а не просто принимают их результаты. Это различие имеет значение: профессиональная AI‑ассистированная разработка требует планирования, тщательной проверки и ответственности, чего не требует случайный vibe coding.

Грань — ответственность

Правило Уиллиссона простое, и оно служит тестом для любого: не фиксировать код, который вы не сможете объяснить другому человеку. Это не значит читать каждую строку: когда агенты генерируют сотни строк одновременно, даже опытные разработчики уже так не делают. Это значит понимать основную логику и уметь обосновать, почему код делает именно то, что делает. Если вы можете, не важно, написал его модель или вы: это не vibe coding, а использование инструмента для создания программного обеспечения.

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

Таким образом, лишь опыт этого не объясняет. Важно то, готовы ли вы брать на себя ответственность за то, что сгенерировал ИИ. Это решение каждый разработчик принимает заново для каждого проекта.

Что происходит, когда контроль отсутствует

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

Тот же базовый проблемный момент — программное обеспечение, которое, казалось, работает, хотя логика авторизации была опасно ошибочной — проявился в приложении, построенном на платформе Lovable: исследование безопасности обнаружило инвертированную логику авторизации, изолировавшую авторизованных пользователей и позволяющую неаутентифицированным атакующим свободно входить, затронув более 18 000 пользователей, включая студентов.

Это не отдельные случаи, происходящие только в «плохих» проектах. По данным отчёта Google DORA 2025, 90 % разработчиков сейчас используют ИИ в работе, при этом примерно треть из них выражают мало или вовсе не доверяют тому, что он генерирует.

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

Контроль строится слоями, а не сразу

В моём случае я не начинал с формального аудита безопасности. Я просто отказывался продолжать, когда не мог объяснить, почему что‑то ведёт себя так, как оно ведёт — естественный инстинкт, который мы привносим в работу аналитика.

Мой рабочий процесс стал более структурированным по мере того, как проекты становились серьёзнее. Вместо того чтобы полагаться только на подсказки, я начал готовить спецификации перед генерацией чего‑либо. Я документировал бизнес‑требования, технологический стек и интеграции. Затем появились модульные тесты и тесты Playwright для основных пользовательских сценариев.

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

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

По сравнению с случаями Tea и Lovable, это была обычная проблема. Я обнаружил её рано, исправил и продолжил работу. Так обычно выглядит проверка на практике. В большинстве случаев она предотвращает рост небольших проблем в крупные.

Я не сомневаюсь в коде лишь потому, что его создал ИИ. Я также не доверяю ему только потому, что приложение работает. Тесты и проверка позволяют мне убедиться, что он ведёт себя так, как задумано.

От vibe coding к agentic engineering

Отказ Андрея Карпати от «vibe coding» в пользу «agentic engineering» — это не просто смена терминологии. «Agentic engineering» предоставляет более полезное название для направления, в котором движется профессиональная разработка. Разработчики могут писать меньше строк самостоятельно, но это не уменьшает их ответственности. Это смещает их работу к формулированию того, что система должна делать, управлению агентами, тестированию их результатов и решению, что безопасно выпускать.

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

Правило, которое стоит сохранять

Перестаньте использовать «vibe coding» как ярлык для любой формы AI‑ассистированной разработки — это размывает термин и стирает важное различие в контроле. Установите простое правило: не выпускайте то, что вы не можете объяснить. И внедряйте контроль в проект по мере его роста, слой за слоем, добавляя проверки в соответствии с возникающими рисками.

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