Влияние LLM на командное взаимодействие
в разработке программного обеспечения

Аннотация

Крупные языковые модели (LLM) все чаще интегрируются в процессы разработки программного обеспечения, обладая потенциалом трансформировать рабочие процессы команд и повышать продуктивность. В данной работе исследуется влияние LLM на командное взаимодействие на протяжении всего жизненного цикла разработки ПО (SDLC). Мы переосмысливаем и актуализируем предыдущее исследование с учетом последних достижений по состоянию на 2025 год, включая новую литературу и кейсы. Мы обозначаем проблему барьеров сотрудничества в SDLC и рассматриваем, как LLM могут улучшить продуктивность, коммуникацию и принятие решений в командном контексте. Посредством обзора литературы, примеров из индустрии, опроса команд и двух кейсов мы оцениваем влияние инструментов с поддержкой LLM (таких как ассистенты генерации кода и ИИ-агенты для управления проектами) на практики совместной разработки ПО. Наши результаты показывают, что LLM могут значительно повысить эффективность (за счет автоматизации рутинных задач и документирования), улучшить ясность коммуникации и содействовать межфункциональному взаимодействию, одновременно создавая новые вызовы, такие как ограничения моделей и проблемы конфиденциальности. Мы обсуждаем эти преимущества и сложности, формулируем исследовательские вопросы, направляющие анализ, оцениваем угрозы валидности и предлагаем направления для будущих исследований, включая адаптацию моделей под конкретные домены, улучшенную интеграцию в инструменты разработки и надежные стратегии обеспечения доверия и безопасности..

I Введение

Крупные языковые модели (LLM), такие как GPT-4 от OpenAI, привели к смене парадигмы в выполнении интеллектуальной работы, позволяя формулировать и выполнять задачи на естественном языке. В области разработки программного обеспечения эти модели активно используются для автоматизации программирования и помощи разработчикам, повышая продуктивность и сокращая рутинные операции. Последние исследования количественно оценили эти преимущества: например, в контролируемом эксперименте разработчики, использующие GitHub Copilot (LLM-ассистент для написания кода), выполняли задачу на 50% быстрее по сравнению с теми, кто его не применял [2]. Подобные инструменты парного программирования с ИИ также повышали уверенность и удовлетворённость разработчиков своей работой [2]. Одновременно внедрение LLM в профессиональной среде стремительно растёт. Опросы 2023 года показали, что примерно 25–38% специалистов уже используют LLM-инструменты в своей работе [1], и ожидается, что этот показатель увеличится по мере расширения возможностей и интеграции LLM..

Жизненный цикл разработки программного обеспечения (SDLC) — это структурированный процесс проектирования, разработки, тестирования, развертывания и поддержки программных систем. Эффективный командное взаимодействие играет ключевую роль на каждом этапе SDLC для обеспечения высококачественных результатов. Однако команды часто сталкиваются с трудностями в совместной работе, такими как недопонимание, разрозненность знаний, повторяющиеся низкоуровневые задачи и неэффективные процессы принятия решений. В данной работе исследуется, как внедрение LLM в деятельность SDLC влияет на взаимодействие в команде. В частности, нас интересует, как инструменты на основе LLM могут повысить продуктивность разработчиков, улучшить коммуникацию между членами команды и способствовать более эффективному принятию решений в рамках программного проекта..

Мы пересматриваем и обновляем предыдущее исследование по данной теме, включая последние разработки вплоть до 2025 года. В последние годы крупные программные платформы начали внедрять LLM-ассистентов в повседневные инструменты (например, Microsoft 365 Copilot для документов Office и AI Companion от Zoom для сводок встреч) с целью поддержки коллаборации и обмена информацией. В то же время ряд научных работ начал исследовать применение LLM в процессах разработки программного обеспечения. Первые данные свидетельствуют, что LLM могут помогать в генерации кода, документировании, мозговом штурме дизайна и даже автоматизированном управлении проектами. Тем не менее, конкретные эффекты использования LLM на человеческую команда Динамика в программных проектах остается недостаточно изученной. Это мотивирует наше исследование влияния LLM на паттерны коммуникации, межфункциональное взаимодействие и общую эффективность команды в рамках SDLC..

Остальная часть статьи структурирована следующим образом: в разделе II рассматриваются связанные работы по использованию LLM в программной инженерии и совместной работе. Раздел III формулирует проблему и исследовательский пробел. Раздел IV описывает методологию, включая обзор литературы, опрос команд и кейс-стади. Раздел V освещает ключевые применения LLM, способствующие командной коллаборации. Раздел VI детализирует дизайн исследования, включая исследовательские вопросы и инструментарий опроса (полная анкета приведена в Приложении). Раздел VII представляет два кейс-стади, демонстрирующих реальное применение LLM в командной работе. Раздел VIII перечисляет исследовательские вопросы, на которые даны ответы. Раздел IX обсуждает угрозы валидности. Раздел X предлагает направления для будущих исследований и новые научные тренды. Наконец, раздел XI подводит итоги, обобщая наши выводы о влиянии LLM на командную коллаборацию в SDLC..

II Связанные работы

Появление мощных LLM (например, GPT-3/4, PaLM, LLaMA) привело к многочисленным исследованиям их применения в разработке программного обеспечения. Учёные активно изучают, как эти модели могут помогать или дополнять различные этапы процесса разработки. Например, LLM продемонстрировали высокие способности в генерация кода и документация кода. Недавнее сравнительное исследование оценило несколько современных LLM (GPT-3.5, GPT-4, Google Gemini 1.5, Meta LLaMA 3.1 и др.) в генерации комментариев к коду и документации; было установлено, что большинство LLM способны создавать документацию, которая по ясности и полноте систематически превосходит оригинальную, написанную человеком, особенно для комментариев на уровне функций [3]. Это указывает на то, что LLM могут автоматизировать одну из рутинных задач разработки — написание документации — потенциально улучшая обмен знаниями и адаптацию новых членов команды..

Еще одной областью интересов является использование LLM в составе мультиагентных систем для решения сложных задач проектирования программного обеспечения и проблемно-ориентированных задач. Du и др.. [4] предлагают концепцию, в которой несколько управляемых LLM автономные агенты совместно работать в командном режиме на различных этапах жизненного цикла разработки ПО (анализ, кодирование, тестирование). В их подходе каждый агент специализируется на определённой роли, а агенты последовательно передают промежуточные результаты друг другу, следуя заранее определённому процессу разработки. Организуя несколько таких команд LLM параллельно и позволяя им обмениваться идеями, авторы смогли исследовать альтернативные решения и в итоге достичь более высокого качества ПО по сравнению с одиночной линейной цепочкой разработки [4]. Аналогично, Cinkusz и др.. [5] интегрировали когнитивные агенты на основе LLM в симуляцию управления проектами по методологии Agile. Их исследование показало, что агенты, управляемые LLM и выступающие в роли виртуальных членов команды в среде Scaled Agile Framework, способны улучшать различные метрики проекта. В итеративных симуляциях эти ИИ-агенты продемонстрировали расширенные возможности в распределении задач, межагентном взаимодействии и управлении жизненным циклом, что привело к измеримым улучшениям, таким как сокращение времени выполнения задач, повышение качества результатов и более согласованная коммуникация внутри команды [5]. Эти работы иллюстрируют перспективность использования LLM не только в качестве индивидуальных ассистентов, но и как компонентов более крупных систем совместно работающих агентов для поддержки или даже имитации командных процессов..

Также появляются исследования, посвящённые использованию LLM для поддержки творческое сотрудничество и генерации идей. LLM могут выступать в роли партнеров по мозговому штурму, генерируя дизайнерские идеи или альтернативные подходы на естественном языке. В ходе всестороннего обзора 61 исследования по использованию LLM для генерации идей было установлено, что LLM чаще всего применяются для создания и уточнения идей во время сессий мозгового штурма, способствуя креативности и продуктивности этих процессов [8]. Однако тот же обзор отметил, что использование LLM на более сложных этапах групповой генерации идей (таких как совместная оценка и выбор идей) остается ограниченным [8]. Это указывает на возможность дальнейшей интеграции LLM в совместные аспекты ранних этапов проектирования программного обеспечения и обсуждения требований..

Несмотря на эти достижения, сохраняется пробел в понимании человеческого факторы при внедрении LLM в команды разработчиков. Предыдущие исследования рассматривали автоматизацию и ИИ для написания кода и документации, но лишь немногие работы фокусируются на том, как LLM влияет на паттерны коммуникации, динамику принятия решений в команде или кросс-функциональное взаимодействие. Первые данные из отраслевых опросов показывают, что работники умственного труда в основном используют LLM для создания контента, поиска информации, помощи в написании кода и составления черновиков сообщений [1]. Однако вопрос о том, как такое применение приводит к ощутимым улучшениям (или новым проблемам) в командной работе на протяжении всего жизненного цикла проекта, остается открытым. Наша работа направлена на восполнение этого пробела путем изучения влияния LLM на взаимодействие команд в рамках SDLC, опираясь на упомянутые технические результаты и дополняя их эмпирическими наблюдениями за реальными командами..

III Постановка задачи

Совместная работа команды критически важна для успеха любого проекта SDLC, однако она часто сталкивается с устойчивыми проблемами. Недостаточная коммуникация между разработчиками, тестировщиками и менеджерами может привести к неверному пониманию требований или статуса проекта. Повторяющиеся задачи (например, написание шаблонного кода или документации) могут отнимать значительное время и снижать мотивацию. Принятие решений в проектах может быть неэффективным из-за неполной информации или когнитивной перегрузки, особенно в крупных командах. Традиционные подходы к смягчению этих проблем включают agile-практики, код-ревью, ежедневные стендапы и стандарты документации, однако они в значительной степени зависят от человеческих усилий и дисциплины..

Хотя автоматизация и искусственный интеллект уже применялись для решения отдельных задач в разработке программного обеспечения (например, автоматизированное тестирование, боты для непрерывной интеграции и т. д.), относительно мало внимания уделялось тому, как новейшее поколение ИИ — в частности, LLM — может напрямую влиять на аспекты совместной разработки. Исследовательский пробел, который мы рассматриваем,: Как крупные языковые модели (Large Language Models), интегрированные в процессы разработки программного обеспечения, влияют на динамику командного взаимодействия на протяжении всего жизненного цикла разработки (SDLC).?

Ключевые подпроблемы включают определение того, могут ли LLM снижать недопонимание (например, путем генерации более четкой документации или резюме встреч), способны ли они брать на себя рутинные задачи (освобождая людей для более творческой работы) и могут ли их предложения или инсайты улучшать принятие решений в команде и кросс-функциональную координацию. Мы также рассматриваем вызовы: LLM может выдавать неточную информацию (потенциально вводя команду в заблуждение), может не понимать контекст проекта без дополнительного обучения и способен вызывать проблемы конфиденциальности или безопасности при работе с проприетарным кодом. Эти опасности подчеркивают важность изучения влияния LLM в реалистичном командном контексте, а не только в изолированных задачах программирования..

IV Методология

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

Сначала мы провели обзор литературы собрать данные из последних исследований (2019–2025 гг.) по использованию ИИ и LLM в разработке программного обеспечения. Это позволило выявить предполагаемые преимущества (например, рост производительности, улучшение качества кода) и известные проблемы (например, ограничения LLM, сложности интеграции). Особое внимание было уделено исследованиям, посвященным вопросам совместной работы, таким как взаимодействие нескольких разработчиков с ИИ-ассистентами и применение ИИ в управлении проектами или документацией..

Далее мы провели кейс-стади двух команд разработчиков программного обеспечения, внедривших инструменты на основе LLM в рабочий процесс (подробно описано в разделе VII). Эти кейс-стадии включают анализ того, как каждая команда внедрила инструмент LLM, какие конкретные проблемы взаимодействия он помог решить, а также сбор наблюдений и отзывов о результатах, таких как сэкономленное время, изменения в коммуникации и возникшие трудности..

Мы также разработали и провели обзор Целевая аудитория исследования — специалисты в области программного обеспечения, использующие LLM. Опрос (см. Приложение) включал как вопросы с множественным выбором, так и открытые вопросы для выяснения ролей участников, способов их использования LLM (для написания кода, документации, коммуникации и т. д.), а также их восприятия влияния этих моделей на рабочий процесс и взаимодействие в команде. Мы собрали ответы от членов двух команд разработчиков в консалтинговой компании, которые уже некоторое время использовали LLM (например, ChatGPT или GitHub Copilot) в своей повседневной работе. Опрос был структурирован по разделам, охватывающим влияние на рабочий процесс, коммуникацию, совместную работу и принятие решений, проблемы и ограничения, а также общие впечатления и предложения..

После сбора данных мы выполнили анализ из ответов на опрос, сочетая ручной качественный анализ с помощью LLM (ChatGPT-4) для выявления паттернов или обобщения тем в открытых отзывах. Мы проверили эти выводы путем триангуляции с данными из литературы и конкретными результатами кейс-стади..

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

В Применение LLM в командном взаимодействии

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

V-A Фреймворки само-коллаборации

Крупные языковые модели (LLM) могут быть настроены для имитации нескольких ролей в команде разработчиков и в некоторой степени взаимодействовать между собой. Недавние исследования Dong и др.. ввели самосотрудничество фреймворк, в котором одна LLM (или набор согласованных LLM) принимает различные роли, такие как Аналитик, Кодер, и Тестировщик, и итеративно генерирует и уточняет программные артефакты для поставленной задачи [6]. Например, роль Analyst может интерпретировать требования и планировать решение, роль Coder — писать код для решения, а роль Tester — проверять или генерировать тесты для кода. Роли обмениваются информацией (промптами и ответами), имитируя рабочий процесс разработки. Такой подход эффективно формирует виртуальную команду LLM-агентов, взаимно облегчающих работу друг друга. Эксперименты показали, что такие специализированные по ролям LLM-агенты, работая совместно, могут значительно улучшить результаты генерации кода, достигая на 30–47% более высокой успешности выполнения задач по сравнению с одиночной работой одного LLM [6]. Это позволяет предположить, что LLM способны повышать эффективность за счёт внутренней обработки некоторых аспектов коллаборации (таких как ревью кода или тестирование) до необходимости вмешательства человека..

V-B Мультиагентное взаимодействие

За пределами сценария, где одна LLM выполняет несколько ролей, несколько LLM могут быть интегрированы в многоагентная система (Многоагентные системы (MAS) для помощи человеческой команде. В многоагентной конфигурации каждый агент (которым может быть экземпляр LLM или LLM, дополненный инструментами) может быть назначен для выполнения определенной задачи или области экспертизы, а агенты взаимодействуют друг с другом для координации действий. Подобные системы предлагаются для управления сложными задачами путем распределения работы между агентами и обеспечения параллельного решения проблем. Например, один агент может специализироваться на фронтенд-коде, другой — на бэкенд-логике, а третий — на обеспечении качества; они могут передавать задачи или информацию друг другу в рамках оркестрационной структуры. и др..’Примером такого подхода является фреймворк Cross-Team Orchestration (Croto), в котором несколько команд LLM-агентов предлагают различные решения заданной проблемы проектирования программного обеспечения, а затем обмениваются идеями для достижения более оптимального решения [4]. Коллаборации мультиагентных LLM использовались для моделирования полных рабочих процессов разработки программного обеспечения и продемонстрировали улучшение качества программного обеспечения и устойчивости решений по сравнению с использованием единой последовательности операций ИИ [4].].

В практических командных условиях агенты на основе LLM могут выступать в роли виртуальных членов команды. Например, агент, интегрированный с системой отслеживания задач, может активно предлагать назначения тикетов или зависимости, в то время как другой агент отслеживает репозиторий кода на предмет проблемных изменений и создает предупреждающие тикеты. Коммуникация между такими агентами (и с человеческими членами команды) требует тщательного управления, чтобы они действительно снижали нагрузку, а не создавали лишний шум. Первые исследования обнадеживают: в области Agile-управления проектами агенты на базе LLM смогли координироваться с помощью естественного языка, имитировать поведение Scrum-команд и повышать эффективность выполнения проектов [5]. Это указывает на то, что при правильной настройке мультиагентные LLM-системы могут усилить человеческие команды, беря на себя координационные задачи и оперативно реагируя на рутинные запросы или события..

V-C Инженерия промптов для командных политик

Инженерия промптов (prompt engineering) относится к искусству разработки входных данных или инструкций, передаваемых LLM, для получения желаемого поведения и выходных данных. Это ключевая техника, позволяющая направлять LLM на соблюдение определенных правил, стилевых рекомендаций или рамок принятия решений, которые могут требоваться команде. В контексте совместной работы инженерия промптов может использоваться для согласования LLM с политиками команды или лучшими практиками. Например, команда разработчиков может создать стандартизированный шаблон промпта для проверки кода: промпт может инструктировать LLM-ревьюера всегда проверять наличие определенных уязвимостей безопасности, соответствие стандартам кодирования и необходимую документацию в любом анализируемом коде. Встраивая эти правила в промпт, выходные данные LLM будут последовательно учитывать требования команды. Инженерия промптов также может применяться для контроля тона и структуры коммуникаций, создаваемых LLM (например, обеспечение того, чтобы автоматически сгенерированное резюме встречи четко включало пункты действий и решения). По сути, инженерия промптов позволяет командам настраивать взаимодействие с LLM в соответствии с конкретными потребностями проекта, повышая релевантность и надежность помощи LLM. По мере роста использования LLM организации даже разрабатывают внутренние репозитории и шаблоны промптов для обеспечения согласованности в использовании ИИ разными членами команды, что стало новой лучшей практикой..

V-D Концептуализация и поддержка генерации идей

LLM могут значительно помочь на ранних этапах ЖЦПО, таких как мозговой штурм требований, проектирование системы и концептуализация архитектуры. Благодаря их способности генерировать текст, близкий к человеческому, и опираться на обширный объем знаний, LLM могут выступать в роли креативных партнеров во время сессий генерации идей. Они могут предлагать альтернативные шаблоны проектирования, предлагать пользовательские истории или функции на основе аналогичных проектов, а также помогать исследовать граничные случаи, которые команда может не сразу учесть. Команды могут проводить мозговой штурм, задавая вопросы LLM, например, “Какие потенциальные подходы можно использовать для реализации функции X при ограничениях Y и Z?” и получить список идей для обсуждения. Это может обогатить творческий процесс, помогая командам преодолеть когнитивную фиксацию и рассмотреть более широкое пространство решений. Как отмечено в литературе, помощь LLM особенно эффективна для генерации и уточнения идей [8]. Например, если команда застряла на вопросе улучшения производительности компонента, LLM может предложить методы (кэширование, параллелизм и т. д.), основанные на известных лучших практиках или даже академической литературе. Однако важно, чтобы команда проверила эти предложения — LLM иногда могут выдавать непрактичные идеи или ссылаться на несуществующие методы. Тем не менее, при разумном использовании LLM ускоряют концептуальную фазу, предоставляя быстрый мозговой штурм по запросу и даже создавая макеты артефактов (например, псевдокод или UML-подобные описания), которые команда может дорабатывать..

В целом, LLM предлагают широкий спектр применений в командном взаимодействии: они могут в определенной степени автоматизировать внутреннюю координацию (самосовместная работа), выступать в роли специализированных агентов в рамках более широкой команды (мультиагентные системы), настраиваться с помощью промптов для соблюдения командных норм и служить катализатором креативного мышления в дизайне. Эти применения формируют основу для конкретных примеров и оценок, представленных в последующих разделах..

VI Дизайн исследования

Наше исследование основано на нескольких научных вопросах и структурированном подходе к их решению. Мы выделили три основных Исследовательские вопросы (RQs)) относительно влияния LLM на совместную работу:

1. RQ1: Как LLM влияют на коммуникацию и совместную работу команд разработчиков в течение SDLC??
   Мы исследуем, помогают ли LLM командам общаться более четко и последовательно, а также становятся ли обмен информацией и принятие решений более эффективными. Например, мы рассматриваем документацию и сводки, сгенерированные LLM, как инструменты для обеспечения единого понимания у всех членов команды. Ожидаемые положительные эффекты включают повышение ясности сообщений и сокращение недопонимания благодаря автоматически создаваемым сводкам обсуждений. Мы также изучаем, способствует ли вовлечение LLM ускорению потока информации (например, получению мгновенных ответов от помощника по коду вместо ожидания ответа коллеги).).

2. RQ2: Каково влияние LLM на кросс-функциональное взаимодействие между ролями (разработчики, тестировщики, менеджеры проектов и т. д.)?.)?
   Данный вопрос посвящен тому, помогают ли инструменты LLM преодолевать разрывы между различными ролями в команде разработчиков. Мы исследуем сценарии, такие как LLM, автоматически генерирующий краткие отчеты о тестировании для разработчиков, или помощник по гибкому планированию, который обновляет информацию как для разработчиков, так и для менеджеров проектов. Мы ожидаем выяснить, упрощают ли LLM совместную работу за счет автоматизации генерации отчетов, поддержания всех в курсе текущего статуса проекта в реальном времени и сокращения накладных расходов на синхронизацию работы между разработкой и QA. Успешным результатом станет улучшенная синхронизация и меньшее количество недопониманий между функциональными ролями..

3. RQ3: Как LLM влияют на практики документирования в командах разработки программного обеспечения??
   В данном исследовании рассматриваются изменения в подходах команд к документации при наличии LLM. LLM потенциально способны автоматизировать создание документации (требований, API, пользовательских руководств) и поддерживать её актуальность по мере изменения кода. Мы оцениваем, сохраняют ли команды с поддержкой LLM документацию более актуальной и точной, а также снижается ли нагрузка на разработчиков по её написанию. Кроме того, исследуется, улучшается ли качество документации (например, повышается ли согласованность, сокращается количество пропусков) благодаря участию LLM. В идеале LLM могут обеспечить фиксацию критически важных знаний и их доступность, что улучшит общую согласованность команды..

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

Мы также собрали качественные данные посредством открытые вопросы и интервью в ходе кейс-стади. В частности, после каждого кейс-стади (подробно описаны в разделе VII) мы возвращались к исследовательским вопросам (RQ), чтобы оценить, как данные из реального примера подтверждают или опровергают наши первоначальные предположения по каждому исследовательскому вопросу..

В ходе исследования применялся итеративный подход: результаты первоначального опроса и данные наблюдений анализировались с помощью ChatGPT-4 (использовался как инструмент анализа) для выявления общих преимуществ и проблем. Это позволило оперативно выявить тенденции, например: «многие разработчики отмечают улучшение коммуникации благодаря автоматическому суммированию заметок с встреч» или «некоторые разработчики опасаются, что чрезмерная зависимость от LLM может препятствовать обучению». Эти инсайты интегрированы в наши выводы..

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

VII Кейс-стади

Чтобы обосновать наш анализ на реальных примерах, мы рассматриваем два кейса команд, внедривших инструменты на основе LLM в свой SDLC, и описываем полученные результаты..

VII-A Кейс 1: Улучшение командной коммуникации и коллаборации

Обзор команды: Первая команда представляет среднюю консалтинговую компанию, специализирующуюся на решениях для защиты данных. В проектную команду входили 4 разработчика программного обеспечения, 1 менеджер проекта, 2 инженера по тестированию и 1 UX-дизайнер. Они работают в Agile-среде с частыми обновлениями для клиентов..

Реализация LLM: Эта команда внедрила ИИ-ассистента для улучшения ежедневной коммуникации и обмена информацией. В частности, они интегрировали GitHub Copilot (работающий на основе GPT-4 от OpenAI)) в свою среду разработки для помощи в написании кода, а также использовали инструмент для ведения заметок на основе LLM в рабочем пространстве Microsoft Teams. Инструменты LLM применялись для облегчения взаимодействия в режиме реального времени (разработчики могли задавать LLM вопросы о кодовой базе или API), а также для автоматического создания документации, такой как заметки о встречах и сводки кода..

Варианты применения: Два ключевых варианта применения получили распространение: - Реал-тайм суммирование встреч: В ходе ежедневных стендапов и еженедельных обзоров спринтов LLM-бот, получая на вход транскрипт, генерировал краткие сводки обсуждаемых вопросов, включая принятые решения и задачи для выполнения.. - По запросу документация и поддержка: Разработчики могли запрашивать LLM (через чат-интерфейс) для получения объяснений внутренних функций библиотеки или извлечения прошлых проектных решений из архивных документов. LLM была дообучена на документации проекта и журналах чатов (в пределах, разрешённых политиками конфиденциальности).).

Преимущества:

1. Улучшенная коммуникация: Сгенерированные LLM резюме обеспечили согласованность всех членов команды, включая тех, кто пропустил встречу, в отношении целей и прогресса проекта. Это значительно сократило время, затрачиваемое на ручное ведение записей, и устранило несоответствия в распространении информации. Члены команды отметили, что письменные резюме повысили ясность поставленных задач.. Доказательства: Менеджер проекта отметил, что еженедельные координационные встречи можно сократить в среднем примерно на 15 минут, поскольку ключевые моменты фиксируются ИИ и не требуют многократного повторения. Внутренний опрос показал рост удовлетворенности команды коммуникационными процессами, так как все получали одинаковые краткие обновления после каждой встречи..

2. Эффективный поиск информации: Используя LLM-ассистента, разработчики могли быстро находить информацию, связанную с кодом, не отвлекая коллег. Например, вместо того чтобы спрашивать у коллеги: «Ты помнишь, как мы реализовали функцию X в прошлом году?», разработчик мог обратиться к LLM, которая извлекала или суммировала соответствующую часть документации или кода. Это упрощало рабочий процесс и сокращало перерывы в работе.. Доказательства: Логи инструмента LLM показали, что разработчики использовали его десятки раз в неделю для выполнения запросов. Члены команды сообщили о субъективном повышении продуктивности, отмечая, что такие задачи, как поиск примера использования API или фрагмента устаревшего кода, стали «почти мгновенными» с LLM, тогда как ранее на это мог уходить час поисков или опросов коллег..

Проблемы:

1. Начальная настройка и обучение: Потребовались усилия, чтобы адаптировать LLM для понимания специфической терминологии команды и контекста проекта. На ранних этапах сводки встреч, создаваемые LLM, иногда ошибочно интерпретировали технические термины или внутренние названия систем, используемые командой.. Решение: Команда провела несколько специализированных тренировочных сессий, предоставляя LLM дополнительную информацию из глоссария проекта и корректируя её выводы. Они также итеративно улучшали промты (например, указывая LLM игнорировать посторонние обсуждения на встречах и фокусироваться на решениях). После нескольких спринтов точность сводок значительно улучшилась..

2. Проблемы конфиденциальности и безопасности данных: Члены команды изначально сомневались в том, стоит ли делиться конфиденциальной информацией о проекте с LLM (особенно учитывая, что ассистент был облачным). Возникали вопросы о возможной утечке проприетарного кода или данных клиентов.. Решение: Компания решила эту проблему, внедрив строгую анонимизацию данных и контроль доступа. Они настроили сервис LLM для удаления определённых конфиденциальных идентификаторов и обеспечили его работу в защищённой песочнице без журналирования исходных данных. Дополнительно были введены правила использования (например, запрет на вставку персональных данных клиентов в ИИ). Эти меры позволили достаточно снизить риски, чтобы команда могла продолжить работу. Примечательно, что этот случай отражает более широкую проблему отрасли: некоторые организации запретили или ограничили использование внешних LLM после инцидентов с непреднамеренной утечкой конфиденциального кода в публичные ИИ-сервисы [8]. В данном случае тщательное управление позволило команде извлекать выгоду от LLM, защищая при этом конфиденциальную информацию..

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

VII-B Кейс 2: Поддержка гибкого управления проектами

Обзор команды: Второе кейс-исследование включает другую команду из той же консалтинговой фирмы, специализирующуюся на разработке мобильных приложений. В команду входили 5 разработчиков, 1 менеджер проекта (выполняющий роль Scrum Master) и 2 дизайнера UI/UX. Они использовали Scrum с двухнедельными спринтами, применяя Jira для отслеживания задач и планирования спринтов..

Реализация LLM: Команда разработала кастомную интеграцию LLM с их инструментом управления проектами (Jira). По сути, они расширили Jira с помощью LLM-агента-"ассистента", способного анализировать данные проекта (бэклог, загрузку команды, историческую скорость) и помогать с задачами планирования и отчетности. LLM была дообучена на текстах по гибкому управлению проектами и исторических данных компании для получения контекста..

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

Преимущества:

1. Оптимизированное распределение задач: Предложения LLM по распределению задач помогли сбалансировать нагрузку. Модель выявила закономерности (например, Разработчик А быстрее справляется с фронтенд-задачами, а у Разработчика B в прошлом спринте было меньше задач, поэтому он может взять больше). Это привело к более справедливому распределению работы и полному использованию потенциала команды.. Доказательства: В течение трех спринтов руководитель проекта отметил рост процента выполнения задач и более стабильную своевременную поставку пользовательских историй. Сравнение метрик показало, что команда увеличила процент завершения спринтов примерно на 10% после внедрения LLM-ассистента, что свидетельствует о лучшем планировании..

2. Автоматизированное формирование отчётов: Генерация отчетов о спринтах и составление заметок для ретроспективы, которые ранее занимали у руководителя проекта несколько часов каждый спринт, были в значительной степени автоматизированы. LLM могла создавать хорошо структурированный отчет за секунды, выделяя ключевые достижения, перенесенные задачи и повторяющиеся проблемы.. Доказательства: Менеджер проекта оценил экономию времени примерно в 5–7 часов в неделю на административных задачах по отчетности благодаря помощи LLM. Это время было перераспределено на более ценные виды деятельности, такие как встречи с заинтересованными сторонами и устранение препятствий в работе команды. Содержание отчетов, сгенерированных LLM, проверялось менеджером проекта на точность и полноту, и обычно требовались лишь незначительные правки..

Проблемы:

1. Кривая обучения для команды: Изначально не все члены команды чувствовали себя комфортно при взаимодействии с LLM-агентом (например, предоставляя ему обратную связь или доверяя его предложениям). Некоторые разработчики игнорировали предложения ИИ по задачам в первом спринте, предпочитая придерживаться своего привычного ручного планирования.. Решение: Команда провела обучающую сессию, чтобы продемонстрировать возможности и ограничения LLM. Они постепенно укрепляли доверие к системе, используя её предложения в качестве отправной точки, а не директивы. В течение нескольких спринтов разработчики стали более открыты к вкладу ИИ, особенно после того, как увидели, как он корректно отмечает перегрузку сотрудников или нереалистичные оценки задач..

2. Адаптация гибких практик (Agile Practices): Универсальная LLM потребовала доработки, чтобы соответствовать специфическим определениям завершённости, терминологии и workflow в Jira, принятым в команде. Например, команда использовала пользовательскую метку для определённых высокоприоритетных багов, которые изначально не обрабатывались LLM особым образом.. Решение: Команда разработчиков непрерывно вносила корректировки в LLM на основе обратной связи. Они обновляли контекст промптов, добавляя определения пользовательских полей, и обучали модель на примерах, указывая, какие элементы следует приоритизировать. Со временем эти циклы обратной связи повысили эффективность LLM в рамках уникального agile-процесса команды..

В примере исследования 2, LLM выступал в качестве помощник по управлению проектами, снижение нагрузки на руководителя проекта и поддержание командного темпа. Это демонстрирует, как LLM могут помогать не только в написании кода, но и в организационных аспектах совместной работы — распределении задач и подведении итогов. Адаптация команды к инструменту подчеркивает важность управления изменениями при внедрении ИИ в существующие рабочие процессы..

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

VIII Исследовательские вопросы (Анализ)

Опираясь на кейс-стади, результаты опросов и литературные данные, мы возвращаемся к исследовательским вопросам, чтобы синтезировать ответы.:

RQ1: Влияние на коммуникацию и взаимодействие между командами разработчиков: Данные свидетельствуют о том, что LLM способны повысить ясность и согласованность в командном общении. В случае 1, например, использование LLM для обобщения стендапов и встреч гарантировало, что все имели доступ к одинаковой информации, и снижало количество недопониманий. Многие респонденты опроса отметили, что документирование с помощью LLM (например, автоматически генерируемые дизайн-документы или релиз-заметки) упрощало синхронизацию команды, так как информация была изложена четко и всегда доступна. Кроме того, LLM ускоряли обмен информацией — разработчики могли получать мгновенные ответы от ИИ-ассистента вместо того, чтобы ждать, пока освободится другой член команды, что ускоряло принятие решений. Однако также отмечалось, что при чрезмерном использовании коммуникация через LLM может стать слишком безличный или не хватает критически важного контекста, который мог бы дать человеческий диалог. Один из респондентов отметил, что полностью сгенерированное ИИ-резюме иногда упускает «тон» решения (например, было ли оно спорным или достигнуто легко). Однако в целом наблюдаемый совокупный эффект оказался положительным: коммуникация стала более фактологической, а документация — более актуальной, что повысило эффективность совместной работы..

RQ2: Влияние на межфункциональное взаимодействие (разработчики, QA, PM и др.).): Интеграция LLM представляется сглаживать кросс-функциональные взаимодействия. В случае 2 LLM помогла наладить взаимодействие между разработчиками и менеджерами проектов за счет автоматизации отчетов и обеспечения единого представления о ходе спринта. Наш опрос показал, что тестировщики и разработчики получили пользу от общих LLM-ассистентов, способных преобразовывать требования в тестовые сценарии и наоборот. Благодаря предоставлению четких автоматизированных отчетов и обновлений статуса LLM снизили трение, часто возникающее между ролями (например, сократилось количество совещаний для получения обновлений PM, поскольку LLM предоставляла их). Другой эффект заключается в том, что LLM могут выступать в качестве нейтральной стороны для стандартизации практик — например, если LLM используется для соблюдения стандартов кодирования или генерации тестовых случаев, она обеспечивает согласованное качество, с которым согласны и разработчики, и тестировщики. Это снижает потенциальные конфликты или обвинения (ИИ становится инструментом, который команда использует коллективно). Было отмечено, что важно следить за тем, чтобы ИИ не смещался непреднамеренно в пользу одной из ролей; например, если обучающие данные ориентированы на разработчиков, это может привести к недостаточному вниманию к документации, критически важной для тестирования или проектирования. Тем не менее, при правильной настройке LLM улучшили синхронизацию между ролями благодаря обновлениям в реальном времени и общим базам знаний, доступным для всех..

RQ3: Влияние на практики документирования: LLMs оказывают здесь значительное влияние, в целом повышение уровня и актуальности документации. Наши результаты согласуются с выводами Dvivedi и др.. сообщалось [3]: LLM могут быстро генерировать высококачественные комментарии к коду и документацию API. На практике команды отмечали использование LLM для создания черновиков архитектурных документов, руководств пользователя или даже сообщений коммитов. В результате задачи по документированию — часто откладываемые из-за нехватки времени — теперь частично выполнялись ИИ, что привело к увеличению доступной документации. Разработчики в опросе отмечали, что им стало проще писать проектные документы, имея «первый набросок» от LLM для редактирования, вместо того чтобы начинать с нуля. Кроме того, LLM, интегрированные в процесс код-ревью, автоматически указывали на отсутствующие комментарии или устаревшие разделы README, побуждая разработчиков обновлять документацию в рамках обычного рабочего процесса. Как следствие, документация проектов становилась более актуальной и точной. Один разработчик написал, “Наша вики никогда не устаревала, потому что ИИ предупреждал нас, когда изменения в коде не соответствовали документации, что было чрезвычайно полезно..” Однако существует кривая обучения: командам требовалось проверять корректность документации, сгенерированной LLM. Первоначально были отмечены некоторые неточности (LLM мог некорректно описывать функцию, если контекст кодовой базы был недостаточным). Но с итеративной обратной связью эти проблемы уменьшились. Вывод заключается в том, что LLM служат эффективными помощниками в документации, сокращая ручной труд и улучшая обмен знаниями внутри команды..

Подводя итог анализа исследовательских вопросов: LLM при продуманной интеграции положительно влияют на командную коммуникацию, обеспечивая ясность и согласованность, помогают согласовывать действия кросс-функциональных членов команды с общими артефактами и обновлениями, создаваемыми ИИ, а также значительно упрощают документирование за счет его автоматизации и мониторинга. Эти улучшения способствуют более эффективной командной работе и результативности проектов, что подтверждается нашими кейсами (более продуктивные встречи, сбалансированная нагрузка и своевременное документирование). В следующих разделах мы рассматриваем ограничения и риски (Threats to Validity) и предлагаем направления для будущих исследований с целью дальнейшего использования LLM в совместной разработке программного обеспечения..

IX Угрозы валидности

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

• Разнообразие выборки: Одна из угроз заключается в том, что наши наблюдения могут быть искажены из-за специфики изученных команд (оба кейса были взяты из схожего организационного контекста) или респондентов, участвовавших в опросе. Если выборка не репрезентативна для более широких отраслевых условий, выводы могут не обладать обобщаемостью. Чтобы минимизировать этот риск, мы стремились включить данные от команд, работающих над разными типами проектов (защита корпоративных данных против разработки мобильных приложений) и с различным составом. В будущих исследованиях включение команд из разных отраслей, масштабов проектов и географических регионов позволит повысить обобщаемость. Мы также опирались на опубликованную литературу, охватывающую широкий спектр сценариев, чтобы подтвердить наши выводы, тем самым избегая излишней узости исследования..

• Конструктная валидность (метрики): Мы выбрали определенные показатели для измерения влияния (например, процент выполнения задач, сокращение продолжительности встреч, точность документации), но если они не полностью отражают «качество совместной работы», наша оценка может быть неполной. Мы согласовали наши метрики оценки с ключевыми аспектами совместной деятельности: продуктивность (количество строк кода или выполненных задач), ясность коммуникации (время встреч и отзывы о понятности в опросах) и качество документации (актуальность, проверка полноты). Используя множественные формы доказательств (количественные метрики и качественные отзывы), мы стремились охватить эти аспекты более точно. В будущих исследованиях можно внедрить более стандартизированные метрики или даже объективные оценки креативности/коммуникации для измерения влияния LLM на командную работу..

• Внутренняя валидность (причинно-следственная связь)): При наблюдении улучшений в производительности команды после внедрения LLM необходимо с осторожностью относить причину исключительно к использованию LLM. Другие факторы (эффекты обучения со временем, параллельные улучшения процессов или просто более усердная работа членов команды) могли внести вклад. Мы попытались изолировать влияние LLM, сравнивая базовые метрики до и после внедрения LLM, а также собирая субъективные оценки команды (например, спрашивая, считают ли они, что улучшения связаны с инструментом). Тем не менее, неконтролируемые переменные остаются угрозой. Мы не можем однозначно доказать, например, что увеличение своевременной поставки было только из-за назначения задач LLM — также возможно, что команда стала лучше оценивать. Мы попытались минимизировать этот эффект путем сравнения на коротких временных интервалах и поддержания других процессов неизменными в течение периода наблюдения..

• Экологическая валидность (реалистичность условий)): Наше исследование проводилось в реальных командных условиях, что повышает экологическую валидность по сравнению с лабораторным исследованием. Однако одной из угроз является возможное изменение поведения команд из-за осознания факта наблюдения («эффект Хоторна»). Мы сделали наблюдение максимально ненавязчивым и интегрировали вопросы в их обычные ретроспективы, чтобы минимизировать этот эффект. Другой аспект реалистичности — сохранятся ли наши результаты в условиях типичного проектного давления: дедлайнов, ответственных релизов и т. д. Отметим, что в обоих случаях присутствовало некоторое давление сроков (особенно в консалтинговых проектах с обязательными поставками для клиентов), поэтому LLM тестировались в достаточно реалистичных условиях. Тем не менее, результаты могут отличаться в условиях экстремально высокого давления или в проектах, связанных с безопасностью..

• Конфиденциальность данных и этика: Практической угрозой для продолжения подобных исследований является конфиденциальность данных, используемых LLM. Некоторые участники могли ограничивать свои ответы или использование LLM из-за корпоративных политик обмена данными (как видно из первоначальных колебаний в Кейсе 1). Это может ограничить применение или выявить лишь частичные эффекты. Мы преодолели эту проблему, тесно сотрудничая с командами для обеспечения соответствия их политикам и фокусируясь на аспектах, которые они готовы обсуждать. Стоит отметить, что такие компании, как Samsung, запретили использование генеративных инструментов ИИ после утечек конфиденциальных данных [8], что может ограничить степень обобщаемости наших позитивных кейсов — некоторые команды просто не будут использовать LLM вовсе, пока эти проблемы не будут решены..

В заключение, хотя наше исследование предоставляет полезные выводы, оно не лишено ограничений. Мы стремились обеспечить применимость результатов в различных контекстах за счёт диверсификации источников данных и тщательного выбора критериев оценки. Однако интерпретация результатов должна учитывать указанные угрозы валидности. Дальнейшие исследования с бо́льшими выборками, контролируемыми экспериментами и межотраслевыми сравнениями помогут дополнительно подтвердить (или уточнить) сделанные здесь выводы..

X Будущие исследования

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

Предметно-ориентированная настройка: Одним из ключевых направлений является улучшение методов настройки или дообучения LLM для конкретных предметных областей и корпоративных контекстов. Готовые LLM могут не понимать жаргон или специфические рабочие процессы каждой команды. Методы эффективного дообучения или few-shot обучения на данных предметной области помогут LLM обеспечивать более точную и релевантную помощь. Например, обучение LLM на внутренней базе знаний компании и репозитории кода (с соблюдением конфиденциальности) может значительно повысить её полезность. Недавние отраслевые инициативы, такие как BloombergGPT (50-миллиардная модель, обученная на финансовых данных), продемонстрировали эффективность специализированных LLM в превосходстве над универсальными моделями при выполнении узкоспециализированных задач [9]. Мы прогнозируем, что всё больше организаций будут разрабатывать собственные адаптированные LLM для таких областей, как здравоохранение, автомобилестроение или корпоративное программное обеспечение, которые смогут бесшовно интегрироваться в их инструменты SDLC и говорить на "языке" их команд..

Протоколы конфиденциальности и безопасности: Как отмечалось, проблемы конфиденциальности являются основным препятствием для внедрения LLM во многих компаниях. Будущие исследования должны быть сосредоточены на технических и процедурных решениях, позволяющих использовать LLM в чувствительных средах. Это включает локальное развертывание LLM (чтобы данные никогда не покидали компанию), методы продвинутой анонимизации данных и детализированный контроль доступа к инструментам ИИ. Исследования в области машинного обучения с сохранением конфиденциальности (такие как федеративное обучение или шифрование при запросах к модели) могут позволить командам использовать LLM для проприетарного кода без риска утечек. Разработка четких руководств и стандартов соответствия для применения LLM в разработке программного обеспечения (аналогично тому, как регулируется лицензирование открытого исходного кода) также повысит уровень доверия. Например, открытым остается вопрос о том, как предотвратить непреднамеренное включение лицензированного кода в предложения LLM — могут потребоваться инструменты для обнаружения и удаления такого контента..

Интеграция инструментов и проектирование рабочих процессов: Крупные языковые модели (LLM) окажутся наиболее полезными при их бесшовной интеграции в существующие инструменты разработки (IDE, системы контроля версий, чаты, трекеры задач). Будущие исследования могут изучить лучшие практики проектирования пользовательского интерфейса и опыта взаимодействия (UI/UX) для ИИ-ассистентов в этих контекстах — например, как LLM должна представлять свои предложения в pull request, чтобы разработчики доверяли им и проверяли их? Каков оптимальный способ интеграции LLM в agile-доски (возможно, автоматическое создание и обновление задач)? По мере того, как всё больше интегрированных сред разработки (JetBrains, Visual Studio и др.) и платформ для совместной работы (Slack, Teams) добавляют функции ИИ, изучение их влияния на командный поток и способов минимизации нарушений станет критически важным. Одна из концепций — проактивные ИИ-ассистенты, которые отслеживают активность разработки и предлагают помощь только в подходящий момент (чтобы избежать постоянных прерываний). Предварительные исследования показывают, что интеллектуальная оркестровка многокомпонентных систем LLM может быть масштабирована за пределы программирования на такие задачи, как проектирование и обслуживание, с многообещающими результатами [5]; встраивание таких оркестровок в инструменты удобным для пользователя способом станет инженерной задачей..

Обучение пользователей и принятие технологий: Внедрение LLM в команды — это в равной степени вопрос управления изменениями среди людей, как и технический аспект. Будущие исследования могут изучить, как лучше всего обучать команды разработчиков совместной работе с ИИ. Какие педагогические подходы повышают доверие разработчиков к предложениям ИИ, сохраняя при этом их бдительность к ошибкам? Возможно, потребуются корпоративные программы обучения, ориентированные на навыки «разработки с поддержкой ИИ» — по сути, обучение разработчиков, тестировщиков и менеджеров тому, как интерпретировать выводы LLM, как создавать эффективные промпты (prompt engineering как навык) и как проверять вклад ИИ. Понимание факторов, влияющих на принятие пользователями (на основе моделей принятия технологий и т. д.), поможет в проектировании функций ИИ, которые команды охотно внедряют, а не отвергают. Лонгитюдные исследования могут измерить, как со временем меняется восприятие инструментов LLM в командах и какая поддержка или улучшения необходимы для обеспечения их постоянного и эффективного использования..

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

Преодоление ограничений и ошибок LLM: Наконец, необходимы дальнейшие исследования по обработке ошибок и сбоев LLM в командном контексте. Некорректное предложение кода или вводящее в заблуждение резюме документации могут вызвать задержки или даже критические ошибки. Методы, такие как самоконтроль ИИ, когда LLM может отмечать собственную неопределенность, или гибридные рабочие процессы проверки человеком и ИИ (например, ИИ выполняет 90% документации, но человек всегда утверждает её), останутся важными. Разработка методов систематического выявления галлюцинаций или некорректных утверждений в выводах LLM (возможно, с помощью вторичных моделей верификации или перекрестной проверки кода) повысит надежность. Установление доверия через прозрачность (например, показ исходных ссылок на информацию, предоставляемую LLM, как это делают некоторые генераторы документации) позволит командам увереннее полагаться на эти инструменты..

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

XI Заключение

Интеграция Large Language Models в жизненный цикл разработки программного обеспечения оказывает трансформационное влияние на командное взаимодействие и общую продуктивность. В данной работе мы обновили и расширили первоначальное исследование, чтобы отразить современное состояние на 2025 год, изучив, как LLM, такие как GPT-4, влияют на способы совместной работы команд разработчиков..

Наши результаты показывают, что LLM значительно улучшают различные аспекты SDLC за счет автоматизации повторяющихся и трудоемких задач. Например, ассистенты генерации кода могут создавать шаблонный код или предлагать реализации, позволяя разработчикам сосредоточиться на более сложных и творческих аспектах разработки. Такая автоматизация не только ускоряет процесс разработки (что подтверждается более быстрым выполнением задач разработчиками с помощью ИИ [2]), но и повышает эффективность процессов, таких как ревью кода и тестирование. LLM могут выполнять предварительный анализ кода, проводить статические проверки или даже генерировать модульные тесты, выступая в роли постоянно активного парного программиста, увеличивающего пропускную способность..

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

Крупные языковые модели (LLM) также способствуют принятию более обоснованных решений в рамках программных проектов. Они могут предоставлять основанные на данных рекомендации и предложения по выбору архитектуры, потенциальным оптимизациям или областям риска, опираясь на обширный корпус знаний, на котором они обучались (включая лучшие практики программирования и известные подводные камни). Например, LLM может предупредить команду, если определенный подход известен своей плохой масштабируемостью или если существуют известные проблемы безопасности, выступая в роли экспертного консультанта по запросу. Хотя человеческое суждение остается критически важным, такие ИИ-перспективы обогащают процесс принятия решений дополнительными аспектами и фактами, которые команда могла упустить из виду..

Распределение ресурсов и управление задачами представляют собой дополнительные направления для совершенствования. Оптимизируя рабочие процессы — например, автоматически назначая задачи или выделяя препятствия — инструменты на основе LLM помогают руководителям проектов и командам более эффективно использовать свое время. Мы обнаружили, что ИИ-ассистент в управлении проектами способен оптимизировать распределение задач и напоминать команде о pending items, обеспечивая более сбалансированную нагрузку и своевременное выполнение задач. Это позволяет руководителям-людям уделять больше внимания стратегическому планированию и наставничеству, вместо того чтобы погружаться в микроменеджмент..

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

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

Однако, как показано в наших перспективных направлениях исследований, эти проблемы решаются за за счёт текущих разработок и совершенствования методологий. Благодаря целенаправленному обучению, чётким политикам и развивающимся технологиям (таким как методы снижение галлюцинаций или предоставление ссылок на источники), многие текущие ограничения могут быть смягчены. Например, для решения проблемы адаптации к предметной области можно использовать специализированные модели меньшего масштаба или генерацию с усилением выборкой, чтобы LLM всегда имел под рукой релевантные знания проекта без необходимости внешнего раскрытия исходных данных..

В заключение, Large Language Models стали мощными союзниками в командах разработчиков программного обеспечения, обеспечивая ощутимое повышение продуктивности, качества коммуникации и принятия решений. Благодаря автоматизации рутинных задач и выполнению функций интеллектуальных ассистентов, LLM позволяют участникам команд сосредоточиться на инновациях и решении сложных проблем, тем самым повышая общую результативность коллектива. На обновленных кейсах и литературных источниках мы продемонстрировали, как эти эффекты проявляются и приносят пользу реальным проектам. Впереди — решение выявленных проблем, но траектория очевидна: LLM станут неотъемлемой частью инструментария совместной работы в разработке ПО, подобно системам контроля версий или continuous integration сегодня. Осознанное внедрение этих инструментов и устранение их ограничений помогут командам достичь новых уровней эффективности и креативности в процессе разработки..

Приложение: Анкета опроса

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

Раздел 1: Общая информация

1. Какова ваша текущая роль в организации?

2. Как долго вы используете LLM в своей работе??

Раздел 2: Влияние на рабочий процесс

1. Каким образом LLM изменили ваш подход к выполнению повседневных задач??

2. Помогли ли LLM повысить вашу эффективность на работе? Если да, то каким образом??

3. Вы полагаетесь на LLM для генерации кода или отладки? Насколько эффективны эти инструменты??

4. Сократили ли LLM время, которое вы тратите на изучение новых технологий или языков??

Раздел 3: Влияние на коммуникацию

1. Повлияло ли использование LLM на ваше взаимодействие с членами команды? Как?

2. Используете ли вы LLM для помощи в написании документации или отчетов? Как это повлияло на вашу рабочую нагрузку??

3. Как LLM повлияли на ясность и эффективность ваших письменных коммуникаций??

Раздел 4: Коллаборация и принятие решений

1. Каким образом LLM повлияли на процесс принятия решений в вашей команде??

2. Изменили ли LLM способ вашего взаимодействия с командой? Если да, то каким образом??

3. Вы считаете, что LLM способствуют или препятствуют взаимодействию между членами команды? Пожалуйста, уточните..

Раздел 5: Проблемы и ограничения

1. С какими трудностями вы столкнулись при интеграции LLM в рабочий процесс??

2. Сталкивались ли вы с какими-либо ограничениями LLM, влияющими на вашу продуктивность??

3. Как вы преодолеваете проблемы или ограничения, связанные с LLM, в повседневных задачах??

Раздел 6: Общее влияние и рекомендации

1. В целом, как бы вы оценили влияние LLM на вашу продуктивность и удовлетворённость работой??

2. Какие улучшения или функции вы предложили бы для LLM, чтобы они лучше поддерживали вашу работу??

3. Считаете ли вы, что LLM будут продолжать играть значительную роль в ваших будущих проектах? Почему да или почему нет??

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