Использовать LLM как собеседника в чате или собрать агента, который работает автономно?

Коллеги из Alpina Digital три месяца строили контент-пайплайн: сбор новостей → генерация видео → публикация в YouTube, TikTok и Reels; использовали три подхода.

✔️Сначала был ассистент в чате. 
Модель писала, человек копировал, монтировал и публиковал. На 10 видео в неделю уходило 4 часа, из которых 30–40 минут на диалог с LLM.  

✔️Потом собрали агента в n8n. Два дня на сборку, два на отладку. 
Визуальный редактор получился неудобным для итераций, без нормальной версионности, отладка — разглядывание JSON. Инструмент рабочий, но для одного человека, у которого есть другие задачи, сомнительное решение.

✔️Перешли на Python через Claude Code. 
Выгрузили workflow из n8n в JSON, скормили LLM, попросили адаптировать. За вечер получили первый рабочий пайплайн в код. 

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

• Ассистент в чате подойдет для задач, которые возникают редко и требуют живого творчества на каждом шаге. Если нет API для автоматической загрузки результата, он остается единственным вариантом.
• Агента стоит писать, когда задача повторяется регулярно, а пайплайн стабилизировался. 
• Визуальный конструктор подходит командам без Python-экспертизы и ресурсов на её получение. Работает для небольших пайплайнов (до 20 нод), которые редко меняются.
• Код на Python становится выгоднее, когда логика разбивается на несколько пайплайнов с переиспользуемыми сервисами. Он дает контроль через git и дешевле конструктора, если есть кастомная обработка или доступен Claude Code.

AI в разработке