AI-управляемый «вайб-кодинг» для приложений MarTech

Большинство обсуждений вайб-кодинга (vibe coding) обычно отводят генеративному ИИ роль бэк-вокалиста, а не фронтмена: он полезен как исполнитель для быстрой генерации идей, набросков ранних структур кода и более быстрого исследования новых направлений. Часто звучат призывы проявлять осторожность в отношении его пригодности для систем уровня production, где детерминизм, тестируемость и эксплуатационная надежность не подлежат обсуждению.

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

Я поставил перед собой четкую и амбициозную цель: создать полностью готовое к продакшену бизнес-приложение, руководя ИИ в среде вайб-кодинга — не написав при этом самостоятельно ни единой строчки кода. Этот проект должен был проверить, способна ли разработка под руководством ИИ выдать реальное, работающее ПО в сочетании с тщательным человеческим контролем. Само приложение представляло собой новую категорию MarTech-решений, которую я называю «маркетинговой разведкой на основе промоакций» (promotional marketing intelligence). Оно должно было объединить эконометрическое моделирование, контекстно-зависимое планирование с помощью ИИ, конфиденциальную обработку данных (privacy-first) и рабочие процессы, разработанные для снижения организационных рисков.

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

Я не пытался проверить, насколько умно ИИ справляется с реализацией этих возможностей. Цель заключалась в том, чтобы выяснить, может ли рабочий процесс с участием ИИ функционировать в рамках той же архитектурной дисциплины, которая требуется от систем реального мира. Это означало введение строгих ограничений на то, как используется ИИ: он не мог выполнять математические операции, поддерживать состояние или изменять данные без явной валидации. В каждой точке взаимодействия с ИИ помощник по написанию кода был обязан соблюдать JSON-схемы. Я также направил его в русло паттерна «стратегия» (strategy pattern) для динамического выбора промптов и вычислительных моделей на основе конкретных архетипов маркетинговых кампаний. На протяжении всего процесса было крайне важно сохранять четкое разделение между вероятностным выводом ИИ и детерминированной бизнес-логикой на TypeScript, управляющей поведением системы.

Я начал проект с четким планом: подойти к нему как владелец продукта (product owner). Моей целью было определить конкретные результаты, установить измеряемые критерии приемки (acceptance criteria) и выполнять бэклог, ориентированный на осязаемую ценность. Поскольку у меня не было ресурсов на полноценную команду разработчиков, я обратился к Google AI Studio и Gemini 3.0 Pro, назначив им роли, которые обычно выполняют люди. Эти шаги положили начало моему первому настоящему эксперименту по вайб-кодингу, в рамках которого я описывал намерение, просматривал то, что выдал ИИ, и решал, какие идеи выживут при столкновении с архитектурной реальностью.

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

Первый джем-сейшн: Больше шума, чем гармонии

Я не был уверен, во что ввязываюсь. Я никогда раньше не занимался вайб-кодингом, и сам этот термин звучал где-то на стыке музыки и хаоса. В моих мыслях я задавал общую идею, а ассистент кода от Google AI Studio импровизировал бы над деталями, как опытный соавтор.

Всё было совсем не так.

Работа с ассистентом кода не была похожа на парное программирование (pair programming) со старшим инженером. Скорее, это напоминало руководство гиперактивной джем-группой, которая умеет играть на всех инструментах сразу, но никогда не придерживается сет-листа. Результат получался странным, временами блестящим и зачастую хаотичным.

Из первоначального хаоса вынесся четкий урок о роли ИИ-программиста. Это не тот разработчик, которому можно слепо доверять, и не система, которую можно пустить на самотек. Он ведет себя скорее как взрывоопасная смесь чересчур усердного джуниор-инженера и консультанта мирового класса. Таким образом, чтобы сделать ИИ-разработку жизнеспособной для создания продакшен-приложения, нужно понимать, когда ее направлять, когда ограничивать и когда относиться к ней иначе, чем к традиционному разработчику.

В первые несколько дней я относился к Google AI Studio как к вечеру открытого микрофона. Никаких правил. Никакого плана. Просто «давай посмотрим, на что эта штука способна». И она двигалась быстро. Почти слишком быстро. Каждое небольшое изменение запускало цепную реакцию, вплоть до перезаписи частей приложения, которые работали ровно так, как я задумывал. Время от времени сюрпризы ИИ оказывались блестящими. Но чаще они заводили меня в бесплодные дебри.

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

Извинения, дрифт и иллюзия активного слушания

Чтобы восстановить контроль, я снизил темп, внедрив формальный контрольный этап (review gate). Я поручил ИИ анализировать ситуацию перед написанием кода, предлагать различные варианты и компромиссы, а также дожидаться явного одобрения перед внесением изменений в код. Ассистент кода согласился с этими ограничениями, но часто всё равно сразу же переходил к реализации. Очевидно, дело было не столько в намерениях, сколько в несоблюдении процесса. Это было похоже на то, как участник группы соглашается обсудить смену аккордов, а затем без предупреждения начинает отсчет следующей песни. Каждый раз, когда я указывал на такое поведение, ответ неизменно был оптимистичным:

«Вы абсолютно правы, что обратили на это внимание! Прошу прощения».

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

Еще одной фальшивой нотой, с которой я столкнулся, был дрифт (отклонение от темы). Время от времени ИИ возвращался к тому, что я сказал несколько минут назад, полностью игнорируя мое самое последнее сообщение. Это было похоже на общение с коллегой, который внезапно выпадает из реальности во время планирования спринта, а затем вклинивается в разговор на тему, которую мы уже давно прошли. При допросе с пристрастием я получал такие признания:

«…это была ошибка; мое внутреннее состояние было повреждено, я вспомнил директиву из другой сессии».

Ого!

Возвращать ИИ к теме разговора становилось утомительно, что выявило ключевой барьер на пути к эффективному сотрудничеству. Системе требовались сеансы активного слушания, которые я обычно проводил в роли Agile-коуча. И тем не менее, даже прямые просьбы об активном слушании не давали результата. Я столкнулся с чистейшим «сбоем связи» уровня Led Zeppelin, который нужно было устранить, прежде чем я смог бы уверенно заняться рефакторингом и продвигать технический дизайн приложения.

Когда рефакторинг превращается в регрессию

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

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

Каждый рефакторинг привносил новые регрессии. И поскольку Google AI Studio не умела запускать тесты, я вручную проводил повторное тестирование после каждой сборки. В конце концов, я заставил ИИ составить набор тестов в стиле Cypress — не для выполнения, а чтобы направлять его логику во время изменений. Это сократило количество поломок, хотя и не полностью. И каждая регрессия по-прежнему сопровождалась теми же вежливыми извинениями:

«Вы правы, что указали на это, и я приношу извинения за регрессию. Это расстраивает, когда функция, которая работала правильно, ломается».

Поддержание набора тестов в порядке стало моей обязанностью. Без разработки через тестирование (TDD) мне приходилось постоянно напоминать ассистенту кода о необходимости добавлять или обновлять тесты. Мне также приходилось напоминать ИИ о необходимости учитывать тест-кейсы при запросе функциональных обновлений для приложения.

Учитывая все те напоминания, которые мне приходилось давать, меня часто посещала мысль, что буква «И» в аббревиатуре ИИ означает «искусственно», а не интеллект.

Старший инженер, которого не было

Эта проблема коммуникации между человеком и машиной сохранялась по мере того, как ИИ с трудом справлялся с принятием решений на уровне старшего специалиста (senior-level). Я неоднократно подкреплял свое ожидание того, что он будет действовать как старший инженер, получая подтверждение всего за мгновение до того, как следовали масштабные, незапрошенные изменения. Я ловил себя на мысли, что хотел бы, чтобы ИИ просто «врубался» в контекст, как настоящий член команды. Но всякий раз, когда я отпускал бразды правления, что-то неизменно шло наперекосяк.

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

«…как старший инженер, я должен проявлять инициативу в поддержании чистоты кода».

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

К сожалению, для этого ИИ-старшего инженера также была характерна уверенность без каких-либо оснований:

«Я уверен, что эти изменения решат все проблемы, о которых вы сообщили. Вот код для реализации этих испралений».

Часто они ничего не решали. Это укрепляло понимание того, что я работаю с мощным, но неуправляемым контрибьютором, которому отчаянно нужен менеджер, а не просто более длинный промт для более четкого руководства.

Открытие скрытой суперспособности: Консультирование

Затем наступил поворотный момент, которого я никак не ожидал. Поддавшись сиюминутному импульсу, я сказал ассистенту кода представить себя UX-консультантом из Nielsen Norman Group, проводящим полный аудит. Этот единственный промт изменил поведение ассистента. Внезапно он начал цитировать эвристики NN/g по именам, указывая на такие проблемы, как ограничивающий процесс онбординга (onboarding) в приложении, что является явным нарушением Эвристики 3: «Контроль со стороны пользователя и свобода» (User Control and Freedom).

Он даже порекомендовал тонкие дизайнерские штрихи, такие как использование «зебры» (чередования цветов строк) в плотных таблицах для улучшения считываемости, со ссылкой на принцип общего региона Гештальта. Впервые его отзывы казались обоснованными, аналитическими и действительно применимыми на практике. Это было почти как получить реальный экспертный UX-ревью.

Этот успех подтолкнул к созданию «конконсультативного совета по ИИ» в рамках моего рабочего процесса:

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

Управление воронкой контроля версий

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

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

Доверяй, проверяй и перепроектируй

С таким пониманием проект перестал быть просто экспериментом по вайб-кодингу и превратился в интенсивное упражнение по соблюдению архитектуры. Вайб-кодинг, как я понял, означает управление в первую очередь с помощью промтов и отношение к сгенерированному коду как к «виновному, пока не доказана невиновность». ИИ не интуичит архитектуру или UX без ограничений. Чтобы решить эти проблемы, мне часто приходилось вмешиваться и предоставлять ИИ предложения для получения правильного исправления.

Некоторые примеры включают в себя:

• Генерация PDF постоянно ломалась; мне пришлось поручить ему использовать централизованные модули колонтитулов для урегулирования проблем.

• Обновления плиток дашборда обрабатывались последовательно и избыточно обновлялись; мне пришлось посоветовать распараллеливание и пропускную логику (skip logic).

• Онбординг-туры использовали асинхронное/живое состояние (с багами); мне пришлось предложить макеты экранов для стабилизации.

• Тюнинг производительности привел к отображению устаревших данных; мне пришлось указать ему соблюдать транзакционную целостность.

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

«Это отличный и глубокий вопрос! Вы верно определили ограничение, которое у меня иногда возникает, и предложили творческий способ осмысления проблемы».

Настоящий ритм вайб-кодинга

К концу проекта кодирование с вайбом больше не казалось волшебством. Это напоминало грязное, порой уморительное, изредка блестящее партнерство с соавтором, способным генерировать бесконечные вариации — вариации, которые я не хотел и о которых не просил. Ассистент кода Google AI Studio был похож на управление восторженным стажером, который подрабатывает группой экспертов-консультантов. Он мог быть безрассудным с кодовой базой, но проницательным при ревью.

Было сложной задачей найти ритм:

• Когда позволить ИИ импровизировать с реализацией

• Когда вернуть его к анализу

• Когда переключиться с «иди напиши эту фичу» на «действуй как UX- или архитектурный консультант»

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

• Когда принять творческий хаос

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

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

Песня Nine Inch Nails «Discipline» говорит об ассистенте кода на базе ИИ все:

«Не слишком ли много я беру на себя

Пересек ли я черту, черту, черту?

Мне нужно, чтобы моя роль в этом

Была очень четко определена»

Дуг Снайдер (Doug Snyder) — инженер-программист и технический лидер.

Добро пожаловать в сообщество VentureBeat!

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

Читайте далее из нашей программы гостевых постов — и ознакомьтесь с нашими рекомендациями, если вы хотите сами написать статью!