Ассистент или агент: как я строил контент-машину тремя способами и что из этого вышло
Продакт из AlpinaGPT три месяца автоматизировал выпуск видео для AI/tech-канала, перепробовав три подхода: ручную работу с ChatGPT, визуальный конструктор n8n и Python-агента на базе Claude Code. Неожиданным итогом стало то, что код оказался не только компактнее, но и предсказуемее, чем ожидалось. Разбираем, как менялась экономика разработки и почему барьер входа в программирование упал.
Задача, которую поставил перед собой Анатолий Клавдиенко, продакт из AlpinaGPT и Alpina Digital, звучит просто, но на практике выматывает: каждую неделю нужно выпускать от пяти до десяти коротких видео для AI/tech-канала в Telegram. Аудитория — продакты, предприниматели и айтишники, которые хотят быть в курсе последних новостей из мира искусственного интеллекта, но не готовы ежедневно штудировать TechCrunch или MIT News. Чтобы видео не превращалось в очередную безликую выжимку из твиттера, приходится прогонять контент через многоступенчатый конвейер: собрать свежие новости из десятка источников, отобрать те, что имеют реальный хук — будь то впечатляющие цифры, контринтуитивность или конкретика, — написать короткий, но цепляющий скрипт для ИИ-аватара, сгенерировать видео с субтитрами, B-roll и музыкой, а затем опубликовать его на YouTube Shorts, TikTok и Instagram Reels с правильными описаниями и тегами для каждой площадки. Для одного ролика это увлекательный творческий процесс, но когда таких роликов нужно делать десятки в неделю, рутина начинает затягивать.
Первый подход — самый очевидный и, как выяснилось, самый медленный. Он заключался в использовании ChatGPT в качестве умного собеседника: автор открывал чат с моделью, RSS-ридер во втором окне и монтажку в третьем, а затем вручную проходил весь конвейер. Он скармливал модели тридцать заголовков, просил выбрать пять самых интересных под свою аудиторию, затем писал скрипт, переводил его в озвучку, монтировал, экспортировал и публиковал. На десять видео в неделю уходило около четырех часов, из которых только тридцать-сорок минут занимал непосредственный разговор с моделью. Остальные три с лишним часа — это ручная сборка: подбор B-roll, выравнивание субтитров, склейка, добавление музыки, создание обложек, написание подписей для трех площадок и загрузка на каждую из них. Каждый отдельный шаг занимал немного времени, но в сумме они складывались в часы. Ключевой признак того, что пора двигаться дальше, сформулировался так: «Я устал быть транспортным уровнем». Модель пишет — он копирует, модель предлагает — он переносит. Ассистент быстр внутри одного диалога, но не дотягивается до API за пределами чата, и это его главное ограничение.
Логичным следующим шагом стал визуальный конструктор n8n self-hosted — открытый, гибкий инструмент с нужными интеграциями. На бумаге он выглядел идеально: можно собрать пайплайн без единой строчки кода. На практике на сборку workflow ушло около двух дней, и еще два дня — на отладку и тестирование. То есть целая рабочая неделя, чтобы выйти из ручного режима. Дальше каждый цикл «настроил — сломалось — починил — донастроил» в визуальном редакторе обходился в разы дороже, чем аналогичный цикл в обычном Python-репозитории. Болели три вещи. Во-первых, визуальный редактор плох для итераций: в коде можно выделить блок и перенести его командой Cmd+X, Cmd+V, а в n8n блок — это нода, и пересборка ветки workflow занимает гораздо больше времени, чем правка функции. Во-вторых, нет версионности и диффа: невозможно спросить у git diff, что изменилось со вчерашнего дня, а откат к версии «вчера утром» требует ручного экспорта JSON workflow в файл. В-третьих, отладка превращается в разглядывание JSON в браузере: нет breakpoints, нет print(), нет нормального step-through. Когда в проде падает нода, приходится идти в UI, открывать execution, разворачивать JSON и искать, где сломалось. n8n — рабочий инструмент для команд с бюджетом на его сопровождение, но для одного человека, который параллельно делает продукт и хочет, чтобы канал жил сам, он начинает работать медленнее, чем хотелось бы.
Самый интересный момент наступил на третьем этапе. Автор не садился писать Python-агента с нуля — он выгрузил рабочий n8n workflow в JSON (это делается из коробки), открыл Claude Code, скинул туда этот JSON и попросил адаптировать его в Python. Один вечер — и у него был первый рабочий пайплайн в коде, который делал то же самое, что и n8n-workflow. Именно здесь экономика разработки кардинально изменилась. Раньше выбор между визуальным конструктором и кодом был выбором между «можно собрать за день» и «надо садиться писать неделю». Теперь же выбор стоит между «собрать за неделю в визуальном редакторе и потом неделю отлаживать в JSON-вкладках» и «выгрузить тот же workflow в JSON, скормить LLM и за вечер получить нормальный Python-репозиторий с диффами, тестами и логами». Барьер входа в программирование упал настолько, что код стал выгоднее визуального конструктора даже на простых пайплайнах.
Этот эксперимент имеет прямое отношение к состоянию российского рынка ИИ, где всё больше компаний и индивидуальных разработчиков ищут способы автоматизировать рутинные процессы. Показательно, что даже в такой, казалось бы, творческой сфере, как создание контента, агенты на основе LLM начинают вытеснять ручной труд и визуальные конструкторы. Опыт Анатолия показывает, что ключевой навык теперь — не столько умение программировать с нуля, сколько умение правильно сформулировать задачу для LLM и использовать существующие инструменты как мост к коду. Это открывает новые возможности для продактов и предпринимателей, которые раньше избегали программирования, но теперь могут создавать сложные автоматизации, просто описав их на естественном языке.
Однако остаются открытые вопросы. Насколько масштабируем такой подход? Что будет, когда агент столкнется с нестандартной ситуацией, которую не предусмотрел автор? Пока что эксперимент показал, что код предсказуемее визуального конструктора, но это не значит, что он полностью избавлен от сюрпризов. В перспективе автор планирует расширять функциональность агента, возможно, добавляя новые источники и форматы, но главный урок из трех месяцев экспериментов — не бояться кода и использовать LLM как мост от визуальных конструкторов к полноценной разработке. Для тех, кто стоит перед выбором, чек-лист прост: если задача ограничивается диалогом и не требует интеграций, ассистент достаточен; если же нужен регулярный конвейер с внешними вызовами, лучше сразу смотреть в сторону агента, причем генерировать его с помощью LLM. Этот подход экономит недели, которые раньше уходили на настройку и отладку визуальных workflow, и позволяет сосредоточиться на творческой части — отборе тем и написании сценариев, а не на перекладывании байтов между вкладками.