Всем привет! Меня зовут Андрей Бровко, я руководитель тестирования Авито Авто. 

ИИ-агенты генерируют код за секунды, но скорость генерации кода не означает качество продукта. Если процессы разработки выстроены слабо, агенты просто быстрее доставляют дефекты.

В этой статье разберём, чем агентская разработка отличается от вайб-кодинга и как это влияет на качество разработки ПО. Спойлер: всё начинается ещё до появления первой строки кода. Обсудим хорошие практики, разберём, на каких активностях тестирования стоит фокусироваться в агентской разработке и по каким метрикам можно понять, что всё идёт как надо. 

Содержание

• Как меняется модель разработки

• Как мы внедряли агентов в Авито

• Хорошие практики при создании навыков и MCP-серверов

• Как работает Spec-Driven Development

• Тестирование в агентской разработке

• Как измерить качество продукта и работы агентов

• Что может пойти не так

• Заключение

  

Как меняется модель разработки

Сначала небольшой исторический экскурс в то, как развивалась технология больших языковых моделей. Будем опираться на бенчмарк SWE-bench (Software Engineering Benchmark) — набор реальных задач из GitHub. Их давали решать агентам, а затем измеряли, насколько решения соответствуют критериям, которые им поставили. 

Если в 2023 году модели успешно решали только 2% задач бенчмарка, то с 2025 года выполняли более 70% задач, а в 2026 году — уже более 80%. Это огромный прогресс! Модели доросли до такого уровня, когда им можно доверять реальные задачи — писать код и выполнять агентскую работу. 

Но что вообще такое агент? 

Агент — это просто программа, которая делает всё то же самое, что и обычный инженер. Может создавать файлы, редактировать их, запускать команды и так далее. Лично я пользуюсь двумя инструментами — Claude Code и Codex (ChatGPT). У этого есть две причины. Во-первых, это вендоры, которые выпускают модели, занимающие топы бенчмарков. Во-вторых, узким горлышком становится стоимость токенов, а они дают хорошую цену по подпискам. А за счёт конкуренции условия постоянно улучшаются. Поэтому по соотношению цены и качества это лучшее, что сейчас есть. 

Напишите в комментариях, какой у вас любимый агент. 

Как мы внедряли агентов в Авито 

Автокомплитом кода и взаимодействием с LLM в чате мы пользовались уже очень давно. Но в 2025 году, после достижения моделями высокого уровня SWE-bench, мы в Авито запустили пилотные проекты по использованию агентов. Например, в одном из них мы взяли 100 инженеров и предоставили им доступ к топовым моделям. В итоге на объективных метриках эффективности разработки ПО (подробнее об этом расскажу ниже) мы не увидели каких-то статистически значимых изменений. При этом метрики качества, которые мы использовали как контрметрики, также остались примерно на том же уровне. Субъективно инженеры оставляли отзывы об ускорении своей работы и высокой удовлетворённости использования агентов. 

Может показаться, что это отсутствие результата, но когда внедряется новая технология, метрики обычно проседают. Это известная модель J-кривая обучения при внедрении нового. Инженеру нужно время, чтобы научиться работать, приспособиться, «набить руку», а у нас ничего не изменилось. Это был позитивный сигнал. 

Ниже J-кривая DORA. Модель предполагает четыре этапа до начала роста: 

1. Обучение (The learning curve). Начинаем использование ИИ-инструментов в ежедневной работе.

2. Валидация (The verification tax). Учимся справляться с возросшей нагрузкой по проверке сгенерированного кода и соблюдением стандартов качества.

3. Адаптация процессов (Pipeline adaptation). Адаптируем остальные этапы SDLC — тестирование, поставка и т.п.

4. Показательный рост (Exponential growth). Прошли этап замедления и получаем полезный эффект.

А на каком этапе вы? Напишите в комментариях!

Мы решили, что в 2026 году пора масштабироваться, и здесь не обойтись без централизации управления и платформизации. Если до этого каждый инженер или каждая команда собирали свой «агентский набор» (навыки, обвязки, промпты), то теперь мы собираем централизованную базу навыков, берём под контроль MCP-сервера (MCP — Model Context Protocol), чтобы использовать накопленный опыт в разных командах и масштабировать его внутри компании, а также обеспечивать безопасность и аудит. Так у нас появились сервисы:

• skills-hub — отвечает за магазин навыков, проверку качества и безопасности, поиск и ранжирование. Помогает не скатываться в skills-hell, ведь навыки появляются как грибы после дождя. Каждый стремится через навык агента «ИИ-зировать» свою работу, и это прекрасно;

• mcp-hub — предоставляет собой MCP-сервер для предоставления доступа к внутренним MCP-серверам, дающим интеграцию с инфраструктурой (кодовая база, документация, баг-трекинг и т.д.);

• AVIDA (Avito Developer Assistant) — безопасный автономный запуск агентов на удалённом сервере с возможностью запуска по расписанию или запросу.

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

→ Умная качественная модель с большим контекстным окном. С малыми или локальными моделями это не работает (на старте пробовали Qwen с 32 млрд параметров и 32 тысячи токенов контекстного окна). Такие модели плохо слушаются инструкций, не могут собрать полный контекст и генерируют непредсказуемый результат.

→ MCP-серверы. MCP — это протокол, который позволяет моделям взаимодействовать с внешним миром. Например, получить данные из Jira или Confluence, собрать требования, зайти в Bitbucket, клонировать код, создать pull request. Модели можно дать доступ ко всему, с чем работает инженер. 

→ Навыки. Модель знает всё на свете, но не знает, как работает Авито изнутри. Её этому не обучали. Поэтому нам нужно составить набор инструкций, чтобы научить модель тому, как мы ведём разработку именно в Авито. 

Хорошие практики при создании навыков и MCP-серверов

Навыки дают инструкции агентам, и от качества этих инструкций будет зависеть результат работы агентов. Ниже — список хороших практик ↓

• Автоматическое статическое тестирование. В репозитории валидируются формат файла SKILL.md, обязательные поля и метаданные. 

• Автоматическое динамическое тестирование. Реализуется через evals, которые запускаются навыком skill-create. Обязательные группы тест-кейсов: happy path и edge cases. Evals запускаются в CI при изменении навыка.

• Ревью навыка на этапе пул-реквеста. Ревью проводит владелец домена или эксперт в области навыка. Это позволяет учитывать нюансы доменной специфики, сокращать ошибки и соблюдать принятые стандарты. Плохой навык получается, когда его просто генерируют LLM без доменного контекста.

• Живое тестирование. Позволяет проверить навык на жизнеспособность не только на стороне автора. Первая версия почти всегда требует доработки, поэтому запускайте навык на реальных задачах.

• Лучшие практики централизованы в навыке skill-creator. Все правила, антипаттерны и примеры живут в едином skill-creator. Все навыки создаются и обновляются навыком skill-creator. Сам skill-creator проходит тот же процесс ревью и тестирования, что и остальные навыки.

• Самоулучшение. В навыке должна быть инструкция по анализу сложностей и проблем, которые возникают во время выполнения задачи. Агент может предложить, что следует улучшить в навыке, и создать PR.

• Навыки версионируются. Skills-hub хранит версии и всегда использует последнюю версию навыка из master-ветки.

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

• Вам не нужен навык. Если требуется строго предсказуемый результат каждый раз, реализуйте алгоритм в коде или в no-code решениях, например в n8n. Если агент и без навыка хорошо справляется с задачей, возможно, skill не добавляет ценности.

• Использование skills-hub. Рекомендуется использовать skills-hub, поскольку система имеет механизмы оценки качества навыков, распространения и разграничения доступа.

• Универсальность навыка по отношению к агенту. Навык должен быть универсальным по отношению к агентам, либо явно проверять и требовать в качестве предусловия наличие агента, под который он заточен.

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

Появившись в 2024 году в стенах компании Anthropic, технология MCP быстро стала популярной, поскольку позволила моделям не только генерировать ответы, но и взаимодействовать с внешним миром. Существует большое количество готовых MCP-серверов, можно брать и пользоваться, но в Авито есть множество собственных разработок, поэтому стоит вопрос разработки своих MCP. 

Ниже — хорошие практики для MCP-сервера:

• Стремитесь к паттерну Tolerant Reader — старайтесь принимать даже не совсем валидные входные данные от агента. Например, быть готовыми к тому, что дата может быть сформирована агентом в разных форматах. Мы можем это обработать на стороне сервера. 

• Оптимизируйте контекст: отдавайте данные в наиболее компактной доступной форме. Это позволит экономить токены и не перегружать контекстное окно агента.

• Не делайте слишком много инструментов. У инструмента могут быть параметры, используйте их вместо того, чтобы создавать новый инструмент. Это также позволит экономить контекст.

• При этом не смешивайте совсем разные по смыслу инструменты.

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

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

• Старайтесь, чтобы модели требовалось делать как можно меньше вызовов для достижения результата. Поскольку модель — это вероятностная сущность, а не алгоритм в коде, то по пути может что-то «потеряться» на промежуточных шагах.

Данные практики позволяют сделать взаимодействие моделей с MCP более устойчивым.

Как работает Spec-Driven Development

С навыками и MCP разобрались, давайте перейдём теперь к тому, как построить процесс целиком. Все уже понимают, что модель может ошибаться, делать не то, что от неё просят, генерировать непредсказуемый результат. Если начинать реализацию в коде сразу, с первого запроса, то результат, скорее всего, будет рандомным, при этом требуется время, чтобы дождаться этого результата, и, вероятно, нужно будет всё переделывать. Поэтому лучше начать с плана или спецификации, и тогда это будет более предсказуемо и эффективно. Так появился подход Spec-Driven Development. 

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

→ Первая рамка — это спецификация. Мы описываем (генерируем и проверяем) чёткую структурированную спецификацию: пользовательские истории, критерии приёмки и всё, что помогает модели понять, что от неё ожидают. Такая спецификация должна быть достаточно подробной. Это поможет уменьшить количество уточнений со стороны человека и последующих переделок. Как правило, описывается в md-формате, который хорошо воспринимается LLM-моделями.

→ Вторая рамка — это тесты. Причём хорошая практика — Test-Driven Development. Разработчиков, с которыми я работал и работаю, было непросто пристрастить к TDD подходу, при котором тесты появляются раньше кода. С появлением LLM это заработало. Модель генерирует тесты до написания кода, и эти тесты становятся дополнительной спецификацией. Чтобы тестам можно было доверять, они проходят ревью человека. Детерминированные проверки тестами, реализованные в коде, добавляют стабильности в недетерминированном контуре.

Весь процесс выглядит следующим образом:

Я упростил схему, но явно визуализировал, что всё «крутится» вокруг спецификации. Начиная от описания задачи в свободной форме в Jira или даже голосом и заканчивая генерацией спецификации в нужном формате, проектированием и ревью. Повторим, что ключевое назначение спецификации — это зафиксировать контекст, в рамках которого генерируется код. Кроме того, агент может вернуться к спецификации в последующих итерациях, чтобы понять причину принятых решений и ожидания от системы. Если они меняются, спецификацию следует обновить.

Ревью здесь обязательно. Важно, чтобы человек проверил ожидаемый результат до того, как мы пройдём цикл. Это касается ревью спецификации, ревью дизайна и ревью тестов. Такой приём называется Human-in-the-loop. 

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

Теперь о том, как реализовать этот подход с помощью готовых инструментов и не заставлять модель проходить весь цикл вручную шаг за шагом. Есть множество популярных фреймворков, приведу в пример три: SpecKit, Superpowers и OpenSpec, они с открытым исходным кодом. По сути, это наборы скиллов и мета-скиллов для управления всем процессом. Они близки по духу, но каждый со своими фишками. Например, мне нравится в Superpowers наличие явного шага с TDD.

Что и как тестировать: стратегия для AI-генерируемого кода

Обеспечение качества — это широкая и комплексная задача, которая может зависеть от множества факторов и условий. Мы сильно сузим контекст и посмотрим, на чём стоит сосредоточиться в условиях агентской разработки с точки зрения тестирования. Есть один из базовых принципов тестирования: чем раньше мы находим проблему, тем дешевле её исправить (подход shift-left). Этот принцип никуда не делся и в агентской разработке. 

• Проверка спецификации — выше мы уже обсудили SDD, спецификация как первый и самый важный шаг подлежит проверке.

• Оценка рисков — и здесь у моделей пока не всё хорошо. По крайней мере, у меня не получилось полностью на них положиться, потому что модель не всегда может адекватно оценить продуктовые риски, а тем более проектные (организационные моменты, нехватка ресурсов, люди, отпуска и всякое такое).

• Ревью тестов — как я писал выше, тесты становятся частью спецификации, поэтому их важно проверять. 

• Ревью кода — кода становится настолько много, что я не уверен, что в будущем построчное чтение кода не станет боттлнеком. Возможно, мы выйдем на новый уровень абстракции и будем валидировать уже функциональный результат, а ревью кода доверим LLM. Этот пункт для меня пока остаётся открытым. Но на данный момент у нас это обязательный этап.

• Приёмочное тестирование — нам нужно убедиться, что результат соответствует ожиданиям, описанным в критериях приёмки спецификации. Может быть выполнен как с помощью автотестов на различных уровнях «пирамиды тестирования», так и вручную.

• Исследовательское тестирование — когда придумываем и выполняем проверки на лету, без заранее подготовленных сценариев или чек-листов, сразу фиксируя «находки» в ограниченный временной слот. Пока я не встречал LLM-решений, которые могли бы это делать на уровне людей.

• Тестирование UX (user experience) — LLM может сказать, что интерфейс отличный, но в реальности всё может быть печально. Продукты, которые делаются для людей, должны оценивать люди.

Важно понимать, что объём и глубина проверок зависят от контекста проекта и имеющихся рисков. Также нужно понимать, что находится в приоритете именно для вашего проекта: качество, скорость, бюджет или объём. Как говорит Роберт Мартин, выбирайте любые три, четвёртого не дано. Поэтому ориентируйтесь на свой домен и на свои риски. Возможно, вам не нужно слишком зажимать процесс — важнее показать скорость, а может, наоборот, нужен стабильный предсказуемый результат.

Как измерить качество продукта и работы агентов

В агентской разработке у нас появились новые артефакты — теперь важно тестировать не только продукт, но и артефакты самих агентов: системные промпты, MD-файлы, навыки, MCP и другую обвязку агентской инфраструктуры.

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

Инструменты оценки

1️⃣ Есть инструменты для того, чтобы оценить навыки. Поскольку речь о недетерминированной системе, здесь нет привычных ассертов в коде. Модель проверяет модель. Стандартные скиллы от вендоров (скиллы для создания скиллов) уже предоставляют такую возможность. Ссылка на Anthropic, ссылка на OpenAI. 

Пример такого «теста» в виде JSON, в котором указан промпт и ожидаемое поведение агента. Модель-судья оценивает и присваивает оценку после завершения по количеству успешно выполненных проверок.

{
  "id": 2,
  "name": "table-driven-and-real-mocks",
  "prompt": "Добавь unit-тесты для метода Process в service_test.go: нужны успешный сценарий, проверка граничных значений и невалидных данных.",
  "expected_output": "Генерирует table-driven тесты с t.Run для позитивного и негативных кейсов, проверяет успешность прохождения тестов.",
  "assertions": [
    {
      "name": "table-driven-format",
      "text": "Тесты оформлены в формате []struct{...} + t.Run(...)"
    },
    {
      "name": "rewrites-non-table-tests",
      "text": "Если в редактируемом файле есть нетабличные тесты, переписывает их в table-driven формат"
    },
    {
      "name": "critical-paths-covered",
      "text": "Покрыты минимум: успешный путь, ошибка зависимости и ошибка валидации"
    },
    {
      "name": "uses-existing-mocks",
      "text": "Используются существующие моки пакета без добавления искусственных обходных решений"
    }
  ]
}

2️⃣ Но навыки не используются изолированно, мы решаем задачу, используя набор навыков, определённые модели, обвязки. Для замера полного контура в Авито реализовали свой инструмент, который проверяет как агент, используя набор навыков, выполняет задачи, специфичные для Авито. 

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

Ниже — тест в формате YAML и как примерно выглядит результат бенчмарка. Изменяя внешние условия, мы можем отслеживать, насколько успешно решается задача.

setup:
  files:
    main.go: |
      package main

      func Hello(name string) string {
        return "Hello, " + name
      }

instructions: |
  Add a test for the Hello function.

  Requirements:
  - Test should verify output format
  - Test should handle empty string
  - Use Go testing package

checks:
  - type: command
    name: "tests pass"
    weight: 2.0
    command:
      command: "go test ./..."
      timeout: 60

И результат бенчмарка:

Метрики

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

Метрики эффективности разработки ПО. Ещё важно смотреть на метрики DORA — это довольно известная программа, которая проводит исследования в области DevOps для выработки методологий, которые способствуют улучшению производительности в области поставки и эксплуатации ПО. DORA предлагает набор метрик, которые помогают понять, насколько эффективно и стабильно построен весь процесс разработки.

Возврат инвестиций. Или ROI (Return on Investment). Бизнес есть бизнес, и финансы играют важнейшую роль. Давайте попробуем посчитать. Если взять среднюю зарплату разработчика в 2500 долларов и подписку стоимостью 100 долларов в месяц на Claude Code, то разработчику достаточно ускориться примерно на 4%, или на 6,4 часа в месяц, чтобы такие затраты как минимум окупались. Более продвинутые расчёт — в отчёте DORA: ROI of AI-assisted Software Development report.

Что может пойти не так

И наконец, риски, анти-паттерны и практические советы для команд. 

Контроль над агентами. Нам важно, чтобы агенты оставались под контролем — это так называемые аудит, корпоративное управление и управления доступом. Если агент начинает жить своей жизнью и делать то, что ему захочется, это может привести к плачевным результатам. Отдельно нужно следить, чтобы агент не действовал бесконтрольно за пределами видимости команды. Мы должны понимать, что делает агент, видеть логи и контролировать его работу. 

Ещё важно следить за персональными данными и за теми данными, с которыми работает агент. Если в каком-то сервисе есть чувствительные данные, мы используем внутренние модели. У нас за это отвечает наша агентская обвязка: skills-hub, mcp-hub, сервис анонимизации данных. Для автономного запуска и работы агентов есть система AVIDA, о которой подробнее расскажут мои коллеги в следующий раз.

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

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

Контроль затрат. Бывали случаи, когда за пару часов разработчик неожиданно тратил значительную сумму на токены. Смотришь, а уже 100 долларов улетело. Поэтому стоимость использования агентов тоже нужно отслеживать.

Вот что помогает на практике:

→ Human-in-the-loop — это ревью требований, ревью тестов и ревью результатов работы модели.

→ Agent-in-the-loop — это подход, при котором агент проверяет работу другого агента с другим промптом. Такой подход можно использовать для ревью кода, запуска и проверки тестов, а ещё для генерации новых тестов.

→ Отдельно стоит отметить TDD — Test-Driven Development. Тесты пишутся до реализации, и этот подход хорошо работает в агентской разработке.

→ Ещё важны безопасность, наличие CI/CD и quality gates с различными видами тестирования. Набор проверок зависит от вашего продукта и того, насколько строгие требования к качеству предъявляются в вашем случае.

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

Заключение

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

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