Введение

Переход от генерации отдельных фрагментов кода к LLM-агентам расширяет границы автоматизации в программной инженерии. Помощник обычно отвечает на локальный запрос. Агент получает цель, составляет план и обращается к репозиторию. Затем он меняет файлы, запускает проверки и повторяет цикл до заданного состояния. В многоагентной системе работа распределяется между специализированными компонентами. В статье J. He, C. Treude и D. Lo LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision, and the Road Ahead рассмотрено применение таких систем на разных стадиях SDLC. Авторы указывают на нерешенные проблемы координации и надежности оценки результата [14]. В данной работе рассматриваются качество сгенерированного кода и место агента в инженерном процессе, включая правила контроля и организационные ограничения.

Эмпирические работы дают противоречивые оценки ИИ-инструментов. В одном контролируемом задании участники с GitHub Copilot завершали работу на 55,8 % быстрее [12]. В исследовании METR участвовали 16 опытных разработчиков, которым предложили 246 задач в знакомых открытых репозиториях. При использовании инструментов начала 2025 г. время выполнения выросло на 19 % [13]. Систематический обзор чаще фиксирует положительные результаты, однако надежность долгосрочных и командных оценок остается ограниченной [15]. Эффект меняется вместе с задачей и состоянием репозитория. На него также влияют опыт пользователя, полнота контекста и цена проверки. Поэтому в работе анализируется связка «методология — стадия SDLC — уровень автономии — пакет доказательств».

Цель работы — определить способы интеграции LLM-агентных систем в современный SDLC и сопоставить формирующиеся Spec-Driven и Context-Driven подходы. Эмпирическая оценка учитывает методологию и профессиональную роль. Дополнительно варьируются критичность проекта, автономия агента и строгость контроля. Временная линия построена по перекрывающимся периодам влияния. Эмпирическую базу составила обезличенная выгрузка 697 анкет специалистов уровня от Junior до C-level. Для последующего развития агентных процессов предложена модель ICEDD, где готовность результата подтверждается проверяемыми свидетельствами.

Эволюция методологий и изменение объекта управления

Историю методов разработки часто сводят к цепочке «Waterfall — V-model — Agile — DevOps — ИИ». Эта последовательность скрывает длительное сосуществование подходов. В работе Royce 1970 г. поэтапный процесс сочетался с обратными связями; автор также требовал раннего проектирования и испытаний [1]. V-образная модель Forsberg и Mooz связала уровни декомпозиции с верификацией и валидацией [2]. Она развивалась рядом с каскадной схемой и усиливала трассируемость требований. Поэтапные модели сохраняются в регулируемых и критических системах, особенно при высокой цене изменения. Здесь доказуемость соответствия часто важнее частоты поставки.

Спиральная модель Boehm сместила внимание на итеративное снижение риска [3]. Манифест Agile 2001 г. закрепил приоритет работающего продукта и быстрой реакции на изменения [4]. Итеративные фреймворки сократили контур обратной связи, сохранив потребность в архитектуре и документации. Контроль также никуда не исчез. Когда программное обеспечение стало постоянно работающим сервисом, объект управления сместился к потоку поставки. DevOps связал разработку с эксплуатацией. CI/CD автоматизировал сборку и выпуск, а SRE формализовал надежность через цели уровня сервиса и наблюдаемость [5]. В отчете DORA ИИ и платформенная инженерия улучшают индивидуальный поток лишь при устойчивой инженерной базе; при слабой базе стабильность поставки может снижаться [6].

На практике сегодня преобладают гибриды. Исследование Mirzaei, Mabin и Zwikael показывает, как гибридные схемы соединяют практики Agile и планово-ориентированных подходов и настраиваются под цели проекта и тип команды [7]. Обзор El Aouni и соавторов посвящен совместному применению Agile, DevOps и облачной инфраструктуры; авторы выделяют выгоды интеграции и трудности согласования процессов [8]. В регулируемых областях к этим практикам добавляются формальные ограничения. Отчет State of Agile описывает текущий этап как адаптацию Agile к ИИ и гибридной работе; отдельное внимание уделено измерению результатов [9]. Временная линия ниже показывает периоды усиления влияния. Она не задает даты исчезновения методов. В разные годы на первый план выходили стадии проекта, риск, скорость обратной связи, поток поставки, надежность, контекст и автономия.

Рис. 1. Перекрывающиеся периоды наибольшего влияния подходов к разработке ПО (авторская систематизация по [1–9])

Таблица 1

Изменение основного объекта управления в SDLC

LLM-агентные системы и способы их интеграции

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

На практике встречаются четыре паттерна интеграции. Самый узкий вариант — помощник внутри IDE: каждую итерацию направляет человек. Агент рабочего элемента получает одну issue или задачу в отдельной ветви. Он может запустить тесты и подготовить изменение, однако слияние требует подтверждения. В многоагентном конвейере планирование отделено от реализации, а проверка поручается другим компонентам. Такая специализация имеет потенциал, хотя координация создает собственные ошибки [14]. Наиболее широкий паттерн охватывает несколько стадий SDLC. Для него нужны формальные права доступа и изолированная среда. Действия журналируются, затраты ограничиваются, переход между стадиями проходит через независимый шлюз.

Таблица 2

Паттерны интеграции LLM-агентов

Spec-Driven и Context-Driven Development

Spec-Driven Development (SDD) задает ожидаемый результат и критерии его приемки. В GitHub Spec Kit спецификация становится первичным артефактом, а рабочий поток имеет вид Spec -> Plan -> Tasks -> Implement [19]. Из требований и сценариев выводится технический план. Затем формируются выполнимые задачи. Такой порядок позволяет сопоставить изменение с исходным намерением. Ошибка в неполной или противоречивой спецификации быстро распространяется на последующие шаги, поскольку агент исполняет ее буквально.

Context-Driven Development (CDD) определяет знания и ограничения, доступные агенту на каждом шаге. В описании Google проектный контекст переносится из временного чата в версионируемые файлы рядом с кодом [20]. Там хранятся планы и архитектурные решения. Отдельно фиксируются стандарты, технологический стек и цели продукта. Для brownfield-систем это особенно полезно: локально корректное изменение способно нарушить неявное соглашение. Контекст, однако, приходится обслуживать. Без правил отбора он разрастается, содержит конфликты и сохраняет устаревшие сведения; чувствительные данные требуют отдельной фильтрации.

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

Таблица 3

Сравнение Spec-Driven и Context-Driven Development

Методика опроса и обработки данных

Эмпирическую базу составила обезличенная выгрузка 697 анкет специалистов в области разработки программного обеспечения. Каждая строка соответствовала ответам одного респондента; прямые идентификаторы и названия организаций в наборе отсутствовали. Для сопоставления результатов с отраслевым контекстом использованы открытые агрегаты. В Stack Overflow Developer Survey 2025 доля использующих или планирующих использовать ИИ-инструменты составила 84 %. Агентный режим еще не стал массовой практикой: 52 % участников не применяли агентов либо ограничивались более простыми инструментами [10]. Исследование JetBrains Developer Ecosystem 2025 охватило 24 534 разработчика из 194 стран; авторы очищали и взвешивали данные [11]. State of Agile описывает организацию разработки как гибридную и адаптивную [9]. Эти источники использованы для интерпретации собственной выборки и не заменяют ответы её участников.

Ответы сгруппированы по профессиональному уровню и размеру компании. В анкете также учитывались отрасль и критичность проекта. В выборку вошли 146 Junior, 223 Middle и 195 Senior, а также 84 специалиста уровня Lead/Architect и 49 руководителей уровня C-level или Engineering Management. Базовая методология определялась по варианту, указанному участником. Распределение по методологиям и профессиональным уровням рассматривалось в виде абсолютных частот и долей. Эти показатели характеризуют опрошенную группу; их перенос на генеральную совокупность требует вероятностного дизайна выборки.

В анкете фиксировались использование CI/CD и применение ИИ. Отдельные поля описывали агентный режим и набор делегируемых стадий. Для аналитического сопоставления ответы кодировались по единой шкале: автономия A принимала значения от 0 до 1, критичность K — от 0,2 до 1. В модель также вошли охват стадий C, полнота доказательств E и строгость управления G. В состав доказательств включались автоматические тесты и статический анализ; третий сигнал задавало человеческое ревью. Для респондентов, применявших агентный режим, индекс интеграции рассчитывался по формуле:

.

Остаточный риск и итоговый процессный эффект определялись как:

Коэффициенты индексов заданы как аналитические допущения. Рост автономии и охвата увеличивает ожидаемую полезность, но одновременно поднимает риск. Доказательства снижают расчетный риск; сходное действие имеет строгость управления. Индексы I, R и P безразмерны и не служат причинными оценками производительности. Начальное состояние анализа чувствительности зафиксировано: seed = 20260802. Устойчивость ранжирования проверялась на 10 000 повторениях Dirichlet-мультиномиальной модели вокруг наблюдаемого вектора долей. Параметр концентрации равен 120.

Таблица 4

Структура выборки по профессиональному уровню

Результаты опроса

Использование или планирование ИИ-инструментов указали 585 из 697 респондентов (83,9 %). Об агентном режиме сообщили 155 из них, что соответствует 26,5 % группы ИИ. Гибридную Agile + DevOps выбрали 315 респондентов (45,2 %), Scrum/Agile — 118 (16,9 %), Kanban/Scrumban — 72 (10,3 %). Waterfall/V-model указали 58 участников (8,3 %). SDD и Agentic/AI-native получили по 49 ответов (7,0 %), CDD — 36 (5,2 %). Гибридная Agile + DevOps оставалась крупнейшей категорией во всех 10 000 итерациях анализа чувствительности. Ранжирование устойчиво внутри выбранного диапазона допущений. Доля 45,2 % описывает опрошенную группу, а не всю отрасль.

Рис. 2. Распределение базовых моделей разработки по данным опроса (N = 697)

Таблица 5

Методология и показатели агентной интеграции по данным опроса

Преобладание гибридной модели связано с тем, что она охватывает четыре рабочих контура. В продуктовом контуре используются backlog и короткое планирование, после чего команда получает обратную связь. Инженерный контур отвечает за контроль версий и code review; сюда же относятся автоматические тесты и управление техническим долгом. Поставку поддерживают CI/CD и воспроизводимые среды. Эксплуатационный контур опирается на SLO, наблюдаемость и работу с инцидентами. LLM-агент в такой схеме действует внутри существующих процедур как ограниченный исполнитель. На текущем уровне зрелости практичным вариантом остается Agile + DevOps с выборочной агентной автоматизацией и человеческими шлюзами.

Из 155 респондентов, применявших агентный режим, 122 указали делегирование кодирования (78,7 %). Тестирование и документацию отметили по 106 участников (68,4 %), ревью — 86 (55,5 %). Требования выбрали 65 респондентов (41,9 %), проектирование — 63 (40,6 %). Значения для развертывания и мониторинга заметно ниже: 30 (19,4 %) и 23 (14,8 %) соответственно. Такой рисунок согласуется с открытыми опросами, где ИИ чаще используют для локальных проверяемых задач [10]. Осторожность возрастает при переходе к эксплуатации и проектному планированию. Исследовательская база также смещена к разработке: обзор 181 бенчмарка из 461 публикации относит к этой стадии около 60 % оценок. На требования приходится 5 %, на проектирование — 3 % [18]. Измерительный инструментарий пока охватывает Agentic SDLC неравномерно.

Рис. 3. Стадии SDLC, делегируемые LLM-агентам по данным опроса (n = 155)

Среди респондентов с агентным режимом медиана индекса интеграции равна I = 0,687. Медиана остаточного риска составила R = 0,166, процессного эффекта — P = 0,575. Высокий человеческий контроль зафиксирован в 86 анкетах, средний — в 58, низкий — в 11. Первый уровень автономии указан в 70 анкетах, второй — в 74, третий — в 11. В высококритичной группе медиана снизилась до первого уровня. При отсутствии всех трех контрольных сигналов медиана P равнялась 0,245. Одновременное наличие тестов, статического анализа и ревью подняло ее до 0,663. Разница зависит от принятой формулы индекса и не является причинной оценкой эффекта.

В SWE-bench и SWE-agent единицей оценки служит проверяемый пакет изменений. SWE-bench содержит 2 294 задачи на основе реальных GitHub issue и pull request; патч проверяется воспроизводимыми тестами [16]. SWE-agent добавляет интерфейс, через который агент взаимодействует с репозиторием и средой [17]. Прохождение тестов еще не подтверждает полноту требований или эксплуатационную пригодность. Безопасность и сопровождаемость также требуют отдельных проверок. Пакет доказательств должен связывать изменение с исходным намерением и содержать независимые тесты. Статический и security-анализ дополняются журналом инструментальных действий; решение о выпуске принимает уполномоченный человек. NIST SP 800–218A расширяет практики безопасной разработки на модели и данные, а профиль NIST AI RMF связывает генеративный ИИ с процедурами идентификации и обработки риска [21, 22].

Перспективы развития после SDD и CDD

SDD снижает неопределенность намерения, CDD помогает удерживать проектный контекст. Вопрос доверия к автономному исполнению остается открытым. Рост контекстных окон и автоматическое извлечение знаний, вероятно, превратят управление контекстом в инфраструктурную функцию. Генерация спецификаций станет обычным этапом работы. Различия между следующими методологиями будут определяться доказуемостью результата и правилами назначения полномочий. С учетом этого предложена Intent-Context-Evidence Driven Development (ICEDD) — разработка, управляемая намерением, контекстом и доказательствами.

В ICEDD намерение фиксирует бизнес-цель и допустимый риск. Спецификация переводит его в проверяемые требования. Контекст хранит архитектуру, код и принятые решения; рядом находятся стандарты и эксплуатационные данные. Агент выполняет ограниченную задачу. Контур Evidence & Governance собирает результаты тестов, трассировку и подтверждение. Переход к следующему контуру разрешается после доказательного шлюза. Если проверка выявляет новый риск или противоречие исходному намерению, меняются код и спецификация. Контекст обновляется в той же итерации. Такая обратная связь остается аудируемой.

Рис. 4. Концептуальная схема ICEDD (предложено автором)

Таблица 6

Возможные направления пост-SDD/CDD методологий

Эти направления пока существуют как исследовательские конструкции. Для их проверки нужны длительные сравнения команд и проектов. Одной скорости недостаточно: следует учитывать дефекты и объем повторной работы. Отдельные метрики должны описывать безопасность и восстановление после инцидентов. Качество проектных знаний и когнитивная нагрузка требуют собственного измерения. Особенно мало данных накоплено по требованиям и архитектуре. Сопровождение и командное взаимодействие также представлены в бенчмарках значительно слабее кодирования [18].

Заключение

Новые методологии обычно сохраняют часть прежних механизмов управления. Waterfall и V-model закрепили поэтапность и трассируемость. Spiral перенес внимание на риск, Agile сократил обратную связь, а DevOps и CI/CD связали изменение кода с поставкой. SRE добавил измеряемую надежность работающего сервиса. LLM-агенты вводят новый объект управления — автономное многошаговое действие. Его результат зависит от способности модели генерировать код, но этого недостаточно. Нужны ясное намерение и актуальный контекст. Границы полномочий и независимая проверка определяют допустимый уровень автономии.

По данным опроса 697 специалистов доля гибридной Agile + DevOps модели составила 45,2 %. Агентное делегирование чаще затрагивало кодирование. Для тестирования и документации получены одинаковые значения — 68,4 %. Эти результаты описывают обследованную выборку. SDD можно использовать для формализации намерения, CDD — для управления долговременным контекстом. ICEDD добавляет проверяемые доказательства. Расширение автономии допустимо при наличии наблюдаемости и воспроизводимого evidence-пакета. Для каждого изменения также нужен безопасный откат. При принятой формуле индекса сочетание этих условий соответствует медиане остаточного риска 0,166.

Литература:

1. Royce W. W. Managing the Development of Large Software Systems / W. W. Royce // Proceedings of IEEE WESCON. — 1970. — P. 1–9. — URL: https://www.praxisframework.org/files/royce1970.pdf (дата обращения: 04.08.2026). — Текст: электронный.
2. Forsberg K. The Relationship of System Engineering to the Project Cycle / K. Forsberg, H. Mooz // Proceedings of the First Annual Symposium of the National Council on Systems Engineering. — 1991. — P. 57–65. — DOI: 10.1002/j.2334–5837.1991.tb01484.x.
3. Boehm B. W. A Spiral Model of Software Development and Enhancement / B. W. Boehm // Computer. — 1988. — Vol. 21, no. 5. — P. 61–72. — DOI: 10.1109/2.59.
4. Beck K. Manifesto for Agile Software Development / K. Beck [et al.]. — 2001. — URL: https://agilemanifesto.org/ (дата обращения: 04.08.2026). — Текст: электронный.
5. Site Reliability Engineering: How Google Runs Production Systems / B. Beyer, C. Jones, J. Petoff, N. R. Murphy. — Sebastopol: O'Reilly Media, 2016. — URL: https://sre.google/sre-book/table-of-contents/ (дата обращения: 04.08.2026). — Текст: электронный.
6. Accelerate State of DevOps Report 2024 / Google Cloud. — 2024. — URL: https://dora.dev/research/2024/dora-report/ (дата обращения: 04.08.2026). — Текст: электронный.
7. Mirzaei M. Customising Hybrid project management methodologies / M. Mirzaei, V. J. Mabin, O. Zwikael // Production Planning & Control. — 2025. — Vol. 36, no. 9. — P. 1188–1205. — DOI: 10.1080/09537287.2024.2349231. — URL: https://doi.org/10.1080/09537287.2024.2349231 (дата обращения: 05.08.2026). — Текст: электронный.
8. El Aouni F. A systematic literature review on Agile, Cloud, and DevOps integration: Challenges, benefits / F. El Aouni, K. Moumane, A. Idri, M. Najib, S. U. Jan // Information and Software Technology. — 2025. — Vol. 177. — Art. 107569. — DOI: 10.1016/j.infsof.2024.107569. — URL: https://doi.org/10.1016/j.infsof.2024.107569 (дата обращения: 05.08.2026). — Текст: электронный.
9. The Adaptation Era: 18th State of Agile Report / Digital.ai. — Raleigh, NC: Digital.ai, 2025. — 21 p. — URL: https://digital.ai/resource-center/analyst-reports/18th-state-of-agile-report/ (дата обращения: 05.08.2026). — Официальное сообщение о выпуске: https://digital.ai/press-releases/digital-ais-18th-state-of-agile-report-marks-the-start-of-the-fourth-wave-of-software-delivery/ (дата обращения: 05.08.2026). — Текст: электронный.
10. 2025 Developer Survey: Artificial Intelligence / Stack Overflow. — 2025. — URL: https://survey.stackoverflow.co/2025/ai (дата обращения: 04.08.2026). — Текст: электронный.
11. State of the Developer Ecosystem 2025: Methodology and Results / JetBrains. — 2025. — URL: https://lp.jetbrains.com/developer-ecosystem-2025-methedology/ (дата обращения: 04.08.2026). — Текст: электронный.
12. Peng S. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot / S. Peng, E. Kalliamvakou, P. Cihon, M. Demirer. — 2023. — arXiv:2302.06590. — DOI: 10.48550/arXiv.2302.06590.
13. Becker J. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity / J. Becker [et al.]. — METR, 2025. — URL: https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf (дата обращения: 04.08.2026). — Текст: электронный.
14. He J. LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision, and the Road Ahead / J. He, C. Treude, D. Lo // ACM Transactions on Software Engineering and Methodology. — 2025. — Vol. 34, no. 5. — Art. 124. — P. 124:1–124:30. — DOI: 10.1145/3712003.
15. Mohamed A. The Impact of LLM-Assistants on Software Developer Productivity: A Systematic Review and Mapping Study / A. Mohamed, M. Assi, M. Guizani. — 2025. — arXiv:2507.03156. — DOI: 10.48550/arXiv.2507.03156.
16. Jimenez C. E. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? / C. E. Jimenez, J. Yang, A. Wettig [et al.] // International Conference on Learning Representations. — 2024. — URL: https://proceedings.iclr.cc/paper_files/paper/2024/hash/edac78c3e300629acfe6cbe9ca88fb84-Abstract-Conference.html (дата обращения: 04.08.2026). — Текст: электронный.
17. Yang J. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering / J. Yang, C. E. Jimenez, A. Wettig [et al.] // Advances in Neural Information Processing Systems. — 2024. — Vol. 37. — URL: https://proceedings.neurips.cc/paper_files/paper/2024/hash/5a7c947568c1b1328ccc5230172e1e7c-Abstract-Conference.html (дата обращения: 04.08.2026). — Текст: электронный.
18. Wang K. Software Development Life Cycle Perspective: A Survey of Benchmarks for CodeLLMs and Agents / K. Wang, T. Li, X. Zhang [et al.]. — 2025. — arXiv:2505.05283. — DOI: 10.48550/arXiv.2505.05283.
19. GitHub Spec Kit: a specification-driven development toolkit // GitHub: [сайт]. — 2026. — URL: https://github.github.com/spec-kit/ (дата обращения: 05.08.2026). — Текст: электронный.
20. Ballinger K. Conductor: Introducing Context-Driven Development for Gemini CLI / K. Ballinger, J. Kornder, S. Aitbayev // Google Developers Blog: [сайт]. — 17.12.2025. — URL: https://developers.googleblog.com/en/conductor-introducing-context-driven-development-for-gemini-cli/ (дата обращения: 05.08.2026). — Текст: электронный.
21. Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: NIST SP 800–218A / NIST. — 2024. — DOI: 10.6028/NIST.SP.800–218A. — URL: https://doi.org/10.6028/NIST.SP.800–218A (дата обращения: 05.08.2026). — Текст: электронный.
22. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: NIST AI 600–1 / NIST. — 2024. — DOI: 10.6028/NIST.AI.600–1. — URL: https://doi.org/10.6028/NIST.AI.600–1 (дата обращения: 05.08.2026). — Текст: электронный.