В прошлые выходные я решил собрать маленький мультиагентный пайплайн для обработки книг в структурированные конспекты. Возьми Make и сделай это за 15 минут, говорили они. Будет просто, говорили они. Все выходные я сначала бился с Make, потом с n8n — вы знали, что надо произносить «нейтен»? Я — нет. В итоге результат на 3+ я получил, но когда прикинул, сколько ещё придётся провозиться, чтобы сделать 4+, сдался.
Сначала я думал, что проблема во мне. Недостаточно хорошо понимаю n8n, криво собрал логику, не туда положил состояние, не так описал агенту задачу, не до конца подружился с HTTP, JSON и прочими радостями no-code, который по мере взросления почему-то всё больше начинает напоминать code. В какой-то момент я уже копировал большие куски JavaScript, которые мне писала LLM-ка, внутрь code-нодов — то есть вроде пришёл в no-code, но сидишь и «пишешь» код. Ничего не понимая в коде. И когда что-то не работает, начинается длинный цикл отладки вида «зайди-выйди из приложения».
С Lovable история другая. То, что я хотел, он собрал мне минут за двадцать — со всеми интеграциями и контролем качества результата. Это и есть его сильная сторона: он не заставляет тебя лезть в технические детали, быстро даёт рабочий результат и создаёт ощущение, что между идеей и продуктом наконец-то убрали лишнюю инженерную прослойку.
Проблема начинается, когда ты хочешь не просто собрать первый вариант, а развивать систему. Пока всё просто — магия работает. Когда появляется новая ветка логики, другой формат данных, исключения и совместимость с тем, что уже было сделано, магия превращается в длинный цикл отладки, ну, вы уже поняли каким методом. Я сначала сделал парсер только для PDF, потом решил добавить TXT. Казалось бы, маленький шаг. Но дальше началась классика: добавляешь одно — перестаёт работать что-то из того, что уже работало.
Вот здесь и видно ограничение. AI-билдер может быстро построить кусок продукта, но он не всегда даёт тебе понятную модель того, что именно было построено. А если ты не понимаешь внутреннюю структуру системы, тебе сложно её развивать, отлаживать и контролировать. Ты не проектируешь изменения, а всё чаще торгуешься с машиной: попробуй так, нет, верни обратно, нет, теперь сломалось другое, давай ещё раз. А я ведь не программист. Мне не хочется заглядывать под капот системе, которую я выбрал как раз потому, что мне обещали не заставлять меня туда заглядывать.
Я полез смотреть Reddit, Hacker News, сабреддиты n8n, Lovable и похожих инструментов. Хотел найти подтверждение, что я просто недостаточно техничный. Не нашёл. Жалоба у non-engineer билдеров примерно одна и та же:
AI-нативные билдеры быстрые, но непрозрачные; workflow-тулы более инспектируемые, но быстро превращаются в визуальные спагетти из нод, условий, HTTP, JSON и кусков кода.
И мне кажется, проблема не в недостающих фичах, а в предположениях о том, кто сегодня строит софт. Большинство инструментов всё ещё живут в старой картине мира: есть инженер, который пишет код, и есть бизнес-пользователь, который двигает блоки. Но AI-агенты эту дихотомию уже сломали. Появился третий пользователь — человек, который не хочет реализовывать систему построчно, но уже должен мыслить как архитектор.
Ему нужно понимать, где проходят данные, где хранится состояние, где агент принимает решение, где нужен человеческий чекпойнт, где возможна ошибка и как её диагностировать. Это не совсем no-code и не совсем code. Это режим проектирования поведения системы.
Пока у этой категории нет устойчивого имени. Но отсутствие имени не означает отсутствие категории. Скорее наоборот: когда все уже чувствуют боль, но ещё не могут нормально назвать, что именно болит, там обычно и появляется новый рынок.
