Anatoly Klavdienko, Product / CustDev

TL;DR

Ассистент в чате — собеседник. Агент — сотрудник, который сам ходит по API, пока ты спишь. Я три месяца строил одну и ту же контент-машину для AI/tech-канала: сначала руками с ChatGPT, потом на n8n, потом на Python через Claude Code — и третий вариант оказался компактнее и предсказуемее, чем я ждал в начале. Дальше — архитектура, реальные тайминги из pipeline.log, история про SaaS-вендора, который подвел за один день, и чек-лист «Когда брать ассистента, а когда писать агента».

Зачем я вообще это полез автоматизировать

Меня зовут Анатолий Клавдиенко, я отвечаю за разработку ИИ-агентов в AlpinaGPT и Alpina Digital.

Задача формулируется просто и выполняется тошнотворно: делать 5–10 коротких видео в неделю для AI/tech-канала в Telegram. Аудитория — продакты, предприниматели, айтишники, которые хотят держать руку на пульсе, но не готовы каждый день читать TechCrunch и MIT News.

Чтобы видео не превращалось в «еще одну выжимку из X», каждый раз нужно пройти один и тот же конвейер:

1. Собрать свежие AI/tech-новости из десятка источников.

2. Отобрать те, у которых есть реальный хук — цифры, контринтуитивность, конкретика.

3. Написать короткий скрипт под ИИ-аватара (короткий не значит легкий: 30–60 секунд должны держать внимание).

4. Сгенерировать видео с аватаром, наложить субтитры и B-roll, добавить музыку.

5. Опубликовать на YouTube Shorts, TikTok и Instagram Reels — с правильным описанием и тегами для каждой площадки.

Для одного видео это интересный творческий процесс. Для пяти–десяти в неделю — работа.

Этап 1. Ассистент в чате — около 4 часов в неделю на 10 видео

Первый подход — самый честный и самый медленный. Открыть ChatGPT в одном окне, RSS-ридер во втором, монтажку в третьем и проходить весь конвейер руками. Ассистент тут — очень умный собеседник: я кидаю ему 30 заголовков, прошу выбрать 5 самых интересных под мою аудиторию, дальше прошу написать скрипт, потом перевожу его в озвучку, монтирую, экспортирую, публикую.

На 10 коротких видео в неделю у меня уходило около 4 часов. Сам разговор с моделью — минут 30–40. Остальные три с лишним часа — ручная сборка и монтаж: подобрать B-roll, выровнять субтитры, склеить, добавить музыку, нарезать обложки, написать подписи под три площадки, разнести по платформам. Каждый шаг занимал немного — а потом «немного» складывалось в «долго».

Признак, что пора уходить с этого этапа, у меня сформулировался так: «Я устал быть транспортным уровнем». Модель пишет — я копирую. Модель предлагает — я переношу. Я не принимаю решений, я перекладываю байты из одной вкладки в другую. Тут и упирается ассистент: он быстрый внутри одного диалога, но не дотягивается до API за пределами чата.

Этап 2. Первый агент — n8n, четыре дня и почему я с него ушел

Логичный следующий шаг — взять визуальный конструктор и собрать пайплайн без кода. n8n self-hosted (n8n docs) — открытый, гибкий, есть нужные интеграции. На бумаге выглядел как ровно то, что мне нужно.

На практике у меня ушло примерно два дня на сборку workflow и еще два дня на отладку и тестирование. То есть рабочая неделя на то, чтобы выйти из ручного режима. Дальше каждый цикл «настроил — сломалось — починил — донастроил» в визуальном редакторе обходился мне в разы дороже, чем тот же цикл в обычном Python-репо.

Болело три вещи:

1. Визуальный редактор плох для итераций. В коде ты выделяешь блок и переносишь — Cmd+X, Cmd+V. В n8n блок — это нода, и пересборка ветки workflow занимает в разы больше времени, чем правка функции.

2. Версионности нет, диффа нет. Я не могу спросить у git diff, что изменилось со вчера. Откатиться к версии «вчера утром» — либо ручной экспорт JSON workflow в файл, либо никак.

3. Отладка — это разглядывание JSON в браузере. Нет breakpoints, нет print(), нет нормального step-through. Когда в проде упала нода — идешь в UI, открываешь execution, разворачиваешь JSON и ищешь, где сломалось.

n8n — рабочий инструмент для команд, у которых есть бюджет ops-времени на его сопровождение. Для одного человека, который параллельно делает продукт и просто хочет, чтобы канал жил сам, он начал работать медленнее, чем я надеялся.

Этап 3. Python-агент через Claude Code — один вечер на переход

Самая интересная цифра — здесь.

Я не садился писать Python-агент «с нуля». Я выгрузил рабочий n8n workflow в JSON (n8n умеет это из коробки), открыл Claude Code, скинул туда этот JSON и попросил адаптировать в Python. Один вечер — и у меня был первый рабочий пайплайн в коде, который делал то же самое, что мой n8n-workflow.

Это и есть тот момент, где экономика поменялась. Раньше выбор «визуальный конструктор vs код» был выбором между «Можно собрать за день» и «Надо садиться писать неделю». Сейчас выбор — между «Собрать за неделю в визуальном редакторе и потом неделю отлаживать в JSON-вкладках» и «Выгрузить тот же workflow в JSON, скормить LLM и за вечер получить нормальный Python-репо с диффами, тестами и логами». Барьер входа в код упал ровно настолько, что код стал выгоднее, чем визуальный конструктор, даже на простых пайплайнах.

После того первого вечера была активная разработка: 19 марта 2026 года я создал на сервере папку /root/video-production/, heygen.py появился 24 марта, основные пайплайны начали появляться 2 апреля и дорабатывались до 20-х чисел, миграция на свой постпроцесс — 21 апреля. Много итераций, много правок — но уже на репозитории, который можно git diff, а не на нодах в браузере.

Объективный маркер вместо «по ощущениям»: 2074 строки production-кода в 19 файлах — это весь агент, 3 пайплайна, 13 сервисов, оркестратор. Для контекста: меньше, чем у меня уходило на средний n8n-workflow по эквивалентной задаче.

Архитектура: три пайплайна, один scheduler, один контейнер

Итог трех месяцев выглядит так:

Три пайплайна, один scheduler, один контейнер. Никакого Kubernetes, никаких очередей, ничего, что нельзя задебажить через docker logs и grep в одном файле.

Pipeline D — Sourcing (news_miniapp.py)

Каждые 4 часа. Идет по 12 RSS-источникам — TechCrunch, The Guardian, VentureBeat, MIT News, The Verge, Ars Technica, The Next Web, AI News, QbitAI, Jiqizhixin, Synced, 36kr — собирает новые статьи, дедуплицирует по URL через url_tracker.py, отдает топ-10 в GPT-4o и сохраняет отфильтрованное в Airtable.

Модель для фильтрации — gpt-4o, явно:

В моей памяти было «Claude Sonnet пишет фильтр», но git blame и сам файл говорят: GPT-4o, и так с самого начала. Хороший аргумент в пользу кода — память врет, код не врет.

Pipeline C — Generation (generate_avatars.py)

Каждые 8 часов. Берет отфильтрованные новости из Airtable, просит GPT-4o написать 5 коротких скриптов под ИИ-аватара, отправляет каждый в HeyGen с одним из 11 look_id и пуллит результат с интервалом 60 секунд до 30 попыток. Видео приходит в формате 720×1280 — вертикаль 9:16, под Shorts/Reels/TikTok.

После генерации видео уходит в custom_postprocess — собственный модуль, про него ниже.

Pipeline A — Publishing (autopost_avatars.py)

Каждые 4 часа. Берет самое старое видео из Google Drive folder ToPublish, делает quality gate: если короче 15 секунд — пропускает и сразу перемещает в Published, чтобы не зацикливать обработку. Дальше — транскрипция Gemini 2.5-flash, метаданные через GPT-4o-mini, параллельная публикация на YouTube Data API v3 + Blotato (TikTok) + Instagram Graph API (Reels). После успешной публикации видео переезжает в папку Published.

YouTube — privacy_status: public, region_code: RU, category_id: '27' (Education), описание заканчивается ссылкой на исходный канал.

Конфиг — один YAML

Всё, что не код, лежит в одном файле — config/settings.yaml:

Поменять интервал, лимит, формат или громкость музыки — правка одной строки в YAML и docker restart. Без редеплоя.

Цифры из прода — что показывает pipeline.log

Все замеры — из реального logs/pipeline.log на сервере, не из моей памяти.

Pipeline D — Sourcing (5 июня 2026, 22:19 UTC):

Второй замер, 5 июня 18:19 UTC — 84 секунды, 8 saved / 2 skipped / 0 errors. Стабильно укладывается в полторы минуты.

Pipeline C — Generation (4 июня 2026):

Шесть–восемь минут на пять видео — ожидаемо: HeyGen polling забирает большую часть, остальное (промпт, постпроцесс, аплоад) укладывается в минуты.

Объем кода: 2074 строки production-Python в 19 файлах. Самые большие сервисы — custom_postprocess.py (405 строк), generate_avatars.py (246 строк), news_miniapp.py (193 строки).

Когда вендор подвел — миграция с SubMagic за один день

Самая показательная часть истории.

С первого дня в пайплайне был SubMagic — внешний сервис для караоке-субтитров и B-roll. В YAML до сих пор валяется блок magic_brolls_percentage: 70 — артефакт старой интеграции. Сам клиент services/submagic.py тоже остался в репо: 88 строк, последняя правка — 19 марта 2026 года. С тех пор — dead code.

Что случилось 20 апреля 2026 года: SubMagic API стал возвращать 502 / 500 Server Error и 402 Payment Required от api.submagic.co/v1/projects. По одному и тому же endpoint, на стабильных запросах, которые раньше отрабатывали. Тариф у меня был оплачен — но API возвращал «недостаточно средств».

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

21 апреля 2026 года — на следующий день — в репо появился services/custom_postprocess.py на 405 строк. Docstring файла, прямая цитата:

Что внутри:

• Whisper для транскрипции аватарного видео в word-level timestamps.

• GPT-4o-mini для расстановки пунктуации в сыром транскрипте.

• Pexels API для подбора B-roll — с дедупом по config/used_pexels_ids.json (последние 200 видео).

• FFmpeg для финального рендера: наложение субтитров, склейка с B-roll, добавление фоновой музыки (volume 0.2).

В pipelines/generate_avatars.py теперь импорт from services.custom_postprocess import process_video — а не from services.submagic. Активный пайплайн на SubMagic не ходит.

Пишу не с гордостью «Смотрите, как быстро я переписал». Пишу как принцип: когда у тебя Python-агент, ты можешь заменить любой кусок цепочки. Когда у тебя SaaS-агент-конструктор — нет. Это не теоретическая разница, а разница в один рабочий день между «Вендор лёг» и «Продакшен снова работает».

Чек-лист: ассистент или агент

Самая важная часть для меня — ради нее писал статью.

Брать ассистента в чате, если:

1. Задача одноразовая или штучная (раз в неделю, раз в месяц).

2. Нужно много креатива на каждом шаге — выбор формата, тон, стиль, нюансы. Ассистент тут — равноправный участник, агент будет глупее.

3. У тебя нет API на ту систему, в которую нужно положить результат. Ассистент не дотягивается до твоего CRM / Notion / чего-угодно без рук — но руки у тебя пока есть.

4. Стек еще не устоялся: ты пробуешь, переключаешься, выкидываешь. Кодифицировать пилот в агенте — преждевременная оптимизация.

Писать своего агента (n8n / Python / что-то еще), если:

1.  Задача повторяется регулярно (минимум раз в неделю) и пайплайн стабилизировался.

2. Большая часть шагов — переключение контекста между API, а не творческие решения. Если 80% работы — «взять X из A, положить Y в B», агент окупится.

3. У тебя есть API/SDK на все ключевые точки в цепочке. Если хотя бы одна — ручной шаг, агент будет постоянно спотыкаться.

4. Ты готов вложить разовые усилия в инфраструктуру (Docker, scheduler, логи, нотификации) ради того, чтобы дальше эту инфру переиспользовать.

Брать визуальный конструктор (n8n / Make / Zapier), если:

1. У тебя нет фона в Python и нет желания его получать.

2. Workflow вмещается в ≤ 20 нод и редко меняется.

3. Кто-то в команде уже сопровождает self-hosted n8n или ты платишь за Cloud, и это не больно.

Писать Python-агент (а не визуальный конструктор), если:

1. Workflow логически разбивается на 3+ пайплайна и они переиспользуют сервисы.

2. Тебе нужен git/diff/rollback (любая команда из больше чем одного человека — это уже да).

3. Один из шагов — кастомная логика (обработка видео, парсинг, дедуп с состоянием), которую конструктором делать дороже.

4. У тебя есть Claude Code или аналог — это снижает стоимость кода настолько, что эквивалентная сложность в визуальном конструкторе становится дороже.

Что бы я сделал иначе

1. Сразу один файл логов с JSON-структурой, а не plain text. Через месяц grep-driven debug перестает масштабироваться.

2. Watchdog для застрявших job-ов с первого дня. APScheduler по умолчанию max_instances=1 и без timeout — это значит, что застрявший job тихо съедает все следующие запуски, а ты узнаёшь об этом, только когда лезешь в логи руками.

3. Свой постпроцесс с первого дня, а не через месяц после того, как SubMagic упал. Это была не «преждевременная оптимизация» — это была честная зависимость от чужого API на критическом пути.

4. Метрики, а не догадки. Сейчас я знаю, что Pipeline D укладывается в 80–84 секунды, потому что сидел и считал по логам. Хочется график в Grafana, а не grep-марафон.

P.S.

16 сентября с 10:00 до 16:00 (МСК) мы проводим онлайн-конференцию «ИИ-Трансформация 2» — про российские и международные кейсы внедрения искусственного интеллекта в бизнес-процессы. Выступят спикеры из Skyeng, mymeet и других компаний — программу сейчас дособираем.

В апреле на первой конференции собралось больше 1150 участников: CEO, CTO и HRD разбирали реальные внедрения — от ИИ-агентов в бэк-офисе до расчёта окупаемости. Записи выступлений и саммари с трендами (агенты, ROI, эффективность ИИ) лежат в нашем боте — можно посмотреть уже сейчас. Участвовать можно бесплатно, предварительная регистрация уже открыта в чат-боте.

Если хочется забрать каркас себе — структура pipelines/ + services/ + один scheduler + один YAML тиражируется на любой content-конвейер за пределами видео. Параллельно я делаю продуктовую штуку про сообщества — AlmaMater; если оттуда будут полезные наблюдения по тому, как такие агенты живут на дистанции, напишу отдельно.

Еще из недавнего: стал экспертом курса «Вайбкод на практике» в Alpina Digital — для тех, кто хочет начать автоматизировать задачи, но пока без кода. Три недели — и в конце решение вашей задачи. Присоединяйтесь.