Университетская среда существенно отличается от коммерческой индустрии программного обеспечения (ПО) по своим целям, ресурсным ограничениям, организационной структуре и педагогическим задачам. Процессы разработки ПО здесь подчинены не только получению функционального результата, но и образовательным, научным и административным целям. Это накладывает специфические особенности на все этапы жизненного цикла программных продуктов: от планирования до сопровождения. Понимание этих особенностей является необходимым условием для корректной постановки задачи автоматизации с использованием ИИ-агентов, поскольку игнорирование контекста приводит к неэффективности или даже деструктивности внедряемых решений.
Ключевое отличие университетской разработки заключается в двойственности ее конечных продуктов. С одной стороны, это учебные проекты, целью которых является формирование компетенций студента. С другой — научные (в том числе исследовательские) проекты, где приоритетом становится получение нового знания или экспериментального прототипа. В обоих случаях код выступает не только как артефакт, но и как средство обучения или исследования. Как отмечают исследователи, внедрение ИИ-агентов в таких условиях сталкивается с проблемой оценки контекстно-зависимых решений: системы эффективно выявляют синтаксические ошибки и стандартные нарушения стиля, но часто неспособны оценить педагогические нюансы или обоснованность архитектурного выбора в учебном коде [3]. Более того, в учебных проектах ценность представляет не только итоговый программный продукт, но и процесс его создания, включая допущенные ошибки и их исправление. Автоматизация, которая скрывает этот процесс, может вступать в противоречие с дидактическими задачами.
В научных проектах, напротив, часто требуется непредсказуемая исследовательская траектория, что затрудняет формализацию требований — необходимую предпосылку для эффективной работы агентов. Как показано в работе [4], университетские проекты, особенно в коллаборациях с индустрией или государственными структурами, страдают от культурных и организационных различий, а также от нечеткого распределения ответственности. Это усугубляется тем, что многие университетские проекты не имеют адаптированных под их нужды процессов разработки и заимствуют практики из индустрии без необходимой модификации.
Университетские проекты практически всегда выполняются в условиях жестких бюджетных, временных и кадровых ограничений. В отличие от коммерческих организаций, университет редко может выделить на разработку полноценную производственную команду. Роли заказчика, аналитика, архитектора, разработчика и тестировщика часто совмещают преподаватели, научные сотрудники и студенты, не имеющие достаточного опыта или времени. Это приводит к тому, что даже небольшое увеличение трудоемкости на этапе интеграции или настройки инструмента автоматизации может сделать его внедрение невозможным. Как показано в исследовании внедрения системы автоматизированного код-ревью в академической среде, хотя такая система сократила время проверки преподавателем на 62 % и выявила 87 % проблем с качеством кода, ее первоначальная настройка и адаптация потребовали «существенных локальных усилий» и привели к ограничениям по охвату [3]. Технические затраты на развертывание LLM-агентов, включая вычислительные ресурсы, оплату API и обслуживание, также могут быть неподъемными для университета, если не предложены экономически эффективные модели, например, с использованием локальных моделей малого размера.
Далее, разработка ПО в университете характеризуется высокой гетерогенностью используемых инструментов и технологий. Различные кафедры, научные группы и даже отдельные курсы могут применять несвязанные друг с другом системы контроля версий, среды разработки (VS Code, Jupyter Notebook), системы управления обучением (LMS), CI/CD конвейеры и хранилища артефактов. Эта «разрозненность» создает серьезные барьеры для внедрения сквозной автоматизации на основе ИИ-агентов. Для эффективной работы агентам необходим богатый «агентно-компьютерный интерфейс», включающий доступ к файловой системе, возможность выполнения тестов и работы с командной оболочкой. Однако в условиях фрагментированной инфраструктуры обеспечение такого интерфейса для каждого отдельного проекта требует значительных интеграционных усилий. Преподаватели и сотрудники вынуждены модифицировать дизайн заданий, рабочие процессы проверки и конвейеры CI/CD для поддержки результатов, созданных с помощью ИИ, что требует времени и институциональной координации.
Исследования показывают, что для преодоления этой проблемы необходимы структурированные фреймворки, превращающие разрозненные инструменты в связный рабочий процесс [2]. Например, внедрение GitLab/GitHub-центричных рабочих процессов позволяет объединить планирование, разработку, совместную работу и развертывание для университетских ИТ-сервисов и учебных/научных сервисов, консолидируя фрагментированные инструменты в единую жизненную платформу.
Следующим отличительным пунктом становится то, что университетская разработка ПО парадоксальным образом сочетает в себе высокую творческую (исследовательскую, учебную) составляющую с большим объемом повторяющихся, рутинных задач. К последним относятся: проверка стиля оформления кода в студенческих работах, базовая оценка соответствия техническому заданию (наличие функций, корректность импортов), запуск однотипных тестов, формирование отчетов об ошибках, первичная классификация запросов на доработку и т. п. Именно эти операции создают значительную нагрузку на преподавателей и научных сотрудников, отвлекая их от содержательного анализа и наставничества. Потенциал автоматизации здесь наиболее очевиден, что подтверждается исследованиями: ИИ-ассистенты лучше всего проявляют себя при решении простых и средних по сложности задач отладки, тогда как сложные задачи по-прежнему требуют человеческого участия [1]. Однако сама по себе автоматизация рутины несет риски: чрезмерная опора на агентов при выполнении базовых операций (например, генерация кода) может привести к атрофии фундаментальных навыков программирования у студентов, если она не сопровождается перепроектированием учебных заданий для развития навыков более высокого порядка (анализ, синтез, оценка). Следовательно, внедрение автоматизации должно быть не тотальным, а выборочным, нацеленным именно на те рутинные операции, чья автоматизация не наносит ущерба педагогическому процессу.
Таким образом, анализ особенностей университетской среды — от педагогических целей учебных проектов до фрагментарности инструментальной базы и применяемых процессных моделей — показывает, что прямое перенесение коммерческих подходов к автоматизации здесь невозможно и даже вредно. Эффективная автоматизация должна учитывать двойственную природу университетских артефактов, работать в условиях жестких ресурсных ограничений, уметь взаимодействовать с разнородными инструментами, вписываться в гибридные (часто Agile-подобные) процессы и быть нацеленной на замещение рутинных операций без ущерба для фундаментального обучения. Эти выводы создают основу для последующего анализа конкретных проблем внедрения ИИ-агентов в данной специфической области.
Литература:
1. AI Assistance Variants in Software Development Cycles / C. Bakke, J. Clauss, E. Voita, M. Callahan. — Текст: непосредственный // Issues in Informing Science and Information Technology. — 2025.
2. Research Software Development & Management in Universities: Case Studies from Manchester’s RSDS Group, Illinois’ NCSA, and Notre Dame’s CRC / D. Katz, K. McHenry, C. Reinking, R. Haines. — Текст: непосредственный // 2019 IEEE/ACM 14th International Workshop on Software Engineering for Science (SE4Science). —, 2019. — С. 17–24.
3. Mrayat, O I A Implementing AI-Based Code Review Automation: A Case Study in Academic Software Development / O I A Mrayat. — Текст: непосредственный // IJAIA. — 2025.
4. Wlodarski, R. Assessment of a Hybrid Software Development Process for Student Projects: A Controlled Experiment / R. Wlodarski, J. -. Falleri, C. Parvéry. — Текст: непосредственный // 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering Education and Training (ICSE-SEET). —2021. — С. 289–299.
