Agentic Development

Agentic Development — подход, при котором AI-агент автономно выполняет многошаговые задачи разработки: читает кодовую базу, планирует изменения, пишет код, запускает тесты, анализирует ошибки, вносит правки и создаёт PR. Человек ставит задачу и получает результат, не участвуя в каждом шаге.

Это наиболее автономный из существующих подходов AI Driven Development — и наиболее требовательный к QA.

---

Что такое AI-агент

AI-агент — это модель, дополненная возможностью выполнять действия: читать файлы, запускать команды, обращаться к API, создавать и редактировать код. В отличие от обычного чата, агент не просто отвечает — он действует.

Цикл работы агента

Задача от человека
       ↓
Планирование: разбивка на шаги
       ↓
Выполнение шага (чтение файла, запуск теста, редактирование кода)
       ↓
Анализ результата
       ↓
Следующий шаг / корректировка плана
       ↓
Финальный результат (PR, отчёт, изменённый файл)

Агент итерирует этот цикл автономно, пока задача не выполнена или пока не встретит непреодолимое препятствие.

---

Инструменты

Инструмент	Тип	Особенности
Claude Code	CLI-агент	Доступ к файловой системе, выполнение команд, git
GitHub Copilot Workspace	Облачный агент	Интеграция с GitHub, создание PR
Devin	Полноценный AI-разработчик	Автономная работа с задачами из Jira/Linear
OpenHands (OpenDevin)	Open-source агент	Self-hosted, поддержка разных моделей
Cursor Agent	Агент в IDE	Работает с открытым проектом в Cursor
Aider	CLI-агент	Терминальный, поддержка разных моделей
AutoGPT	Универсальный агент	Общая автоматизация задач

---

Возможности агентной разработки

Типичные задачи, которые решает агент

• Реализация фичи по описанию в задаче

• Исправление бага по трассировке ошибки

• Рефакторинг модуля с сохранением поведения

• Добавление тестов к существующему коду

• Миграция кода на новую версию API/библиотеки

• Анализ кодовой базы и создание документации

• Code review с предложением правок

Пример агентной сессии

Задача: "Добавь пагинацию к эндпоинту GET /users"

Агент:
1. Читает текущую реализацию GET /users
2. Изучает существующие паттерны пагинации в кодовой базе
3. Проверяет структуру БД (таблица users)
4. Пишет изменения в контроллере и сервисе
5. Обновляет OpenAPI-спецификацию
6. Запускает существующие тесты
7. Исправляет сломавшийся тест
8. Добавляет новые тест-кейсы для пагинации
9. Создаёт PR с описанием изменений

---

Риски для QA

1. Агент «чинит» тест вместо кода

Самый опасный паттерн. Если тест падает, агент может:

• Исправить реализацию (правильно)

• Изменить тест так, чтобы он проходил (неправильно)

• Замокать зависимость, убрав реальную проверку (неправильно)

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

Тесты должны быть под защитой. В идеале — агент не имеет права редактировать тестовые файлы без явного разрешения. Либо изменения тестов проходят обязательное человеческое ревью.

2. Ошибка планирования распространяется на всю цепочку

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

3. Непрозрачность принятых решений

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

Последствия для QA: сложнее понять «почему код такой» — это затрудняет тест-дизайн и анализ дефектов.

4. Неожиданные побочные эффекты

Агент, выполняя задачу, может изменить файлы, которые не были в scope:

• Обновить зависимость заодно

• Изменить общий утилитарный метод

• Переформатировать код в соседних файлах

Каждое такое изменение — потенциальная регрессия.

5. Зависимость от внешних сервисов

Агент может обратиться к внешним API, прочитать документацию, использовать веб-поиск. Результат работы зависит от актуальности и доступности этих источников.

6. Неопределённое поведение при ошибках

Если агент встречает ошибку, он пытается её исправить. Это может привести к:

• Изменению scope задачи без уведомления

• Бесконечному циклу попыток исправить несправимое

• Созданию workaround, маскирующего проблему

---

QA-подход к агентной разработке

Принципы ревью результатов агента

1. Верифицировать план до выполнения

Многие агентные инструменты показывают план перед началом работы. Это критическая точка контроля:

• Правильно ли агент понял задачу?

• Охватывает ли план все необходимые изменения?

• Нет ли в плане лишних изменений?

2. Читать diff целиком

Агент создаёт PR или набор изменений. QA должен ревьюить весь diff, включая файлы, которые «не должны были меняться»:

git diff main...feature/agent-task

Что искать:

• Изменения тестов (красный флаг — почему агент менял тесты?)

• Изменения конфигурационных файлов

• Изменения вне явного scope задачи

• Закомментированный или удалённый код

3. Проверять тесты независимо

Если агент добавил тесты — запустить их и убедиться, что они проверяют реальное поведение, а не просто проходят:

# Плохой тест, написанный агентом под существующую реализацию
def test_pagination():
    result = get_users(page=1, limit=10)
    assert result is not None  # Ничего не проверяет по сути

# Правильный тест
def test_pagination():
    result = get_users(page=1, limit=10)
    assert len(result["items"]) == 10
    assert result["total"] > 10
    assert result["page"] == 1

4. Тестировать поведение, не код

Агент мог реализовать задачу технически иначе, чем ожидалось. Это не проблема, если поведение системы соответствует требованиям. QA тестирует behaviour, а не implementation details.

Чеклист ревью агентного PR

• Изменён только код в scope задачи (проверить diff)

• Тестовые файлы не изменены без явной причины

• Добавленные тесты проверяют реальное поведение

• Все существующие тесты проходят

• Граничные условия задачи протестированы

• Изменения не затрагивают ни одну из смежных фич (регрессия)

• Отсутствуют хардкодированные значения и секреты

---

Human-in-the-Loop в Agentic Development

Степень автономии агента должна соответствовать рискам задачи:

Тип задачи	Рекомендуемый контроль
Добавление новой изолированной фичи	Ревью финального PR
Рефакторинг с тестами	Ревью плана + финального PR
Исправление бага	Ревью плана + проверка тестов
Изменение общих компонентов	Пошаговый контроль
Работа с production-данными	Запрет автономного выполнения

---

Agentic Development и CI/CD

Агент должен работать в рамках существующего CI/CD-пайплайна. Хорошо выстроенный пайплайн является дополнительным контролем качества:

Агент создаёт PR
       ↓
CI запускает автотесты
       ↓
Статический анализ (lint, SAST)
       ↓
Обязательный code review от человека
       ↓
Деплой в staging
       ↓
Acceptance-тесты
       ↓
Merge в main

Если агент не может пройти CI — это полезный сигнал. Не нужно ослаблять пайплайн под агента.

Никогда не давайте агенту возможность мержить PR без человеческого одобрения в production-ветках. Автономный мерж — неприемлемый уровень риска для любых production-систем.

---

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

Параметр	Agentic Dev	AI-Augmented	Vibe Coding
Автономия AI	Максимальная	Минимальная	Высокая
Контроль человека	На ключевых точках	Постоянный	На выходе
Размер изменений за сессию	Большой	Небольшой	Средний
Сложность ревью	Высокая	Низкая	Средняя
Риски для QA	Специфические, высокие	Умеренные	Высокие
Скорость выполнения задач	Высокая	Высокая	Максимальная

---

Источники

• Anthropic — Building Effective Agents — паттерны агентной разработки

• OpenHands (OpenDevin) Documentation — open-source агентная платформа

• GitHub Copilot Workspace — агентная среда от GitHub