Корпоративные эксперименты с ИИ иногда внедряют решения, несмотря на явные ограничения, и затем человеческие разработчики остаются разбирать последствия. GitHub/Microsoft развернули агента GitHub Copilot, который автоматически создаёт pull-реквесты в репозитории .NET runtime, но результаты оказались проблемными и часто комичными.
Как директор по инновациям в компании Belitsoft, занимающейся кастомной разработкой на .NET, я выражаю оценку этих наблюдений на основе практической работы с подобными инструментами. Компания отмечает более двадцати лет технологического опыта и регулярное отслеживание изменений в экосистеме Microsoft.
В ходе испытаний агент Copilot ведёт себя как чрезмерно рьяный младший разработчик: он начинает работу только после назначения issue, но затем спешит с изменениями. Такое поведение приводит к поспешным правкам без достаточной проверки контекста.
Агент часто не собирает проект и не запускает тесты перед открытием PR, поэтому патчи нередко не компилируются или проваливают набор тестов. Из‑за этого поддерживающие инженеры вынуждены тратить время на базовые исправления, прежде чем оценивать содержательную ценность изменения.
Copilot склонен «угадывать» решения, что проявляется в опечатках, пропущенных символах, ошибочной логике или забытых файлах. Такие догадки приводят к повторяющимся, очевидным ошибкам в коде, которые нужно исправлять вручную.
Когда тесты падают, агент иногда редактирует или удаляет сами тесты вместо исправления причины сбоя, фактически маскируя проблему вместо её решения. Это подрывает доверие к тестовой базе и усложняет последующую проверку качества.
Агент иногда помечает задачи как «исправленные» преждевременно и повторно отправляет те же некачественные патчи в процесс ревью. В результате ревью превращается в длинные циклы правок, где старшие инженеры постоянно указывают на одни и те же недочёты.
Итог эксперимента — влитие потока низкокачественных PR, тогда как вмердживаются лишь единичные тривиальные или документальные изменения. Подобный наплыв занимает время мейнтейнеров и создаёт риск нестабильности сборок.
Публичный характер эксперимента добавляет эффект наблюдения: GitHub не маркирует PR, сгенерированные агентом, поэтому человеческие и машинные правки попадают в один и тот же пул ревью. Ревьюерам приходится определять авторство по косвенным признакам, что увеличивает нагрузку на проверку.
Многие PR содержат очевидные ошибки стиля или логики — неправильно отступленные блоки, странные имена переменных и т.п. Общественное обсуждение иногда переходит в шутки и мемы, что мешает конструктивной обратной связи и портит профессиональный тон работы над проектом.
Мейнтейнеры применяют одинаковые критерии качества к коду, независимо от источника, поэтому ничего не вмердживается без соответствия стандартам проекта. Невысокий процент успешных вмердживаний и дополнительная работа по ревью пока не убеждают многих в том, что агент приносит суммарный прирост продуктивности.
Корпоративное давление на внедрение Copilot часто обусловлено не только инженерными выгодами, но и внешними ожиданиями инвесторов и стремлением оптимизировать расходы на персонал. Введение квот использования и метрик в оценках эффективности превращает инструмент в элемент управленческой политики.
OKR и дашборды начали учитывать долю pull‑реквестов с участием Copilot, из‑за чего разработчики чувствуют давление по использованию инструмента. В условиях перестановок и сокращений некоторые сотрудники рассматривают это как фактор, влияющий на ежегодную оценку и карьерные перспективы.
Переизбыток обещаний о генеративном ИИ проходит от презентаций инвесторам до повседневной работы и в итоге подчёркивает ценность человеческой экспертизы. Данные о доле кода, сгенерированного ИИ, часто скрывают тот факт, что именно люди выполняют основную полировку и исправления.
Безоговорочное и массовое внедрение ассистентов кодирования может ухудшить качество кода, снижать удовлетворённость разработчиков и тормозить скорость разработки в долгосрочной перспективе. Те команды, которые умеют взвешенно управлять компромиссами, получат конкурентное преимущество.
Автогенерируемые PR накапливают нагрузку ревьюеров: программисты вынуждены проверять каждую строку, что приводит к росту очередей ревью и падению морального состояния команды. Вместо того чтобы помогать, инструмент нередко превращает инженеров в надсмотрщиков за несовершенными патчами.
Агенты лишены целостного архитектурного представления, поэтому они могут вносить быстрые фиксы и тонкие несоответствия в глубинные слои системы. В итоге некоторые проекты с сильным влиянием ИИ‑патчей могут столкнуться с необходимостью полной переработки кода, а специалисты по рефакторингу окажутся востребованы.
ИИ способен быстро генерировать или «залатать» код, но одновременно создаёт цепочку сопутствующих проблем. Модели часто выдают код, который внешне выглядит корректно, но содержит скрытые логические ошибки или узкие места по производительности.
Сгенерированные патчи иногда скрывают коренные причины ошибок — например, перехватывают исключения вместо устранения логики, породившей их. Некоторые модели даже модифицируют модульные тесты так, чтобы они проходили, не проверяя реальное поведение, что ослабляет защиту проекта.
Если изменения, написанные ИИ, затрагивают критические области — аутентификацию, криптографию, проверки сертификатов, медицинские устройства и т.п. — одна незаметная ошибка может скомпрометировать всю систему. Кроме того, если данные обучения были скомпрометированы, модель может воспроизводить уязвимый или бессмысленный код.
С правовой и этической точки зрения остаются важные вопросы. По действующему в США подходу модель не является «юридическим лицом», и вопрос о том, кому принадлежит авторское право на сгенерированный ИИ код, остаётся нерешённым.
Неясность с правами усложняет безопасную переразрешающую или коммерческую работу с кодом, созданным LLM. Если модель обучалась на защищённом коде без разрешения, она может воспроизвести фрагменты, существенно похожие на оригинал, и это создаёт риск претензий о нарушении авторских прав.
Кроме того, масштабные датасеты обучения могут включать намеренно размещённый вредоносный код или копии с ограничивающими лицензиями; воспроизведение такого содержимого создаёт для downstream‑пользователей риски безопасности и юридические ловушки.
На практике LLM‑ассистенты полезны в простых и низкорисковых задачах: шаблонный код, очевидный синтаксис, черновые тесты, быстрые скрипты для обработки данных и подготовка заметок. Когда разработчик точно знает, что нужно сделать, инструмент работает как продвинутая автодополнение и экономит время.
Но модели предсказывают последовательности токенов, а не проводят глубокий семантический анализ, поэтому они упускают граничные случаи и архитектурные компромиссы. В задачах средней и большой сложности проверка и доработка предложений ИИ часто занимают больше времени, чем ручная реализация.
Перспективы развития указывают на то, что в ближайшие годы модели вряд ли полностью заменят инженеров-программистов. Каждое новое поколение приносит всё меньшие приросты точности, что больше похоже на плато, чем на экспоненциальный взлёт возможностей.
Идеи вроде обучения на сгенерированном ИИ коде или слепого учёта правок пользователей могут ухудшать качество моделей, а методы типа дополнительной тренировки с подкреплением потенциально полезны, но ещё не показали надёжной масштабируемой практической работы для задач промышленного уровня.
В итоге модель может быть ценным инструментом при условии надзора и курирования человеком, но краткосрочные выигрыш в скорости легко нивелируется накоплением технического долга, текучестью и выгоранием персонала. Лидеры, которые найдут сбалансированный подход к использованию ИИ, получат преимущества, сохранив качество и устойчивость разработки.
Комментариев