Риски ИИ в разработке: что может пойти не так в реальном проекте

Когда ИИ-ассистент генерирует четыре тысячи строк кода за час, а потом выясняется, что половина из них содержит уязвимости — это не гипотетический сценарий. Это уже происходит в production-системах по всему миру

Скорость без безопасности — не прогресс

В 2025 году 84% профессиональных разработчиков используют ИИ-инструменты в ежедневной работе [1]. Рынок корпоративных инвестиций в ИИ достиг $252,3 млрд, прибавив 26% за год [2]. Компании внедряют GitHub Copilot, Cursor, Claude Code, рассчитывая сократить time-to-market и снизить нагрузку на инженеров.

Ожидания оправдываются — частично. Скорость генерации кода реально выросла в 4 раза. Но ровно в это же время количество security-находок в репозиториях выросло в 10 раз [3]. Это не случайность и не издержки роста: это системный паттерн, который проявляется снова и снова в реальных проектах.

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

1. Уязвимый код: скорость генерации ≠ качество безопасности

Самая обсуждаемая и наиболее задокументированная проблема — уязвимости в ИИ-сгенерированном коде. Veracode протестировала более 100 крупных языковых моделей и зафиксировала, что 45% генерируемого кода содержит известные уязвимости по классификации OWASP [4]. При этом плотность уязвимостей в ИИ-коде в 2,74 раза выше, чем в человеческом [5].

Независимое исследование Apiiro среди компаний из списка Fortune 50 выявило ещё более тревожные цифры: по сравнению с ручным кодом, ИИ-сгенерированный код содержит на 322% больше путей для privilege escalation, на 153% больше архитектурных дефектов и на 40% больше случаев утечки секретов [5].

Конкретные типы слабых мест, которые ИИ воспроизводит особенно часто [4]:

1. SQL-инъекции — ИИ проваливает тест безопасности в 20% случаев.
2. Небезопасная криптография — провал в 14% случаев.
3. Log injection — встречается в 88% сценариев при генерации логирования.
4. XSS (межсайтовый скриптинг) — не предотвращается в 86% тестовых кейсов.
5. Хардкод-секреты (ключи API, пароли) — стабильная проблема во всех LLM.

Реальный пример — платформа Lovable для AI-разработки. Её генератор создавал схемы баз данных без политик Row Level Security. В результате любой авторизованный пользователь мог читать, изменять и удалять данные других пользователей. Уязвимость затронула более 170 production-приложений — не как ошибка в одном месте, а как структурный дефект, унаследованный из шаблона [6].

Аналитика CodeRabbit за декабрь 2025 года, охватившая 470 open-source pull requests, показала, что ИИ-код содержит примерно в 1,7 раза больше серьёзных проблем по сравнению с кодом, написанным людьми [5].

Парадокс в том, что ИИ великолепно справляется с синтаксическими ошибками и простыми логическими багами (их частота упала на 76% и 60% соответственно [3]), но именно сложные security-паттерны — то, что требует контекстного понимания архитектуры, — остаются его ахиллесовой пятой.

2. Галлюцинации: уверенность без знания

Языковые модели не «знают» код в человеческом смысле — они предсказывают следующий токен на основе статистики. Это порождает галлюцинации: технически корректный по виду код, ссылающийся на несуществующие методы, устаревшие API или библиотеки, которых не существует [7].

Главная опасность галлюцинаций — не их частота, а гиперуверенность подачи. Модель не говорит «я не знаю» — она генерирует убедительный несуществующий ответ [7]. Разработчик, особенно джуниор, часто не может отличить корректный код от правдоподобно выглядящей выдумки.

Практические последствия в проектах:

1. Код компилируется и проходит базовые тесты, но падает в production при специфических условиях.
2. ИИ рекомендует параметры конфигурации, которых нет в документации используемой версии фреймворка.
3. При генерации тестов модель «проверяет» несуществующее поведение, создавая ложную уверенность в покрытии.
4. Генерация архитектурных схем с API-вызовами к сервисам, которые изменили интерфейс.

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

Ключевой принцип для управления этим риском: относитесь к ИИ-ассистенту как к очень быстрому стажёру без чувства самосохранения. Он выдаёт тонну идей и кода, но всё это требует проверки [7].

3. Slopsquatting: галлюцинации как вектор атаки на supply chain

В апреле 2025 года исследователи из трёх американских университетов опубликовали работу, которая переформатировала восприятие угроз supply chain. Анализ 576 000 фрагментов кода, сгенерированных 16 различными LLM на Python и JavaScript, выявил: примерно в 20% случаев модели рекомендовали пакеты, которых не существует [9].

Ключевое открытие: эти галлюцинации воспроизводимы. Одна и та же модель при похожих запросах снова и снова придумывает одни и те же несуществующие имена пакетов. 43% галлюцинированных имён повторялись в 10 из 10 запросов, 58% — хотя бы в двух [9].

Исследователь по безопасности Сет Ларсон (Python Software Foundation) назвал этот вектор атаки slopsquatting — по аналогии с typosquatting, только здесь атакующий не ждёт опечатки от человека, а заранее регистрирует пакеты с именами, которые предсказуемо «придумывает» ИИ [10].

Механика атаки:

1. Атакующий изучает, какие несуществующие пакеты LLM рекомендует чаще всего.
2. Регистрирует эти имена на PyPI, npm или аналогах.
3. Заливает в пакет вредоносный код.
4. Любой разработчик, следующий рекомендации ИИ и не проверяющий существование пакета, устанавливает малварь.

Реальный пример: фейковый пакет huggingface-cli на PyPI набрал более 30 000 загрузок за три месяца [10]. Атаки такого типа уже классифицированы по MITRE ATT&CK как T1195.002 (компрометация цепочки поставок ПО).

Открытые LLM демонстрируют наибольшую частоту галлюцинаций. Коммерческие инструменты надёжнее, но GPT-4, например, всё равно галлюцинирует имена пакетов примерно в 5% случаев [11] — что при тысячах AI-рекомендаций в день создаёт существенную поверхность атаки.

4. Утечка данных и потеря интеллектуальной собственности

Кейс Samsung в 2023 году стал учебником по тому, как быстро может произойти катастрофа при бесконтрольном использовании ИИ. Компания открыла доступ к ChatGPT для инженеров своего полупроводникового подразделения 11 марта — и уже через 20 дней зафиксировала три отдельных инцидента утечки [12].

Инженеры делали вполне разумные, с их точки зрения, вещи:

1. Вставили в ChatGPT проприетарный исходный код базы данных производственного оборудования для отладки ошибок.
2. Загрузили алгоритмы обнаружения дефектов полупроводниковых компонентов для оптимизации.
3. Преобразовали запись внутреннего совещания в текст через сторонний сервис и отправили в ChatGPT для составления резюме.

Проблема: исходный код, управляющий измерениями и обнаружением дефектов — это интеллектуальная собственность, конкурентное преимущество, измеряемое в нанометрах и процентах выхода годных изделий. После отправки в OpenAI данные перешли под контроль третьей стороны, и Samsung не мог ни отозвать, ни удалить их [12].

Samsung запретил все генеративные ИИ-инструменты в течение месяца. Одновременно компания начала разработку собственного внутреннего LLM — путь, который после инцидента избрали многие крупные корпорации, включая JPMorgan и Bloomberg [13].

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

Отдельный вектор — утечка секретов в репозитории. Исследование GitGuardian показывает, что репозитории с активным использованием GitHub Copilot утекают хотя бы один секрет в 6,4% случаев — это на 40% выше, чем в репозиториях без ИИ-ассистентов [3]. AI-assisted коммиты раскрывают секреты более чем вдвое чаще: 3,2% против 1,5% для коммитов без ИИ [14].

В контексте российского законодательства это создаёт дополнительные регуляторные риски: с 1 марта 2026 года действует Приказ ФСТЭК № 117, затрагивающий применение ИИ в безопасной разработке, а требования к обработке персональных данных и защите КИИ делают бесконтрольную передачу данных в зарубежные LLM юридически опасной [15].

5. Технический долг: скорость сейчас — расплата потом

Forrester в 2025 году предупредил: индустрию разработки ждёт «цунами технического долга» в ближайшие два года — прямое следствие массового вайб-кодинга [16].

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

1. Дублирование кода. Copilot генерирует «retry с backoff» три раза для трёх разных сервисов. Каждая реализация чуть отличается. Три месяца спустя — три разных бага при изменении SLA.
2. Нарушение SOLID и принципов чистой архитектуры. ИИ оптимизирует локальное решение, не видя глобальной структуры.
3. Отсутствие тестов. Вайб-кодинг катастрофически снижает дисциплину TDD.
4. Слишком большие файлы. Отсутствие разбивки на модули — типичный признак.
5. Churn (код, который добавляется и быстро изменяется или удаляется). По прогнозам, к концу 2025 года churn достиг ~7% — признак кода, который «не до конца понят» при слиянии [17].

Данные SonarSource: ИИ-ускоренные кодовые базы показывают на 9% больше багов и PR в среднем на 154% крупнее, чем человеческие [18]. Ревьюеры тонут в объёме, внимание рассеивается, дефекты уходят в main.

Статистика METR (2025) особенно показательна: в рандомизированном контролируемом исследовании 16 опытных разработчиков работали над 246 реальными задачами с ИИ и без. Результат: использование ИИ снизило продуктивность на 19%. При этом сами разработчики оценивали, что ИИ ускорил их работу на 20% — разрыв между восприятием и реальностью составил 39 процентных пунктов [19].

6. Деградация навыков: тихая системная угроза

Исследование Anthropic (опубликовано в феврале 2026 года в InfoQ) замерило влияние ИИ-ассистентов на освоение новых библиотек. Разработчики, делегировавшие ИИ генерацию кода, набрали на 17% ниже по тестам понимания по сравнению с теми, кто использовал ИИ лишь для концептуальных вопросов [20].

Паттерн воспроизводит то, что уже изучено на примере авиации: пилоты, полностью доверяющие автопилоту, теряют навыки ручного пилотирования — иногда с катастрофическими последствиями. Разница сейчас в масштабе: предыдущие волны автоматизации затрагивали отдельные роли, LLM трансформируют весь сектор знаний одновременно [21].

По данным Stanford Digital Economy Study, к июлю 2025 года занятость разработчиков в возрасте 22–25 лет снизилась почти на 20% от пика конца 2022 года [22]. Входной уровень в профессию поднялся: рутинные задачи, которые исторически оправдывали найм джуниоров, автоматизированы.

Исследование Clutch (июнь 2025, 800 специалистов): 59% разработчиков используют ИИ-сгенерированный код, которого они не понимают [23]. У джуниоров без фундаментальной базы формируется порочный круг: они доверяют ИИ больше, чем собственной интуиции, именно потому что не имеют навыков для оценки его вывода.

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

7. Атаки на инструменты разработки: backdoor через конфигурацию

18 марта 2025 года компания Pillar Security описала новый вектор атаки — Rules File Backdoor [14]. Атакующие внедряют скрытые инструкции в конфигурационные файлы (.cursor/rules, аналогичные файлы для Copilot), используя невидимые Unicode-символы: zero-width joiners, bidirectional text markers. ИИ-ассистент обрабатывает эти скрытые инструкции и тихо генерирует бэкдорный код, который выглядит чистым при обычном code review.

GitHub не классифицировал технику как уязвимость, но 1 мая 2025 года ввёл предупреждение для Copilot о скрытых Unicode-символах [14]. Конфигурационные файлы ИИ-инструментов стали самостоятельным вектором атаки, требующим контроля целостности.

Другой вектор — prompt injection через контент, с которым взаимодействует ИИ-агент. По мере того как агенты получают доступ к файловой системе, API, внутренним системам, возможность манипуляции через внешние данные (документы, email, веб-страницы) становится реальной угрозой [24]. Специалисты по безопасности Лаборатории Касперского отмечают, что расширение контекста агентов создаёт риск «размывания внимания» модели и ошибочных действий с инфраструктурой [24].

Практические рекомендации: как управлять рисками

Организационный уровень

1. Разработать и внедрить AI Acceptable Use Policy до, а не после первого инцидента. Политика должна разграничивать допустимые данные для ввода в публичные LLM: проприетарный код, данные клиентов, конфигурации инфраструктуры — вне зоны.

1. Для критических проектов использовать on-premise или private cloud LLM, исключающие передачу данных на серверы третьих сторон. Инцидент Samsung — это обучение ценой реального ущерба; обучение на чужом опыте значительно дешевле.

1. Ввести обязательный security review для ИИ-сгенерированного кода — отдельный от стандартного code review. В критически важных проектах проверка тимлидом является обязательной [25].

1. Настроить DLP (Data Loss Prevention) для мониторинга исходящего трафика к LLM-сервисам. Технические меры надёжнее осведомлённости — Samsung показал, что инженеры нарушали политику не из злого умысла, а из стремления работать эффективнее.

Технический уровень

1. Интегрировать SAST/SCA в CI/CD для автоматического сканирования всего кода, включая AI-сгенерированный. При темпах 10 000+ новых находок в месяц ручной контроль неэффективен.

1. Проверять все зависимости, рекомендованные ИИ, через официальные реестры перед установкой. Lockfile commitment — обязателен. Атака slopsquatting эксплуатирует именно момент первой установки.

1. Контролировать целостность конфигурационных файлов ИИ-инструментов (.cursor/rules, .copilot и аналогов) через git diff с проверкой на скрытые Unicode-символы.

1. Ограничить права ИИ-агентов по принципу least privilege. Агент, которому нужен только read-only доступ к репозиторию, не должен иметь права на запись в базу данных.

Уровень команды

1. Ввести «защитные зоны» без ИИ для джуниоров на этапе онбординга. McKinsey реализовал аналогичный подход: ИИ-доступ открывается после демонстрации независимых компетенций [21].

1. Регулярно проверять понимание кода, написанного с ИИ. Если разработчик не может объяснить логику — это сигнал.

1. Поддерживать культуру «ИИ — инструмент, а не автор». Архитектурные решения, выбор зависимостей и решение нестандартных задач должны оставаться зоной человеческой ответственности.

Чек-лист безопасного внедрения ИИ в разработку

• Политика допустимого использования ИИ принята и доведена до команды
• Список запрещённых к вводу в LLM данных определён и техническими средствами контролируется
• SAST/SCA интегрированы в пайплайн и покрывают AI-сгенерированный код
• Все LLM-рекомендованные зависимости проходят верификацию по официальным реестрам
• Конфигурационные файлы ИИ-инструментов под контролем целостности
• Права ИИ-агентов ограничены по принципу least privilege
• Для критических проектов — on-premise или enterprise-tier LLM с гарантиями data residency
• Программа обучения команды по рискам ИИ проведена
• Процесс отдельного security review для AI-кода регламентирован

Ошибки, которые совершают чаще всего

1. «Запретить ИИ» как ответ на риски. Разработчики всё равно будут использовать инструменты неофициально — только уже без какого-либо контроля. Корпоративный запрет без альтернативы не снижает риск, а лишь скрывает его.

1. Политика без технического enforcement. Samsung ввёл ограничение на 1024 байта данных в запросе — но не на сетевом уровне. Инженеры проигнорировали рекомендацию, потому что не было технического барьера [13].

1. Один стандартный code review на весь код — ИИ-сгенерированный и человеческий. Крупные PR с AI-кодом требуют иного подхода: они в среднем на 154% больше и содержат изменения сразу в нескольких файлах и сервисах [18].

1. Игнорирование долгосрочного влияния на команду. Скорость доставки растёт, но incidents per pull request тоже растут — на 23,5% по данным Apiiro [3]. Это сигнал, требующий реакции.

1. Отсутствие мониторинга качества AI-кода. Без метрик — bugs per PR, churn rate, vulnerability density — невозможно понять, работает ли governance реально.

Тренды: что будет дальше

67% разработчиков по всему миру применяют ИИ в рабочих процессах [26] — мы прошли точку невозврата от экспериментов к инфраструктуре. Переход от AI-assisted к AI-agentic разработке (агенты, автономно модифицирующие кодовую базу) уже идёт: Copilot Agent Mode, Cursor, Devin и аналоги меняют роль человека от исполнителя к ревьюеру.

Регуляторная среда ужесточается: в России вступил в силу Приказ ФСТЭК № 117 (март 2026), формируется нормативная база для ИИ в КИИ [15]. В ЕС AI Act уже предъявляет требования к высокорисковым системам. Организации, выстраивающие governance сейчас, получат конкурентное преимущество при выходе на регулируемые рынки.

Инструменты для контроля качества AI-кода активно развиваются: специализированные SAST для LLM-кода, behavioral analysis зависимостей, SCA с проверкой на slopsquatting. Это рынок, которого два года назад не существовало.

Заключение

ИИ в разработке — это не будущее, это настоящее. И настоящее требует зрелого подхода: не запрета и не слепого доверия, а системного governance.

Семь описанных категорий рисков (уязвимый код, галлюцинации, slopsquatting, утечка данных, технический долг, деградация навыков, атаки на инструменты) не взаимоисключающие — они взаимоусиливающие. Команда, не понимающая код, который генерирует ИИ, не заметит ни галлюцинацию, ни уязвимость, ни бэкдор.

Что делать прямо сейчас:

1. Провести аудит: какие данные сейчас передаются в LLM вашими разработчиками.
2. Оценить текущий security posture AI-сгенерированного кода в репозиториях.
3. Разработать и принять AI Acceptable Use Policy.
4. Интегрировать SAST/SCA с покрытием AI-кода в CI/CD.
5. Обучить команду — не «как запрещать ИИ», а «как использовать ответственно».

HighVibe: слой контроля там, где ИИ-код уходит в production

Все семь рисков, разобранных выше, объединяет один общий момент: уязвимость, бэкдор, слитый секрет или вредоносная зависимость попадают в production через pull request. Скорость AI-кодинга опередила скорость review: дифы не дочитывают, зависимости не проверяют, конфиги и служебные файлы смотрят хуже всего.

Именно в этот момент — до merge и до релиза — работает HighVibe. Это дополнительный слой контроля безопасности AI-кодинга: продукт анализирует конкретное изменение в коде, конфигурации и служебных файлах, новые и обновлённые зависимости, контекст релиза, и помогает команде заметить риск до того, как он ушёл в main.

Логика простая: не тотальное сканирование репозитория без повода, а анализ конкретного PR — что изменилось, что приехало вместе с изменением, что блокирует безопасный выпуск. Вместо длинного security-отчёта — короткий понятный сигнал: что критично, что нужно перепроверить, какой следующий шаг.

В контексте рисков AI-разработки HighVibe закрывает несколько сценариев, которые сложно покрыть стандартными инструментами:

1. AI написал быстро, но PR никто не прочитал до конца — HighVibe смотрит на изменение целиком, включая места, которые review пропускает.
2. Новая или транзитивная зависимость приехала вместе с PR — анализ lock-файлов, advisories, package hallucinations как часть контроля изменения.
3. Служебный код, конфиги, миграции, CI/CD-файлы — именно то, что читают хуже всего и куда легче всего встроить бэкдор или debug-настройку, оставшуюся в production.
4. Перед релизом нужен ответ «что действительно блокирует выпуск», а не ещё один список из сотни находок.

HighVibe не заменяет SAST, SCA, SBOM-инструменты или AppSec-программу — он работает рядом с ними как дополнительный слой, ориентированный на момент принятия решения: merge или нет, release или нет.

Источники

[1] Stack Overflow — "Stack Overflow Developer Survey 2025" — https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/

[2] Stanford HAI — "AI Index Report 2025" — https://www.kt-team.ru/blog/dora-2025-ai-change-3-years-part-4

[3] Apiiro — "4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks" — https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/

[4] Veracode — "GenAI Code Security Report 2025" — https://www.veracode.com/blog/ai-generated-code-security-risks/

[5] SoftwareSeni — "AI-Generated Code Security Risks: Why Vulnerabilities Increase 2.74x" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[6] Vibe Coder Blog — "Security Researchers Sound the Alarm on AI Code Vulnerabilities" — https://blog.vibecoder.me/security-researchers-ai-code-vulnerability-crisis

[7] MayAI — "Галлюцинации ИИ: как уменьшить их количество при кодинге" — https://mayai.ru/stolknulis-s-problemami-v-kodinge-iz-za-gallyuczinaczij-ai-uznajte-kak-umenshit-ih-kolichestvo-i-povysit-kachestvo-razrabotki/

[8] NeuroToday — "Галлюцинации ИИ: что это такое, почему возникают и как с ними бороться" — https://www.neurotoday.ru/journal/chto-takoe-gallyucinacii-ii

[9] BleepingComputer — "AI-hallucinated code dependencies become new supply chain risk" — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[10] dsebastien.net — "Slopsquatting, Typosquatting, and the New Software Supply Chain Attacks" — https://www.dsebastien.net/slopsquatting-typosquatting-and-the-new-software-supply-chain-attacks-how-ai-and-vibe-coding-are-making-package-registries-even-more-dangerous/

[11] Daniel J. Glover — "Slopsquatting: AI Supply Chain Attacks" — https://www.danieljamesglover.com/blog/2026-01-26-slopsquatting-ai-supply-chain-attacks/

[12] ModelPiper — "The Samsung ChatGPT Leak: What Developers Need to Know" — https://modelpiper.com/blog/samsung-chatgpt-code-leak/

[13] RedTeams.ai — "Case Study: Samsung ChatGPT Confidential Data Leak (2023)" — https://redteams.ai/topics/case-studies/case-study-chatgpt-data-leak-2023

[14] Cloud Security Alliance — "Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/

[15] sec.ussc.ru — "Безопасная разработка — 2026: как 117 приказ ФСТЭК России меняет правила игры" — https://sec.ussc.ru/prikaz_117_ai

[16] Tabnine — "How to avoid vibe coding your way into a tsunami of tech debt" — https://www.tabnine.com/blog/how-to-avoid-vibe-coding-your-way-into-a-tsunami-of-tech-debt/

[17] Xebia — "Vibe Coding With GitHub Copilot: Fun Until Maintenance Hits" — https://xebia.com/blog/vibe-coding-github-copilot-maintenance/

[18] Medium / Faisal Feroz — "AI Coding Tools and Technical Debt" — https://fferoz.medium.com/ai-copilot-is-writing-your-code-10x-faster-its-also-creating-technical-debt-10x-faster-a96491cb4f63

[19] Final Round AI — "How AI Vibe Coding Is Destroying Junior Developers' Careers" — https://www.finalroundai.com/blog/ai-vibe-coding-destroying-junior-developers-careers

[20] InfoQ — "Anthropic Study: AI Coding Assistance Reduces Developer Skill Mastery by 17%" — https://www.infoq.com/news/2026/02/ai-coding-skill-formation/

[21] WebProNews — "The Great Forgetting: How AI Tools Are Quietly Eroding the Skills" — https://www.webpronews.com/the-great-forgetting-how-ai-tools-are-quietly-eroding-the-skills-they-were-built-to-enhance/

[22] Stack Overflow Blog — "AI vs Gen Z: How AI has changed the career pathway for junior developers" — https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/

[23] Clutch — "Blind Trust in AI: Most Devs Use AI-Generated Code They Don't Understand" — https://clutch.co/resources/devs-use-ai-generated-code-they-dont-understand

[24] togliatti24.ru — "Использование ИИ в разработке повышает риск утечек и атак на данные" — https://togliatti24.ru/dzen/view/ii-v-razrabotke-mozet-sozdat-novye-riski-utecek-dannyh-i-kiberatak

[25] IBS Training — "ИИ в разработке ПО: преимущество или риск" — https://ibs-training.ru/about/news/II_v_razrabotke_PO_preimushchestvo_ili_risk/

[26] Habr — "Революция ИИ в 2026 году: ключевые тренды" — https://habr.com/ru/articles/1014910/