7.1 Смена парадигмы генеративного ИИ

Обзор и мотивация

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

Центральное утверждение этой темы в том, что это смена парадигмы, а не постепенное изменение инструментария. Смена парадигмы меняет то, что фактически измеряют ваши существующие инструменты, а не просто значения, которые они сообщают. Спидометр всё ещё измеряет скорость после того, как вы меняете двигатель автомобиля; несколько метрик этой книги не переживают этот переход так чисто. Частота развёртывания (тема 2.10) может расти, потому что ИИ ускорил подлинно ценную работу, или потому что ИИ сделал тривиально лёгким генерировать много мелких, низкоценных изменений; одно число больше не может отличить одно от другого так, как могло в основном, с соответствующей осторожностью, раньше. Та же логика применяется с ещё большей силой к сырым счётчикам коммитов, строкам кода и объёму запросов на слияние, против всех которых тема 3.4 уже предупреждала как против отдельных метрик, теперь усиленных в риск, релевантный также на уровне команды и организации.

Для крупных команд этот сдвиг прибыл быстрее, чем практика измерения большинства организаций могла к нему адаптироваться, и пробел между скоростью принятия и адаптацией измерения это то место, где живёт реальный риск этой части. Корпоративные организации, продолжающие сообщать метрики активности эры до ИИ без корректировки, рискуют праздновать метрику, тихо переставшую коррелировать с ценностью; государственные организации, оценивающие инвестицию в инструментарий ИИ, нуждаются в ясном понимании того, какие именно метрики остаются заслуживающими доверия, а какие уже нет, прежде чем принимать решения о закупках или политике, построенные на устаревших предположениях измерения.

Ключевые принципы

Это смена парадигмы в том, что измеряют метрики, а не постепенное изменение. Некоторые существующие метрики тихо перестали означать то, что они раньше означали.
Объём выработки никогда не был надёжным представителем ценности, и теперь он стал активно ненадёжным. Предупреждение темы 3.4 всегда было правильным; этот сдвиг делает его игнорирование гораздо более дорогим.
Пробел между скоростью принятия ИИ и скоростью адаптации измерения это реальный риск. Организации принимают инструментарий быстрее, чем пересматривают свои метрики.
Не каждая метрика в этой книге затронута одинаково. Метрики результата (часть 5) гораздо более устойчивы к этому сдвигу, чем метрики активности и сырой выработки.
Этот сдвиг общеотраслевой и продолжающийся, а не разовая корректировка. Ожидайте продолжающихся изменений по мере того, как инструментарий и паттерны его принятия продолжают развиваться.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Продолжать сообщать метрики до ИИ без изменений	Никаких нарушений, привычная отчётность	Рискует празднованием метрик, тихо переставших коррелировать с ценностью
Полный аудит набора метрик и сознательный пересмотр	Восстанавливает заслуживающее доверия измерение	Требует реального аналитического усилия и управления организационными изменениями
Полностью отказаться от метрик активности и выработки	Напрямую устраняет наиболее подверженный риск	Теряет некоторый законно полезный контекстуальный сигнал (оговорка темы 3.4)
Ужесточить страховочные метрики без полного аудита	Быстрее внедрить	Может упустить метрики, чья подверженность менее очевидна, чем в самых ясных случаях

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

Вопросы для обсуждения в команде

Для каждой метрики на нашей панели, показала бы команда, активно использующая помощь ИИ, но не производящая больше реальной ценности, улучшенное показание? Пройдитесь по вашим метрикам явно с этим тестом; те, что его не проходят, ваши кандидаты наивысшего приоритета для пересмотренных страховочных метрик или вывода из эксплуатации.
Выросла ли наша частота развёртывания или объём коммитов с момента принятия помощи ИИ в написании кода, и проверили ли мы, двигалась ли доля неудачных изменений или частота дефектов соответственно? Откройте фактические сочетанные данные, а не предполагайте положительный или отрицательный результат.
Поспевает ли наша мощность обзора кода за любым увеличением объёма кода с помощью ИИ, или глубина обзора тихо разрушается под возросшим давлением? Проверьте метрики стадии обзора (тема 2.9) конкретно на признаки усиления риска поверхностного одобрения.
Помечаем ли мы дефекты по тому, был ли исходный код существенно сгенерирован ИИ, и если да, что показывают эти данные пока? Если вы сейчас это не помечаете, обсудите, что потребовалось бы, чтобы начать, поскольку эти данные напрямую релевантны тому, держатся ли всё ещё ваши исторические предположения о качестве.
Сознательно ли мы пересмотрели наш устав метрик (тема 1.4) в свете этого сдвига, или наша практика измерения просто продолжилась без изменений? Если честный ответ второе, этот пробел именно то, что эта тема рекомендует закрыть в первую очередь.
Как бы выглядело для нашей организации быть застигнутой врасплох этим сдвигом, празднуя метрику, уже переставшую означать то, что мы думали, что она означает? Этот конкретный, слегка неудобный мысленный эксперимент помогает мотивировать аудит, который рекомендует эта тема, до, а не после того, как этот сценарий фактически произойдёт.

Отраслевой взгляд

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

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

Корпорация. Масштаб этого риска значительно усугубляется здесь, поскольку принятие ИИ по десяткам или сотням команд одновременно может сдвинуть валидность метрики по всей организации до того, как какая-либо отдельная команда заметит паттерн локально. Проводите аудит набора метрик, который рекомендует эта тема, на организационном уровне, а не только команда за командой, и обновляйте управление (тема 1.4) централизованно и явно.

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

Примеры

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

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

Бизнес-кейс: мотивация, ROI и TCO

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

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

Антипаттерны и ловушки

Продолжение сообщения метрик активности эры до ИИ без изменений и некритично: рискует празднованием метрики, тихо переставшей коррелировать с реальной ценностью.
Сообщение роста частоты развёртывания или объёма выработки без сочетанной страховочной метрики стабильности: повторяет предупреждение темы 2.10 со значительно более высокими ставками при разработке с помощью ИИ.
Предположение, что сгенерированный ИИ код несёт тот же профиль дефектов, что код, написанный человеком, без проверки: непроверенное предположение, способное быть активно неправильным.
Позволение глубине обзора тихо разрушаться под возросшим объёмом сгенерированного ИИ кода: риск поверхностного одобрения из темы 2.9, усиленный.
Отношение к этому сдвигу как к разовой корректировке, а не продолжающейся заботе: инструментарий и паттерны его принятия продолжают развиваться, и практика измерения должна поспевать.
Сравнение с отраслевыми ориентирами без понимания того, сдвинулись ли сами эти ориентиры под тем же давлением: рискует ложным чувством относительной производительности.

Модель зрелости

Уровень 1, Инициация: Метрики эры до ИИ сообщаются без изменений, без осведомлённости о том, что принятие ИИ могло затронуть их валидность.
Уровень 2, Развитие: Некоторая осведомлённость о сдвиге существует, но никакой систематический аудит существующего набора метрик не был проведён.
Уровень 3, Стандартизация: Полный аудит набора метрик был проведён, со страховочными метриками, ужесточёнными, и метриками, задокументированными как затронутые или устойчивые, по всей организации.
Уровень 4, Управление: Дефекты и результаты качества активно помечаются и отслеживаются по уровню помощи ИИ, чтобы проверить, а не предположить, что исторические связи качества организации всё ещё держатся.
Уровень 5, Оркестрация: Организация имеет зрелую, продолжающуюся практику пересмотра своих метрик по мере того, как инструментарий ИИ и паттерны принятия продолжают развиваться, и может указать на конкретные решения управления, принятые проактивно в ответ на этот сдвиг, а не реактивно после того, как проблема проявилась.

Идеи для обсуждения

Какие из наших текущих метрик больше всего польстили бы команде, активно использующей помощь ИИ, но не производящей больше реальной ценности?
Выросла ли наша частота развёртывания с момента принятия ИИ, и двигалась ли с ней доля неудачных изменений?
Помечаем ли мы результаты качества по уровню помощи ИИ, и что показали бы эти данные?
Поспевает ли наша мощность обзора за любым увеличением объёма сгенерированного ИИ кода?
С каким отраслевым ориентиром мы сейчас себя сравниваем, и сдвинулся ли он сам под этим давлением?

Основные выводы

Генеративный ИИ это смена парадигмы в том, что измеряют несколько существующих метрик, а не постепенное изменение инструментария; некоторые метрики тихо перестали означать то, что они раньше означали.
Метрики активности и сырой выработки наиболее подвержены; метрики результата (часть 5) сравнительно устойчивы.
Ужесточайте страховочные метрики, особенно долю неудачных изменений, пропорционально принятию разработки с помощью ИИ.
Проверяйте, а не предполагайте, несёт ли сгенерированный ИИ код другой профиль дефектов, чем код, написанный человеком, используя помеченные данные утёкших дефектов.
Относитесь к этому как к продолжающейся, а не разовой заботе управления (тема 1.4), поскольку инструментарий и паттерны его принятия продолжают развиваться.

Источники и дальнейшее чтение

Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким (основа измерения на основе результата, которая, утверждает эта тема, становится более, а не менее важной под этим сдвигом).
Исследование GitHub по парному программированию с ИИ и продуктивности разработчиков (отраслевое исследование измеримых эффектов разработки с помощью ИИ).
Программа Google Cloud DevOps Research and Assessment, dora.dev (продолжающееся исследование State of DevOps, включающее находки о принятии ИИ в последние годы).
The Tyranny of Metrics, Джерри З. Мюллер (общий кейс для скептицизма к метрикам, основанным на объёме, напрямую релевантный по мере того, как объём выработки становится дешёвым).

7.1 Смена парадигмы генеративного ИИ

Обзор и мотивация

Ключевые принципы

Рекомендации

Явно проводите аудит вашего существующего набора метрик на валидность в эру ИИ

Пересмотрите частоту развёртывания и время выполнения конкретно, с повышенным вниманием к страховочной метрике

Относитесь к мощности обзора кода как к новому, критическому узкому месту

Не предполагайте, что сгенерированный ИИ код несёт тот же профиль дефектов, что код, написанный человеком

Явно обновите ваш устав метрик и процесс управления для этого сдвига