Как генеративный AI меняет разработку ПО

Александр открывает второй разговор с Игорем Курочкиным про отчёт DORA этого года: в прошлый раз разбирали методологию, теперь речь про сами результаты и про то, какие вопросы исследователи задавали. Игорь, который помогает большим компаниям развивать инженерную культуру и разбирает отраслевые отчёты, напоминает, что документ вырос из опроса State of DevOps 2024, дополнен глубинными интервью и инсайтами команд внутри Google.

Александр уточняет, что опубликовали его в 2025 году; по его прикидке, в нём порядка шестидесяти страниц и восемь разделов, среди которых подход DORA, понимание ландшафта и способы мерить влияние AI, воздействие на работу инженеров, большой блок про доверие, адопшен технологии и финальный список практических действий.

Уже к третьему-четвёртому разделу Александра не покидало ощущение, что он читает одно и то же с разных ракурсов. Игорь соглашается: это разные взгляды на один материал, а структура напомнила ему книгу Technology Strategy Patterns с делением на руководящие принципы и практические действия.

Дальше — индивидуальный уровень. Игорь объясняет, что авторы работают с конструктами и AI Adoption тоже конструкт: вопроса «оцените внедрение в процентах» в анкете нет, уровень собирают из пяти-шести вопросов. Главная гипотеза звучит как «что будет, если внедрение AI вырастет на 25%», и симуляция показывает, что произойдёт с выгоранием, состоянием потока, продуктивностью и двумя типами работы — полезной и тойлом.

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

Он вспоминает выступление Эндрю Ына, который когда-то создавал Coursera: в стартапах его фонда соотношение продактов и разработчиков сдвинулось с одного к трём к одному к одному, потому что узким местом стало придумывание гипотез, а не их реализация.

Тойл Игорь определяет как непродуктивную, утомительную работу: долю времени на ручные задачи, которые поддаются автоматизации, но не несут долгосрочной ценности, — операционку, отнимающую время у фич и проверки гипотез. Термин, по его словам, появился в первой книге по SRE, где описали и как его мерить, и как с ним бороться.

Александр называет это рутиной по поддержанию рабочего состояния сервиса и напоминает, что DORA с 2018 года входит в Google Cloud, а там добиваются автохилинга и автономности: иначе команда растёт пропорционально числу сервисов, а не числу изменений.

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

По результатам сильно растёт только качество документации; Александр добавляет, что качество кода и скорость тоже подрастают, и связывает это с агентами на кодревью — им можно задать критерии качества и получить почти фитнес-функции.

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

Игорь предупреждает: SonarQube и GitLab по-разному считают сложность и техдолг. Александр уточняет, что опрос отражает восприятие препятствий в работе, а не показатели этих инструментов.

Меняется и модель поставки: recovery time перенесли в скорость, а стабильность дополнили rework rate. Игорь не нашёл его источник в анкете; Александр предполагает связь с внеплановыми задачами, но обещает проверить. Точного ответа в этом фрагменте нет.

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

Александру таблица показалась инструментом менеджера: разрешить инструменты тем, кому важно делать больше; признавать вклад независимо от того, кто сгенерировал код; оценивать результат, а не потраченное время; подавать AI как повод учиться; а тем, кому важен интерес, оставлять задачи, где модели пока слабы. Сам он так никогда не действовал, считая, что инженеры разберутся, но читать было любопытно: «условному Васе» из его примера нужны то признание, то деньги, то интересная работа.

Блок про доверие Александр считает очень интересным: воспринимаемый эффект расходится с реальным, и если ассистент угадывает через раз, его начинают считать замедлением. В его компании отзывы зависят от языка — на Python подсказкам верят, на редком языке со сложным синтаксисом ругаются, — а разбора таких факторов в отчёте нет.

По приведённым в разговоре оценкам, около 60% видят рост продуктивности, порядка 30% не видят эффекта; вывод авторов в том, что чем выше доверие, тем выше продуктивность, и у Stack Overflow это тоже проблема номер один. Эту часть делали вместе с командой Engineering Productivity в Google.

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

Игорь замечает, что четыре предложенные стратегии масштабирования похожи на внедрение любого платформенного сервиса, а Александр по распределениям симуляций видит, что цели по adoption и политики использования попали в слабую часть графика: работает то, что звучит дженерик, — те же советы, что про внедрение IDP.

Из нового Игорю запомнилось переименование capability в conditions и добавленный сервисный уровень; финальный фреймворк оба считают слишком общим.