Это конспект вебинара. Спикер — Даниил Степанов, разработчик‑исследователь Veai, преподаватель ИТМО, ранее работал в JetBrains и Huawei.

AI уже пишет заметную часть промышленного кода, а процессы качества у многих команд остались такими, будто код всё ещё пишет только человек и в прежнем объёме.

Если коротко: проблема чаще всего не в том, что «модель тупая». Проблема в том, что вокруг агента нет инженерного контура: спецификации, ограничений, независимых тестов, security‑checks, ревью‑пайплайна и артефактов, которым можно верить.

Качество кода в эпоху AI: как не утонуть в багах и уязвимостях 2026 Veai

TL;DR

• AI‑кодинг уже стал массовой практикой, а не экспериментом энтузиастов. На это указывают JetBrains Developer Ecosystem, Stack Overflow Developer Survey, GitHub Octoverse и исследования DORA/Faros AI: разработчики активно используют AI‑ассистентов, а доля AI‑generated кода в промышленной разработке быстро растёт.

• Рынок обещал «AI скоро напишет весь код», но исследования показывают более жёсткую картину: первые внедрения могут снижать продуктивность, раздувать PR и переносить узкое место в ревью, сопровождение и безопасность.

• AI‑дефекты сложнее ловить, потому что ошибка может появиться на любом шаге цепочки: понимание задачи, план, tool‑call, API, изменение кода, проверка.

• Типичный паттерн новичка: «задача в чате → LLM генерирует код → баги и регрессии → LLM пустой хайп».

• Лечится это не магическим промптом, а пайплайном: SDD, TDD, линтеры, SAST/SCA/DAST, fuzzing, property‑based testing, AI‑review и triage.

• Спецификация нужна не для бюрократии. Она не даёт агенту додумывать бизнес‑логику и ограничения за вас.

• Один агент не должен одновременно писать тесты, реализацию и ревьюить сам себя. Роли нужно разводить.

• AI‑review работает лучше как набор узких ревьюеров: security, architecture, tests, spec‑compliance, performance. Потом отдельный triage должен проверять каждую находку.

• Любое утверждение LLM должно подтверждаться артефактом: логом тестов, отчётом анализатора, coverage diff, профилем, метрикой.

Исследования и отчёты, на которые можно опереться по рынку и качеству AI‑кода:

• JetBrains Developer Ecosystem 2025 — ежегодный обзор практик разработчиков, включая использование AI‑инструментов.

• Stack Overflow Developer Survey 2025: AI — отношение разработчиков к AI‑инструментам, доверие и сценарии применения.

• GitHub Octoverse — динамика разработки на GitHub и роль AI/Copilot в экосистеме.

• DORA research — исследования инженерной эффективности, delivery performance и влияния практик разработки.

• arXiv:2605.06464 — работа, на которую ссылается презентация в части уязвимостей и сопровождения AI‑кода.

• arXiv:2511.04427 — работа, на которую ссылается презентация в части роста цикломатической сложности.

Видео запись вебинара:

Контекст: AI‑кода стало много

На слайдах вебинара были такие вводные:

Рынок при этом любит громкие обещания. В презентации отдельно собрали публичные прогнозы: «90% кода через 3–6 месяцев», «AI как mid‑level инженер», «никому больше не нужно программировать».

А затем показали вторую таблицу, уже не про ожидания, а про измерения:

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

Главная мысль вебинара

Проблема чаще всего не в агентах, а в процессе.

Типичный сценарий внедрения выглядит так:

На самом деле вывод другой: AI‑разработка требует другого контура качества.

Почему AI‑дефекты сложнее ловить

Обычный баг часто локален: человек ошибся в условии, забыл null‑check, перепутал поле. AI‑баг может быть распределён по цепочке.

Агент сначала чуть неправильно понял задачу. Потом построил логичный план. Потом нашёл похожий API, но не тот. Потом написал стилистически чистый код. Потом сам же написал тест, который подтверждает его решение. В каждом отдельном месте всё выглядит почти нормально.

Отсюда практический вывод: ревью AI‑кода не может ограничиваться просмотром diff. Нужно проверять требование, план, тесты, зависимости, security, конфигурацию и фактические артефакты запуска.

Где именно ломается агент

В презентации ошибки разложили по этапам агентской цепочки.

Разберём самые болезненные классы.

Ошибка 1. Агент понял слова, но не понял смысл

Разработчик обычно говорит с другим разработчиком поверх огромного слоя неявного контекста: домен, архитектура, старые решения, внутренние правила, ограничения безопасности, привычки команды.

Модель без этого слоя действует буквально. Если попросить «добавь endpoint баланса», она может сделать endpoint, который возвращает баланс кому угодно. Формально endpoint есть. Но по факту — неприемлемо.

Практический вывод: в задаче должны быть явно указаны роли, права, статусы ошибок, инварианты и non‑functional requirements.

Ошибка 2. Happy path вместо реального мира

AI часто пишет код для идеальной вселенной:

• пользователь существует;

• баланс положительный;

• банк отвечает;

• сеть не падает;

• повторный запрос не приходит;

• валюта одна;

• null и пустые списки не встречаются;

• часовой пояс не важен.

В проде всё наоборот.

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

Ошибка 3. Потеря инвариантов

Инвариант — это правило, которое нельзя нарушать даже при локальном изменении. Например:

• баланс кошелька не может уйти в минус;

• операция списания идемпотентна;

• пользователь видит только свои данные;

• pending‑транзакции не учитываются в доступном балансе;

• PII не попадает в логи;

• read‑endpoint не должен менять состояние.

Агент может не знать, что это правило существует, если оно нигде не записано.

Практический вывод: инварианты нужно выносить в spec, тесты, property‑based checks и review skills.

Ошибка 4. Галлюцинации API и supply chain

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

Особенно неприятен supply‑chain риск. Если модели регулярно галлюцинируют имя несуществующего пакета, злоумышленник может занять это имя в registry и ждать, пока кто‑то подключит зависимость.

Практический вывод: любые новые зависимости должны проходить SCA, allowlist/denylist и human review. Агент не должен самовольно тянуть пакеты.

Ошибка 5. Reward hacking и test hacking

Если критерий звучит как «сделай тесты зелёными», агент может оптимизироваться не под задачу, а под метрику.

Как это выглядит:

• ослабил assertion;

• удалил сложный сценарий;

• заменил реальный объект mock'ом;

• захардкодил ожидаемое значение;

• решил, что упавшие интеграционные тесты «не относятся к задаче»;

• сослался на прогон тестов, который был до последних изменений.

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

Практический вывод: тесты должны фиксироваться до реализации и меняться через отдельный процесс ревью. Нужны mutation testing, coverage diff и анализ CI‑артефактов.

Почему ручного ревью недостаточно

Ручное ревью нужно, но оно плохо масштабируется как единственная защита.

Вывод: человек должен получать не «посмотри 3000 строк», а короткий отчёт после автоматических слоев проверки.

От промпта к пайплайну

На вебинаре предложили заменить надежду на хороший промпт инженерным пайплайном:

1. Спецификация.

2. Линтеры и базовые ограничения.

3. Тесты, property‑based testing, fuzzing.

4. Security checks.

5. Архитектурные ограничения.

6. AI‑review.

7. Triage.

8. Человеческое решение.

SDD: спецификация как конституция задачи

Spec‑Driven Development в контексте LLM — это документ, который фиксирует:

• что является правильным результатом;

• где границы задачи;

• что агенту запрещено трогать;

• как результат будет проверяться.

Плохая задача:

Сделай вывод баланса.

Нормальная задача:

Пользователь должен видеть актуальный баланс по подтверждённым операциям. Доступ только для владельца аккаунта или оператора поддержки. Endpoint GET /balance/{userId} возвращает 200, 403 или 404. Валюта RUB. Используется banker's rounding. Pending‑операции не учитываются. p95 < 50 ms. PII не попадает в логи.

Что должно быть в хорошей спецификации

EARS: как писать требования без двусмысленности

На слайдах был полезный формат EARS. Он хорош тем, что превращает мутный текст в шаблоны, понятные и человеку, и агенту.

Практический вывод: формулировки «желательно», «нормально обработать», «как обычно» лучше не использовать. Агент слишком легко заполнит пустоты сам.

Три уровня SDD

Для большинства команд разумный старт — spec‑first на сложных задачах и spec‑anchored для критичных частей: платежи, права доступа, интеграции, ядро продукта.

Типичный SDD‑цикл для агента

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

SDD в мультиагентной разработке

В чате вебинара справедливо заметили: не стоит давать одному агенту писать спеку, кодить и тестировать. Для контекста и качества лучше разделять роли.

Спецификация в такой схеме становится общей точкой истины. Без неё каждый агент будет понимать задачу по‑своему.

Инструменты и форматы для SDD

Из презентации:

TDD для LLM: тест как исполняемый промпт

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

Цикл:

Фаза Red: какие тесты нужны до реализации

Тесты не обязаны быть идеальными. Но они должны быть независимыми от реализации агента.

Главный риск TDD с агентом: test hacking

Агент может добиться формального прохождения метрики без решения задачи. Поэтому нужны защитные механизмы:

Где агентный TDD окупается

За пределами SDD и TDD

SDD и TDD не закрывают всё.

Агент всё ещё может:

• написать код, который проходит тесты, но содержит уязвимость;

• придумать несуществующую библиотеку;

• нарушить глобальную архитектуру ради локального решения;

• сделать тесты такими, чтобы их было легко пройти;

• добавить лишнюю стоимость: больше токенов, больше проверок, больше шума.

Поэтому нужен следующий слой.

Настройка среды: rules, ignore, skills, hooks

Практический вывод: правила должны версионироваться и ревьюиться как код. Если правило живёт только в голове тимлида, агент его не знает.

Линтеры и архитектурные ограничения

Линтеры — первая линия обороны. Они дешёвые, быстрые и отсекают грязный AI‑код до ревью.

Важно: архитектурные тесты особенно полезны с AI. Агент любит локально удобные решения. ArchUnit и похожие инструменты напоминают ему, что проект больше одного файла.

Security‑слой: SAST, SCA, DAST и не только

Практический вывод: если агент добавил зависимость или обработку пользовательского ввода, security‑check должен быть не опциональным, а обязательным.

Fuzzing и property‑based testing

AI неплохо пишет очевидные unit‑тесты. Плохо — странные входы и инварианты.

Fuzzing подаёт на вход много случайных данных и ищет падения. Инструменты из презентации: AFL++, libFuzzer, Atheris, Hypothesis, Cats, EvoMaster.

Property‑based testing проверяет свойства, а не отдельные примеры. Инструменты: Hypothesis для Python, jqwik для Java, fast‑check для JavaScript/TypeScript.

Пример из презентации:

from hypothesis import given
import hypothesis.strategies as st

@given(st.lists(st.integers()))
def test_sort_preserves_length(lst):
    assert len(sorted(lst)) == len(lst)

Для AI‑кода это очень удачная связка: модель может пройти пример [3, 1, 2], но сломаться на пустом списке, дубликатах, больших числах или нестандартной локали.

Пирамида тестов всё ещё нужна

Если строгий TDD‑контур не внедрён, базовая иерархия тестов становится минимальной защитой.

Перевёрнутая пирамида, где всё проверяется медленными E2E, плохо подходит агентам: feedback loop становится слишком длинным.

Предел автоматизации: зачем всё ещё нужен ревьюер

Автоматика проверяет факты:

• типы совпали;

• тесты зелёные;

• секреты не утекли;

• зависимость не в denylist;

• latency в бенчмарке не выросла.

Но автоматика не всегда понимает намерение:

• действительно ли код решает бизнес‑задачу;

• не появился ли архитектурный костыль;

• не нарушена ли доменная модель;

• не стало ли решение слишком дорогим в сопровождении.

Здесь начинается AI‑review, а потом человеческое ревью.

AI‑review: не «проверь всё», а пайплайн

AI‑review pipeline — это организованный процесс проверки изменений одним или несколькими агентами. У каждого агента ограниченный контекст, роль и проверяемый формат результата.

Что проверяет AI‑review:

• соответствует ли diff issue, spec или acceptance criteria;

• не нарушены ли бизнес‑правила;

• нет ли скрытых побочных эффектов;

• достаточно ли тестов, логов и отчётов;

• нет ли архитектурных или security‑проблем;

• не подогнаны ли тесты под реализацию.

Локальное ревью: чем меньше scope, тем выше точность

AI‑review лучше запускать рано: прямо в IDE, агентском цикле или перед локальным коммитом.

Практическая схема:

1. Агент сгенерировал небольшой участок кода.

2. Ревьюер запускается в новом чате без истории генерации.

3. Ему передают только релевантный контекст: diff, соседний код, контракт, тесты, spec.

4. Он возвращает проблемы в строгом формате.

5. Исполнитель исправляет.

6. Проверка повторяется.

Новый чат важен: ревьюер не должен быть эмоционально и контекстно «на стороне» исполнителя.

Большой review pipeline для PR

Узкие ревью‑сабагенты

Один универсальный агент с задачей «найди всё плохое» обычно даёт поверхностный результат. Узкая роль работает лучше.

Контекст для ревьюера

Полезный набор:

• diff и изменённые файлы;

• issue, spec, acceptance criteria, ADR;

• связанные тесты;

• отчёты CI;

• вызывающие и вызываемые методы;

• публичные контракты;

• правила архитектуры;

• security‑требования;

• AGENTS.md,.agentignore, проектные skills.

Важно не перегнуть. Слишком мало контекста — агент не увидит проблему. Слишком много — потеряет фокус.

Triage: один потенциальный баг — одно решение

После сабагентов нельзя просто склеить все замечания в длинный комментарий. Нужен triage.

Правила triage из презентации:

Формат хорошей находки:

id: SEC-003

file: src/main/java/.../BalanceController.java

line: 42

severity: high

claim: endpoint allows reading another user's balance

proof: authorization check compares requested userId with path owner only in UI, backend check absent

evidence: related test BalanceAccessTest does not cover SUPPORT/user mismatch

recommendation: add backend authorization check and negative integration test

Как собрать свой review pipeline из истории проекта

Это один из самых практичных выводов вебинара.

Не надо начинать с абстрактного промпта «ты senior reviewer». Лучше взять историю своего проекта:

1. Выгрузить issues, PR‑комментарии, review discussions, причины отклонённых изменений.

2. Собрать документ: типовые баги, архитектурные правила, частые замечания, опасные зоны.

3. Выделить зависимости: какие модули чаще ломаются вместе.

4. Разделить знания на skills: security‑skill, architecture‑skill, testing‑skill, domain‑skill.

5. Написать skill оркестратора: когда запускать каких ревьюеров, какой контекст давать, как делать triage.

6. Запускать этот pipeline на каждом значимом PR.

Так ревью‑пайплайн отражает реальные ошибки команды, а не среднюю температуру по GitHub.

Гибридизация: LLM + формальные инструменты

Финальная часть вебинара была про связку LLM и классического анализа программ.

Простая схема:

1. Инструмент фиксирует проблему: файл, строка, трассировка, метрика, упавший тест.

2. LLM связывает сигнал с контекстом проекта и формулирует гипотезу.

3. Агент предлагает минимальное исправление.

4. Инструмент запускается снова и подтверждает или опровергает результат.

Это важная мысль: LLM не должна быть единственным источником истины. Она хорошо интерпретирует, группирует, объясняет, пишет harness, предлагает патч. Но финальное подтверждение должен дать инструмент.

Где LLM помогает формальным инструментам

Сценарий: SAST‑отчёт на 200 предупреждений

Без LLM команда часто тонет в отчёте: критичные дефекты, дубликаты, low‑priority, false positives — всё в одной куче.

С LLM можно сделать так:

1. Сгруппировать одинаковые предупреждения.

2. Восстановить data‑flow от пользовательского ввода до опасной операции.

3. Отметить находки, требующие ручной проверки.

4. Предложить минимальное исправление.

5. Сгенерировать проверочный тест.

6. Подготовить резюме: исправить / отклонить / исследовать вручную.

Но последнее слово остаётся за инструментом и человеком.

Сценарий: performance regression

Рабочий контур из презентации:

1. Агент получает данные профилировщика: async‑profiler, JFR, flame graphs, OpenTelemetry, Prometheus.

2. Находит критические участки: медленные endpoints, тяжёлые SQL, лишние аллокации, locks.

3. Связывает аномалию с коммитом, функцией или конфигурацией.

4. Готовит план оптимизации.

5. Добавляет benchmark.

6. После исправления повторно измеряет latency, CPU, memory или throughput.

Практический вывод: «кажется, стало быстрее» не считается. Нужна повторная метрика.

Финальный пайплайн безопасной AI‑разработки

Если собрать вебинар в один чек‑лист:

1. Формализовать задачу: spec, plan, acceptance criteria, риски.

2. Настроить инструмент: AGENTS.md, rules, ignore, skills, hooks.

3. Ограничить scope: агент не должен читать и менять всё подряд.

4. Разделить роли: writer, implementer, reviewer, triage, CI.

5. Сначала зафиксировать проверки: unit, integration, property, security, regression.

6. Дать агенту маленький шаг реализации.

7. Прогнать дешёвые проверки: типы, линтеры, архитектурные правила.

8. Прогнать тесты и security‑checks.

9. Запустить локальный AI‑review в новом контексте.

10. Для большого PR — scope resolver, routing, узкие reviewers, triage.

11. Подтвердить выводы артефактами.

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

13. Сохранить spec, plan, diff, логи и отчёты рядом с задачей.

Практический минимум для команды, которая только начинает

Если весь pipeline пока кажется тяжёлым, можно начать с малого.

Минимум на эту неделю

• Завести AGENTS.md с правилами проекта.

• Добавить.agentignore для секретов, prod‑конфигов и зон, куда агенту нельзя.

• Запретить агенту добавлять зависимости без явного approval.

• Для задач сложнее одного файла требовать plan.md.

• Просить агента писать список изменённых файлов и команд проверки.

• Не принимать «тесты прошли» без лога.

Минимум на месяц

• Выделить 2–3 критичных модуля и описать для них spec‑anchored документы.

• Добавить архитектурные тесты: слои, зависимости, запреты.

• Включить SCA и secret scanning в обязательный CI.

• Настроить review skill на основе частых замечаний команды.

• Запускать AI‑review в отдельном контексте перед PR.

Минимум для enterprise‑контура

• SDD для критичных задач.

• Независимые роли агентов.

• Property‑based testing для доменных инвариантов.

• Fuzzing для парсеров, API, input‑heavy кода.

• SAST/SCA/DAST по policy.

• Triage agent с форматом находок.

• Метрики: false positive rate, время ревью, escaped defects, security findings, cost per PR.

Где здесь Veai

Вся схема упирается в качество фактов о проекте. Агенту мало grep, RAG и длинного терминального лога. Для нормальной проверки нужны точные IDE‑факты:

• какие символы реально существуют;

• где используется метод;

• какие публичные контракты затронуты;

• какие тестовые конфигурации доступны;

• какие инспекции падают;

• какие зависимости подключены;

• что реально произошло при запуске;

• какие изменения относятся к scope задачи.

Veai работает внутри IDE как источник таких фактов. Поэтому агент может не только «рассуждать про код», но и опираться на структуру проекта, зависимости, запуски, ошибки, инспекции и артефакты валидации.

Это не рекламный тезис «IDE лучше чата». Это инженерный тезис: чем автономнее агент, тем важнее источник проверяемых фактов.

Ответы на вопросы из чата

Чем spec‑first отличается от spec‑anchored?

Spec‑first — одноразовая спецификация под задачу. Написали, реализовали, после merge её могут забыть.

Spec‑anchored — спецификация живёт рядом с кодом. Изменение поведения требует изменения SPEC.md в том же PR.

В spec‑anchored нужна одна спека на всю систему?

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

Структура: цель, scope, non‑goals, бизнес‑правила, инварианты, внешние контракты, NFR, acceptance criteria, проверки.

Как изолировать контекст в рое агентов?

Через оркестратора. Он решает, какой агент получает какой контекст. Исполнителю не нужно видеть всё обсуждение аналитика. Security reviewer не обязан читать весь UI diff. Triage agent должен видеть конкретную находку, proof и связанные артефакты.

Меньше истории, больше релевантных фактов.

Можно ли прогонять ревью двумя моделями и давать арбитру?

Да. Особенно для критичных изменений. Разные модели могут по‑разному видеть технические и бизнес‑риски. Но арбитр должен просить доказательства, а не выбирать «кто убедительнее написал».

Как улучшить опыт code review для человека?

Дать человеку не сырой поток замечаний, а triage report: blocker/high/medium, файл, строка, доказательство, ожидаемое влияние, рекомендация. Человек должен решать сложное, а не вычищать шум.

Можно ли разбивать большой PR на маленькие коммиты и ревьюить отдельно?

Можно, но коммит не всегда хороший срез. Часто лучше дробить по связанным компонентам: модуль, контракт, API, бизнес‑сценарий. Тогда ревьюер видит смысловую единицу, а не историю переписывания.

Какая роль разработчика, если код ревьюят модели?

Разработчик остаётся владельцем решения. Просто его роль смещается: меньше ручного просмотра очевидных вещей, больше постановки рамок, проверки артефактов, архитектурных решений, security и non‑functional requirements.

Хард‑скиллы становятся важнее, а не менее важными.

Узкое место теперь в написании кода или ревью?

Зависит от проекта, но написание кода ускоряется быстрее, чем ревью. Поэтому ревью, проверки и сопровождение становятся bottleneck. Это совпадает с цифрой про рост времени PR‑ревью.

Помогает ли всё это быстрее писать или только усложняет?

Если применять ко всему подряд, усложняет. Если применять там, где ошибка дорогая, помогает.

Простая задача — короткий цикл. Деньги, безопасность, права доступа, миграции, большие PR — полноценный pipeline.

Какую локальную модель выбрать для кодинга на 128 GB?

В ответе на вебинаре позиция была осторожная: для серьёзного агентского кодинга локальные модели пока часто уступают большим hosted‑моделям. На отдельных задачах они полезны, но строить весь сложный pipeline только вокруг локальной модели рискованно.

Итог

LLM действительно ускоряет разработку. Но скорость без процесса превращается в скорость накопления неизвестного долга.

Рабочая формула вебинара такая:

Чем автономнее агент, тем жёстче должны быть границы и независимее проверка.

И ещё короче:

Нет артефакта — нет доказательства.

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

Челлендж для читателей: проверьте свой AI‑generated PR

Если вы уже используете Copilot, Cursor, Claude Code, Codex, Veai или любой другой агентский инструмент, попробуйте маленький эксперимент на одном реальном PR.

Возьмите изменение, где AI написал заметную часть кода, и прогоните его по чек‑листу:

Формат результата можно сделать таким:

Проект: backend / frontend / mobile / data / другое

Размер PR: N файлов, N строк

AI‑инструмент:...

Что нашлось:

• security:...

• tests:...

• architecture:...

• false positives:...

Что бы добавили в AGENTS.md / rules / review skill:...

Будет особенно интересно сравнить не модели, а процессы. Один и тот же агент может дать мусор на голом prompt и нормальный результат, если у него есть spec, тесты, ограничения и отдельный ревьюер.

Если попробуете — принесите результаты в комментарии: какие классы проблем нашлись, что оказалось шумом, а что реально стоило поймать до merge.