AI разработка и Comprehension debt
Всем знакомо понятие технический долг. Но мы часто забываем про comprehension debt: непонятно, почему он такой.
Если техдолг живет в самих артефактах разработки, то comprehension debt находится в разрыве между артефактом и моделью системы в голове разработчиков. Код может быть чистым и покрытым тестами, но непостижимым: допущения нигде не записаны, и что сломается при их нарушении, никто не знает.
Xia проводило исследование, в котором участвовали 78 профессионалов и выявилено: 58% времени разработчика уходит на понимание кода проекта, а не на написание. Самая дорогая статья в разработке, и такой она была до всякого AI (!!!)
Что изменил AI Раньше понимание кода было побочным продуктом его написания ведь чтобы написать код, приходилось построить модель предметной области. Она получалась бесплатно, как "отход" производства. А вот AI генерация напрочь разрывает эту полезную связь. Код появляется, а модель нет. И больше этот долг не копится годами, он берётся в момент создания проекта с помощью AI.
Сухие цифры с появлением AI GitClear в независимом исследовании выявила следующие цифры на 600+ млн коммитов в период 2023–2026: перемещения строк (признак рефакторинга) −70%, кросс-файловые вызовы −35%, работа с легаси −74% к уровню 2022. При этом дублирование блоков +81%, copy/paste +41%, конструкции, маскирующие ошибки, +47%
Дублирование и падение связности это ровно те свойства, что делают систему непостижимой потому как концепция больше не определена в одном месте. При этом сам код может может быть вполне неплохим, документированным и тд
Главное свойство: "долг невидим тому, кто берёт" METR провела рандомизированное испытание, в котором 16 опытных разработчиков использовали AI на 246 реальных задачах из их собственных зрелых репозиториев, в среднем по два часа на задачу. При этом это были проекты, с которыми они работали лет по пять. Каждая задача случайно попадала в один из двух режимов: AI разрешён или запрещён. Замеряли сколько заняло решение задачи от начала до готового результата. С AI выходило на 19% дольше. При этом заранее разработчики ожидали ускорения на 24%, а после эксперимента, уже зная свои результаты, считали, что AI их ускорил на 20%.
Измеримость comprehension debt Любое изменение или баг в осознанной инженером системы, который понимает модель предметной области будет сопровождаться на два шага - понять что происходит в коде - понять как внести изменения / починить что-то
Значит стоит замерять время до первого осмысленного PR, потому как понимание кода проекта дороже починки. А если вы слепо отдали это на AI значит вы "увеличиваете проценты" вашего "микрозайма", а не решаете задачи проекта.
Как работать с comprehension debt Comprehension debt это нормальный инструмент как и финансовый кредитный займ. Вопрос в том, кто и когда решает занять.
С AI этот долг принимается по умолчанию в каждом PR, каждым разработчиком, и всегда в пользу "займа".
Но есть осмысленная развилка как и с кредитами:) Решение должно приниматься один раз на модуль и быть записано. 1. Для скрипта, лендинга, разового отчёта занимайте смело и не читайте ничего. 2. Для расчётного ядра, которое проживёт десять лет у заказчика платите сразу: текстом, инвариантами, правилами. И если есть возможность минимизировать AI, то делайте это, либо осмысленно используйте его ранжируя PR написанный с AI на кросс-ревью командой разработки - повысите понимание кода
Comprehension debt почти никогда не отдаёт тот, кто его взял. Его отдаёт человек, который через полгода в три часа ночи разбирает инцидент в чужом модуле. Или поддержка, принявшая продукт на сопровождение.
"Плохо не занимать. Плохо занимать не глядя и отдавать чужими руками" (c) #разработка #архитектура #ит #ai #техдолг #управление #менеджмент
· 22.08
Мысль про то, что понимание раньше было бесплатным побочным продуктом написания кода — сильная. В такой формулировке я об этом не думал.
Добавлю из регулируемой области: там у comprehension debt есть ещё и юридическое измерение. Если через год приходит проверка и спрашивает, почему система приняла такое решение, ответ «код чистый, тесты зелёные» не принимается. Нужны зафиксированные допущения.
Получается, что там этот долг нельзя копить в принципе. Возможно, именно поэтому генерация кода в таких отраслях будет приживаться медленнее, чем все ждут.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 22.08
Это факт! К слову, я бы сильно переживал, если бы хоть часть софта для АЭС была бы написана ИИ 🤣
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 22.08
Спасибо за комментарий) Особенно в части про сильную мысль :)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён