Как не потерять качество кода, когда команда стала писать быстрее с ИИ

Скорость — не синоним качества. Почему рост производительности с AI-ассистентами создаёт новые риски и что с этим делать до merge и релиза

Введение: «работает» — не значит «готово к продакшену»

За последние два года AI-ассистенты прошли путь от экспериментального инструмента до стандартного элемента рабочего стола разработчика. По данным Stack Overflow Developer Survey 2024, 63% профессиональных разработчиков уже используют AI в рабочем процессе [7]. DORA 2025 фиксирует ещё более высокую отметку: 90% опрошенных специалистов применяют AI в ежедневной работе [3].

Результат предсказуем: команды пишут код быстрее. Эпических спорят о том, насколько быстрее — данные варьируются от 10% до 55% роста производительности [8]. Но в том же 2025 году несколько независимых исследований зафиксировали тревожную тенденцию: скорость растёт, а качество кода — нет. Более того, в ряде метрик оно деградирует.

Это не значит, что AI-инструменты бесполезны. Это значит, что привычная модель контроля изменений — code review раз в день, несколько линтеров в CI, security-сканирование перед релизом — не успевает за новым темпом. Рабочий PR не обязательно безопасен. Принятая подсказка не обязательно верна. И чем больше кода генерируется, тем критичнее становится вопрос: кто и как проверяет каждое изменение перед тем, как оно попадёт в main?

Эта статья — для CTO, VP Engineering, Tech Lead и AppSec-специалистов, которые уже столкнулись с этой проблемой или хотят опередить её.

Часть 1. Что происходит с качеством кода в эпоху AI-ассистентов

Дублирование, клонирование и технический долг

GitClear провёл масштабный анализ 211 миллионов изменённых строк кода за период 2020–2024 годов. Вывод жёсткий: доля рефакторинга в изменениях упала с 25% в 2021 году до менее чем 10% в 2024-м, тогда как доля copy/paste выросла с 8,3% до 12,3% [1]. Количество блоков кода с пятью и более дублированными строками за 2024 год увеличилось в 8 раз [9].

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

Отдельные данные от Carnegie Mellon: исследователи проанализировали 807 open-source репозиториев на GitHub, принявших Cursor между январём 2024-го и мартом 2025-го, и отслеживали их до августа 2025-го. AI кратковременно ускоряет генерацию кода, но базовые метрики качества продолжают двигаться в неправильном направлении — даже с учётом значительного улучшения моделей за этот период [10].

MIT Sloan Review формулирует проблему ёмко: «AI-инструменты делают разработчиков на 55% производительнее, но быстрое развёртывание создаёт опасный технический долг» [8]. В brownfield-окружениях с легаси-системами AI-генерированный код, написанный младшими разработчиками, усугубляет уже существующие проблемы.

Исправление бага в AI-сгенерированном коде оценивается в 3–4 раза дороже, чем в человеко-написанном, потому что разработчику сначала нужно восстановить намерение модели, а потом уже применять исправление [11].

Рост скорости и падение стабильности

DORA 2025 вводит важное разграничение: AI улучшает индивидуальную эффективность, качество кода и производительность команды, но одновременно увеличивает instability при росте velocity [3]. Это не противоречие — это системный эффект.

Данные телеметрии по 22 000 разработчиков за 2025 год фиксируют следующее: медианное время в PR review выросло на 441%, количество PR, смёрдженных без ревью, увеличилось на 31%, а количество багов на разработчика выросло на 54% [12]. Количество инцидентов на PR выросло на 242,7% — то есть вероятность production-инцидента на каждое смёрженное изменение утроилась.

При этом сами PR становятся крупнее: их размер вырос на 51,3% [12]. Большой PR — это когнитивная перегрузка ревьюера, снижение глубины ревью и рост вероятности пропуска критических изменений.

DORA однозначно указывает: команды без сильных инженерных практик практически не получают выгоды от AI, а AI усиливает имеющиеся слабости так же уверенно, как усиливает сильные стороны [3].

Часть 2. Безопасность: где AI-генерированный код особенно уязвим

Уязвимости из OWASP Top 10 в сгенерированном коде

Veracode протестировал более 100 LLM-моделей и установил, что 45% сгенерированного кода не проходит security-тесты, вводя уязвимости из OWASP Top 10 [2]. Checkmarx получил схожие данные: до 70% AI-генерированного кода оказывается небезопасным при проверке несколькими популярными ассистентами [13].

AI-генерированный код имеет в 2,7 раза более высокую плотность уязвимостей по сравнению с человеко-написанным кодом [14]. Security-покрытие ревью для AI-генерированного кода в среднем на 20–30% ниже, чем для ручного [14].

Наиболее частые типы уязвимостей:

1. Cross-Site Scripting (CWE-80): AI-инструменты не предотвращают XSS в 86% релевантных сэмплов, по данным Veracode [2].
2. Log injection: присутствует в 88% AI-генерированных сценариев [14].
3. Hardcoded credentials (CWE-259/798): регулярно встречаются в коде, сгенерированном ассистентами, обученными на публичных репозиториях с накопленными историческими утечками [5].
4. SQL injection (CWE-89) и Code Injection (CWE-94): входят в MITRE Top 25 Most Dangerous Software Weaknesses 2024 [15].

Отдельная проблема, выявленная в исследовании IEEE-ISTAS 2025: итеративное уточнение кода через LLM не улучшает безопасность — напротив, после пяти итераций количество критических уязвимостей вырастает на 37,6% [16]. Это противоречит интуитивному предположению, что «поправил и стало лучше».

Секреты и credentials в AI-генерированном коде

GitGuardian's State of Secrets Sprawl 2025 фиксирует: репозитории с активным Copilot показывают на 40% более высокую частоту утечек секретов по сравнению со средним публичным репозиторием [5]. За 2025 год на GitHub было обнаружено около 29 миллионов новых захардкоженных секретов — рост 34% год к году [17].

Утечки AI-service credentials ускоряются особенно быстро: рост 81% за год. Коммиты, связанные с Claude Code, показывают утечки секретов с частотой около 3,2% — вдвое выше базового уровня [17].

Причина системная: LLM обучены на публичных репозиториях, где захардкоженные секреты исторически встречаются часто. Модели воспроизводят паттерны. Даже если секрет был удалён из репозитория после утечки — он остаётся в весах модели и может быть воспроизведён повторно [18].

В марте 2025 года была раскрыта атака «Rules File Backdoor» (CVE-2025-53773): скрытые Unicode-символы в конфигурационных файлах могут инжектировать вредоносные инструкции, управляющие генерацией кода Copilot [19]. Это новый класс атак, специфичный для AI coding-среды.

Package hallucinations и slopsquatting

Исследование, опубликованное в марте 2025 года, проанализировало 576 000 Python и JavaScript сэмплов, сгенерированных LLM. Результат: примерно в 20% случаев рекомендованные пакеты не существуют [4]. 43% галлюцинированных имён пакетов стабильно воспроизводятся при повторных запросах — это предсказуемые, а не случайные ошибки [4].

В апреле 2025 года Seth Larson из Python Software Foundation ввёл термин slopsquatting: атака, при которой злоумышленник заранее регистрирует галлюцинированные AI-ассистентом имена пакетов с вредоносной нагрузкой [20]. Академическое подтверждение пришло в мае 2025 на USENIX Security 2025.

Отчёт Socket за 2025 год насчитал 454 648 вредоносных пакетов в публичных registry [20]. Supply chain атакуется с двух сторон одновременно: AI галлюцинирует несуществующие имена, а злоумышленники эти имена регистрируют.

Часть 3. Почему привычные процессы не успевают за новым темпом

PR стали больше, ревью — хуже

Традиционная code review предполагала, что разработчик читает весь diff. Это предположение разрушается при размере PR свыше 300–400 строк — когнитивная усталость снижает глубину ревью [21]. AI-ассистенты систематически увеличивают размер PR.

Исследование Qodo: 65% разработчиков называют missing context главной причиной плохого качества при рефакторинге, около 60% — при генерации тестов и code review [6]. Контекстные пробелы цитируются чаще, чем галлюцинации.

При этом только 3,8% разработчиков сообщают о низком уровне галлюцинаций и высокой уверенности в том, что AI-генерированный код можно шипить без human review [6]. Большинство перепроверяет, переписывает или удаляет AI-предложения — но не всегда успевает это сделать перед merge.

Служебный код остаётся слепым пятном

Конфигурации, CI/CD-файлы, IaC-шаблоны, миграции баз данных, internal tools — всё это читают хуже всего. AI-ассистенты генерируют и их тоже. Например, AI может предложить AWS IAM permissions с избыточным доступом или Kubernetes RBAC roles с излишними правами администратора — и это будет принято как часть большого PR, в котором основное внимание уделяется бизнес-логике [29].

OWASP GenAI Security Project ввёл LLM01 (Prompt Injection) как главный риск LLM-приложений. Но применительно к AI coding существует и обратная сторона: prompt injection в конфигурационных файлах как вектор манипуляции поведением ассистента при генерации кода [13].

Ложная уверенность

Исследования зафиксировали паттерн, который называется «false sense of security»: разработчики, использующие AI-ассистенты, написали значимо менее безопасный код, чем группа без AI, — но при этом выше оценивали безопасность собственных решений [16]. 58% разработчиков доверяют AI-выходу без тестирования [14].

DORA 2025 прямо указывает: только 24% опрошенных доверяют AI-генерированному выходу в значительной степени [3]. Оставшиеся 76% сомневаются — но сомнения не всегда конвертируются в действие до merge.

Часть 4. Практический фреймворк: как удержать качество

Принцип 1. Контроль должен встраиваться в процесс, а не приходить после

Ключевое правило: gate нужен до merge, а не после. Реакция на production-инцидент в 3–10 раз дороже, чем предотвращение на уровне PR [11].

Практическая архитектура контроля строится в три слоя:

1. Автоматика в IDE и pre-commit: линтеры, форматтеры, секрет-детекторы, SAST с быстрым feedback loop прямо в среде разработчика.
2. Автоматика на уровне PR: AI-code review (CodeRabbit, Qodo, GitHub Copilot PR Reviews, Cursor Bugbot), качественные gates в CI/CD — покрытие, дублирование, security patterns, утечки секретов.
3. Human review с чётко разграниченными зонами ответственности: архитектурные решения, бизнес-логика, trade-offs. Всё, что могут поймать инструменты — отдаётся инструментам.

По данным Microsoft, AI-assisted code review покрывает более 90% PR в компании и влияет на более 600 000 pull requests в месяц [22]. Это не замена human review — это освобождение человека для тех решений, где его суждение действительно необходимо.

Принцип 2. Маленькие PR — системная практика

Оптимальный размер PR для эффективного ревью — до 400 строк, идеально до 300 [21]. Это не только практика code review — это способ борьбы с когнитивной перегрузкой в условиях высокой скорости генерации.

Большой PR читают по диагонали. Диагональное чтение пропускает именно то, что находится в конфигурациях, зависимостях и вспомогательном коде — то, что AI чаще всего генерирует с рисками.

SLA на первый ревью-комментарий: рекомендуемый стандарт — 24 часа [21]. Растущий бэклог PR — сигнал дисбаланса нагрузки или недостаточной автоматизации, а не признак «команда занята».

Принцип 3. Зависимости — первый класс угроз

Каждая новая зависимость, которую предлагает AI-ассистент, требует проверки:

1. Пакет существует в официальном registry?
2. Это тот пакет, который имелся в виду, а не typosquat или slopsquat?
3. У пакета есть известные уязвимости (CVE, advisories)?
4. Какова история транзитивных зависимостей?
5. Есть ли SBOM для этого изменения?

Никогда не устанавливать пакет только по рекомендации AI без самостоятельной верификации имени и источника [4]. Это особенно актуально для менее популярных экосистем, где «случайных» пакетов меньше и слopsquatting-атака менее заметна.

SCA-инструменты (Snyk, Dependabot, Socket) должны работать на каждый PR, не только по расписанию.

Принцип 4. Секреты не должны оказываться в коде

Pre-commit hooks с secret scanning — не опция, а обязательный элемент. GitGuardian, truffleHog, detect-secrets — любой из них значительно снижает вероятность попадания credentials в репозиторий. Дополнительно:

1. Запрет на хранение секретов в конфигурационных файлах — только ссылки на vault или environment variables.
2. Обязательная ротация секретов при обнаружении утечки.
3. Аудит MCP server configurations: именно этот класс конфигов показал более 24 000 экспонированных секретов в 2025 году [17].

Принцип 5. Разделить «нельзя мёрджить» и «нужно посмотреть»

Не все находки одинаково критичны. Смешивание blocking и non-blocking issues в одном потоке создаёт шум и приводит к alert fatigue — разработчики начинают игнорировать предупреждения.

Рекомендуемая классификация для PR-feedback:

1. Blocking (нельзя мёрджить): уязвимости безопасности, утечки секретов, критические баги корректности, нарушения принципиальных архитектурных решений.
2. Non-blocking/warning: потенциальные проблемы производительности, дублирование кода, именование, незначительные стилевые отступления.
3. Suggestion/nit: оформление, читаемость, незначительные рефакторинги.

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

Принцип 6. Метрики качества — рядом с метриками скорости

Если команда измеряет только velocity (deployment frequency, PR merge rate), она оптимизирует только скорость. Нужны метрики другого порядка:

1. Change failure rate: доля развёртываний, приведших к инцидентам.
2. Rework rate: доля кода, переписанного в течение двух недель после написания.
3. PR review coverage: доля PR, прошедших содержательное ревью.
4. Security findings per release: количество находок безопасности на релиз.
5. Mean time to detection: время от появления уязвимости до её обнаружения.

DORA 2025 добавил Rework Rate в список ключевых метрик именно из-за роста AI-генерированного кода [3, 44]. Это прямой сигнал quality degradation.

Часть 5. Что особенно рискованно в AI-кодинге: карта слепых зон

Конфигурации и IaC

Terraform, Helm charts, Kubernetes YAML, GitHub Actions workflows — AI генерирует их уверенно, но с системными паттернами ошибок: слишком широкие IAM-права, debug-режимы, открытые порты, небезопасные defaults. Эти файлы читают быстро или не читают совсем, особенно если основная часть PR содержит значимую бизнес-логику.

Миграции баз данных

Необратимые или сложно обратимые операции — DROP, ALTER, массовые UPDATE — должны проверяться отдельно. AI может генерировать корректную по синтаксису миграцию с разрушительным эффектом при применении в production.

Internal tools и служебные скрипты

Инструменты деплоя, скрипты backup, обработчики очередей — код, который «работает один раз» и потому почти не ревьюируется. При этом именно здесь часто хранятся захардкоженные credentials, широкие права доступа и отсутствующий error handling.

Тесты

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

Часть 6. Системный взгляд: AI как усилитель практик

DORA 2025 формулирует это точно: AI усиливает то, что уже есть. Команды с сильными инженерными практиками получают выгоду от AI. Команды с проблемами в процессах видят, как AI эти проблемы усугубляет [3].

Это значит, что вопрос «как не потерять качество с AI» — это в первую очередь вопрос зрелости инженерных практик. AI не создаёт проблему качества с нуля. Он делает существующую проблему видимой и масштабирует её.

Google Cloud Blog, анонсируя DORA 2025, особо отметил: «Ценность AI раскрывается не инструментами самими по себе, а окружающими техническими практиками и культурной средой» [47]. Семь ключевых capabilities для эффективного AI-adoption включают автоматизацию, platform engineering, экспериментирование и управление рисками [47].

Инвестиции в контрольный слой — это не бюрократия, это конкурентное преимущество. Команда, которая может уверенно и быстро принимать изменения, знает о каждом критическом риске до merge и не теряет время на post-production fire drills — быстрее в конечном счёте, чем команда, которая движется быстро и ломает вещи.

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

Часть 7. Типичные ошибки при внедрении AI-ассистентов в команду

Ошибка 1. «Раз AI написал, значит проверено»

Самая распространённая. 58% разработчиков принимают AI-output без тестирования [14]. AI-ассистент — это инструмент генерации, а не инструмент верификации. Код нужно проверять независимо от источника.

Ошибка 2. Ослабление ревью при росте скорости

Логика «у нас теперь больше кода, поэтому на каждый PR меньше времени» ведёт к деградации ревью как практики. Правильная логика — «у нас больше кода, поэтому нужно больше автоматизации в pre-merge, чтобы ревьюер концентрировался на том, что важно».

Ошибка 3. Один и тот же процесс для всех типов изменений

Фича в бизнес-логике и изменение в CI/CD-конфиге или IaC — это разные объекты с разным профилем риска. Дифференцированный подход к ревью по типу изменения снижает нагрузку там, где риск низкий, и усиливает контроль там, где риск высокий.

Ошибка 4. Откладывать security до отдельного security sprint

Security sprint раз в квартал при постоянном потоке AI-генерированного кода — это очередь уязвимостей, ожидающих своего часа в продакшне. Security-проверки должны быть частью каждого PR, а не отдельного этапа.

Ошибка 5. Игнорировать lock-файлы и транзитивные зависимости

package-lock.json, yarn.lock, requirements.txt — изменения в этих файлах часто воспринимаются как шум. Именно здесь могут появляться новые пакеты, введённые AI-ассистентом без явного запроса разработчика. Аудит lock-файлов должен быть частью review.

Будущее: куда движется контроль качества в AI-эпоху

Несколько трендов, которые формируются прямо сейчас:

AI-агенты заменяют отдельные сессии кодинга на автономные циклы с множеством коммитов. Это кардинально меняет модель: вместо «человек написал, человек отправил на ревью» появляется «агент написал несколько сотен строк, часть из которых никто не видел». Управление quality gates в agentic workflows — отдельная область, которая только формируется [22].

Формальная верификация на уровне PR начинает выходить из академической среды. Исследование Cobalt AI в апреле 2026 года применило Z3 SMT-solver для формальной верификации 3 500 AI-генерированных артефактов — это первый шаг к mathematical exploitability proofs для production code [12].

SBOM для AI-генерированного кода обсуждается в контексте регуляторных требований, особенно в европейской повестке. Требования к software transparency распространяются и на AI-компонент генерации [25].

Специализированные security frameworks для LLM-приложений продолжают развиваться: OWASP LLM Top 10 2025 опубликован, в декабре 2025 вышло расширение для agentic сценариев [15].

Заключение: качество — это процесс, а не состояние

Команды, которые стали писать быстрее с AI, оказались перед выбором: сохранить прежний уровень контроля (и потерять часть выгоды от скорости) или ускорить и процессы контроля тоже.

Правильный ответ — второй. Но это требует инвестиций: в автоматизацию pre-merge проверок, в дифференцированные gates по типу изменения, в культуру «маленьких PR», в обязательный аудит зависимостей и секретов, в метрики, которые делают деградацию качества видимой до того, как она стала production-проблемой.

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

Что делать дальше:

1. Провести аудит текущего coverage: какой процент PR проходит автоматическую security-проверку, сканирование зависимостей и секретов?
2. Внедрить secret scanning как обязательный pre-commit hook и CI-step.
3. Установить policy для размера PR: цель — до 400 строк.
4. Дифференцировать ревью по типу изменения: конфиги, IaC, зависимости — отдельный чеклист.
5. Добавить Rework Rate и Change Failure Rate в дашборд рядом с velocity.
6. Пересмотреть, что блокирует merge, а что является suggestion — и убедиться, что различие понятно команде.

Источники

[1] GitClear — "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones" — https://www.gitclear.com/ai_assistant_code_quality_2025_research

[2] Veracode — "We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests." — https://www.veracode.com/blog/genai-code-security-report/

[3] Google Cloud Blog — "Announcing the 2025 DORA Report" — https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

[4] 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/

[5] The Hacker News — "The New Frontier of Security Risk: AI-Generated Credentials" — https://thehackernews.com/expert-insights/2025/04/the-new-frontier-of-security-risk-ai.html

[6] Qodo — "State of AI code quality in 2025" — https://www.qodo.ai/reports/state-of-ai-code-quality/

[7] DevOps.com — "AI in Software Development: Productivity at the Cost of Code Quality?" — https://devops.com/ai-in-software-development-productivity-at-the-cost-of-code-quality-2/

[8] MIT Sloan Management Review — "The Hidden Costs of Coding With Generative AI" — https://sloanreview.mit.edu/article/the-hidden-costs-of-coding-with-generative-ai/

[9] DevClass — "AI is eroding code quality states new in-depth report" — https://devclass.com/2025/02/20/ai-is-eroding-code-quality-states-new-in-depth-report/

[10] Rob Bowley — "AI Is still making code worse: A new CMU study confirms" — https://blog.robbowley.net/2025/12/04/ai-is-still-making-code-worse-a-new-cmu-study-confirms/

[11] Baytech Consulting — "AI Technical Debt: How Vibe Coding Increases TCO" — https://www.baytechconsulting.com/blog/ai-technical-debt-how-vibe-coding-increases-tco-and-how-to-fix-it

[12] Faros AI — "DORA Report 2025 Key Takeaways: AI Impact on Dev Metrics" — https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025

[13] Growexx — "AI-Generated Code Security Risks: How It Aligns with OWASP Top 10" — https://www.growexx.com/blog/ai-generated-code-owasp-top-10/

[14] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[15] arxiv — "Security Vulnerabilities in AI-Generated Code" — https://arxiv.org/pdf/2510.26103

[16] arxiv — "Security Degradation in Iterative AI Code Generation: A Systematic Analysis" (IEEE-ISTAS 2025) — https://arxiv.org/html/2506.11022v2

[17] TechRadar — "Over 29 million secrets were leaked on GitHub in 2025, and AI really isn't helping" — https://www.techradar.com/pro/security/over-29-million-secrets-were-leaked-on-github-in-2025-and-ai-really-isnt-helping

[18] GitGuardian Blog — "Yes, GitHub Copilot Can Leak Secrets" — https://blog.gitguardian.com/yes-github-copilot-can-leak-secrets/

[19] StackHawk — "GitHub Copilot + StackHawk: Secure Code from The Start" — https://www.stackhawk.com/blog/github-copilot-secure-coding-guide/

[20] Simon Roses — "The Dependency Trap: Supply Chain Risks in AI-Generated Code" — https://simonroses.com/2026/05/the-dependency-trap-supply-chain-risks-in-ai-generated-code-part-4/

[21] CodeAnt AI — "How to Review Code in 2025: Code Review Best Practices That Work" — https://www.codeant.ai/blogs/code-review-process-guide

[22] Microsoft Engineering — "Enhancing Code Quality at Scale with AI-Powered Code Reviews" — https://devblogs.microsoft.com/engineering-at-microsoft/enhancing-code-quality-at-scale-with-ai-powered-code-reviews/

[23] Axify — "A 2026 Guide on How to Use AI for Developer Productivity" — https://axify.io/blog/use-ai-for-developer-productivity

[24] arxiv — "Broken by Default: A Formal Verification Study of Security Vulnerabilities in AI-Generated Code" — https://arxiv.org/pdf/2604.05292

[25] Cloud Security Alliance — "Vibe Coding's Security Debt: The AI-Generated CVE Surge" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/