Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO:переписать нормально.

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

А зря.
Разработчик тратит на обслуживание этого долга, по разным оценкам, от 23 до 42% рабочего времени. Это значит, что каждый понедельник вашей команды уходит на бесплатный рабочий день в пользу старого кода, или полтора месяца в год каждый год без учёта отпусков и больничных.

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

При выражении технический долг, большинство представляет раздел в бэклоге, куда складывают то, что надо бы как-нибудь потом отрефакторить. Выглядит оно как файл TODO.md в корне репозитория или (что ещё прикольнее) стикеры на доске в углу спринта, которые мигрируют из недели в неделю до полной потери местоположения.

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

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

Технический долг – это как тёмная материя: вы знаете, что он существует, можете оценить его влияние, но не можете его увидеть или измерить напрямую

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

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

Такая злая магия. Финансовый кредит вы, по крайней мере, видите в выписке, а техдолг точно нет. Он не отображается в P&L, недоступен для аудиторов и его тем более не видит инвестор на дью-дилидженсе (если только не привёл с собой грамотного CTO).

Рассмотрим с какой скоростью он может расти.

Математика смерти

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

Сложный процент работает в две стороны: если вы кладёте деньги в банк под 10% годовых спустя семь лет сумма удваивается. Если же вы должны кому-то под 10% принцип работает наоборот. Так вот техдолг и есть вклад наоборот. 

И ставка по нему, в зависимости от того, в какой компании вы работаете, колеблется между 5% и 20% годовых.

Рассмотрим три основных сценария. Если же ваш проект чуть в стороне от шаблона подставьте свои цифры, всё равно формула одна.

Долг через N лет = текущий долг × (1 + ставка роста)^N

Стартап выглядит безопаснее всех, у него большой запас прочности. Но это иллюзия. Скорость роста долга в стартапе кратно выше: команды небольшие, с поверхностным ревью, главный девиз «деплоим, потом разберёмся». Через десять лет стартап либо превратится во что-то большее и унаследует свои грехи, либо умрёт раньше, чем долг успеет дозреть (что и выходит в большинстве случаев).

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

По классике с энтерпрайзом всё по-особенному. Парадокс в том, что он проживёт дольше всех, т.к. у него есть бюджет, чтобы тушить даже пожары годами. Но «тушить» и «развиваться» глаголы разные . К моменту, когда долг съедает 80% бюджета, компания превращается в зомби: формально жива, но новых продуктов не выпускает уже годами. 

А теперь, барабанная дробь, главное!

Данный расчёт сделан в оптимистичном допущении, что выручка и зарплатный фонд растут вместе с долгом, но они не растут. По данным Хабр Карьеры, зарплаты IT-специалистов в РФ за 2024–2025 выросли в среднем на 2%, что как понимаете ниже официальной инфляции. Выручка большинства российских IT-компаний сопоставима.

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

Когда технический долг подразделения превышает 50% стоимости его технологических активов, риски и затраты старых систем начинают перевешивать их ценность.

McKinsey – известнейшая консалтинговая компания

Переведём с американского айтйшного на русский: дешевле снести и построить заново. 

Что это значит для вас?

Цифры выше чистая макроэкономика.
Чтобы лучше понимать картину, давайте спустимся с уровня отрасли на уровень конкретного рабочего стола, потому что техдолгу в целом не важна индустрия, он идёт по вашу душу и душу вашего руководителя (да, это не всегда хорошо).

Итак, если вы разработчик

Помните, что вы пришли в эту профессию что-то строить?
Ради алгоритмов, архитектуры, новых библиотек, и того самого момента, когда тесты впервые загораются зелёным.

А теперь ответьте честно: что вы делали на прошлой неделе? Сколько часов потратили на дебаг кода, написанного человеком, которого уже нет в компании? Сколько раз открывали файл на 4 000 строк и закрывали обратно, не трогая, потому что страшно?

Если по ощущениям много, то это не ощущения. По разным данным, в среднем от 23% до 42% времени разработчика уходит на борьбу со старым кодом, вмес то написания нового. 

В 2024-м Atlassian вообще насчитал, что 69% разработчиков теряют 8+ часов в неделю на разные формы неэффективности (тот самый понедельник). Силы уходят на обслуживание системы, которую построили вы или тот, кто был до вас.

Опять же, если обратиться к исследованиям, только 19% профессиональных разработчиков довольны своей работой (2024, Stack Overflow), и это рекорд за всё время наблюдений, в худшую сторону. Как вы уже понял, главная причина ощущение, что строишь не вперёд, а назад. Каждая новая строчка кода, написанная сегодня поверх техдолга, становится завтрашним техдолгом для того, кто придёт после вас, и вы это знаете. Просто у вас нет других опций: роадмап горит, релиз послезавтра, а в таск-трекере  ещё двенадцать тикетов.

Если вы руководитель

У вас есть метрики.
Velocity, lead time, deployment frequency, change failure rate и т.д.. Вы их смотрите, а они стабильно ухудшаются. Команда говорит, что всё нормально, но фичи выходят дольше, чаще откатываются релизы, и всё в этом духе. И проблема не в команде.

Компании с высоким техдолгом тратят на поддержку систем на 40% больше конкурентов и выпускают новые фичи на 25–50% медленнее. Те же, кто активно работает с долгом, растут по выручке на 20% быстрее. Двадцать процентов годового роста – за одно решение не позволить кодовой базе деградировать. 

Когда CEO спросит у вас «почему deployment frequency упал в три раза за два года» это вне компетенции DevOps, а математическое следствие того, что два года назад вы посмотрели на предложение рефакторинга ядра, и ответили «потом, у нас квартал». Теперь «потом» наступило, и достанется оно или вам, или преемнику.

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

Некрология успешных компаний

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

Knight Capital: 45 минут, $440 миллионов и 18 лет в помойку

К 2012 году Knight Capital был крупнейшим трейдером американских акций – через их платформу проходило около 17% (!) всего объёма торгов на бирже США.

1 августа 2012 года команда под дедлайном выкатила обновление торгового алгоритма. Чтобы успеть, повторно использовали кусок старого кода, который должен был быть удалён ещё несколько лет назад, но никто не дошёл до уборки. Кусок остался на одном из серверов, был случайно активирован и за 45 минут после открытия NYSE начал покупать и продавать акции в гигантских неавторизованных объёмах.

$440 миллионов за сорок пять проклятых минут. На следующий день акции Knight Capital упали на 75% . К лету 2013 года компания была вынуждена продаться конкуренту. Всё из-за старого куска кода, который «потом удалим».

Friendster: первая социальная сеть, проигравшая TPS

Кто-то ещё помнит Friendster? Если нет, как говорится, это и есть весь поинт.

В 2002 году Friendster был первой полноценной социальной сетью в современном понимании, ещё за полтора года до Facebook, и за два до MySpace. На пике было свыше 100 миллионов пользователей, и у них были все ресурсы стать тем, чем стал Цукерберг.

Но не стали, потому что страницы грузились по 20-40 секунд. Команда не успевала масштабировать архитектуру под рост, и каждое решение принималось по схеме «давайте быстро, а потом перепишем». К моменту, когда у конкурентов страницы открывались за две секунды, пользователи Friendster уже ушли к более расторопным сервисам.

HealthCare.gov: пятьдесят подрядчиков, ноль архитектуры

В 2013 году правительство США запустило HealthCare.gov — национальный портал медицинского страхования. К разработке привлекли более пятидесяти подрядчиков, каждый из которых строил свой модуль. Единой архитектуры не было.

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

Тут даже не не классический техдолг, а organizational debt в чистом виде: пятьдесят команд и ни одного владельца за конечный продукт.

Что у них общего?

Ни одна из этих компаний не считала себя вот-вот умирающей. Knight Capital был лидером рынка. Friendster №1 в социальных сетях, а вообще HealthCare.gov финансировался самой могущественной экономикой мира.

И все трое смотрели на свой техдолг и говорили: «У нас всё под контролем. Разберёмся потом».

Результат на лицо.

Катализатор апокалипсиса

Всё, что мы посчитали выше, про традиционный техдолг. Тот что копится со скоростью человеческих рук. Но это, снова барабанная дробь, была эпоха до AI.

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

Это AI-копайлот, вайб-кодинг, Cursor, Claude Code, Windsurf, GitHub Copilot, и так далее, и тому подобное. И именно это происходит сейчас в большинстве команд, которые сделали ставку на скорость.

К цифрам, которые уже есть:

45% сгенерированного LLM кода содержит уязвимости безопасности, а рост adoption AI-инструментов на 90% коррелирует с ростом времени ревью кода на 91% и ростом размера pull request на 154% – то есть код пишется существенно быстрее, чем проверяется. 

GitClear проанализировал 211 миллионов изменённых строк кода за 2020–2024 годы. С приходом AI-копайлотов доля дублирующегося кода выросла в четыре раза. Т.е. AI генерирует решения, которые в кодовой базе уже были, но он об этом не знает, а ревьюер их тупо пропускает.

Я не думаю, что за 35 лет карьеры в технологиях видел столько технического долга, созданного за такое короткое время

API-евангелист Kin Lane

Но есть еще более интересная цитата от Стива Краузе

Когда вы вайб-кодите, вы накапливаете техдолг со скоростью, с которой LLM может его генерировать. Это как дать кредитную карту ребёнку, не объяснив концепцию долга

Это новый класс долга – назовём его код без автора.
Никто не знает, как и почему он работает. И даже по логике когда он сломается, никто не будет знать, что с ним делать.

Ожидается, что к 2028 году подход «prompt-to-app» увеличит количество дефектов в ПО на 2500% – в 25 раз. 

Помните 10% годового роста долга из второго блока?
Можете (по вашему желанию) больше не переживать, в эпоху AI это даже не средний показатель, а так, точка старта.

Вопрос в зал

Если вы дочитали до этого места значит, что-то в статье попало.
Простого решения у этой задачи нет ,иначе мы бы не наблюдали $1,5 трлн годового долга у одних только США. Но есть несколько вопросов, которые имеет смысл задать себе. 

• Какой процент IT-бюджета у вас уходит на обслуживание долга? Если не знаете – это уже ответ.

• Когда последний раз в вашем роадмапе появилась задача уменьшить техдолг, а не выкатить фичу?

• Сколько ваших разработчиков смогут уйти завтра, унеся с собой единственное знание о том, как работает критическая часть системы?

• Если бы вы показывали продукт инвестору сегодня – вы бы открыли ему кодовую базу?

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

И теперь главный вопрос.
Через сколько лет, по вашей честной оценке, умрёт ваша кодовая база?