Какие пределы использования ИИ в заказной разработке ПО

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

Антон, расскажите, как за последние полгода изменились инструменты ИИ для разработчиков? И что такое ИИ-агенты?

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

Параллельно развивались технологии локального инференса — программные движки, позволяющие запускать большие языковые модели непосредственно на собственном оборудовании. Среди них можно выделить llama.cpp, Ollama и vLLM. Эти продукты прошли несколько циклов оптимизации, и на текущий момент скорость локальной генерации становится комфортной для интерактивной работы.

На нашем кластере, построенном на потребительских видеокартах Nvidia RTX 3090 (по 24 ГБ памяти), мы достигли скорости порядка 100 токенов в секунду при работе с квантованными 4-битными версиями моделей Qwen 3.5 и Qwen 3.6 (архитектура MoE). Это значение получено на синтетических тестах и справедливо для легкой нагрузки, при параллельной обработке нескольких запросов пропускная способность снижается. Тем не менее такая производительность позволяет использовать в Витрине ИИ Ренью локальные модели как основу для регулярной работы в агентных сценариях.

Что такое Витрина ИИ, как она поивилась и развивалась в компании?

Чуть больше года назад, в мае 2025-го, мы запустили пилотный проект «Витрина ИИ» — внутренний веб-интерфейс, предоставляющий сотрудникам доступ к набору генеративных моделей. Проект изначально рассматривался как попытка системно встроить AI-powered подход во все ключевые практики компании — от разработки и тестирования до работы с документацией и коммуникаций. Требовалось определить потенциальный масштаб внедрения, оценить эффект на производительность и выявить ограничения в соответствии с действующими политиками информационной безопасности и конфиденциальности.

В пилоте приняли участие 37 сотрудников разных ролей: разработчики, тестировщики, аналитики, менеджеры проектов и офисные специалисты. По итогам пяти месяцев был собран пул из 44 подтвержденных кейсов использования. Абсолютное большинство участников (92%) в качестве главного эффекта назвали экономию времени. Активные пользователи, применявшие витрину несколько раз в неделю или ежедневно, в среднем экономили 3–4 часа в неделю, а на отдельных задачах — до 8–10 часов.

Сейчас витрина — это действующий сервис, интегрированный в рабочие процессы. Ее архитектура построена на базе Open Web UI — опенсорсного решения, которое предоставляет единый чат-интерфейс для подключения как внешних коммерческих моделей через OpenRouter (Google Gemini, Anthropic Claude, OpenAI, DeepSeek и другие), так и локально развернутых open-source моделей. Маршрутизация запросов реализована таким образом, чтобы в зависимости от класса задачи и уровня чувствительности данных направлять их либо в облако, либо в локальный контур.

За прошедшие месяцы локальный кластер был обновлен. На смену ранним версиям Qwen пришли более свежие Qwen 3.5 и Qwen 3.6 с 27 и 35 млрд параметров в 4-битном квантовании. По внутренним оценкам, качество генерируемого кода и аналитических ответов этих моделей примерно соответствует уровню коммерческих аналогов полугодовой давности. Витрина получила ряд функциональных расширений: поддержку загрузки и анализа документов, аудиоввод и аудиовывод, генерацию изображений через подключенные внешние модели, а также возможность сохранения ответов в форматах docx и xlsx. Были оптимизированы OCR-движок и RAG-поиск по большим документам. Некоторые инженеры используют локальную модель для автодополнения кода и рефакторинга через плагины к IDE — в частности, Continue для VS Code и IntelliJ IDEA, подключенный к API нашей же витрины.

Какие бизнес-задачи вы уже решаете с помощью агентного подхода и как это технически устроено?

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

Техническим фундаментом для этого стали так называемые MCP-серверы (Model Context Protocol) — специализированные сервисы-посредники, предоставляющие агенту унифицированный интерфейс к конкретной системе. В наших экспериментах такой подход позволил протестировать несколько рабочих сценариев, которые раньше требовали ручного выполнения или написания отдельных скриптов.

Первый сценарий — автоматизация работы с трекером задач. Инженер настроил связку из локальной модели и тестового стенда YouTrack. Агент получает на вход текстовое описание эпика (например, «добавить endpoint для экспорта отчетов») и через MCP-сервер создает в трекере набор связанных задач, самостоятельно подбирая исполнителей, теги и параметры. Ручная декомпозиция подобного объема заняла бы ощутимое время; агент выполняет ее за десятки секунд. Планируется развернуть аналогичную связку на продуктивном YouTrack.

Второй сценарий — оптимизация SQL-запросов. Агент получает на вход сложный запрос, находит в тестовой базе данных все релевантные таблицы, при необходимости создает их копии и наполняет синтетическими данными, выполняет исходный запрос, затем в несколько итераций генерирует альтернативный оптимизированный вариант, выполняет его и сравнивает результаты, пока они не сойдутся с ответом на изначальный запрос. Финальный отчет содержит описание внесенных изменений и сравнение времени выполнения. Сценарий был реализован на PostgreSQL и локальной модели Qwen 3.5.

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

Четвертый сценарий из нашей практики — генерация UI-автотестов. Написание автотестов вручную требует много времени на однотипные операции: поиск локаторов, реализацию модели объектов страницы (Page Object Model), связывание шагов. При этом сам процесс хорошо формализуем, есть четкие правила, по которым действует тестировщик. Мы описали эти правила в виде последовательности промптов. Агент получает на вход Excel-файл с шагами пользователя и ожидаемым результатом, затем за несколько итераций создает исполняемый код тестов: сначала импортирует ручные кейсы, затем генерирует локаторы элементов, а после наполняет тестовые классы и объекты страницы. Вся генерация занимает несколько минут, а тестировщик подключается только на финальной валидации.

Для реализации этих и других агентных сценариев мы развернули локальную версию опенсорсного агента, архитектура которого восходит к Claude Code от Anthropic. Агент работает в связке с локальной моделью Qwen 3.5, развернутой на наших видеокартах. Возможность легко подключать локальную модель к различным агентным системам обеспечивается использованием Open WebUI в качестве прокси для взаимодействия с моделями. Поскольку инференс происходит на собственной инфраструктуре, ограничения по стоимости токенов, характерные для коммерческих API, отсутствуют — это позволяет запускать ресурсоемкие агентные сценарии без оглядки на накладные расходы.

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

А где-то еще, кроме классической разработки, вы применяете ИИ-инструменты?

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

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

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

Как вы разделяете сценарии с точки зрения экономики и безопасности? Где используете облако, а где — локальные модели?

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

Для задач, не связанных с конфиденциальной информацией (поиск по открытой документации, генерация текстовых материалов, быстрые консультации по синтаксису или архитектурным паттернам), запросы маршрутизируются к внешним быстрым моделям, таким как Google Gemini Flash или DeepSeek. Причина: высокая скорость ответа при минимальных затратах.

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

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

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

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

Какие регуляторные тренды вы видите и как они влияют на ваши планы? И как вообще меняется культура работы с ИИ внутри компании?

Параллельно с технологической эволюцией формируется и нормативная база. В марте 2026 года на публичное обсуждение был вынесен проект федерального закона «Об основах государственного регулирования сфер применения технологий искусственного интеллекта в Российской Федерации». Документ вводит понятия «суверенных» и «национальных» больших фундаментальных моделей, предполагает создание реестра доверенных моделей и устанавливает, что к применению в государственных информационных системах и на значимых объектах КИИ будут допускаться только модели, включенные в этот реестр. Хотя законопроект в текущей редакции не принят, его содержание задает направление, к которому рынку имеет смысл готовиться заранее. Компании, уже вложившиеся в собственную инфраструктуру локального инференса, окажутся в более выигрышной позиции по сравнению с теми, кто полностью зависит от облачных решений.

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

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

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