Технический долг ИИ в коде, написанном агентами

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

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

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

Измеряйте остаток, а не авторство

Технический долг описывает будущие затраты, созданные сегодняшним проектным решением. Квадрант технического долга Мартина Фаулера добавляет различие, которое по-прежнему нужно командам: долг бывает намеренным или непреднамеренным, разумным или безрассудным. Код агента не создает пятой категории. Он меняет скорость распространения решения и упрощает ситуацию, в которой никто не чувствует ответственности за него.

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

У этого различия есть практическое следствие. Не создавайте корзину ai_debt, куда навсегда отправится каждое непопулярное изменение. Применяйте одинаковые показатели сопровождаемости ко всему репозиторию, а участие агента оставьте диагностической меткой. ISO/IEC 25010 делит сопровождаемость на модульность, повторное использование, анализируемость, изменяемость и тестируемость. Эти названия полезнее единой оценки качества, потому что показывают, какая будущая задача причинит боль.

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

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

У сгенерированного кода повторяются характерные следы

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

Первый след - локальная правильность при общем дублировании. Агент видит текущий файл и пишет рабочую вспомогательную функцию, хотя похожая функция уже есть в другом месте. Простой поиск клонов находит буквальные копии. Дороже обходится смысловое дублирование: несколько валидаторов описывают одно бизнес-правило под разными именами и с разными крайними случаями. Отслеживайте повторяющиеся блоки с помощью jscpd или PMD CPD, затем проверяйте крупнейшие новые группы. Не ставьте цель свести показатель к нулю. Сгенерированные клиенты, фикстуры и миграции требуют явных исключений, чтобы сигнал описывал код, который люди сопровождают.

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

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

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

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

Исходная линия не дает цифрам лгать

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

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

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

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

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

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

Ежемесячная процедура занимает одну рабочую сессию

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

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

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

#!/usr/bin/env bash
set -euo pipefail
commit=$(git rev-parse HEAD)
code_files=$(git ls-files '*.ts' '*.tsx' ':!:vendor/**' ':!:dist/**')
printf 'metric\tvalue\tcommit\n' > debt-signals.tsv
printf 'tracked_code_files\t%s\t%s\n' "$(printf '%s\n' "$code_files" | sed '/^$/d' | wc -l | tr -d ' ')" "$commit" >> debt-signals.tsv
printf 'suppression_markers\t%s\t%s\n' "$(printf '%s\n' "$code_files" | xargs grep -E 'eslint-disable|ts-ignore|TODO|FIXME' 2>/dev/null | wc -l | tr -d ' ')" "$commit" >> debt-signals.tsv
npx jscpd -l 8 -k 60 -r json -o reports .

Форма вывода намеренно скучная: metric, value и commit, а за ними строки вроде suppression_markers, 37 и хеша коммита. JSON от jscpd остается отдельным артефактом, потому что число без расположения файлов не помогает исправлению. В настоящем конвейере замените npx закрепленным локальным исполняемым файлом. Изменение версии анализатора может создать тренд, даже если код не изменился.

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

Цена ревью должна быть в оценочной таблице

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

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

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

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

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

Полезный качественный показатель - время восстановления картины. Дайте инженеру, который не писал изменение, его задачу, diff и тесты, затем попросите объяснить поведение и вероятные способы отказа. Запишите, где понадобился внешний контекст. Не нужно делать это для каждого изменения. Несколько образцов с сильным влиянием обнаружат сгенерированную косвенность, которой не видят статические метрики.

Зависимости и конфигурация несут скрытый долг

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

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

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

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

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

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

Сгенерированные тесты способны скрыть риск

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

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

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

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

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

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

Оценочной таблице нужны решения, а не общий балл

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

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

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

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

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

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

Исправьте процесс до того, как обвинять модель

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

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

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

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

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

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