Технический долг после ИИ-разработки: как он появляется и как его остановить

Скорость — не бесплатна. Пока команды наращивают темп с AI-ассистентами, в кодовой базе тихо копится долг, который придётся отдавать с процентами

Введение: скорость в кредит

2025 год стал переломным. По данным Stack Overflow Developer Survey, 84% разработчиков используют или планируют использовать AI-инструменты в своей работе [1]. Google и Microsoft раскрыли, что AI генерирует уже более 20% нового кода внутри компаний [7]. Sonar опросил 1100 разработчиков и получил цифру в 42% AI-assisted коммитов в среднем по команде — с ожиданием роста до 65% в течение двух лет [8].

Всё это выглядит как победа: функции материализуются быстро, бойлерплейт испаряется, команды отчитываются о росте production-темпа. Но за ускорением стоит скрытая цена.

Форрестер предупреждает: 75% технических директоров к 2026 году столкнутся с умеренным или серьёзным техническим долгом, накопленным в эпоху AI-скорости [8]. Gartner идёт дальше: неконтролируемый prompt-to-app подход грозит ростом числа дефектов на 2500% к 2028 году — не потому что AI пишет случайный мусор, а потому что AI пишет код, синтаксически корректный, функционально работающий, но контекстуально слепой [4].

Эта статья о том, как именно накапливается технический долг в AI-ускоренных командах, и что реально работает для его остановки.

Что такое технический долг в контексте AI-кодинга

Термин «технический долг» ввёл Уорд Каннингем ещё в 1992 году: это накопленная стоимость решений, которые ускоряют разработку сегодня в обмен на замедление завтра. В традиционном понимании — срезанные углы, пропущенный рефакторинг, временные решения, ставшие постоянными.

AI добавил к этому новое измерение. Раньше технический долг накапливался из-за нехватки времени. Теперь он накапливается из-за нехватки понимания: AI производит код быстрее, чем человек способен его критически осмыслить. При этом код выглядит правильно, проходит тесты и попадает в production — а проблемы обнаруживаются через месяц в 3 часа ночи.

Исследователи выделяют несколько новых типов AI-специфического долга:

1. Структурный долг — дублирование, раздутая кодовая база, отсутствие переиспользования.
2. Семантический долг — код, функционально работающий, но не соответствующий архитектурным решениям проекта.
3. Долг безопасности — уязвимости и утечки секретов, воспроизведённые из шаблонов обучающей выборки.
4. Долг supply chain — галлюцинированные или непроверенные зависимости.
5. Долг документации — отсутствие обоснований скрытых архитектурных решений, принятых AI без явной документации.

Как AI создаёт технический долг: механизмы

Дублирование вместо переиспользования

GitClear проанализировал 211 миллионов изменённых строк кода за период 2020–2024 годов на данных анонимных корпоративных репозиториев и 25 крупнейших open-source проектов. Результаты настораживают [2]:

• 8-кратный рост частоты блоков кода из 5+ дублированных строк по сравнению с двумя годами ранее.
• В 2024 году впервые в истории измерений copy-pasted lines превысили moved lines — то есть разработчики стали копировать чаще, чем реструктурировать.
• 46% изменений составляли чистые новые строки при снижении доли перемещённого кода.

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

Контекстная слепота

Крупное эмпирическое исследование 2026 года на arxiv [7] зафиксировало: разработчики склонны чрезмерно доверять качеству AI-кода, принимая сгенерированные фрагменты без надлежащей валидации. В результате непроверенный код попадает в production.

Исследование 567 агентных pull requests показало, что 45,1% из них потребовали человеческих правок для приведения в соответствие с проектными стандартами [9]. AI не видит архитектурной истории репозитория, не знает о нефункциональных требованиях команды и принимает дизайн-решения, не документируя их.

Ещё один эффект — «phantom bugs»: по данным вендорного отчёта OX Security (октябрь 2025), 20–30% AI-генерируемых кодовых баз содержат избыточную логику для маловероятных edge cases, деградирующую производительность [9].

Парадокс METR: быстрее кажется, медленнее работает

В июле 2025 года некоммерческая организация METR опубликовала результаты рандомизированного контролируемого исследования: 16 опытных разработчиков с глубоким знанием собственных репозиториев (в среднем 1 млн+ строк кода, 22 000+ GitHub stars) выполняли 246 задач с AI-инструментами и без [3].

Перед началом разработчики ожидали ускорения на 24%. После завершения оценивали своё ускорение в 20%. Объективные замеры показали: с AI они работали на 19% медленнее.

METR выделил пять факторов замедления: избыточный оптимизм по поводу AI-помощи, высокая экспертность в собственном коде делала AI менее полезным, накладные расходы на проверку и переработку AI-предложений. Это не значит, что AI-инструменты бесполезны — на менее знакомом коде и рутинных задачах картина другая. Но эффект замедления на сложных задачах реален и имеет прямое отношение к накоплению долга: когда AI генерирует больше кода, чем команда успевает качественно проверить, долг растёт быстрее.

По данным Harness State of Software Delivery 2025, большинство разработчиков сегодня тратят больше времени на отладку AI-кода и устранение уязвимостей, чем раньше [4]. Число pull requests на разработчика выросло на 20% с приходом AI, но число инцидентов на pull request выросло на 23,5% [8].

Долг безопасности: скрытая часть айсберга

Технический долг от AI-кодинга не ограничивается качеством и поддерживаемостью. Наиболее опасная его часть — долг безопасности.

Уязвимости из обучающей выборки

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

По данным Cloud Security Alliance и Endor Labs, 62% AI-генерируемого кода содержит архитектурные дефекты или известные уязвимости [10]. Veracode в анализе 2025 года зафиксировала, что 45% AI-кода уязвимы по стандарту OWASP Top 10 [10]. Для Java показатель превышает 70%. Это не экзотические случаи — это воспроизводимые CWE-паттерны: CWE-89 (SQL injection), CWE-79 (XSS), privilege escalation.

Исследование Pearce и коллег (2025) установило: около 40% AI-генерируемого кода в контекстах, чувствительных к безопасности, содержит критические уязвимости [7].

Утечки секретов

AI-ассистенты воспроизводят небезопасные паттерны работы с учётными данными из обучающей выборки. Практический результат — захардкоженные ключи, токены и пароли в коде.

Статистика 2025–2026 годов [5, 11]:

• В 2025 году в публичных репозиториях GitHub было обнаружено 28,65 млн новых захардкоженных секретов — рост 34% год к году (GitGuardian, 2026).
• AI-ассистированные коммиты раскрывают секреты вдвое чаще человеческих: 3,2% против 1,5%.
• Утечки учётных данных AI-сервисов выросли на 81% год к году — это самая быстрорастущая категория.
• 82% раскрытых секретов остаются активными даже после обнаружения.
• 70% организаций не имеют автоматизированного сканирования секретов для AI-генерируемого кода.

Отдельного внимания заслуживает инцидент с Cursor в 2024 году: оказалось, что редактор отправлял содержимое .env-файлов на свои серверы для tab completion даже при наличии этих файлов в .cursorignore [11].

Supply chain и hallucinated packages

Один из наиболее системных рисков AI-кодинга — галлюцинированные зависимости. AI-модели изобретают несуществующие пакеты с правдоподобными именами.

Анализ 576 000 AI-генерируемых образцов кода (апрель 2025, исследование Larson и Nesbitt, термин «slopsquatting») установил [6]:

• Около 20% AI-генерируемых образцов ссылаются на несуществующие пакеты.
• 43% галлюцинированных пакетов воспроизводились стабильно при 10 повторных запросах.
• 58% появлялись более одного раза — то есть это системные, а не случайные галлюцинации.

Схема атаки прямолинейна: злоумышленники регистрируют галлюцинированные имена на npm и PyPI до того, как разработчики пытаются установить пакет. Исследование Endor Labs показало, что только каждая пятая версия зависимости, рекомендованной AI-ассистентами, была одновременно безопасной и реально существующей [10].

В марте 2025 года Pillar Security раскрыл уязвимость «Rules File Backdoor», затронувшую GitHub Copilot и Cursor: скрытые unicode-символы в конфигурационных файлах позволяли влиять на генерацию кода ассистентами [10].

OWASP Top 10 для LLM-приложений 2025 включает supply chain на третье место, отдельно подчёркивая риски, специфичные для LLM: отравление обучающих данных, уязвимые плагины, скомпрометированные сторонние модели [12].

Почему традиционные подходы не работают в прежнем виде

Code review не успевает за объёмом

Традиционный code review рассчитан на человеческий темп генерации кода. AI-кодинг меняет уравнение: разработчик присылает diff в три раза больше обычного — и ревьюер физически не может прочитать его так же внимательно.

Дифы дочитываются не до конца. Служебный код, конфиги, миграции, CI/CD-файлы и internal tools исторически читаются небрежнее — а именно там часто скрываются самые неприятные проблемы.

Исследование Microsoft Research (2025) по Proactive Technical Debt Management подтверждает: гибридные системы, сочетающие автоматизацию с человеческой экспертизой, улучшают эффективность review без существенной потери качества [13].

CI/CD не закрывает новые векторы

Стандартные SAST-инструменты обнаруживают известные паттерны уязвимостей. Они менее эффективны против:

• галлюцинированных зависимостей (не знают, что пакет несуществующий);
• семантических архитектурных дефектов (код работает, но нарушает инварианты системы);
• захардкоженных секретов в нестандартных форматах (82% остаются активными после обнаружения);
• контекстуальных проблем безопасности (CORS, права доступа, конфигурации).

Как остановить накопление долга: практический фреймворк

1. Review gates до merge

Ключевой принцип: рабочий pull request не обязательно безопасен. Критическая точка контроля — до слияния, а не после.

Что проверять в каждом PR до merge:

• Все новые или обновлённые зависимости — проверяются против lock-файла и advisory-базы.
• Конфигурационные файлы и CI/CD — это зоны высокого риска для скрытых изменений.
• Секреты — автоматическое сканирование (GitGuardian, truffleHog, Gitleaks) как обязательный pre-merge шаг.
• Область изменений — если diff затрагивает критичную инфраструктуру или аутентификацию, требуется отдельный security review.

2. SCA и валидация зависимостей

Каждый пакет, предложенный AI-ассистентом, должен проходить верификацию:

• существование в реестре (npm, PyPI, Maven Central);
• соответствие lock-файлу проекта;
• проверка по SBOM и advisory-базам (OSV, GitHub Advisories, NVD);
• транзитивные зависимости — не только прямые.

Рекомендация OWASP: ведите Software Bill of Materials для всех сторонних компонентов [12].

3. Secrets management с первого дня

• Никаких секретов в коде, независимо от среды и контекста.
• .env-файлы в .gitignore — и проверка, что ни один AI-ассистент не читает их для tab completion.
• Централизованные secrets manager'ы (HashiCorp Vault, AWS Secrets Manager, аналоги).
• Automated secrets scanning в CI — не как опция, а как блокирующий шаг.
• Ротация ключей при малейшем подозрении на утечку.

4. Архитектурный контекст для AI

Чем больше архитектурного контекста имеет AI-ассистент, тем меньше контекстуального долга он создаёт.

Практические шаги:

• Описание архитектурных ограничений и инвариантов в ARCHITECTURE.md или ADR (Architecture Decision Records).
• Явный контекст для системных промптов AI-ассистентов: «не использовать внешние зависимости без согласования», «все секреты через Vault», «паттерн X запрещён».
• Spec-driven development: описание требований до генерации кода снижает процент PR с человеческими правками с ~45% до значимо меньшего [9].

5. Метрики, которые стоит отслеживать

Не все метрики одинаково полезны в AI-эпоху. Pull requests per developer вырос — но это не значит, что продуктивность выросла. Следите за:

• incidents per pull request (индикатор качества, не только скорости);
• code churn rate (рост — сигнал накопления долга);
• duplicate code ratio (8x рост — красный флаг из реальных данных);
• mean time to detect security vulnerability;
• dependency freshness и SCA findings per release.

6. Разрыв между «работает» и «безопасно для production»

Ключевая ловушка AI-кодинга: функционально корректный код не является автоматически production-ready. Чек-лист для каждого AI-генерируемого изменения перед релизом:

• Зависимости проверены и существуют в реестре?
• Нет захардкоженных секретов или fallback-ключей?
• CORS, права доступа и конфигурация окружения проверены для production?
• Debug-флаги и development-настройки убраны?
• Затронутые endpoints покрыты тестами не только happy path?

Контрарные аргументы: AI — не всегда проблема

Честный разбор требует упоминания противоположной позиции.

Аргумент 1: При правильном использовании AI помогает сокращать долг. Это подтверждается практикой: AI-инструменты эффективны для рефакторинга, генерации тестов и автоматизированной документации существующего кода.

Аргумент 2: Исследование METR замеряло опытных разработчиков на хорошо знакомых codebases. В иных условиях — на незнакомом коде, рутинных задачах, быстром прототипировании — картина другая.

Аргумент 3: Инструменты быстро улучшаются. METR работал с early-2025 моделями; более поздние версии показывают другие результаты в ряде задач.

Взвешенная позиция, поддерживаемая данными: AI-кодинг создаёт реальные риски накопления долга при отсутствии процессов контроля. При наличии этих процессов — становится умножителем продуктивности без соответствующего роста долга [13].

Кейсы и сценарии

Сценарий 1: Hallucinated package в production

Команда использует AI-ассистент для интеграции с облачным провайдером. Ассистент предлагает pip install aws-helper-sdk — пакет с правдоподобным именем, которого нет в официальном реестре. Разработчик запускает установку. Пакет уже зарегистрирован злоумышленником с вредоносным кодом. SCA-проверки нет, pre-merge validation отсутствует.

Что остановило бы атаку: автоматическая проверка существования пакета в реестре до установки; сверка с SBOM проекта; SCA в CI как блокирующий шаг.

Сценарий 2: Debug-флаги в production

Команда генерирует конфигурационный файл с AI-ассистентом. Ассистент включает debug: true и verbose_logging: true — стандартные для development окружения настройки. Разработчик принимает diff, не дочитывая конфиг до конца. Через неделю в логах обнаруживается полный дамп SQL-запросов.

Что остановило бы: явная проверка конфигурационных файлов в review gate; разделение dev/production конфигов с автоматической валидацией перед deploy.

Сценарий 3: Архитектурный дрейф

Разработчик с AI-ассистентом генерирует 15 компонентов за неделю. Каждый — функционально рабочий. Через квартал обнаруживается, что компоненты используют три разных паттерна обработки ошибок, два несовместимых подхода к сериализации и четыре версии одной утилиты. Рефакторинг займёт три спринта.

Что остановило бы: архитектурный контекст в системных промптах ассистента; ADR как обязательный ввод для крупных изменений; periodic architecture review с инструментами статического анализа.

Роль инструментов контроля изменений

Среди инженерных команд растёт понимание, что AppSec-инструменты, работающие с полным репозиторием по расписанию, не успевают за темпом AI-кодинга. Нужен контроль на уровне конкретного изменения — в момент до merge.

Именно эту логику реализует HighVibe: анализ конкретного PR и связанного контекста, включая зависимости, конфигурационные файлы и релизный контекст. Вместо ещё одного длинного security-отчёта команда получает чёткий ответ: можно ли безопасно принять это изменение прямо сейчас, и что именно требует внимания. Особенно это актуально для конфигов, CI/CD-файлов и транзитивных зависимостей — именно тех зон, которые дочитываются в review хуже всего.

Тренды и прогнозы

Что точно известно из данных

• Объём AI-генерируемого кода продолжает расти: DORA и Stack Overflow фиксируют устойчивый тренд [4].
• Долг компаундируется: необслуживаемый AI-код достигает 4x традиционных costs обслуживания ко второму году [8].
• CVE, атрибутируемые AI-инструментам, растут экспоненциально: с 6 в январе 2026 до 35 в марте 2026, по данным Georgia Tech Vibe Security Radar [6].

Что вероятно на основе трендов

• Регулирование качества AI-кода будет ужесточаться. OWASP уже включил supply chain и специфические LLM-риски в Top 10 [12]. Национальные стандарты по безопасности AI-сервисов разрабатываются в России и ЕС параллельно.
• Инструменты AI-кодинга будут интегрировать проверки безопасности на уровне самого ассистента.
• Роль AppSec в командах трансформируется: по прогнозу Gartner, к 2028 году 50% функций контроля рисков мигрируют из юридических и security-отделов в AI-инжиниринг [4].

Что спорно

• Насколько следующее поколение AI-моделей само справится с генерацией безопасного кода — открытый вопрос. Ряд исследований показывает улучшения, но проблема контекстуальной слепоты системная, не модельная.
• Будет ли «2026 годом AI quality» (как предсказывает CodeRabbit) или скорость продолжит побеждать качество в большинстве команд — зависит от организационных решений, а не только от технологий.

Заключение: что делать прямо сейчас

Технический долг от AI-кодинга — не аргумент против AI-инструментов. Это аргумент за явные процессы контроля, которые не успели вырасти вместе со скоростью генерации.

Три вещи, которые стоит сделать этой неделей:

1. Провести аудит текущего review-процесса. Как часто конфигурационные файлы и зависимости в PR проверяются так же внимательно, как функциональный код? Если ответ — «реже» — там накапливается долг.

1. Добавить SCA и secrets scanning как блокирующие шаги в CI. Не информационные, а именно блокирующие merge при критических находках.

1. Зафиксировать архитектурные ограничения в документации, доступной для AI-ассистентов. ADR, ARCHITECTURE.md, явные запреты на паттерны — чем больше контекста имеет ассистент, тем меньше контекстуального долга он создаёт.

Долг можно остановить. Но для этого нужно признать, что «работает в CI» и «безопасно для production» — разные утверждения.

Источники

[1] Stack Overflow — "Stack Overflow Developer Survey 2025" — https://survey.stackoverflow.co/2025

[2] GitClear — "AI Copilot Code Quality 2025" — https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality

[3] METR — "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

[4] ArmorCode / Gartner — "Gartner Predicts 2026: AI Potential and Risks Emerge in Software Engineering Technologies" — https://www.armorcode.com/report/gartner-predicts-2026-ai-potential-and-risks-emerge-in-software-engineering-technologies

[5] GitGuardian — "2026 State of Secrets Sprawl" (via Snyk) — https://snyk.io/articles/state-of-secrets/

[6] Cloud Security Alliance — "CSA Research Note: AI-Generated Code Security, Vibe Coding 2026" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/

[7] arxiv — "Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild" — https://arxiv.org/html/2603.28592v1

[8] BuildMVPFast — "AI Generated Code Technical Debt: How to Manage It" — https://www.buildmvpfast.com/blog/ai-generated-code-technical-debt-management-2026

[9] Augment Code — "What Happens When AI Technical Debt Compounds (And How Spec-Driven Dev Prevents It)" — https://www.augmentcode.com/guides/ai-technical-debt-compounds-spec-driven-development

[10] Kusari — "AI Coding Assistants in 2026: 4× Faster, 10× Riskier" — https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost

[11] Help Net Security — "29 million leaked secrets in 2025: Why AI agents credentials are out of control" — https://www.helpnetsecurity.com/2026/04/14/gitguardian-ai-agents-credentials-leak/

[12] OWASP — "Top 10 for LLM Applications 2025" — https://owasp.org/www-project-top-10-for-large-language-model-applications/

[13] CERFACS/COOP — "The Impact of AI-Generated Code on Technical Debt and the Need for Accelerated Codebase Appraisal" — https://cerfacs.fr/coop/hpcsoftware-codemetrics-kpis

[14] LeadDev — "How AI generated code compounds technical debt" — https://leaddev.com/technical-direction/how-ai-generated-code-accelerates-technical-debt

[15] Snyk — "Slopsquatting: New AI Hallucination Threats & Mitigation Strategies" — https://snyk.io/articles/slopsquatting-mitigation-strategies/

[16] vc.ru — "AI-кодинг обещал 10x продуктивности. Разработчики получили выгорание и технический долг" — https://vc.ru/id2585050/2698649-ai-koding-vygoranie-razrabotchikov-i-rost-tekhnicheskogo-dolga

[17] Habr/VK Tech — "Разработка с AI в 2025: от идеи до продакшена с Claude Code" — https://habr.com/ru/companies/vktech/articles/963714/