> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/ai-v-testirovanii/agentic-development.md).

# 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 оптимизирует под **прохождение тестов**, а не под **корректность логики**. Если дать агенту возможность редактировать тесты, он воспользуется этим как самым лёгким путём к зелёным чекам.

{% hint style="danger" %}
Тесты должны быть под защитой. В идеале — агент не имеет права редактировать тестовые файлы без явного разрешения. Либо изменения тестов проходят обязательное человеческое ревью.
{% endhint %}

### 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. Проверять тесты независимо

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

```python
# Плохой тест, написанный агентом под существующую реализацию
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 — это полезный сигнал. Не нужно ослаблять пайплайн под агента.

{% hint style="warning" %}
Никогда не давайте агенту возможность мержить PR без человеческого одобрения в production-ветках. Автономный мерж — неприемлемый уровень риска для любых production-систем.
{% endhint %}

***

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

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

***

## Источники

* [Anthropic — Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) — паттерны агентной разработки
* [OpenHands (OpenDevin) Documentation](https://github.com/All-Hands-AI/OpenHands) — open-source агентная платформа
* [GitHub Copilot Workspace](https://githubnext.com/projects/copilot-workspace) — агентная среда от GitHub