Загрузка 0
ПОДЕЛИТЬСЯ

Мой блог

Листай вниз

Почему стоит перестать называть всё вайб-кодингом: разница между хаосом и агентной инженерией

Почему стоит перестать называть всё вайб-кодингом: разница между хаосом и агентной инженерией

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

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

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

Реклама
Платформа Lovable и интерфейс генерации веб-приложений с ИИ
Платформы вроде Lovable позволяют собирать рабочие веб-приложения за считаные часы.

Почему термин «вайб-кодинг» потерял первоначальный смысл

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

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

Примечательно, что сам Карпатый со временем согласился с этой критикой. Годом позже он предложил более точное обозначение для дисциплинированной работы с нейросетевыми агентами — «агентная инженерия» (agentic engineering). Этот подход описывает рабочий процесс, в котором программист выступает в роли архитектора и супервизора: он направляет действия ИИ-агентов и тщательно проверяет их выходы, а не просто слепо соглашается с предложенным кодом.

Главный водораздел — личная ответственность за результат

Проверочное правило Саймона Уиллисона максимально простое: никогда не отправляйте в репозиторий тот код, логику которого вы не сможете объяснить коллеге. Это не означает необходимость вручную читать каждую из сотен строк, созданных агентом за один промт — сегодня этого не делают даже самые опытные инженеры. Речь идет о четком понимании базовой логики, алгоритмов и обоснованности выбранных нейросетью решений.

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

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

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

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

Реклама

Аналогичная проблема проявилась в проекте, собранном на платформе Lovable. Специалисты по информационной безопасности обнаружили, что нейросеть инвертировала логику авторизации. В результате зарегистрированные пользователи оказывались заблокированы, тогда как анонимные сторонние визитеры получали полный доступ к системе. Уязвимость затронула свыше 18 000 пользователей, включая студентов.

Подобные провалы происходят не только у новичков. Согласно отчёту Google DORA за 2025 год, порядка 90% разработчиков применяют искусственный интеллект в повседневной работе, но около трети из них признаются, что практически не доверяют сгенерированным результатам. Широкое распространение ИИ при низком уровне доверия делает ручную проверку критически важной — особенно когда речь идет о модулях аутентификации, правах доступа и работе с персональными данными.

Как выстроить пошаговый контроль над AI-кодом

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

По мере усложнения моих проектов структурировался и сам рабочий процесс:

  • Формирование спецификаций: Вместо написания хаотичных промтов я заранее документирую бизнес-требования, технологический стек и внешние интеграции.
  • Автоматизированное тестирование: Добавление юнит-тестов и сквозных сценариев на Playwright для главных пользовательских путей.
  • Аудит безопасности и зависимостей: Проверка библиотек, выбранных ИИ, а также внедрение сканирования загружаемых файлов на вредоносный код.

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

От безответственного вайб-кодинга к агентной инженерии

Введенный Андреем Карпатым переход от «вайб-кодинга» к «агентной инженерии» — это не просто смена терминов в лексиконе. Это точное отражение эволюции профессиональной разработки. Инженеры действительно пишут всё меньше кода вручную, но уровень их ответственности от этого не снижается.

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

Правило, которое стоит внедрить каждому разработчику

Нам пора прекратить называть «вайб-кодингом» любые формы работы с нейросетями. Этот термин обесценивает профессиональный подход и размывает грань между квалифицированным контролем и халатностью. Мое главное правило простое: никогда не выпускайте в продакшен софт, работу которого вы не в состоянии объяснить. Выстраивайте систему контроля поэтапно, добавляя проверки по мере роста сложности и рисков проекта. ИИ может написать за вас весь код, но взять на себя ответственность за релиз он никогда не сможет.

Источник: www.unite.ai

Реклама
01.