> 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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vladislaveremeev.gitbook.io/qa_bible/ai-v-testirovanii/agentic-development.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.