Workflow или вайбкодинг: когда автоматизацию собирают на платформе, а когда пишут кодом

Что платформа даёт из коробки, а в коде придётся написать самому

• Запуск. Расписание, вебхук, событие в почте или чате — это готовые узлы-триггеры. В коде за тем же стоят cron, сервер, который не выключат, и очередь.
• Повторы при ошибке. У каждого узла есть «Повторять при ошибке», «Макс. попыток» и «Пауза между попытками». Отдельно настраивается поведение при сбое: остановить процесс, продолжить дальше или увести элемент в отдельный error-выход и там разобрать.
• История запусков. Видно статус, данные на входе и выходе каждого шага и стоимость запуска в токенах с разбивкой по CPU, памяти и трафику. Это тот самый «почему вчера в 3 часа ночи не отправилось», на который в своём скрипте отвечают логи, если их писали.
• История версий. Кто менял схему, когда и сколько в ней было узлов; любую версию можно восстановить, и восстановление тоже попадёт в историю.
• Ключи отдельно от схемы. Подключения живут в учётных данных пространства, а не в тексте процесса, поэтому схему можно выгрузить файлом и передать коллеге, не передавая секреты.
• Разграничение доступа. Пространства с ролями: у отдела свои процессы, ключи и участники.

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

Что даёт свой код

• Любые библиотеки и алгоритмы. Тяжёлая обработка данных, своя математика, парсинг нестандартного формата — всё, что есть в экосистеме языка.
• Git по-настоящему. Ветки, ревью изменений построчно, автотесты, CI, откат одной командой.
• Производительность. Цикл на миллион строк в коде отработает за секунды и будет стоить дешевле, чем тот же цикл, разложенный на узлы.
• Свой интерфейс. Если у задачи есть пользователи, экраны и логин — это продукт, а не процесс, и платформа тут ни при чём.
• Никаких чужих ограничений. Нет каталога коннекторов — есть весь интернет и любой протокол.

Сравнение по существу

Где платформа честно проигрывает

• Алгоритмика и тяжёлые данные. Разложенный на узлы цикл по большому массиву платит за себя CPU-секундами. Миллион строк дешевле обработать кодом — хоть внутри узла «Код», хоть отдельным сервисом.
• Ограничения песочницы. В узле «Код» сейчас доступен JavaScript. Произвольные npm-пакеты в облаке не подключить: список модулей задаётся администратором, и расширить его можно только в своём контуре.
• Ревью схемы. История версий с восстановлением есть, а вот веток, merge-реквестов и построчного diff — нет. Изменения в схеме смотрят глазами на канве, и на большом процессе это хуже, чем git diff.
• Автотестов у схемы нет. Проверка — это тестовый прогон на реальных данных, а не набор юнит-тестов, которые гоняет CI перед выкладкой.
• Продукт — не процесс. Если нужен личный кабинет, свои экраны и логика на каждый клик, workflow вам этого не даст и не должен.

Где проигрывает вайбкод

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

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

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

Важно, что собирать её можно ровно тем же способом — словами. Через MCP процесс создаёт ИИ-клиент: вы описываете задачу в Claude или ChatGPT, а в пространстве появляется workflow. Скорость вайбкодинга сохраняется, а чёрного ящика не возникает — вы сразу видите получившуюся логику на канве и правите её руками, не возвращаясь в переписку.

Пять вопросов, чтобы выбрать

1. Это интеграция или продукт? «Перекладывать данные между системами по событию» — процесс. «Экраны, роли, свои пользователи» — продукт и код.
2. Сколько будет похожих задач? Одна — берите что быстрее. Пять-десять однотипных выгрузок — платформа, иначе получите зоопарк скриптов.
3. Кто будет чинить в ваше отсутствие? Если в команде нет программиста, код без автора — это мина замедленного действия.
4. Есть ли тяжёлые вычисления? Алгоритм и большие объёмы — код. Вызовы API, условия и маршрутизация — узлы.
5. Какие требования к данным? Если нельзя наружу — платформу ставят в свой контур, и это отдельный разговор про инфраструктуру, а не про язык.

Гибрид: в реальности выигрывает он

Практика обычно оказывается посередине.

• Узел «Код» внутри схемы. Вся обвязка — триггеры, ретраи, ключи, история — от платформы, а десять строк своей логики пишутся прямо в узле. В том числе ИИ-ассистентом.
• Свой сервис за вебхуком. Тяжёлый расчёт живёт отдельным сервисом, workflow его вызывает и разносит результат по системам.
• Сборка процесса словами. Через MCP ИИ-клиент собирает и правит схему в вашем пространстве — это тот же вайбкодинг, только результатом можно пользоваться, не читая код.

Что куда обычно ложится

• Заказы с маркетплейса в 1С, уведомления в Telegram, выгрузки в CRM — workflow: много внешних систем, мало логики.
• Рекомендательный алгоритм, скоринг, сложный парсер — код, который workflow вызывает как шаг.
• Разовая миграция или парсинг на один вечер — скрипт, и не жалко выбросить.
• Отчёты по расписанию, напоминания, дежурства — workflow: расписание и повторы уже есть.
• Сервис с личным кабинетом — код целиком.

Частые вопросы

Что дешевле — платформа или свой код?

Считать надо не только разработку. В коде вы платите за сервер, хранилище и время инженера, который правит скрипт при каждом изменении на той стороне. В Staqflow оплачивается runtime — токены за CPU-секунды, а ожидание ответа чужого API процессор почти не грузит. Порядок цен — на странице тарифов.

Может ли ИИ собрать workflow за меня?

Да, для этого есть MCP-сервер: ИИ-клиент создаёт и правит процессы в вашем пространстве, а результат сразу видно на канве — в отличие от сгенерированного кода, который придётся читать. Сборка и правка через MCP токены не тратят: они списываются только за запуски, включая тестовые.

Почему вайбкод называют чёрным ящиком?

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

Нужен ли программист для платформы?

Для типовых процессов — нет: узлы, условия и выражения осваивает аналитик. Программист пригодится там, где начинается узел «Код» и нестандартные API.

Что делать, если нужного коннектора нет?

Взять универсальный HTTP-запрос — этого хватает почти всегда. Полный список готовых — в каталоге интеграций.

Не привяжемся ли мы к платформе?

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

А если данные нельзя отдавать в облако?

Платформа ставится в собственный контур на Docker Compose или k3s — тогда и схемы, и ключи, и история запусков остаются на ваших серверах.

Попробуйте

1. Создайте аккаунт — карта не нужна.
2. Соберите самый надоевший ручной процесс: триггер, два-три узла, уведомление в чат.
3. Или опишите его словами своему ИИ-клиенту через MCP — и посмотрите, что получилось на канве.

Если после этого окажется, что задача всё-таки про алгоритм, а не про интеграции, — пишите код. Мы сами так делаем.