От экспериментов к рабочему процессу

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

Опыт оказался неоднозначным: на генерации тестов инструменты показывали себя приемлемо, но при работе с функциональностью теряли контекст проекта и допускали ошибки. Разработчики часто получали результат быстрее, если писали код самостоятельно. Но без подходящих инструментов, доступа к моделям и обучения

Как рассказал Роман Засорин, руководитель направления разработки внутренних систем, дело было не только в ограничениях моделей 24-го года. Команде не хватало времени на освоение инструментов, доступа к платным моделям и централизованного обучения. Поэтому первый эксперимент не стал устойчивой частью рабочего процесса — встроить ИИ в повседневную работу не получилось.

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

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

Что показал проект в цифрах

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

По данным команды Девелоники — на фронтенд-разработку с применением ИИ ушло 235 часов при оценке ручной разработки в 600 часов. На бэкенд, в свою очередь, потребовался 361 час при оценке в 550 часов. В сумме это 596 фактических часов против 1150 часов предварительной оценки ручной разработки.Таким образом, фактические трудозатраты оказались примерно на 48% ниже расчетной оценки.

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

Как организовать работу с ИИ-агентом

Чтобы достичь эффективности такого уровня, отметил эксперт, нужно выработать систему. Александр Клюев сосредоточился на правилах, инструкциях и постановке задач. Агент начинает каждую новую сессию без полноценного знания конкретного проекта, поэтому ему нужно передать карту репозитория, сведения о технологическом стеке, архитектурные ограничения и требования к результату.

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

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

Для доступа к задачам, базе знаний и макетам используется MCP — протокол подключения ИИ-агентов к внешним инструментам и источникам данных. Он сокращает ручное копирование информации, но требует контроля прав доступа и проверки полученных данных. Потому что подключение к внешним системам само по себе не гарантирует достоверность ответа агента.

Ограничения на фронтенде и работа с существующей системой

Антон Тарганчук, фронтенд-разработчик Девелоники, в рамках доклада подсветил ограничения в своем направлении работ. Он рассказал, как проходил процесс интеграции современного React приложения в устаревший Angular. В этом случае разработчикам нужно было развивать новую функциональность, не останавливая действующую систему и не переписывая ее целиком.

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

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

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

Ошибки — не повод останавливаться

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

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

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

Главный вывод экспертов

Переход к работе с ИИ-агентами требует одновременно технической настройки и изменения привычного процесса разработки. На митапе ГК Softline специалисты разобрали этот путь с трех сторон:

• Роман Засорин — со стороны организации работы и внедрения новых инструментов;
• Александр Клюев — на примере задач бэкенд-разработки и результатов проекта;
• Антон Тарганчук — с точки зрения фронтенда и интеграции новых компонентов в существующую архитектуру.

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