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

На этом месте обычно в разговор влетает AI. Сначала в виде привычного оптимизма: сейчас дадим разработчикам кодовых ассистентов, они станут писать быстрее, и всё как‑то наладится. Проблема в том, что писать код быстрее — ещё не значит быстрее выпускать изменения. Если весь остальной процесс остался прежним, то вы просто ускорили один участок длинной очереди.

Я Илья Радченко, директор по платформенным продуктам SimpleOne. В этой статье о том, чего AI-агентам не хватает, чтобы от них была реальная польза. Разберём, какой фундамент нужен agentic‑разработке кроме самих агентов. Покажу на нашем примере, как мы использовали агентов и сократили сроки/расходы на разработку.

Разработку на монолите замедляют трения, а не код

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

• требования надо собрать и уточнить;

• задачу надо разложить на шаги;

• нужно понять, где в системе вообще вносить изменения;

• потом написать код;

• потом проверить, не сломалось ли что‑то сбоку;

• потом провести ревью;

• потом собрать, выкатить, посмотреть, как это живёт.

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

Ну тогда посадим агента вместо человека?

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

Примерно так:

• один агент помогает собрать требования;

• другой уточняет постановку;

• третий превращает её в спецификацию;

• четвёртый строит план реализации;

• пятый пишет код;

• шестой проводит код‑ревью;

• седьмой готовит тесты или прогоняет smoke‑проверки;

• дальше подключаются сборка и выкладка.

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

Есть и ограничения — agentic‑разработка всё ещё требует сильного человека в контуре. Если посадить на неё совсем неопытного специалиста и ждать, что он  одной постановкой задачи получит зрелое решение, ничего хорошего не выйдет. Чем сложнее домен, тем важнее опыт.

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

Что нужно, чтобы agentic‑разработка вообще заработала

На словах всё звучит прекрасно: сейчас сделаем команду из агентов, и жизнь наладится. Однако agentic‑разработка не существует в вакууме. Ей нужен хотя бы минимальный фундамент:

1. Трекер задач, он же доска

Если у вас несколько агентов, которые делают разные части работы, ими нужно как‑то управлять. По сути, задача должна раскладываться на карточки и подкарточки, которые можно раздавать отдельным ролям и отслеживать по стадиям. Это тот же принцип, что и у обычной команды. Только вместо аналитика, разработчика и тестировщика часть карточек получают субагенты. Без общей доски и понятного статуса вы очень быстро получите не «оркестр», а хаотичную толпу чатиков.

2. IDE и среда исполнения

Агентам мало «что‑то придумать». Им нужно где‑то писать код, проверять его, запускать, смотреть результат, возвращаться с корректировками. Поэтому у agentic‑разработки должен быть нормальный контур исполнения: IDE, runtime, сборка, интеграция с системой контроля версий. Иначе старый плохой сценарий: нейросеть сгенерировала кусок кода в чате, человек скопировал, вставил, что‑то сломал по дороге, пошёл чинить руками. Разовый эксперимент так пережить можно, но если хочется системности, копипастный вайбкодинг очень быстро начинает стоить дороже, чем кажется.

3. Доступ к данным и контексту

Агент не может принять вменяемое решение, если он не знает, что за клиент, что за задача, какой у неё приоритет, что происходит в CRM, ITSM, SDLC‑контуре и как вообще устроена текущая система.

Если хочется, чтобы агент помогал не только писать код, но и, например, приоритизировать бэклог, смотреть влияние на архитектуру или учитывать бизнес‑параметры, ему нужен доступ к этим данным. И не в формате «вот тебе 15 ссылок на Confluence, удачи».

4. MCP‑сервер и нормальный доступ агентов к инструментам

Чем больше в системе инструментов, тем дороже для агента каждое действие через голый API. Нужен слой, который позволяет не вручную разбирать каждый вызов, а работать с контекстом и функциями как с понятными инструментами. Именно поэтому в контексте agentic‑контура всё чаще обсуждают MCP — это удобный способ дать агентам стандартизированный доступ к данным, операциям и внешним системам без того, чтобы каждый раз строить велосипед на уровне интеграций. Мы, кстати, уже рассказывали, как это работает на платформе SimpleOne.

Как Low-code платформа сделает агентную разработку дешевле

Где вообще всё это удобно собирать? Теоретически — где угодно, например, GitHub + Jira + свой MCP-сервер. Практически — чем больше в сценарии компонентов, тем сильнее хочется, чтобы они уже жили в одном месте.

И тут Low‑code платформа неожиданно оказывается хорошим фундаментом. В нормальной Low‑code платформе уже есть:

• модель данных;

• бизнес‑логика;

• интерфейсы;

• процессы;

• среда исполнения;

• доступ к прикладным данным;

• интеграционный слой.

То есть большая часть того, что для agentic‑подхода нужно склеивать вручную в обычном стеке, уже лежит рядом. Так у агентов появляется единая среда, в которой проще ориентироваться. Не надо каждый раз прыгать между пятью репозиториями, тремя админками, отдельным рантаймом и внешним интеграционным комбайном.

Low-code не заставляет отказываться от разработки, но дает возможность сделать мост между No-code для самых простых сценариев и Pro-code для сложных. Для agentic‑разработки это идеально. Почему? Потому что не все задачи одинаковые: где‑то достаточно быстро собрать процесс и интерфейс, где‑то нужно написать более сложную логику, где‑то нужен полноценный код и тонкая настройка поведения. На Low‑code платформе разработчику не нужно каждый раз выбирать между двумя крайностями: «или визуальный конструктор для детей, или суровый enterprise‑стек с тремя неделями на настройку». Порог входа в сложную автоматизацию становится ниже, а переход к более серьёзному сценарию — мягче.

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

По сути, Low‑code платформа даёт agentic‑разработке то, без чего она быстро вырождается: среду с памятью (платформа знает свою модель данных и помнит прошлые решения, а агент этим пользуется), встроенным контекстом и более коротким путём от постановки задачи к рабочему результату. Это дешевле не по лицензии, а по трению. Когда говорят «дешевле», многие сразу спорят про стоимость платформы, токенов, железа и лицензий. Но основной выигрыш часто в другом:

• меньше ручных переключений;

• меньше копипаста между инструментами;

• меньше ошибок на стыках;

• меньше времени на сборку производственного контура;

• меньше когнитивной нагрузки на команду.

Да, вычисления стоят денег. Да, токены дорожают. Да, если бездумно делать агента‑разработчика, можно получить дорогую игрушку. Но если у вас уже есть платформа, которая закрывает значительную часть инфраструктурных потребностей, то стоимость agentic‑сценария снижается просто за счет меньшего числа лишних движений.

Мы уже попробовали реализовать полный цикл разработки с помощью агентов на базе технологической платформы SimpleOne, вот что получилось:

Кейс 1: дашборд upstream / downstream задач

Задача: собрать дашборд, который показывает потоки задач по командам разработки — upstream (что поступит в работу) и downstream (что уже в производстве). Цель — дать менеджерам и техлидам визуальный инструмент с фильтрами, сортировками и дополнительными алгоритмами.

Что построили:

• Виджет-дашборд upstream/downstream: серверный и клиентский скрипт, шаблон, стили, локализация (RU/EN), портальная страница.

• Настраиваемые типы задач: декомпозиция историй под фичами + отдельные потоковые колонки.

• Диалог настроек с конструктором условий; ленивая загрузка — открытие ускорено с ~12 с до ~1 с.

• Портируемость между стендами (устойчивость к разным схемам данных); развернут на двух стендах.

• Фильтры (продукты active^public, команды), превью-попап и модалка записи фиксированного размера.

Если бы делали классическим путём (экстраполяция):

А вот как по нашим расчётам может выглядеть разработка с помощью агентов:

Теперь подробнее про процесс:

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

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

По плану работают агенты‑разработчики. Они создают код компонентов, формируют запросы к данным, настраивают фильтры и сортировки. Агент‑ревьюер проверяет: смотрит на структуру кода, оценивает корректность использования API платформы, разбирает потенциальные проблемы с поддерживаемостью. Инфраструктурный агент отвечает за техническую часть завершения работы, то есть собирает модуль, запускает сборку, выкатывает дашборд на нужный стенд.

Все шаги опираются на платформу через MCP‑слой поверх её API и интеграций. Агенты получают доступ к данным и функциям как к описанным инструментам: им не нужно вручную конструировать запросы к каждому сервису, они работают с моделью задач, статусов и потоков, которая уже существует в системе.

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

Кейс 2: мультискоринг бэклога

Задача — расширить модули SDLC и ITSM на платформе через скоринг элементов бэклога: собрать параметры из разных источников (CRM, ITSM, техблок), оценить экономическое и техническое влияние задачи, и на основе этого ранжировать дефекты и фичи. Идея — превратить очередь задач во взвешенный список, где приоритизация строится на данных.

Что построено:

• 3 модели скоринга по типам (дефекты · истории · фичи), сведённые к общей шкале 0–10;

• движок из 4 Script Include (агрегатор, оркестратор, парсер формул, валидатор);

• экономическое влияние по обращениям + голоса + широта спроса по компаниям;

• вторая ось: технический риск (дефекты/истории) и бизнес-влияние с экспертной оценкой PO (фичи);

• 4 усилителя: критическая уязвимость, критический инцидент клиента A, топ-клиент (A + топ-3), фича-активатор;

• перцентильная калибровка соизмеримости типов;

• массовый пересчёт ~6 400 активных записей + авто-пересчёт при изменениях;

• формы, чек-листы, человеко-читаемый разбор оценки; ~14 инкрементов + 17 авто-проверок.

Аналогичную подсистему «с нуля» делает команда из нескольких ролей, не один разработчик:

Happy-path от постановки до рабочего результата оцениваем так:

Сам процесс разработки получается таким:

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

Архитектурный агент собирает из этого модель: какие источники данных использовать для каждого признака, как совместить бизнес‑параметры из CRM и ITSM с техническими параметрами из SDLC, какой формат результата удобен для команд разработки и сопровождения, как интегрировать скоринг в существующие экраны. На основе плана агенты‑разработчики реализуют вычисления, формируют обращения к данным платформы, связывают результаты с интерфейсом.

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

При этом за кулисами каждой задачи работает не один ИИ‑агент, а пара: один создаёт решение, второй придирчиво его проверяет. Второго мы называем скептиком. Он смотрит работу на каждом шаге — от формулировки задачи до готового кода — и выносит вердикт: пропустить или вернуть на доработку.

Скептик проверяет не красоту кода, а суть:

• решает ли код именно ту задачу, которую поставили (а не похожую);

• нет ли логических дыр, забытых сценариев и противоречий с исходным замыслом;

• соблюдены ли правила платформы и не пострадает ли производительность.

Например, в этом кейсе агент по ошибке начал занижать клиентов‑партнёров, по умолчанию считал их «второсортными». Скептик заметил, что это противоречит правилу «реальная категория клиента всегда в приоритете», и завернул решение, пока ошибку не устранили. Такое легко пропустить глазами и тестами: код-то рабочий, просто считает не то. По логам проекта скептик заворачивает больше около 58% черновиков. Рутинные огрехи он отсеивает и правит сам, а человеку выносит не список багов, а только осмысленные развилки.

Как и в первом кейсе, доступ к данным идёт через MCP‑слой. Агенты работают не с наборами URL, а с сущностями клиентов, обращений, проблем, задач и архитектурных элементов, описанными в платформе. Это позволяет строить многомерный скоринг на живых данных, не на ручной выгрузке.

Инфраструктурный агент завершает цикл: собирает модуль скоринга, выкатывает его в рабочий SDLC‑контур. После этого механизм живёт внутри платформы. Команда открывает интерфейс, видит задачи бэклога с уже рассчитанным приоритетом, можно фильтровать, сортировать, принимать решения по очереди. Система работает на актуальных записях CRM, ITSM и SDLC; пересчёт идёт по правилам, заложенным в коде. Агентный контур в этом кейсе отвечает за проектирование, реализацию, проверку и внедрение, а дальше приоритизация функционирует как обычная часть продукта.

Результат

• Система мультискоринга, встроенная в SDLC и ITSM-контур, которая работает по живым данным.

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

Что из этого следует

Если коротко, то картина такая.

• Классическая разработка в тяжёлых системах слишком медленно доводит гипотезу до проверки.

• Простые AI‑ассистенты ускоряют отдельные операции, но не меняют процесс целиком.

• Agentic‑разработка меняет саму механику SDLC: разработчик становится оркестратором, а часть производственной работы берут на себя агенты.

• Для этого нужен не только AI, но и полноценная среда: доска задач, IDE, runtime, данные, интеграции, MCP.

• Low‑code платформа оказывается удобным местом для такой модели, потому что объединяет всё это в одном контуре.

• На выходе команда получает более дешёвый, удобный и быстрый путь от идеи до работающего результата.

• Вопрос уже в том, где разворачивать ИИ-агентов так, чтобы они действительно приносили пользу и не тратили баснословные суммы.

***

Готовы ли вы доверить агентам весь цикл разработки?