От GitHub Issue до продакшена: Как построить конвейер, который заставит AI-агента менять ваш сайт

Если вы устали вручную переводить баг-репорты и пожелания пользователей в задачи для разработчиков, вам нужен такой AI-агент. Я настроил конвейер, который автоматически берет любой тикет из GitHub Issues и пытается превратить его в готовую, работающую веб-страницу на вашем сайте.

Этот гайд раскладывает по полочкам, как работает такая система, какие компоненты нужны и где кроются главные риски.

Зачем вообще нужно, чтобы AI чинил ваш сайт по тикету?

Основная проблема в разработке — разрыв между фидбеком пользователя (в виде сырого текста в тикете) и готовым, развернутым кодом. Обычно это требует участия менеджеров, аналитиков и разработчиков.

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

Ваша задача — не просто заставить LLM писать код. Ваша задача — построить рабочую систему (пайплайн), которая будет принимать сырые данные (Issue) и выдавать структурированный результат (рабочую страницу).

Как выглядит конвейер: от Webhook до GitHub Actions

В основе этой системы лежит архитектура, которая превращает GitHub в триггер, а агента — в исполнителя.

Пошаговая логика выглядит так:

1. Триггер: Пользователь создает Issue в репозитории.
2. Сбор данных: GitHub Webhook ловит это событие.
3. Обработка: Webhook запускает внешний сервис (например, Docker-контейнер), который содержит AI-агента.
4. Действие: Агент анализирует текст Issue и решает, что нужно сделать с сайтом.
5. Выкатывание: Если решение принято, агент генерирует изменения в коде и запускает процесс деплоя через GitHub Actions.

🛠️ Шаг 1. Настройка приема тикетов (The Trigger)

Для начала нужно, чтобы внешняя система знала о новом Issue. Это делается через GitHub Webhooks.

Вам нужно настроить webhook для нужного репозитория. Он должен быть привязан к событию issues (или issue_comment, если вы хотите реагировать на комментарии).

В вашем коде-сервисе (который будет принимать webhook) вы должны уметь парсить JSON-тело, чтобы извлечь:

• issue_number: Номер тикета.
• issue_title: Заголовок (главная суть запроса).
• issue_body: Тело тикета (самые подробные требования).

🤖 Шаг 2. Архитектура агента и промптинг (The Brain)

Самый важный элемент — сам агент. Он не может просто "думать"; ему нужны стартовые промпты, которые определяют его роль и границы.

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

1. Планировщик (Planner Agent): Получает Issue и генерирует план действий (например: "Нужно создать новый компонент /feature/issue-123 и обновить Header.jsx").
2. Генератор кода (Coder Agent): Получает план и генерирует конкретные фрагменты кода (React, Python и т.д.).
3. Тестировщик (QA Agent): Проверяет сгенерированный код на соответствие плану и на наличие ошибок.

Ключевой момент: Используйте несколько профилей (как в источнике — 8 разных профилей Codex-агента). Это позволяет вам адаптировать агента под разные задачи: один профиль для фронтенда (React), другой для бэкенда (API), третий для написания документации.

В стартовый промпт (System Prompt) критически важно прописать не только роль, но и ограничения.

``json { "role": "Coder Agent", "system_prompt": "Ты — опытный фронтенд-разработчик React. Твоя задача — принимать требования пользователя и генерировать чистый, готовый к коммиту код. Ты обязан придерживаться структуры компонента src/components/. Не генерируй код, который не является React-компонентом. Всегда добавляй JSDoc-комментарии.", "guardrails": "Нельзя использовать внешние API без явного указания в плане. Всегда проверяй валидность JSX." } ``

🚀 Шаг 3. Деплой и финализация (The Action)

Полученный код должен попасть на сайт. Здесь на помощь приходит GitHub Actions.

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

Логика в пайплайне:

1. Webhook передает агенту требования.
2. Агент генерирует патч-файл или список изменений.
3. Ваш сервис (на стороне сервера) записывает эти изменения в локальную ветку репозитория.
4. Сервис инициирует запуск GitHub Actions, передавая ему команду git push с новыми изменениями.

Это превращает AI-агента из простого кодогенератора в полноценного DevOps-исполнителя.

Подводные камни: Где ломается идеальный конвейер

Если вы решите строить такую систему, будьте готовы к следующим проблемам:

⚠️ 1. Эскалация полномочий (The Jailbreak Risk)

Самый большой риск — это "сбежавший" агент. Если вы не установили жесткие guardrails (ограничения) в промпте, агент может решить, что для выполнения задачи ему нужно сделать что-то несанкционированное (например, удалить важный файл или отправить данные на внешний ресурс).

Решение: Всегда обрабатывайте действия агента через санитайзер. Перед тем как выполнить команду git push или curl, прогоните ее через отдельный, не-LLM-зависимый модуль, который проверяет, находится ли действие в списке разрешенных API-вызовов.

⚠️ 2. Состояние мира (State Management)

LLM-агенты работают в контексте, а не в реальном времени. Если в Issue затронута сложная зависимость (например, изменение API, которое влияет на 5 других модулях), агент может проигнорировать контекст и выдать нерабочий код.

Решение: Делите задачи на микро-шаги. Не просите агента "починить сайт", просите "сгенерировать компонент X в файле Y, используя API Z".

⚠️ 3. Стоимость и предсказуемость

Использование мощных моделей (вроде GPT-4 Turbo) для каждого запроса может быть очень дорогим. Как показано в источнике, для экспериментальной, но предсказуемой работы часто достаточно самых дешевых и быстрых моделей (например, GPT-3.5 или их мини-варианты).

Вывод: Для эксперимента и проверки концепции (PoC) выбирайте минимально необходимый уровень "разумности" модели, чтобы держать расходы под контролем.

Что попробовать дальше

1. Внедрить механизм регрессионного тестирования: После того как агент сгенерировал код, не деплойте его сразу. Запустите набор unit-тестов (Jest, Pytest) на этом коде, прежде чем он попадет на продакшен.
2. Создать систему откатов: Обязательно заложите в пайплайн автоматический механизм отката (rollback). Если деплой провалился, система должна автоматически откатить код до предыдущей стабильной версии.
3. Управление контекстом: Вместо того чтобы передавать весь Issue, извлекайте из него только сущности (Entities): Что меняется, Где меняется, Для кого меняется.

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

Источники

• Habr AI: Пользователь пишет issue, агент меняет сайт. Да, я это сделал