7.2 Измерение разработки программного обеспечения с помощью ИИ

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

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

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

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

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

• Измеряйте помощь ИИ по результату, а не по объёму выработки или сообщаемой поставщиком статистике использования. Дисциплина темы 1.3 применяется здесь с полной силой.
• Используйте подлинную сравнительную группу, где осуществимо, а не только сравнение до-и-после, которое может исказить растущая общеотраслевая базовая линия.
• Самостоятельно сообщаемая экономия времени слабый сигнал сама по себе. Сочетайте её с объективными данными времени цикла и качества.
• Измеряйте полную стоимость, включая время обзора и исправления, а не только скорость генерации.
• Разные задачи и разные инженеры могут видеть очень разную ценность помощи ИИ. Избегайте единого, смешанного общеорганизационного числа, скрывающего эту вариацию.

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

Стройте подлинное сравнение, а не только снимок до-и-после

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

Измеряйте время цикла и качество вместе, никогда одно лишь заявление о скорости помощи ИИ

Применяйте дисциплину темы 2.6 и темы 2.10 напрямую: отслеживайте, движется ли работа с помощью ИИ быстрее через стадии времени цикла, и одновременно движется ли доля неудачных изменений или доля утёкших дефектов (тема 5.1) для этой работы в неправильном направлении. Подлинный прирост продуктивности показывает более быстрое время цикла со стабильным или улучшенным качеством; ложный прирост показывает более быстрое время цикла с деградирующим качеством, именно тот обмен, против которого предупреждала тема 7.1, раскрытый здесь через ту же дисциплину сочетанной метрики, которую эта книга применяет на протяжении всего изложения.

Включайте время обзора и исправления в полный учёт стоимости

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

Относитесь к самостоятельно сообщаемой экономии времени как к исходной гипотезе, а не выводу

Самостоятельное сообщение разработчика «это сэкономило мне час» полезно как начальный сигнал и как качественный контекст (сочетанный количественно-качественный подход темы 5.3 применяется и здесь), но оно подвержено тем же искажениям памяти и желательности, против которых предупреждает тема 1.5 для любых самостоятельно сообщаемых данных, и оно ничего не говорит о последующей стоимости обзора или исправления. Используйте самостоятельное сообщение для генерации гипотез о том, где помощь ИИ помогает больше всего, затем проверяйте эти гипотезы против объективных данных времени цикла и качества, прежде чем сделать твёрдый вывод.

Сегментируйте измерение по типу задачи и избегайте единого смешанного числа

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

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

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

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

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

1. Была ли у нас, или могли бы мы всё ещё построить, подлинная сравнительная группа для оценки принятия нашего инструментария ИИ, или мы полностью полагаемся на сравнение до-и-после? Если истинная сравнительная группа никогда не была установлена, обсудите, могла бы историческая базовая линия контрольной карты всё ещё предоставить разумно строгую альтернативу.

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

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

4. Какие заявления о самостоятельно сообщаемой экономии времени мы собрали, и проверили ли мы какие-либо из них против объективных данных? Выберите конкретное, часто повторяемое заявление и проверьте, фактически ли его поддерживают объективные данные.

5. Смешивает ли наше текущее измерение все типы задач в одно число, или мы знаем, какие конкретно категории работы видят сильнейшую ценность помощи ИИ? Если смешано, обсудите, что могла бы раскрыть разбивка, сегментированная по задаче, что скрывает текущее число.

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

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

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

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

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

Государство. Решения об общественных технологических расходах, включая закупку инструментария ИИ, часто сталкиваются с особым контролем и могут требовать формального обоснования затрат и выгод (тема 5.5). Встройте дисциплину измерения, которую рекомендует эта тема, в любую пилотную фазу с самого начала, поскольку строгая, задокументированная методология оценки значительно укрепляет итоговый кейс финансирования или закупки.

Примеры

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

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

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

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

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

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

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

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

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

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

1. Какое подлинное сравнение, если таковое есть, у нас есть для нашего текущего принятия инструментария ИИ?
2. Измеряли ли мы время цикла и качество вместе, или только заявление о скорости?
3. Какое самостоятельно сообщаемое заявление о помощи ИИ нам следует проверить против объективных данных?
4. Какая конкретная категория задач показывает сильнейшее доказательство подлинной ценности помощи ИИ для нас?
5. Могли бы мы сейчас защитить нашу инвестицию в инструментарий ИИ перед скептической финансовой заинтересованной стороной с доказательством?

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

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

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

• Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким (дисциплина измерения результата, которую эта тема применяет к оценке инструментария ИИ).
• Исследование GitHub по парному программированию с ИИ и продуктивности разработчиков (эмпирическое исследование отраслевого масштаба результатов разработки с помощью ИИ).
• Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021) (многомерная дисциплина измерения, которую эта тема применяет к конкретной новой категории инструментария).
• How to Measure Anything, Дуглас У. Хаббард (построение защитимых сравнений и количественное измерение ценности в условиях подлинной неопределённости).