Современный ИИ уже неплохо справляется с разработкой бизнес-автоматизаций. Можно описать процесс словами, дать агенту доступ к n8n или исходному коду, подключить документацию — и через некоторое время получить готовую цепочку из триггеров, API-запросов, условий и преобразований данных. То, на что раньше интегратор тратил несколько часов, теперь иногда действительно собирается за минуты.
Проблема начинается позже, когда первый вариант почти работает, но в одном месте приходит не то поле, другой сервис возвращает неожиданную структуру ответа, а третий этап не принимает результат предыдущего. Агент добавляет преобразование, затем ещё одну проверку, после неё появляется отдельная ветка обработки, и через несколько итераций автоматизация наконец начинает выполнять задачу. Только к этому моменту она уже может состоять из такого количества промежуточной логики, что человеку проще заново понять исходный бизнес-процесс, чем разобраться, зачем понадобился каждый из добавленных узлов.
Именно такую ситуацию недавно описывал разработчик, использующий Claude Code для создания сложных сценариев n8n. По его словам, модель хорошо составляла первоначальный план и довольно быстро собирала рабочую основу, но последовательное исправление небольших ошибок приводило к разрастанию схемы. В какой-то момент автору приходилось самому упрощать получившийся процесс, после чего тот начинал работать устойчивее. В обсуждении другие разработчики независимо пришли к похожему выводу: чем хуже заранее определены границы между этапами и структура передаваемых данных, тем легче агенту превратить локальные исправления в постоянную часть архитектуры.
Это хороший пример более общей проблемы. ИИ резко снижает стоимость добавления нового кода, узла или условия, но дешёвое добавление логики не означает дешёвую систему.
Почему локальное исправление может ухудшить весь процесс
Представим простую автоматизацию обработки заявки с сайта. На вход поступают имя клиента, телефон, электронная почта и текст обращения. Система должна проверить данные, создать сделку в CRM и уведомить менеджера. В первоначальной версии всё выглядит достаточно просто, пока не выясняется, что один источник называет номер телефона "phone", другой — "phone_number", а третий передаёт его внутри вложенного объекта "contact".
Можно исправлять каждую новую ситуацию непосредственно перед тем узлом, где возникает ошибка. Тогда рядом с CRM появится одно преобразование, потом второе, затем дополнительное условие для заявок без телефона и ещё один блок для приведения данных к нужному формату. Все эти решения по отдельности выглядят разумно и действительно устраняют конкретные сбои.
Но через некоторое время архитектура начинает отражать не устройство процесса, а историю его ремонта.
Более устойчивое решение в таком случае — один раз определить внутренний формат заявки и приводить все внешние источники к нему на входе. Тогда дальнейшие этапы работают уже не с особенностями Gmail, формы сайта или внешнего API, а с единым набором полей. Если позже добавится новый источник, изменится только входной адаптер, а не половина сценария.
Человек способен совершить ту же ошибку. Проблема не уникальна для ИИ. Но агенту намного дешевле добавить ещё один промежуточный шаг, чем человеку, поэтому неудачная архитектура может очень быстро обрасти вполне работающими костылями.
Агент решает ту проблему, которую ему показали
У языковой модели обычно есть локальный контекст: конкретный узел завершился ошибкой, поле не передалось, API вернул неожиданный ответ. Естественная реакция — исправить именно это место. Однако причина может находиться несколькими этапами раньше, и тогда очередной локальный патч только скрывает её.
Поэтому после нескольких последовательных исправлений полезно перестать спрашивать агента, как устранить следующую ошибку, и поставить другую задачу: пересмотреть весь путь данных и объяснить, почему эта ошибка вообще стала возможна. Иногда правильным результатом такого анализа оказывается не новый узел, а удаление трёх старых и изменение одной общей структуры.
Это одна из важных особенностей разработки с ИИ. Модель очень хорошо производит решения, но ей нужно явно разрешать пересматривать уже сделанное. Иначе система естественным образом растёт только в одну сторону — за счёт добавления новой логики.
Контракты между этапами уменьшают пространство для импровизации
Одна из наиболее практичных рекомендаций из обсуждения разработчиков — заранее определять структуру данных между основными этапами автоматизации. Это обычный инженерный подход, но при работе с агентами он становится особенно полезным.
Если первый этап получает письмо, можно сразу договориться, что дальше по системе передаются адрес отправителя, тема, основной текст и список вложений. Неважно, откуда именно пришло письмо — из Gmail, Outlook или собственного почтового сервера. Особенности внешнего источника должны закончиться на границе интеграции.
То же самое относится к результатам обработки моделью. Если классификатор должен вернуть категорию обращения, уровень уверенности и признак передачи человеку, эти поля лучше определить заранее. Тогда следующий этап не зависит от того, как модель решила оформить ответ в конкретном запуске.
Такие контракты не только упрощают разработку. Они позволяют тестировать части процесса независимо друг от друга. Если вход и ожидаемый выход известны, можно быстро понять, какой компонент действительно сломался, вместо того чтобы запускать всю цепочку и наблюдать, где ошибка проявится в последний раз.
Сначала полезно построить один прямой маршрут
ИИ провоцирует сразу просить слишком много. Если компания хочет автоматизировать обработку входящих заявок, возникает желание одним заданием получить готовую систему: забрать письмо, определить клиента, проверить CRM, классифицировать обращение, создать сделку, отправить ответ, уведомить менеджера, обработать ошибки и записать всё в журнал.
Современный агент действительно способен собрать такую схему. Проблема в том, что при первом сбое одновременно появляется слишком много возможных причин.
Практичнее сначала провести одну тестовую заявку от входа до простого и хорошо проверяемого результата. Получить сообщение, привести его к установленной структуре и записать в тестовую таблицу. После этого подключить CRM, затем уведомления, затем обработку исключений. Такой подход выглядит медленнее только в первые полчаса, зато дальше каждая ошибка возникает внутри уже понятного участка системы.
Один из участников обсуждения описывал работу над автоматизацией примерно из сорока узлов именно таким образом: сначала проверять отдельные API и минимальные цепочки, а затем постепенно добавлять функциональность. Он потратил на процесс около двух дней, но не пытался заставить агента сгенерировать окончательный вариант за один проход.
Для бизнес-автоматизации это особенно важно, потому что внешние сервисы часто ведут себя менее аккуратно, чем тестовая среда.
«Проверь, что работает» — плохой критерий
Агент может запустить сценарий и увидеть зелёные статусы всех узлов. Это ещё ничего не говорит о том, произошло ли в бизнес-системе именно то, что ожидалось.
Лучше заранее подготовить контрольный пример. Например, тестовая заявка должна принадлежать существующей компании «Альфа», содержать определённый номер телефона и создавать ровно одну сделку с конкретным ответственным. Повторная отправка того же события не должна создавать вторую сделку.
Теперь проверка становится предметной. Система не просто завершилась без исключения, а создала именно ту запись, которая ожидалась.
Чем критичнее процесс, тем важнее проверять финальное состояние, а не технический успех отдельных операций. CRM вполне может вернуть успешный ответ, но сохранить не все поля. Письмо может быть отправлено, но не тому получателю. Документ может быть обработан, но сумма оказаться записана в неправильное поле. Все узлы при этом останутся зелёными.
Настоящие ошибки начинаются после красивой демонстрации
Тестовая автоматизация обычно получает аккуратные данные и работает с доступными сервисами. Реальный бизнес-процесс устроен иначе. Иногда отсутствует обязательное поле, API отвечает слишком долго, авторизация внезапно истекает, webhook приходит дважды, внешняя система принимает запрос, но падает до завершения собственной операции.
Поэтому перед запуском нужно проверять не только нормальный сценарий, но и сбои. Что произойдёт, если CRM недоступна? Можно ли безопасно повторить операцию? Не появится ли дубль? Сохранится ли исходная заявка для повторной обработки? Получит ли ответственный сотрудник понятное уведомление?
Именно здесь обычно проходит граница между демонстрацией и промышленной автоматизацией. Соединить несколько API между собой сегодня действительно может ИИ. Сделать так, чтобы процесс предсказуемо переживал отказы, гораздо сложнее.
ИИ не обязательно должен находиться внутри самой автоматизации
Если процесс создаётся с помощью ИИ, возникает естественное желание использовать модель и внутри него. Но многие операции лучше оставить обычному коду.
Проверка наличия обязательного поля не требует языковой модели. Сравнение числа с порогом тоже. Поиск записи по точному идентификатору, повтор запроса после временного сбоя или проверка формата даты выполняются детерминированно и намного проще тестируются.
ИИ полезен там, где есть неопределённость: нужно понять смысл письма, разобрать нестандартный документ, классифицировать неоднозначное обращение или подготовить текст. После этого результат снова можно передать обычной программе, которая проверит обязательные поля и выполнит разрешённое действие.
Такая архитектура обычно надёжнее, чем один универсальный агент, который одновременно понимает запрос, принимает решение, вызывает нужный сервис и сам же оценивает, получилось ли.
В этом нет противоречия. ИИ вполне может быть отличным инструментом для разработки автоматизации, в которой большая часть рабочей логики остаётся обычной программой.
Сложность проявляется не при создании, а при следующем изменении
Во время первоначальной разработки практически любую схему можно довести до рабочего состояния. Реальная стоимость архитектуры становится заметна позже, когда меняются требования.
Допустим, компания переходит на другую CRM. В хорошо спроектированной системе заменяется один слой интеграции, а внутренний формат заявки остаётся прежним. После этого запускаются готовые тесты, и можно достаточно быстро убедиться, что процесс работает.
В плохой архитектуре особенности конкретной CRM оказываются размазаны по множеству узлов, условий и промптов. Тогда изменение одного внешнего сервиса требует разбирать весь сценарий. Даже если первоначальную версию ИИ собрал за час, дальнейшее сопровождение может стоить значительно дороже.
Поэтому полезная метрика сложности — не количество узлов и не объём кода, а стоимость безопасного изменения.
Насколько быстро новый разработчик понимает процесс? Сколько компонентов приходится менять при небольшом изменении требований? Есть ли тесты, которые показывают, что старые функции не сломались? Можно ли заменить внешний сервис без полной переделки цепочки?
Эти вопросы намного ближе к реальной стоимости владения автоматизацией.
ИИ позволяет быстрее создавать технический долг
Раньше плохая архитектура хотя бы требовала времени на реализацию. Нужно было написать функцию, проверить её, добавить новую ветку, соединить всё вместе. Это не останавливало разработчиков от костылей, но создавало естественную цену каждого дополнительного решения.
ИИ эту цену резко снизил.
Новый узел появляется за секунды, функция преобразования — почти мгновенно, а крупный участок логики можно полностью переписать за несколько минут. При хорошей архитектуре это огромный выигрыш. При плохой — способ очень быстро построить систему, в которой никто не понимает происхождение половины логики.
Поэтому в работе с ИИ рефакторинг становится не косметической процедурой, которую можно отложить на потом, а частью основного цикла разработки. После нескольких крупных изменений стоит специально анализировать, что можно удалить, какие преобразования повторяются и не появилось ли несколько разных решений одной и той же задачи.
Полезный вопрос к агенту иногда звучит не «что ещё добавить?», а «какую часть этой системы теперь можно убрать без потери функциональности?».
Хорошие автоматизации часто выглядят скучно
Зрелый бизнес-процесс редко производит сильное впечатление на демонстрации. Данные поступили, прошли проверку, преобразовались в установленный формат, сохранились в нужной системе. При ожидаемом временном сбое операция повторилась, при неожиданной ошибке появилась запись в журнале и уведомление ответственному.
В другом обсуждении пользователь описывал небольшую автоматизацию, которая переносит сведения о заказах из общего почтового ящика в таблицу и отправляет уведомление в рабочий канал. По его словам, она работает около шести месяцев без необходимости вмешательства. До этого тот же человек пытался создать значительно более сложный сборщик потенциальных клиентов с сайтов, который постоянно ломался после изменений структуры страниц.
Это не исследование и не доказательство того, что маленькие процессы всегда лучше больших. Но разница в количестве внешних предположений очевидна. Почтовый API имеет определённый контракт. Веб-страница, которую никто не обещал сохранять неизменной, может поменяться в любой момент.
Поэтому автоматизацию стоит упрощать не ради эстетики. У каждого лишнего внешнего допущения появляется собственная вероятность отказа и стоимость сопровождения.
ИИ полезнее всего там, где заканчиваются строгие правила
Показательный пример — автоматизация для небольшого ресторана, где актуальное предложение обновляется по фотографии доски. Вместо того чтобы заставлять сотрудников открывать административную панель сайта, процесс начинается с привычного действия: человек фотографирует меню.
ИИ нужен для того, чтобы распознать и структурировать неаккуратный визуальный ввод. После этого результат отправляется сотрудникам ресторана на проверку, и только согласованные данные попадают на сайт.
Здесь модель решает ограниченную задачу, для которой обычные правила действительно неудобны. А всё, что можно сделать предсказуемо — согласование, хранение, публикация — остаётся обычной автоматизацией.
Такие системы намного проще контролировать, чем универсального агента, которому дают фотографию и право самостоятельно определить, что изменить на сайте, как сформулировать текст и когда его опубликовать.
Как я бы подходил к разработке такой системы
Перед первым промптом имеет смысл описать сам процесс: какие данные поступают на вход, какой результат должен получить бизнес, какие ошибки допустимы, какие действия необратимы и в каких случаях решение должен принимать человек. После этого процесс разбивается на относительно независимые этапы с понятными входами и выходами.
Первый рабочий вариант должен быть максимально коротким и покрывать основной сценарий. Реальные исключения добавляются после того, как основная цепочка уже работает и покрыта тестами. При этом исключения стоит брать из фактических данных компании, а не генерировать десятки гипотетических веток «на всякий случай».
Для критичных этапов нужны контрольные примеры с заранее известным результатом. Для всей цепочки — несколько сквозных тестов. И только после этого систему имеет смысл подключать к рабочим CRM, почте, бухгалтерии или сайту.
ИИ при таком подходе действительно сильно ускоряет разработку, но не подменяет архитектуру.
Что измерять после запуска
Если компания проводит пилот, недостаточно показать, что автоматизация смогла один раз выполнить задачу. Стоит измерять весь процесс в течение хотя бы нескольких недель: сколько операций проходит без вмешательства, сколько требуют проверки, сколько завершаются ошибками, сколько времени уходит на устранение проблем и как часто приходится привлекать разработчика.
Отдельно стоит считать стоимость одного корректно завершённого результата. Если автоматизация обрабатывает тысячу операций почти бесплатно, но каждую неделю требует несколько часов специалиста для восстановления после нестандартных ситуаций, эти часы являются частью её себестоимости.
Иногда решение, которое агент создал за час, оказывается хуже решения, на которое разработчик потратил два дня, но потом почти не возвращается к нему. Первоначальная скорость разработки и итоговая экономическая эффективность — разные показатели.
Чем лучше ИИ пишет код, тем важнее архитектура
Кажется, что развитие моделей постепенно уменьшает значение технической реализации. Бизнес формулирует желаемый результат, а агент сам разбирается с API, форматами данных, условиями и ошибками.
Частично так и происходит. Но одновременно возникает противоположный эффект: когда реализация становится дешёвой, цена неправильного решения увеличивается. Теперь плохую архитектурную идею можно воплотить не за неделю, а за час — быстро, последовательно и во множестве деталей.
Поэтому качество автоматизации всё меньше определяется тем, способен ли ИИ написать нужный код. С этим он справляется всё лучше. Намного важнее другое: понятна ли архитектура, можно ли независимо проверить каждый этап, легко ли заменить внешний сервис, переживает ли процесс ошибки и сможет ли другой специалист через полгода понять, как всё устроено.
Если после десяти итераций агент построил огромную работающую схему, а опытный разработчик посмотрел на неё, удалил треть компонентов и система стала проще и устойчивее, это не обязательно означает, что ИИ плохо программирует.
Скорее наоборот: он научился писать настолько быстро, что теперь особенно важно вовремя остановить генерацию и проверить, не превратилась ли скорость разработки в скорость накопления сложности.
