«Сидит у меня в Make.com эта цепочка из сорока модулей. Работала полгода — а потом один сервис поменял API, и всё посыпалось. Я открыл воркфлоу и понял: я не понимаю, как оно работает. Я его когда-то собрал, запустил и забыл. А теперь чинить — разбираться с нуля. Проще было написать скрипт на Python и не мучиться.»
Так выглядит типичная история разработчика, который подсел на no-code. Не сразу, конечно. Сначала всё красиво: мышкой навёл, мышкой кликнул — и работает. Пара минут настройки вместо часов кодинга. Кажется, что ты нашёл лайфхак. А потом проходит год, и ты понимаешь, что наделал костылей на костылях.
Почему разработчики вообще идут в no-code
Логика понятная. Пришёл заказ — нужна интеграция CRM с почтой, уведомления в Telegram, синхронизация с таблицей. Писать микросервис ради этого? overkill. Поставить n8n на VPS? надо администрировать. А тут — берёшь Make или Zapier, кидаешь модули, подключаешь аккаунты, и за десять минут готово.
Я так делал. Клиенты были довольны. И я тоже — задачу закрыл быстро, денег взял немного, зато оборот вырос. Беспроигрышная ситуация.
Но потом начинается рутина. У клиента появляется новый источник данных. Формат изменился. Нужно добавить условие — «если сумма больше 50 тысяч, отправлять одному менеджеру, если меньше — другому». И ты открываешь свой воркфлоу, смотришь на сорок модулей с названиями вроде «JSON Parse 3» и «Iterator 2» — и думаешь: где тут моя логика?
Когда ты пишешь код, у тебя функции, понятные названия, git-история. За пять минут находишь нужное место и меняешь. В no-code у тебя визуальный конструктор, где каждый блок — чёрный ящик. Видишь входы и выходы, а что внутри — загадка.
Что реально происходит с вашими воркфлоу через полгода
Конкретный пример из моей практики. Собрал автоматизацию для маркетингового агентства: заявки с сайта попадают в Google Sheets, дальше разбираются по вкладкам в зависимости от бюджета, и если бюджет больше определённой суммы — человек получает звонок от менеджера в течение часа.
Работало отлично. Полгода я вообще к этому не возвращался. А потом агентство выросло, они наняли нового менеджера, и логика сегментации изменилась. Нужно было добавить новое условие, поменять порог суммы и учитывать город клиента.
Я открыл Make. Попытался найти, где у меня условие по сумме. Оказалось — в третьем модуле, который называется «Filter 2». Фильтр срабатывает на этапе, когда данные уже прошли через два парсинга и один Lookup. Почему так — я не помнил. Помнил только, что когда-то оно работало и трогать было не нужно.
В итоге я час разбирался, добавил новое условие, случайно сломал старую логику, полчаса чинил — и в конце концов просто переписал всё на Python за вечер. С нуля. Сто строк кода — понятных, с комментариями, с версионированием.
Вот этот момент — когда ты тратишь больше времени на разбор своего же визуального воркфлоу, чем на написание кода с нуля — это и есть момент, когда no-code превращается из ускорителя в тормоз.
Замкнутый круг: быстро сделать, долго чинить
Есть ещё одна проблема, которую я заметил не сразу. No-code платформы постоянно говорят: легко автоматизировать что угодно. И это правда — легко. Но эта лёгкость создаёт опасный соблазн: автоматизировать всё подряд. Без рефлексии о том, нужно ли это.
У меня был период, когда я буквально каждую мелкую задачу пытался запихнуть в автоматизацию. Переслать сообщение из чата в чат? Zapier. Сохранять скриншоты в папку? Make. Уведомлять о новых файлах? Integromat. В итоге больше двадцати активных воркфлоу, и я перестал понимать, что где происходит.
А потом несколько сервисов одновременно поменяли тарифы. Бесплатные интеграции перестали работать. И мне пришлось перебирать все двадцать воркфлоу и выяснять, какие ещё актуальны, а какие давно дублируют друг друга.
Код так не разрастается. Файл, зависимости, импорты — всё на виду. А визуальный редактор — это куча, где каждый модуль понятен по отдельности, но общая картина размывается.
Есть ли ситуации, где no-code оправдан
Буду честен: не всё однозначно. Есть сценарии, где no-code реально экономит время. Простые вещи — связать две-три интеграции, настроить уведомления, автоматизировать рутину без сложной логики. Визуальные конструкторы отлично подходят, если автоматизацию делает не разработчик, а проджект-менеджер или маркетолог. Им не нужно лезть в код.
Но когда ты разработчик и берёшь no-code как «быстрое решение для клиента» — ты продаёшь грязный техдолг. Клиент получает чёрный ящик, который ты и сам через полгода не разберёшь. А если клиент захочет масштабировать — всё, привет, переписываем.
Я для себя выработал правило: если задача требует больше трёх условных ветвлений или связана с обработкой данных сложнее, чем «взять одно и положить в другое» — пишу код. Если это простая интеграция, которая точно не будет расти — можно взять no-code. Но честно оценивать, какая из этих ситуаций передо мной, а не хвататься за визуальный конструктор просто потому что «быстро».
Что я понял в итоге
No-code — это не зло и не панацея. Это инструмент, у которого есть своя ниша. Проблема в том, что разработчики часто берут его не из нишевых соображений, а из лени или из желания закрыть задачу побыстрее. А потом пожинают плоды в виде воркфлоу-«паутины», которую невозможно поддерживать.
Сейчас, когда ко мне приходит задача на автоматизацию, я задаю себе три вопроса. Насколько сложная логика? Будет ли это расти? Кто будет это поддерживать через год? Если хотя бы на один вопрос ответ «да» — пишу код. Если все три «нет» — можно и в конструкторе собрать.
Звучит просто, но мне потребовалось полтора года и десяток забытых воркфлоу, чтобы до этого дойти. Теперь экономлю время не на сборке, а на том, что сразу делаю правильно.
