Payload Logo

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

20 июля 2026 г.

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

Автор статьи

Александр Владимиров

Рубрика

ИИ, Разработка ПО

Время чтения

10 минут

Эволюция ИИ-инструментов от изолированных запросов к агентным системам

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

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

Параллельно развивались технологии локального инференса – программные движки, позволяющие запускать большие языковые модели непосредственно на собственном оборудовании. Среди них можно выделить llama.cpp (написан на C++, оптимизирован для consumer-grade железа), Ollama (упрощает развертывание и управление моделями) и vLLM (ориентирован на высоконагруженные сценарии, использует PagedAttention для эффективного использования памяти). Эти продукты прошли несколько циклов оптимизации, и на текущий момент скорость локальной генерации становится комфортной для интерактивной работы.

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

ИИ в разработке ПО

Витрина ИИ в Renue: от пилота к действующему инструменту

Около года назад, в мае 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-файл с шагами пользователя и ожидаемым результатом, затем за несколько итераций создает исполняемый код тестов: сначала импортирует ручные кейсы, затем генерирует локаторы элементов, а после наполняет тестовые классы и объекты страницы. Вся генерация занимает несколько минут. Агент убирает монотонную работу, а на финальной валидации остается человек, который проверяет, что сгенерированный код действительно реализует нужный сценарий тестирования. Для отработки логики работы агента на этапе эксперимента мы использовали внешнюю модель и сейчас переносим его на локальную витрину с Qwen, чтобы исключить передачу даже описательных шагов за периметр.

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

 

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

За пределами классической разработки: прототипирование и автоматизация рутины

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

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

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

Экономика и безопасность: разграничение сценариев вместо жесткого выбора


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

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

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

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

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

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

Тренды регулирования, культура и планы развития


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

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

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

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

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

Читайте также