Skip to content
Agentic Engineering

Обеспечение качества с агентами

AI-сгенерированный код меняет динамику проверки кода и тестирования. Вашим политикам нужно адаптироваться.

Варианты политики проверки кода

Section titled “Варианты политики проверки кода”

Должен ли AI-сгенерированный код проверяться иначе? Большинство команд приходят к компромиссу.

ПолитикаКак работаетПодходит для
Без дифференциацииОдинаковый ревью для всего кодаНебольшие, high-trust команды с строгими ревью
Только раскрытиеАвторы отмечают значимый AI-кодПрозрачность без бюрократии
Уровневый ревьюДополнительная проверка на critical paths + AICodebases с varying риском
AI-assisted ревьюAI делает предварительный ревью; люди фокусируются на том, что пропустил AIКоманды с высоким PR volume

Если вы требуете раскрытие

Section titled “Если вы требуете раскрытие”

Сделайте это легко:

  • Чёткий триггер: “Раскрывайте, когда >20% PR было сгенерировано AI-инструментами”
  • Простой механизм: Чекбокс в шаблоне PR или тег/лейбл
  • Без стигмы: Раскрытие — это информация, не оценка
  • Полезные метаданные: Какой инструмент? Какие промпты? Помогает учиться

Чеклист ревью для AI-кода

Section titled “Чеклист ревью для AI-кода”

Обучите ревьюеров обращать внимание на специфичные для AI проблемы:

  • Галлюцинированные API или методы
  • Правдоподобная, но неправильная логика
  • Отсутствующая обработка edge cases
  • Непоследовательность с существующими паттернами
  • Over-engineered для задачи

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

Развитие навыков ревьюера

Section titled “Развитие навыков ревьюера”

Некоторые ревьюеры ловят AI-ошибки лучше других. Это можно развить.

  • Делитесь примерами AI-неудач, пойманных на ревью
  • Объединяйте младших ревьюеров с опытными
  • Создайте командную базу знаний об AI-подводных камнях

Чего не делать

Section titled “Чего не делать”
  • Не создавайте отдельную “AI-код” ветку — интеграционные кошмары
  • Не требуйте менеджерского approve для использования AI — убивает adoption
  • Не игнорируйте разговор — притворяться, что ИИ ничего не меняет, не помогает никому

Сдвиг тестирования влево

Section titled “Сдвиг тестирования влево”

Традиционно: Писать код → Тестировать → Ревьюить → Деплоить

Агентно: Писать спецификацию → Генерировать тесты → Генерировать код → Верифицировать тесты → Ревьюить → Деплоить

Тесты идут перед реализацией.

Почему это работает

Section titled “Почему это работает”
  • Тесты определяют критерии успеха для агента
  • Агенты могут запускать тесты для самопроверки
  • Меньше итераций, когда цель ясна
  • Тесты документируют намерение

Как внедрить

Section titled “Как внедрить”

Пишите тесты как часть определения задачи. Перед тем как просить агента реализовать фичу, напишите (или сгенерируйте) тесты, которые он должен пройти.

Используйте TDD-промптинг. “Вот тесты. Напиши код, чтобы они прошли.”

Относитесь к провалам тестов как к обратной связи от агента. Тестовый набор ловит баги, не вы.

Использование агентов для генерации тестов

Section titled “Использование агентов для генерации тестов”

Агенты отлично пишут тесты. Используйте это.

Unit-тесты: Дайте агенту функцию, получите тестовые случаи. Проверьте на пробелы в покрытии.

Edge cases: Агенты хороши в воображении случаев, которые вы можете пропустить.

Интеграционные тесты: Сложнее, но агенты могут генерировать scaffolding.

Рабочий процесс

Section titled “Рабочий процесс”
  1. Укажите агенту на модуль
  2. Попросите тесты, покрывающие happy path, edges и errors
  3. Проверьте на пробелы и галлюцинированное поведение
  4. Уточняйте, пока покрытие значимо

На что обратить внимание

Section titled “На что обратить внимание”
  • Тесты, которые проходят по неправильным причинам
  • Замоканные зависимости, скрывающие реальные проблемы
  • Тесты, которые не тестируют реальное требование
  • Copy-paste тесты, не добавляющие покрытие

Тестовое покрытие как guardrail

Section titled “Тестовое покрытие как guardrail”

Высокое тестовое покрытие делает агентную разработку безопаснее.

  • Минимальные gates покрытия: Не позволяйте агенты-сгенерированному коду снижать покрытие
  • Требования для critical paths: Некоторые пути требуют 100% покрытия со значимыми тестами
  • Тренды покрытия: Отслеживайте, коррелирует ли adoption агентов с изменениями в покрытии

Тестирование output агентов

Section titled “Тестирование output агентов”

Не просто тестирование кода — тестирование поведения самого агента.

Критерии приёмки: Определите, что код должен делать, что не должен, edge cases и метод верификации.

Canary testing (для автоматизированных workflows):

  • Прогоняйте изменения агента через расширенные тестовые наборы перед merge
  • Выкатывайте за feature flags
  • Мониторьте на аномалии после деплоя

Отслеживание регрессий: Замечайте паттерны — определённые типы задач вносят больше багов? Есть проблемные codepaths?

Тестовая пирамида для агентов

Section titled “Тестовая пирамида для агентов”
  • Unit-тесты (основа): Быстрые, сфокусированные, запускаются постоянно. Генерируются агентами с проверкой человеком.
  • Интеграционные тесты (середина): Верифицируют, что компоненты работают вместе. Human-guided генерация.
  • E2E-тесты (вершина): Верифицируют полные пользовательские flows. Меньше, но критичны. Часто всё ещё human-written.
  • Contract-тесты (границы): Верифицируют API-контракты. Особенно важно, когда агенты модифицируют интерфейсы.

Ресурсы

Section titled “Ресурсы”

Обязательное

Section titled “Обязательное”