Коротко

n8n и Make хороши, когда процесс линейный, интеграции понятные, цена ошибки низкая, а команде нужен быстрый запуск. Кастомная разработка нужна, когда появляются права доступа, сложная бизнес-логика, нестандартная 1C, документы, RAG, человек в контуре, логи, evals и ответственность за production.

Вопрос не в том, что “лучше”. Вопрос в том, где заканчивается сценарий автоматизации и начинается продуктовый контур.

Если нужно: «пришла форма → отправить в Telegram → создать строку → сгенерировать черновик» - low-code почти всегда разумный старт. Если нужно: «агент читает WhatsApp, сверяет CRM и 1C, понимает документы, показывает источник, просит подтверждение и логирует решение» - это уже не просто цепочка блоков.

Когда n8n и Make подходят

Low-code подходит для быстрых, понятных и ограниченных процессов: уведомление о новой заявке, перенос данных между формой, таблицей и CRM, генерация черновика письма, классификация простого обращения, ежедневный отчёт в Telegram, обогащение лида, напоминания, простая синхронизация статусов, прототип AI-процесса до кастомной разработки.

Сильная сторона n8n и Make - скорость. Можно быстро собрать рабочий поток, показать команде, проверить пользу и не писать backend раньше времени.

Где low-code начинает трещать

Проблемы начинаются, когда процесс перестаёт быть линейным: много исключений, разные роли пользователей, нужно показывать источники, есть персональные или финансовые данные, CRM и 1C расходятся, документы приходят в PDF, фото и Excel, нужен RAG, детальные логи, интерфейс для разбора ошибок и сценарий меняется каждую неделю.

Low-code можно растянуть далеко. Но в какой-то момент схема превращается в хрупкую паутину: много блоков, непонятно где ошибка, сложно тестировать, страшно менять, невозможно нормально объяснить ответственность.

Отдельная граница - evals. Прототип AI-flow на n8n или Make собрать можно: взять 20-30 примеров, прогнать вручную, посмотреть, отвечает ли агент примерно так, как нужно. Но серьёзные evals на low-code обычно не строятся. В production нужны версионированные наборы кейсов, ожидаемое поведение, повторяемые прогоны, сравнение моделей и промптов, отчёт по регрессиям, quality gate перед релизом и история ошибок. Это уже инженерный контур, а не цепочка автоматизаций.

Если агент отвечает клиентам, читает документы, сверяет 1C или влияет на CRM, evals становятся частью системы. Без них команда не понимает, стало ли лучше после изменения промпта, не сломался ли старый сценарий и можно ли выпускать новую версию. Подробнее подход разобран в статье зачем AI-проекту evals.

Когда нужна кастомная разработка

Кастом нужен, если AI становится частью операционного процесса: WhatsApp-агент квалифицирует лиды, внутренний ассистент ищет по документам с правами доступа, агент сверяет счета и 1C, поддержка отвечает с источниками, AI контролирует CRM-гигиену, RAG работает по разным типам документов, руководителю нужен dashboard качества и ошибок.

Здесь важны не только интеграции, но и продуктовые вещи: роли, интерфейс, история действий, подтверждения, ошибки, мониторинг, evals, обновление базы знаний, безопасность.

Гибридный подход

Часто лучший путь - не выбирать религию. Low-code можно использовать для прототипа, внутренних уведомлений, вспомогательных sync-задач и быстрых связок. Кастомный backend - для критичной логики, прав, RAG, evals, логов и интерфейсов.

Например, n8n получает событие из CRM и отправляет его в кастомный сервис. Кастомный сервис решает, что делать с AI, проверяет источники, сохраняет лог и возвращает результат. Потом low-code отправляет уведомление менеджеру. Это нормальная архитектура, если границы ясные.

Как принять решение

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

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

Практичный порядок

Начните с low-code, если задача простая и надо быстро проверить ценность. Но заранее договоритесь, какие признаки означают переход к кастому: процесс стал бизнес-критичным, появились персональные или финансовые данные, нужно читать 1C или документы, нужна история решений, выросло число исключений, появились роли, требуется SLA или один сценарий стал зависеть от десяти костылей.

Если эти признаки уже есть на старте, не мучайте low-code. Делайте пилот ИИ за 30 дней как инженерный прототип и сразу проектируйте production-границы.

FAQ

Можно ли сделать AI-агента в n8n?

Можно сделать прототип или простой агентный flow. Но если агент работает с правами, источниками, документами, CRM, 1C и handoff, понадобится кастомный слой.

Make хуже n8n?

Нет. Это разные инструменты. Выбор зависит от команды, интеграций, self-hosting, бюджета, требований к контролю и поддержки.

Можно ли начать в low-code и потом переписать?

Да, это хороший путь, если прототип не маскируют под production. Сразу фиксируйте границы и данные, которые потом переедут в нормальную систему.