ИСПОЛЬЗОВАНИЕ НЕЙРОСЕТЕЙ В ПРОЦЕССЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

THE USE OF NEURAL NETWORKS IN THE SOFTWARE DEVELOPMENT PROCESS

Bulatovich Alexander Vladimirovich

Master's graduate, Federal State Budgetary Educational Institution of Higher Education «Omsk State Transport University», Russia, Omsk

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

Abstract. The article considers the use of neural networks in the software development process from the point of view of systems analysis. The primary application scenarios for the neural networks currently in use–specifically Large Language Models (LLMs)–are examined: LLM, methods of integration into the software life cycle, and risks related to quality, security and overreliance are described. The article proposes a methodology for evaluating the implementation of AI in the software development process.

Ключевые слова: большие языковые модели, разработка программного обеспечения, системный анализ, генерация кода, тестирование, DevOps, безопасность ПО, агентные системы.

Keywords: large language models, software development, systems analysis, code generation, testing, DevOps, software security, agent systems.

Процесс разработки программного обеспечения динамически менялся на всём протяжении его существования. Изначально программы для ЭВМ писались на самом низком уровне, в том числе на уровне бинарных команд, машинного кода.

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

В последние годы разработка ПО начала меняться ещё более кардинально, не только за счет появления новых языков программирования или фреймворков, а за счет появления инструментов, которые частично берут на себя интеллектуальные операции разработчика. Это меняет саму парадигму программирования, оставляя разработчику место проектировщика программы на человеческом языке.

Большие языковые модели (LLM, Large Language Models) перестали быть обычными чат-ботами, генерирующими текст. В контексте программной инженерии они стали использоваться для написания фрагментов кода, объяснения чужих модулей, подготовки тестов, поиска ошибок, генерации документации, а также для поддержки DevOps-процессов [2], [3].

За 4 года активной фазы популяризации LLM (начало популярности больших языковых моделей и чат-ботов на их основе приходится на 2022-2023 годы с выходом Chatgpt от OpenAI), нейросетевые модели LLM становятся важной составляющей процесса разработки, всё больше приближаясь к самостоятельному разработчику начального уровня.

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

Первые сильные результаты в генерации программного кода были связаны с моделями, обученными на больших массивах исходного кода. В работе M. Chen и соавторов была представлена модель Codex, а также набор HumanEval для оценки функциональной корректности решений, создаваемых из описания задачи [1]. В дальнейшем область стала быстро развиваться: появились инструменты автодополнения, чат-интерфейсы в IDE, агенты, способные работать с репозиторием, и специализированные модели, ориентированные на исправление реальных задач из GitHub.

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

Отдельного внимания заслуживает метод RAG (Retrieval-Augmented Generation), то есть генерация ответа с предварительным поиском релевантных фрагментов во внутренней базе знаний. В разработке ПО это может быть поиск по репозиторию, wiki, требованиям, OpenAPI-спецификациям, логам, тестам и прошлым pull request. Преимущество RAG состоит в том, что модель получает не общий абстрактный контекст из обучения, а конкретные материалы проекта. Это снижает вероятность галлюцинаций и позволяет давать ответы, которые ближе к реальной архитектуре.

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

Обзор J. Liu и соавторов показывает, что LLM-агенты уже рассматриваются как отдельная парадигма для задач программной инженерии, поскольку они расширяют модель возможностью использовать внешние ресурсы и работать в цикле обратной связи [5].

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

Codex от OpenAI и Claude Code от Anthropic – это два ведущих агента для разработки ПО. Они, в отличие от продуктов чат-ботов одноимённых компаний, могут решать сложные задачи, итеративно получая обратную связь от интерфейсов. С настроенными определённым способом ролями агентов и выбранной методологией, это позволяет создать полноценные студии разработки с минимальным количеством работников.

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

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

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

Безопасность является одной из главных проблем при использовании LLM. OWASP выделяет для LLM-приложений такие классы рисков, как prompt injection, insecure output handling, training data poisoning, sensitive information disclosure, excessive agency и overreliance [7]. Для разработки ПО эти риски проявляются очень конкретно. Например, модель может получить вредоносную инструкцию из текста issue или README-файла, получить её из интернета в процессе поиска и затем предложить опасное действие. Также модель может сгенерировать команду, которая изменяет файлы шире, чем требуется задачей.

В 2025 году OWASP также выделила риски для Model Context Protocol (MCP), поскольку современные агенты все чаще подключаются к инструментам, репозиториям, файловым системам и внешним сервисам [8]. В этом случае проблема уже не только в качестве ответа, а в том, что агент может выполнить действие. Для программной инженерии это особенно важно, потому что агент с доступом к репозиторию, CI/CD или облачной инфраструктуре должен работать по принципу минимальных прав. Ему не нужен полный доступ ко всем системам, если задача ограничена исправлением одного модуля.

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

Для оценки таких систем используются не только классические тесты наподобие HumanEval, где нужно написать функцию по описанию, но и более приближенные к реальной разработке бенчмарки. SWE-bench оценивает способность модели исправлять реальные задачи из GitHub-репозиториев: системе дается кодовая база и issue, а результатом должен быть patch, устраняющий проблему [4], [6].

Автором предлагается методика пилотной оценки внедрения ИИ в организации – эксперимент, позволяющий оценить целесообразность внедрения использования LLM в бизнес-процессах конкретной команде разработчиков.

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

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

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

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