[Перевод] Выжимка из исследования Echoes of AI: ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы

• Перевод и выжимка исследования Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability

• Более визуально видео с обзором исследования можно посмотреть на канале Дейва Фарли - Continuous Delivery.

О чём речь

Большинство исследований влияния ИИ на разработку измеряют одно: скорость написания кода. «На сколько процентов быстрее закрыта задача?» «Сколько строк сгенерировано за час?» По сути, мы измеряем скорость набора текста и называем это продуктивностью.

Но любой, кто работал с production-системами дольше полугода, знает: начальная разработка — это 20–50% стоимости жизни системы. Остальное — поддержка, изменения, рефакторинг, устранение дефектов. Оценки варьируются, но, как правило, расходы на поддержку превышают стоимость первоначальной разработки в 3–4 раза.

Вопрос, который почти никто не задавал: что происходит, когда другой разработчик берёт код, написанный с ИИ-ассистентом, и пытается его развивать? Именно на него отвечает исследование «Echoes of AI», опубликованное на arXiv группой авторов во главе с Маркусом Боргом (Markus Borg) при участии Дейва Фарли (Dave Farley) — того самого, из канала на youtube Continuous Delivery.

Дизайн эксперимента

Исследование отличается от типичных экспериментов несколькими важными свойствами:

• 151 участник, из них 95% — практикующие разработчики, а не студенты (именно на студентах обычно проводят исследования по AI Usage).

• Предварительно зарегистрированный алгоритм исследования (зарегистрирован для ICSME 2025 с In-Principal Acceptance).

• Две фазы, причём вторая — полноценное рандомизированное контролируемое исследование (РКИ)

Фаза 1: разработка с ИИ и без

Участникам дали RecipeFinder — намеренно «грязное» Java/Spring Boot веб-приложение (~2 000 строк), содержащее code smells, внедрённый баг и неполные юнит-тесты. Задача: добавить фичу фильтрации рецептов по времени приготовления.

Участников разбили на две группы через стратифицированную случайную выборку:

• AI-devs — работали с ИИ-ассистентами (Copilot, ChatGPT, Cursor и др.)

• !AI-devs — работали без ИИ

Фаза 2: поддержка чужого кода (RCT)

75 новых участников получали код из Фазы 1 и должны были расширить его (добавить фильтрацию по стоимости порции). Ключевые условия:

• Никакого ИИ во второй фазе.

• Участники не знали, был ли код написан с ИИ или без.

• Успешное завершение проверялось через acceptance-тесты в GitHub Actions.

Вопрос для исследования: «может ли кто-то другой работать с тем, что ты произвёл?»

Что измеряли

Для оценки поддерживаемости использовали четыре метрики:

CodeHealth от CodeScene — агрегированная метрика на основе 25+ факторов: вложенная сложность, «God Class», дублирование, примитивная одержимость, bumpy road и др. По данным CodeScene, это единственная метрика уровня кода с доказанной связью с бизнес-результатами: код с высоким CodeHealth позволяет итерировать до 2× быстрее, а риск дефектов снижается до 15× по сравнению с «красным» кодом.

Анализ данных проводился двумя методами параллельно: частотным (Wilcoxon, Welch's t-test, бутстрэп) и байесовый (линейная регрессия для CH, дробная логистическая для TC, ординальная логистическая с латентной переменной для PP).

Результаты

Фаза 1: ИИ ускоряет начальную разработку

Здесь результаты подтверждают то, что уже многократно показано в литературе:

• Все AI-devs: медианное ускорение 30,7%

• Привычные пользователи ИИ (habitual AI users): средний speedup 55,9%

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

Фаза 2: поддерживаемость — главные результаты

А вот здесь начинается самое интересное:

Более того, для кода от привычных пользователей ИИ обнаружено статистически значимое улучшение CodeHealth. Одно из объяснений: ИИ склонен генерировать «скучный», идиоматический, предсказуемый код. А скучный код — это хороший код с точки зрения поддерживаемости, потому что «сюрприз — враг maintainability».

Предупреждения: code bloat и когнитивный долг

Авторы исследования сами подчёркивают два риска, которые их метрики не полностью захватывают:

Code bloat (раздувание кода)

Когда генерация кода становится почти бесплатной, велик соблазн генерировать слишком много. Объём сам по себе — мощный драйвер сложности. ИИ делает проще, чем когда-либо, утонуть в собственной кодовой базе.

Cognitive debt (когнитивный долг)

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

Джейсон Горман (Jason Gorman) из Codemanship описывает это через эффект амнезии Гелл-Манна: «Я часто слышу: "Ну, ИИ плохо работает с языком, который я хорошо знаю, зато отлично — с тем, который знаю плохо". Чем меньше мы понимаем вывод, тем меньше замечаем проблемы».

ИИ как усилитель: связь с DORA и практиками

Результаты исследования хорошо ложатся на данные DORA State of AI-Assisted Software Development 2025. Ключевой тезис отчёта DORA: ИИ — это усилитель. Он усиливает сильные стороны высокопроизводительных организаций и дисфункции — слабых.

По данным DORA:

• 90% респондентов используют ИИ в ежедневной работе

• 80% считают, что ИИ повысил их продуктивность

• При этом стабильность доставки продолжает падать — команды ускорились, но их системы не справляются с возросшим темпом

• Подход «fail fast, fix fast» не работает как компенсация нестабильности

Команды, которые реально выигрывают от ИИ, по данным DORA, уже практиковали:

• Малые батчи — одна проблема за раз

• Быстрые итерации с непрерывным тестированием, ревью, рефакторингом и интеграцией

• Высокомодульные архитектуры с локализованным «радиусом поражения» изменений

• Организацию вокруг end-to-end результатов, а не ролевых или технологических силосов

• Высокую автономию с принятием решений на месте

Горман: «Далеко не "изменив правила игры", вероятностные ИИ-ассистенты просто добавили ещё один слой неопределённости. Та же игра, другие кости».

Больше подобных обзоров, практики внедрения ИИ и менеджменте в командах разработки в моем ТГ-канале.