ИИ написал код — что дальше? Почему вайбкодинг не отменяет мышление маркетолога

В дальнейшем в работе регулярно возникали ситуации, когда хотелось что-то улучшить: автоматизировать рутину, сделать удобнее существующий процесс, ускорить решение задачи. Глубокой разработкой я не занимаюсь: знаю CSS и HTML на базовом уровне, понимаю общие конструкции Python, но писать сложные скрипты или полноценные сервисы с нуля — не моя компетенция. И времени на полноценное погружение в разработку при основном SEO-фокусе тоже, к сожалению, нет.

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

Когда появились инструменты, которые позволяют погружаться в код через нейросети, стало интересно. Появилось ощущение, что теперь можно собирать что-то самому: описывать задачу словами и получать рабочий результат. Звучит волшебно!

Но обычно я скептически отношусь к новинкам и не ожидаю, что всё будет работать само.

Почему опасно думать, что вайбкодинг — это просто

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

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

Вайбкодинг и правда позволяет самостоятельно быстро сделать простой сервис или решение для автоматизации рутины, но всё не так просто.

Ложное чувство простоты

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

На этапе точечных доработок нейросеть начинает буксовать. Она может:

• забывать контекст и уже внесённые изменения;
• править логику только в одном месте, игнорируя остальные;
• наоборот, менять код сразу в нескольких местах, где этого не требовалось.

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

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

Особенности вайбкодинга

Иногда вокруг вайбкодинга возникает поляризация: либо «это наше всё», либо «это бесполезная игрушка». Оба подхода некорректны. Нейросеть не знает контекста проекта и актуальных внешних факторов.

Нейросеть не думает за маркетолога. Но может ему помочь

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

Нейросеть действительно может быть полезна на этапе идей. За счёт большой базы примеров она умеет предлагать разные варианты реализации, подкидывать гипотезы, показывать возможные сценарии. В этом смысле «среднее по больнице», которое часто считают минусом, здесь работает в плюс: можно быстро получить набор направлений для размышлений.

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

В маркетинге это особенно критично. Один и тот же приём может работать в одной нише и полностью проваливаться в другой.

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

Кейс: определили категории и марки авто с наибольшим спросом

Для определения приоритетов проработки разделов сайта нам было важно понять, что ищут больше всего. Начали с кластеризации запросов через SEO-сервисы, но спрос очень разнородный: тут и просто «киа», и «купить рио», и «купить спортейдж» и прочее – спрос и по бренду авто, и по конкретным моделям. А нам нужно было 1) понять, к какой категории относится каждый из запросов (легковые, грузовые авто; спецтехника) 2) какой спрос по каждому бренду суммарно (учитывать запросы, которые содержат название модели, принадлежащей бренду, но без её прямого упоминания, например, запросы с «рио» должны относиться к группе «Киа»).

Написали подробный промпт с логикой, как присваивать категории для запросов и обкатали на Gemini.

В результате получили ровно то, что и хотели – у каждого запроса была присвоена категория.

Позже – сделали скрипт на Python с подключением к DeepSeek API, который анализировал в рамках того же подхода, но уже из табличного файла с бОльшим количеством запросов.

Так стало понятнее, какие типы и марки авто более популярны, что сейчас мы уже проработали на сайте, а на что стоит обратить внимание. И всё это автоматически, в понятном, структурированном виде.

Нейросеть работает в рамках задачи и качества входного описания

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

Поэтому на формулировку задачи иногда уходит больше времени, чем на саму генерацию кода, и это нормально.

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

Если вы создаёте что-то актуальное, особенно связанное с внешними источниками, помните, что вам же придётся и поддерживать работу продукта.

Кейс: Сделали сервис для анализа AI-ответов на поиске Яндекс и Google

На заре аналитики генеративных ответов, первыми возможность для сбора данных предоставили сервисы парсинга. Зарубежные, например, SerpWow, Scraper API, немного позже – отечественные: A-Parser, XMLRiver. Для многих наших клиентов первоочередной целью было посмотреть типы ответов и упоминаемость именно в AI-ответах на поиске: Поиск с Алисой и Google AI Overviews. Проблема в том, что парсеры отдавали результат не в user-friendly формате: просто выгрузка в ответ на запрос. А нам хотелось сделать что-то более удобное, где можно видеть результаты в динамике по датам.

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

Самое время вспомнить про лёгкость создания 80% кода и сложность с оставшимися 20% – сделать MVP было относительно просто, а вот скорректировать какие-то мелочи без ущерба или достроить сложную логику – крайне болезненно. К тому же, важно понимать, насколько легко будет поддерживать продукты, созданные через вайбкодинг. У меня нет полноценных компетенций в разработке – при любой корректировке, которая требует более глубокой проработки или ломает что-то сбоку, уходит очень много времени, чтобы исправить.

Нейросеть не понимает человека, а собирает средние данные

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

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

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

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

Нейросеть может выходить за рамки ТЗ

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

Это напрямую связано с поддержкой проектов, собранных через вайбкодинг. На этапе доработок нейросеть может:

• изменить код там, где её об этом не просили;
• не изменить его там, где логика должна быть одинаковой;
• сломать часть функционала, которая не проверяется сразу.

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

Доверять нейросетям вообще сложно. Трагедия в двух актах:

Что делать, чтобы вайбкодить было проще

Первая рекомендация — регулярно делайте бэкапы.

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

Вторая важная вещь — базовое понимание того, как работает код.

Желательно – на уровне разработчика, базово – на уровне логики. Нужно хотя бы примерно представлять, где что подключается, почему элемент может не отображаться, откуда берётся ошибка.

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

Третья рекомендация — фиксировать промты.

Особенно если проект развивается итеративно. Я для этого веду отдельный документ, где сохраняю ключевые формулировки задач. Это помогает сразу в нескольких ситуациях:

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

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

Особенно важна конкретика в промптах. Чем подробнее и точнее описана задача, тем выше шанс получить ожидаемый результат. Здесь хорошо работает простой принцип: если что-то кажется очевидным — это всё равно нужно проговорить. У человека и у нейросети «очевидное» может выглядеть совершенно по-разному. Если не задать рамки, получится формально правильное, но неподходящее решение.

Четвёртая рекомендация – пробуйте и не бойтесь! Но повышайте свой уровень компетенций или привлекайте специалиста

Быстрое MVP, решение рутинной задачи, – с этим может помочь вайбкодинг. Но маркетолог сможет подсказать, какие параметры нужны, а разработчик – как сделать код простым и поддерживаемым. Оптимизатор поможет убедиться, что рекомендации и правда полезны.

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

Риски вайбкодинга без маркетингового мышления

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

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

• «Можно, а зачем?» Сделать простой сервис с помощью вайбкодинга можно, но если на рынке уже есть аналогичные решения, которые делают то же самое, что полезного несёт такая разработка, кроме собственного опыта? Важно предусматривать дистрибуцию, считать экономику. Либо наверняка понимать, что это решение локальной задачи или повышение своего опыта в вайбкодинге.
• Рост технического долга. Нейросеть может писать избыточный или несистемный код. Каждая новая доработка может усложнить структуру и увеличить риск поломок.
• Потеря управляемости. Без понимания логики кода сложно быстро найти ошибку, внести изменения или масштабировать решение. Сервис начинает жить своей жизнью.
• Зависимость от случайных решений нейросети. Если специалист не контролирует процесс, ИИ сам принимает решения: может менять код там, где не нужно или не учитывать важные связи между частями продукта.

Где маркетологи чаще всего ошибаются

На моём опыте почти все ошибки, которые я замечала, связаны с неправильной постановкой задач или неверным управлением процессом.

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

Как маркетологу прокачаться в вайбкодинге

Главный совет — относиться к вайбкодингу как к инструменту, который помогает усилить специалиста. Тогда он действительно будет ускорять процессы, а не создавать новые проблемы.

• Учитесь ставить задачи. Рассказывайте нейросети, какую проблему хотите решить и какой результат будете считать успешным. Чем чётче заданы цель, ограничения и контекст, тем ближе итог к ожиданиям.
• Разбирайте логику кода и не принимайте результат вслепую. Для этого не обязательно быть разработчиком, но нужно понимать, как устроено решение в целом: где что подключается, откуда берутся данные и что может пойти не так. Это снижает риск незаметных поломок и упрощает доработки.
• Проверяйте решения на пользователях и данных. Инструмент должен встраиваться в воронку и проверяться так же, как любая маркетинговая гипотеза. Запуск — это только начало, дальше важно смотреть на поведение пользователей и метрики, дорабатывать продукт.
• Связывайте инструмент с воронкой и целями бизнеса. Каждое решение должно отвечать на вопрос, зачем оно существует. Если инструмент не влияет на ключевые показатели или не поддерживает стратегию, его ценность сомнительна независимо от качества кода.

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

Маркетолог формирует цель инструмента, задаёт ограничения и определяет, какой результат считается успешным. Он принимает решения и несёт ответственность за последствия, а не просто генерирует варианты через ИИ.

Вайбкодинг снимает часть технических барьеров, но не ответственность за выбор решений.

Ключевые компетенции маркетолога при работе с ИИ

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

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

Заключение

Вайбкодинг отлично подходит для экспериментов, обучения, проверки гипотез, создания инструментов и автоматизации рутины. Он даёт быстрый вход и снижает порог в разработку. Но он не отменяет необходимости думать, анализировать и принимать решения.

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