Технический долг это накопленная цена быстрых решений в коде: сегодня вы сэкономили время, а завтра каждая правка обходится дороже. Долг бывает осознанным и вынужденным, и его можно оценить в часах. Ниже разберем, откуда взялся термин, как его классифицировать и что с ним делать в эпоху AI-разработки.
TL;DR. Технический долг возникает, когда команда сознательно или по незнанию выбирает быстрое решение вместо правильного, а потом платит замедлением разработки. Метафору предложил Уорд Каннингем в 1992 году. Ниже: квадрант Фаулера, шесть причин, оценка в SonarQube, риски вайбкодинга и план управления долгом.
Что такое технический долг простыми словами?
Технический долг это будущие затраты на переделку, которые вы создаете, выбрав быстрое решение вместо аккуратного. Пока вы их не оплатите, разработка идет медленнее.
Технический долг работает как кредит: быстрое неидеальное решение дает выигрыш во времени сегодня, а проценты вы платите каждой следующей правкой. Чем дольше долг лежит нетронутым, тем дороже любое изменение рядом с ним. Главная цена здесь не деньги, а скорость команды.
Представьте форму заявки, которую скопировали в двенадцать мест вместо одного компонента. Работает? Да. Но когда меняется одно поле, править приходится двенадцать файлов, и хотя бы в одном про правку забудут. Это и есть проценты по долгу.
Долг бывает не только в коде. Он живет в архитектуре, документации, тестах и инфраструктуре. Просто в коде его проще заметить.
Кто придумал термин технический долг и зачем?
Метафору технического долга ввел Уорд Каннингем в 1992 году, когда описывал систему WyCash. Он сравнил быстрое неидеальное решение с займом, по которому надо платить проценты.
Уорд Каннингем предложил метафору технического долга в 1992 году в отчете о системе WyCash. Идея простая: если вы выпустили код, который не отражает ваше лучшее понимание задачи, вы взяли в долг. Пока код не переписан, вы платите проценты в виде замедления разработки.
Метафора прижилась потому, что она понятна не только программистам. Менеджеру не нужно читать код, чтобы понять, что кредит рано или поздно придется возвращать. С этого момента разговор о рефакторинге перестает звучать как каприз разработчиков.
Здесь есть нюанс. Изначальная мысль была шире, чем «пишем плохо, чтобы быстрее». Долг может появиться и у хорошей команды, просто потому что понимание задачи растет, а код остается прежним.
Что такое квадрант технического долга Фаулера?
Мартин Фаулер разделил технический долг на четыре типа по двум осям: осознанный или неосознанный, разумный или безрассудный. Так проще понять, какой долг терпим, а какой нет.
Квадрант технического долга Фаулера строится на двух вопросах. Команда знала, что берет долг, или не знала? И решение было взвешенным или безрассудным? Пересечение осей дает четыре типа, и у каждого своя цена.
| Тип долга | Что это значит | Пример |
|---|---|---|
| Осознанный и безрассудный | Знали, что делаем плохо, и не планировали исправлять | «Тесты писать некогда», и так до конца проекта |
| Осознанный и разумный | Взяли долг ради срока и записали, когда вернем | Выпустили MVP на упрощенной схеме, ремонт в плане на следующий месяц |
| Неосознанный и безрассудный | Не знали базовых практик | Вся логика лежит в одном файле на три тысячи строк |
| Неосознанный и разумный | Сделали хорошо, но поняли лучший вариант только после релиза | Через полгода стало ясно, как надо было разбить модули |
Опасен второй столбец слева, где долг взят молча. Первую строку таблицы нужно обсуждать с командой, последнюю просто принимать как часть работы.
Почему появляется технический долг? Шесть причин
Технический долг растет из шести источников: жесткие сроки, отсутствие тестов, устаревшие зависимости, решения без архитектуры, временные обходные пути и потеря знаний при уходе людей.
Технический долг почти никогда не рождается из одной ошибки. Он собирается из сотни мелких компромиссов, каждый из которых в момент принятия казался разумным. Шесть причин встречаются чаще остальных.
| Причина | Как выглядит | Что помогает |
|---|---|---|
| Жесткие сроки | Пропускаем ревью, чтобы успеть к релизу | Явно фиксировать взятый долг в бэклоге |
| Нет тестов | Боятся трогать старый код | Писать тест перед правкой |
| Устаревшие зависимости | Библиотеку не обновляли годами, обновление ломает все сразу | Обновлять маленькими шагами регулярно |
| Решения без архитектуры | Фичи добавляются туда, где нашлось место | Короткое обсуждение схемы до кода |
| Временные обходные пути | «Потом уберем», и стоит уже второй год | Ставить дату и владельца на каждый костыль |
| Потеря знаний | Автор модуля ушел, никто не понимает логику | Документация и парное ревью |
Обратите внимание на «временные» обходные пути. Именно они чаще всего живут дольше самого проекта, потому что у них нет ни срока, ни ответственного.
Как посчитать технический долг и что показывает SonarQube?
SonarQube оценивает технический долг как ориентировочное время на исправление найденных замечаний. Это ориентир для сравнения проектов и динамики, а не точная сумма денег.
SonarQube считает технический долг как суммарное ориентировочное время, которое нужно на исправление всех найденных замечаний в коде. Цифра получается в часах или днях. Полезна она прежде всего для сравнения: как проект выглядел месяц назад и как выглядит сегодня.
В документации Sonar сказано, что в идеале команда вообще не добавляет новых замечаний, то есть нового долга. Отсюда правило Clean as You Code: следите за новым кодом, а старый чините по мере касания. Подробности лежат в документации SonarQube по замечаниям.
Есть ограничение, о котором забывают. Оценку нельзя воспринимать как бюджет проекта. Автоматический анализатор находит запахи кода и уязвимости, но не видит, что архитектура ушла в тупик или что знания живут в голове одного человека.
Универсальных процентных порогов нормального долга не существует. Любые «допустимые 5%» из интернета лучше игнорировать.
Как вайбкодинг ускоряет накопление технического долга?
Вайбкодинг ускоряет генерацию кода, поэтому проверка становится узким местом. Без защитных механизмов AI-агенты добавляют уязвимости и технический долг быстрее, чем команда успевает их замечать.
По материалу Sonar от 24 февраля 2026 года, по мере ускорения генерации кода узким местом становится проверка. Без защитных механизмов агенты могут добавлять уязвимости и технический долг. Логика понятна: код пишется за минуты, а читать его приходится теми же людьми и теми же глазами. Sonar отдельно описывает, как интегрировать Claude Code с SonarQube MCP server.
Из нашей практики: код от AI почти всегда «почти работает». Дальше начинается доводка, и она бывает мучительной. Вот как это описывает Максим.
Максим: «Мог просто засесть до пяти ночи и просто там править одну какую-то функцию, которая не работала. В моменте я уже испотел, и мне хотелось просто всё это закрыть. Но я понимал, что это можно решить и нужно решить, чтобы идти дальше.»
Если вы работаете в Claude Code или Cursor, три привычки заметно снижают риск.
| Как AI ускоряет долг | Что делать |
|---|---|
| Код принимают, не читая | Читать каждый дифф перед коммитом |
| Нет тестов на сгенерированное | Просить агента писать тесты вместе с кодом |
| Разные части проекта написаны в разных стилях | Держать файл правил для агента |
| Уязвимости попадают незаметно | Подключить статический анализ к процессу |
Как управлять техническим долгом на практике?
Управлять долгом помогают три вещи: правило Clean as You Code, регулярное время на рефакторинг в спринте и тесты перед изменением старого кода.
Управление техническим долгом начинается с остановки роста. Пока каждый новый коммит добавляет замечания, гасить старые бесполезно: вы черпаете воду из лодки с дырой. Поэтому первым шагом идет Clean as You Code, то есть контроль качества именно нового кода.
Второй шаг: закладывать в каждый спринт время на рефакторинг. Не «когда будет свободная неделя», а как обычную задачу с оценкой. Какую долю выделять, решает команда, и универсального числа здесь нет.
Третий шаг: тесты перед изменением старого кода. Сначала фиксируете текущее поведение тестом, потом меняете. Так вы не сломаете то, что работало.
И еще одно. Ведите реестр долга: что взяли, зачем, кто отвечает, когда вернем. Осознанный долг без записи быстро превращается в неосознанный.
Когда технический долг не страшен и где метрики врут?
Осознанный и разумный долг бывает оправдан, а метрики анализаторов не видят архитектурных и организационных причин. Цифра в отчете это повод для разговора, а не приговор.
Долг не всегда плох. Если стартап выпускает MVP за неделю на упрощенной схеме и записывает, что перепишет ее после первых оплат, это нормальная сделка. Проблема начинается, когда запись потерялась, а схема осталась.
Метрики тоже ограничены. SonarQube не заметит, что три сервиса дублируют одну логику на разных языках, или что вся команда боится трогать модуль оплаты. Организационный долг вроде нехватки документации и ухода ключевых людей вообще лежит за пределами анализатора.
Честный вывод такой: используйте оценку долга для динамики, а не для отчета перед руководством. Растет от релиза к релизу? Значит, пора говорить о рефакторинге. Стоит на месте при росте кодовой базы? Команда справляется.
Частые вопросы про технический долг
Технический долг это плохо?
Не всегда. Осознанный и разумный долг бывает оправдан: вы быстрее выходите на рынок и заранее знаете, когда и как вернете его. Плохо, когда долг копится незаметно и никто не планирует его гасить.
Чем технический долг отличается от багов?
Баг это код, который работает неправильно. Технический долг это код, который работает, но его тяжело менять. Баг видно пользователю сразу, а долг проявляется как рост сроков любых новых доработок.
Как измерить технический долг в часах?
Инструменты вроде SonarQube суммируют ориентировочное время на исправление найденных замечаний. Это оценка для сравнения проектов и отслеживания динамики. Реальные трудозатраты она не заменяет, потому что не видит архитектурные проблемы.
Есть ли нормальный процент технического долга?
Универсального порога нет. Любые цифры зависят от проекта, команды и этапа продукта. Полезнее смотреть на динамику: растет ли долг от релиза к релизу и замедляется ли из-за него разработка.
Вайбкодинг увеличивает технический долг?
Может, если код от AI попадает в проект без проверки. Генерация стала быстрой, а узким местом стала ревью. Помогают тесты, статический анализ и привычка читать сгенерированный код перед коммитом.
С чего начать погашение технического долга?
С правила Clean as You Code: новый код не добавляет новых замечаний. Затем выделяйте часть каждого спринта на рефакторинг и пишите тесты перед правкой старого кода. Так долг перестает расти, и его можно спокойно сокращать.
Глоссарий
Технический долг это будущие затраты на переделку кода, возникающие из-за быстрых компромиссных решений.
Рефакторинг это изменение внутренней структуры кода без изменения его поведения.
Квадрант Фаулера это модель, которая делит долг по осям «осознанный или неосознанный» и «разумный или безрассудный».
Clean as You Code это подход, при котором команда следит за качеством нового кода и не добавляет новых замечаний.
Запах кода это признак в коде, который не ломает программу, но указывает на потенциальную проблему.
Вайбкодинг это создание цифровых продуктов с помощью AI-агентов, когда человек ставит задачу и проверяет результат.
Что делать дальше?
Возьмите свой проект и разложите текущий долг по четырем клеткам квадранта. Уже этого хватит, чтобы понять, что чинить первым. Если вы собираете продукты с AI, загляните в каталог AI-инструментов VibeCoderz и подберите тот, где проверка кода встроена в процесс. Нужен разбор вашего стека или проекта? Запишитесь на консультацию к Максиму.
Обновлено: сентябрь 2026.