Я полезла в n8n и Claude Code, чтобы говорить с подрядчиками на одном языке. Через несколько месяцев у меня появились скрипты, боты и агенты для рассылок, мониторинга, медиадайджестов и аналитики.
Я Вика, работаю в службе Маркетинговых коммуникаций функции Корпоративные коммуникации и брендинг СИБУРа. До недавнего времени это означало понятный набор задач: контент, рассылки, медиа, Telegram-сообщества, мониторинг, подрядчики, согласования, отчеты. А потом в нашу функцию пришел ИИ. Сначала как большая тема для обсуждения: что можно автоматизировать, какие процессы ускорить, где собрать контент-завод, как работать с подрядчиками. А потом все стало гораздо интереснее.
На одной из встреч с агентством-подрядчиком мы обсуждали Telegram-бота для транскрибации видео. Отправляешь файл, бот обрабатывает его, возвращает подробную расшифровку и саммари. Я попросила добавить поддержку аудио: чтобы можно было отправлять не только видео, но и аудиозапись. В ответ услышала: две недели и 300 тыс. рублей.
На уровне здравого смысла у меня возник вопрос: если из видео все равно извлекается аудиодорожка, почему аудиофайл на входе превращает задачу почти в отдельный проект? Но дальше здравый смысл заканчивался. Я не понимала, как устроен пайплайн, где там реальная сложность, а где оценка с запасом. Аргументов для спора не было.
В тот момент я поняла неприятную вещь: чтобы быть нормальным заказчиком AI-решений, мне не хватает технической базы, чтобы понимать, что я покупаю, какие вопросы задавать и где действительно нужна сложная разработка.
Внешний контекст тоже подталкивал к автоматизации. Мы, как и все, боремся за эффективность, поэтому команда стала компактнее, а задачи никуда не исчезли. Часть того, что раньше закрывали стажеры или подрядчики, все равно нужно было делать, ИИ помог просто не утонуть в операционке.
Дисклеймер: это не инструкция по вайбкодингу и не обзор инструментов. Это заметки человека из маркетинговых коммуникаций, который три месяца назад впервые открыл терминал и теперь собирает агентов для рассылок, мониторинга, медиадайджестов, аналитики и производства контента. Я не разработчик и не претендую на промышленный уровень инженерии. Если интересно, как выглядит путь многофункционального эксперта, который внезапно обнаружил, что может пересобрать собственную работу руками – добро пожаловать под кат.
Пришла к Claude без задачи
Первое, с чего я начала, – это не написание кода и не выбор инструмента. Я зашла в Claude и сказала примерно так:
«У меня дикая нагрузка, было три стажёра – стало ноль, у меня очень много рутины и мне кажется, что многое можно автоматизировать, но я не понимаю как. Проинтервьюируй меня и подскажи, с чего конкретно начать»
Claude задал мне 20–30 вопросов. Что я делаю в течение рабочего дня, какие задачи повторяются каждый день, какие раз в неделю, какие раз в месяц, как именно я их делаю, в каких сервисах, сколько времени уходит на каждую, что больше всего бесит. Я отвечала развёрнуто, не пыталась казаться умнее или собраннее, чем есть.
В ответ он выдал мне пунктами: вот здесь у тебя уходит много времени, здесь повторяющаяся механика без принятия решений, здесь можно полностью автоматизировать через скрипт, здесь нужен агент с расписанием. Дальше я сказала ему: я только начинаю свой путь, давай возьмём что-то простое и соберём низко висящие фрукты. С этого началась вся история, и дальше я пошла по пунктам, которые мы вместе подсветили.
Собрала email-рассыльщик за сутки
Первым рабочим проектом стал скрипт для email-дайджеста журнала «СИБУР Клиентам». Раньше подготовка такой рассылки требовала ручной работы: взять статьи с сайта, прочитать, подготовить аннотации, собрать структуру письма, сверстать во встроенном конструкторе сервиса рассылок. Сейчас на входе я передаю ссылки, а дальше скрипт сам забирает тексты, делает аннотацию каждой статьи и оформляет все в дайджест.
Никакой магии: ссылки, парсинг, LLM, шаблон рассылки. Но для меня это был момент, когда ИИ перестал быть генератором текста и стал инструментом пересборки процесса. На выходе скрипт давал готовую HTML-вёрстку. Я копировала её и вручную переносила в DashaMail, это наш сервис рассылок. Это уже экономило время, но я понимала, что есть ещё один очевидный шаг. Спросила у Claude, можно ли подключить его прямо к DashaMail.
Он сказал, что да, нужен API. Я пошла в техподдержку DashaMail, запросила API, получила его и скормила Claude. Claude собрал MCP-сервер – это коннектор, который связывает агента с сервисом по стандартному протоколу Model Context Protocol.
Экономика тоже появилась: около 7 часов моей работы в месяц или примерно 900 тыс. рублей в год, если считать через работу подрядчика. Для бюджета большой функции это не революция. Для человека, который только научился работать с ИИ, – успех.
Собрала сквозную аналитику, чтобы увидеть клиента
В какой-то момент стало понятно: автоматизировать производство рассылок – это только половина задачи. Если агент быстро собрал письмо, отправил его и мы снова смотрим только open rate в интерфейсе сервиса рассылок, система всё равно остаётся слепой. Мы ускорили механику, но не изменили качество решений.
У нас много каналов коммуникации с клиентами: email-рассылки, журнал «СИБУР Клиентам», сайт «Бизнес-практик», Telegram-сообщество, вебинары. Каждый канал по отдельности даёт свою статистику: здесь открытия, там клики, там регистрации, там посещения вебинара. Но клиент не живёт внутри одного канала. Одна компания читает статьи, открывает письма, регистрируется на вебинары – и приходит. Или регистрируется, и не доходит. Как отличить?
Поэтому следующим слоем я начала собирать сквозную аналитику. Так появился SIBUR Analytics Hub – внутренний хаб, который стягивает данные из разных каналов в одну модель-дашборд: «вот компания, вот её касания с нашими коммуникациями, вот какие темы она читала, какие письма открывала, на какие вебинары регистрировалась и какие действительно посетила».
Для меня это был важный переход. До этого агенты помогали быстрее делать коммуникации. Хаб начал отвечать на другой вопрос: что происходит с аудиторией после того, как коммуникация вышла.
У такого инструмента сразу два выхлопа:
Первый – коммерческий. Если мы видим, что компания регулярно читает материалы по конкретной теме, кликает на продуктовый контент, приходит на вебинары и попадает в «горячий» сегмент, это уже сигнал не только для коммуникаций. Такой сигнал можно передать дивизионам: возможно, здесь есть интерес, который стоит проверить в живом контакте.
Второй – коммуникационный. Сквозная аналитика помогает планировать контент не по ощущению «кажется, эта тема важная», а по фактическому поведению аудитории. Какие статьи дочитывают через рассылки, какие темы приводят людей на сайт, какие вебинары собирают регистрации, где есть интерес, но не хватает материала. Это уже вход в следующий цикл контент-планирования.
Сейчас я достраиваю поверх этого ещё один слой – агентный. Агент-аналитик должен смотреть на данные хаба и находить тенденции, аномалии и гипотезы. SEO-агент – сопоставлять поведение текущей аудитории с поисковым спросом. Контент-стратег – превращать выводы двух агентов в темы и форматы для следующего месяца.
И вот здесь для меня замкнулся круг. Сначала ИИ помогал мне быстрее собрать письмо. Потом – собрать несколько таких процессов для коллег. А теперь я постепенно прихожу к системе, где ИИ не только производит коммуникации, но и помогает понять, какие коммуникации вообще стоит делать.
Первый внутренний заказчик: мониторинг внешних сайтов
Я рассказала о собранных инструментах на статусе команды. И тут ко мне пришли коллеги из смежной службы и спросили, можно ли так же автоматизировать мониторинг внешних сайтов, включая форумы, СМИ, Википедию и так далее.
Важно для контекста:
Сейчас в функции три неравных класса людей по отношению к AI-инструментам. Есть те, кто формулирует задачи и ждёт результата – источники заказа. Есть те, кто пользуется готовыми агентами – пользователи. И есть совсем узкий слой, который пока собирает и поддерживает – AI-генераторы. Я сейчас в этом узком слое. И это не означает, что так должно оставаться навсегда.
Напротив, мы сейчас ищем пропорцию: сколько человек в функции должно уметь собирать агентов, сколько критически оценивать их выхлоп, а сколько просто получать пользу без погружения в технологию. Мне кажется, идеальная картина – когда каждый эксперт может собрать простой инструмент под свою задачу, а сложные системы остаются на тех, кто готов углубляться. Но до этой картины ещё путь. Пока я делюсь тем, что получилось у меня.
Итак. Задача выглядела буднично: каждый день проверять статьи о компании и ее предприятиях, чтобы не пропустить важные апдейты или изменения. Раньше это делали вручную или через подрядчика. Формально задача небольшая, фактически это тот самый невидимый слой работы, который легко не заметить, пока кто-то каждый день не тратит на него время.
Я собрала Telegram-бота, куда коллеги сами могут добавлять ресурсы для мониторинга. Каждое утро скрипт подключается к разным ресурсам по API, забирает текущие версии статей, сравнивает их с предыдущими версиями в базе данных, выделяет изменения и отправляет их в LLM.
Модель помогает определить приоритет: косметическая правка, содержательное изменение или потенциально чувствительный репутационный сигнал. На выходе коллеги получают в Telegram короткую интерпретацию: что именно изменилось, насколько это важно и нужно ли смотреть руками.
Сейчас бот мониторит 36 ресурсов, им пользуются 5 человек. Если считать через внешний мониторинг, аналогичная задача могла бы стоить около 2-2,5 млн рублей в год.
Здесь я впервые почувствовала разницу между автоматизацией ради экономии и автоматизацией ради управляемости. Скрипт не заменил репутационного специалиста. Он снял ежедневную проверку «на всякий случай» и оставил человеку более важную часть работы: оценку и решение.
К этому моменту у меня было три рабочих агента и ощущение, что я в общих чертах разобралась. Дальше я взялась за задачу, которая казалась такой же, как все…
Получила монстра из скрипта
В смежной службе каждый день собирают для компании утренний «срез» полезной информации. Это не только про публикации медиа, а в т.ч. про любые полезные сигналы из открытых источников: отраслевые обзоры, упоминания конкурентов и партнёров, свежие исследования, высказывания регуляторов, новые инициативы на стыке наших рынков. Всё, что за последние сутки появилось и может быть полезно своевременно довести до бизнес-функций.
Исходные данные приходили из нескольких систем мониторинга и открытых площадок. Дальше начиналась ручная чистка: выкинуть шум, разнести информацию по тематическим блокам, переписать сухие формулировки в нормальный язык, добавить то, что «обязательно должно попасть в поле зрения» руководителей и экспертных команд. В конце это конвертируется в один общий продукт, который улетает по широкой рассылке.
Коллеги делали работу очень тщательно, поэтому каждая подборка занимала приличное время: правки подрядчику, свои комментарии, повторная вычитка, финальное согласование с руководителем. В какой-то момент они пришли ко мне с вопросом:
можно ли хотя бы механику собрать на скриптах, чтобы руками не перебирать всё подряд?
Я уже поработала с API разных сервисов, настроила несколько агентов под свои задачи и, конечно, решила, что здесь будет «ещё один такой же кейс». Есть источник данных, есть правила отбора – дальше вроде бы понятно.
Сложность оказалась совсем не там, где я её ожидала. На старте у коллег был понятный верхнеуровневый запрос и общее представление о результате: утренний срез публичного инфополя, который удобно читать бизнесу. Но настоящая продуктовая логика начинала рождаться только тогда, когда они видели первые рабочие версии инструмента
Я приношу первую сборку. Мы смотрим её вместе – и тут же появляются новые сценарии:
а можно, чтобы отдельный сигнал можно было переписать, не пересобирая весь выпуск? И перегенерировать аннотацию к одному сюжету, не трогая остальные?
Я дорабатываю. На следующем круге становится ясно, что одних правок мало: нужны роли и прозрачный маршрут согласования. Появляется запрос на редактора и согласующего, а также на то, чтобы весь цикл «подготовка → правки → подтверждение» проходил внутри одного инструмента, без писем и разрозненных файлов. Я снова иду делать.
Через несколько итераций я поймала себя на том, что «маленький скрипт» уже совсем не маленький. В какой‑то момент файл разросся почти до шести тысяч строк: в нём одновременно жили сборка и нормализация входящих данных, фильтрация по правилам, генерация текстов, роли пользователей, интерфейс для правок и кусочки внутренней аналитики. Каждая новая фича что‑то ломала. Стало понятно, что дальше так нельзя.
Пришлось остановиться и перестроить это как систему. Я разнесла всё по слоям:
отдельно – загрузка и приведение входящих материалов к единому формату;
отдельно – логика отбора и группировки сигналов по темам;
отдельно – AI‑пайплайн, который помогает переписывать сухой текст в рабочие аннотации
В отдельный блок уехали пользовательские роли, интерфейс для редактирования и согласования, история версий и базовый мониторинг того, как инструмент отрабатывает каждый день.
Параллельно всплыло ещё одно важное открытие: я плохо проинтервьюировала коллег на старте.
Мы много говорили про финальную картинку – «утренний срез поля, где собраны только действительно важные сигналы», – но почти не разбирали в деталях, как именно они принимают решения: что однозначно попадает в выпуск, что считается дубликатом, какие пограничные кейсы для них критичны и чем «важный» сигнал отличается от «интересного, но необязательного». В итоге значительная часть требований всплывала уже по ходу тестирования, а каждая новая идея докручивалась поверх живого прототипа.
На данной стадии мы уже вышли на прототип веб-приложения. По сути – это внутренняя платформа, которая каждое утро собирает из разных открытых источников всё, что за сутки произошло вокруг нашего контура, вычищает шум, раскладывает сигналы по блокам и отдаёт редактору готовый черновик. Дальше внутри того же интерфейса можно поправить формулировки, проверить, ничего ли не потерялось, пройти по цепочке согласований и отправить итоговую версию тем, кому важно держать руку на пульсе внешнего поля.
Когда я бралась за эту задачу, в голове был скрипт «на вечер» – слегка облегчить коллегам ручную работу. В итоге получился живой продукт: с ролями, интерфейсом, логикой отбора и кучей нюансов, о которых на старте никто не думал. И это был первый момент, когда я всерьёз задумалась:
где заканчивается вайбкодинг ради удобства, и начинается зона решений, за которые отвечаешь уже как за полноценный инструмент для других команд?
Передала канал нейросетям
Параллельно с дайджестом у меня был ещё один проект, который вырос из совсем другой задачи. Один из наших дивизионов хотел сделать телеграм-канал с новостями отрасли, не брендовый. В конце 2025-го мы пытались собирать это через агентство, получалось сложно, дорого и медленно. Проект припарковали.
Когда я уже накопила опыт после первых агентов, я решила попробовать собрать архитектуру сама.
Канал работает на мультиагенте. Первый агент парсит новости из СМИ и Telegram-каналов в нужной тематике. Второй рерайтит. Третий редактирует и публикует. Я в этот процесс почти не вмешиваюсь, занимаюсь только стратегией.
Дальше я наложила сверху аналитический слой. Это отдельный агент, который раз в месяц отсматривает всю отраслевую повестку за период и формирует для подписчиков пдф-отчет: матрицу с ценами, ключевые тренды и тенденции, прогноз. Когда мы это запустили, к нам пришёл наш профильный дивизион и сказал: классная штука, мы это сами на оперативках обсуждаем. Только нам ещё нужно, чтобы в каждой публикации была интерпретация конкретно для нас – пояснение, как происходящее в отрасли касается СИБУРа.
Сейчас я как раз достраиваю поверх канала дополнительный слой. Агент будет знать всё про СИБУР (наши продукты, клиентов, конкурентов) и интерпретировать внешние новости через эту призму. Параллельно подключаю не только СМИ, но и сырые данные: таможенную статистику, Росстат, отраслевую статистику по нашему сегменту. Идея в том, чтобы агент замечал важные сигналы ещё до того, как они попадут в СМИ, и формировал бизнес-гипотезы.
Главная сложность здесь не техническая, а в данных. Чтобы агент не говорил чепуху, он должен хорошо понимать всю нашу продуктовую линейку. Вот жду нужную фактуру от коллег.
Вместо финала
К моменту написания статьи у меня скопилось больше десятка скриптов, ботов и агентов. И тут я поймала себя: они не заменили мне стажёров. Они сделали меня руководителем маленькой команды цифровых джунов. Быстрые, не устают, работают ночью. Но есть важная оговорка: такая команда работает только там, где есть чёткие инструкции, проверки и ограничения. Без этого инициатива превращается в новый источник хаоса.
Вайбкодинг позволяет собрать прототип за вечер. Это правда. Но прототип и промышленное решение – разные жанры совсем. Между ними целая инженерная дисциплина: логи, тесты, мониторинг, обработка исключений. Примечательно, что я перестала считать инструмент готовым в тот момент, когда он красиво сработал один раз. Готовым он становится позже, когда несколько недель подряд выдаёт понятный результат, и ты уже не заглядываешь в каждый символ с тревогой.
А вот обратная сторона. Когда понимаешь, что можешь собрать инструмент сама, остановиться сложно. Раньше идея упиралась в привычную цепочку: подрядчик, бюджет, сроки. Теперь мозг щёлкает: «А это можно автоматизировать?» Иногда меня спасают только лимиты Claude. Когда заканчиваются, вспоминаю, что есть внешний мир.
Но главный вопрос, кажется, не в том, должна ли коммуникационная функция уметь кодить. Вопрос в другом:
умеет ли она отличить момент, когда прототип ещё можно держать на коленке, от момента, когда за него уже нужно отвечать как за продукт — и идти в ИТ за серьёзной разработкой?
Я пока сама учусь эту границу проводить. Но одно стало понятно: чтобы формулировать хороший заказ на AI-решение, недостаточно сказать «давайте автоматизируем». Нужно понимать, из каких шагов состоит процесс, где в нём данные, где решения, где риски, где нужна проверка – и в каких точках человек всё ещё обязан оставаться в контуре.