# AI-агенты ведут проект, пока я в отпуске: Claude Code, Paperclip и GStack без магии

Короткая версия: AI-агент может поддерживать проект без вас, если вы дали ему не “делай бизнес”, а узкий operational loop: найти баг → проанализировать → исправить → открыть PR → отревьюить другим агентом → задеплоить → проверить прод. Стратегия, новые эксперименты и продуктовые решения сами из воздуха не появляются.

Это пост по мотивам видео “[Я в отпуск — AI агенты работают за меня](https://youtu.be/E3P0a03mN8A)”, исходного поста [1654](https://t.me/danokhlopkov/1654) и follow-up [1659](https://t.me/danokhlopkov/1659) с итогами отпуска.

## Что было в исходном посте

**Я в отпуск — AI агенты работают за меня**

Рассказал, как засетапил [GStack](https://t.me/danokhlopkov/1647) + [Paperclip](https://t.me/danokhlopkov/1637). Застримил без купюр, как юзаю и дебажу этот AI-сетап.

Видео: [youtu.be/E3P0a03mN8A](https://youtu.be/E3P0a03mN8A)

После отпуска стало понятнее, где это работает, а где нет.

## Что реально работало

Работал не “автономный бизнес”, а конкретный цикл поддержки:

1. Баг появляется в Sentry.
2. Агент в роли CTO анализирует ошибку.
3. Агент делает фикс.
4. Создается PR.
5. Другой агент ревьюит изменения.
6. Изменения деплоятся.
7. Агент проверяет, что на проде все ок.
8. В параллель регулярно постится build in public в канал проекта.

Для проекта вроде [ffmemesbot](https://t.me/ffmemesbot) этого уже достаточно, чтобы не оставлять продукт совсем без присмотра.

## Что работало плохо

Главная проблема: багфикс часто приводил к новому багу, потом агент откатывался или менял код туда-сюда. Это не “AI тупой”, это нормальная цена плохо ограниченной автономности.

Вторая проблема важнее: агент не делал продуктовую стратегию сам. Не было новых экспериментов, развития продукта и фичей, потому что CEO-задачи не были поставлены. CTO без CEO чинит баги. Он не придумывает, куда двигать продукт, если это не описано в системе.

Третий баг был технический: GStack нужно запускать так, чтобы он не ждал моего input, потому что меня реально нет. Фикс простой, но обнаружился уже после отпуска.

## Архитектура такого сетапа

| Компонент | Роль | Если убрать |
| --- | --- | --- |
| Claude Code / Codex | Исполнитель в коде | Некому читать repo, менять файлы и гонять команды |
| GStack | Рабочий цикл, роли, проверки, goal/office-hours | Агент превращается в один длинный чат без менеджмента |
| Paperclip | Оркестрация задач и связка “AI-организации” | Сложнее запускать повторяемые процессы |
| Sentry/логи | Триггер для работы | Агент не знает, где горит |
| GitHub PR | Контроль изменений | Правки сложнее ревьюить и откатывать |
| Второй агент-ревьюер | Независимая проверка | Один агент легко рационализирует свой же diff |
| Документы/GBrain | Память и правила | Каждая итерация начинается с амнезии |

AI-агенту нужен не промпт на 20 строк, а маленькая операционная система вокруг него.

## Vacation-proof чеклист

Перед тем как оставлять агента работать без вас, проверьте:

1. Есть понятный “definition of done”: тесты, деплой, прод-проверка, формат отчета.
2. Есть список запретных действий: не удалять данные, не менять оплату, не деплоить миграции без ревью.
3. Есть триггеры: Sentry, CI, GitHub issues, cron, ручная очередь задач.
4. Есть отдельный ревью-раунд другим агентом.
5. Есть журнал решений: что сделал, почему, какие файлы трогал, что проверить человеку.
6. Есть способ не ждать input, если сценарий должен идти автономно.
7. Есть бюджет и лимиты, чтобы агент не сжег деньги за ночь.
8. Есть простой rollback.

Без этого вы запускаете не автономность, а генератор сюрпризов.

## Как формулировать задачи агенту

Плохой промпт: “следи за проектом и улучшай его”. Нормальный промпт: “каждый час проверь Sentry и GitHub Actions. Если есть новая production ошибка с повторяемостью больше N, найди root cause, предложи план, сделай минимальный фикс в отдельной ветке, запусти тесты, открой PR, попроси review agent проверить diff. Не меняй public API и не трогай миграции без отдельного approval. В конце дай отчет: ошибка, причина, diff, тесты, риски”.

Разница в том, что нормальный промпт задает loop, границы и критерии результата.

## Что добавилось из обсуждений

В чате люди быстро упираются не в “какая модель умнее”, а в стоимость, контекст и harness:

- для анализа большого количества диалогов советовали не отдавать “весь проект в AI”, а задать правила, формат вывода и пайплайн чанков;
- для простого анализа текста можно брать дешевые или локальные модели, не обязательно жечь топовые;
- на больших кодовых базах контекст протухает, и агент начинает ломать больше;
- subagents помогают, но если они зависают или работают без четкой роли, основной агент все равно переписывает за ними.

Вывод: автономность надо проектировать как production workflow. Модель — это исполнитель, а не вся система.

## Где GStack помогает

GStack полезен не потому, что “еще один агент”, а потому что заставляет задать менеджерскую структуру:

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

Именно поэтому связка с [office hours и goal loop](/blog/gstack-goal-office-hours-ai-workflow/) важнее очередного промпта “сделай лучше”.

## Карта интентов

Для запроса `ai coding agent workflow` человеку нужен не футуризм, а схема:

| Интент | Ответ |
| --- | --- |
| “Как запустить AI-агента на проекте?” | Narrow loop, роли, trigger, review, rollback |
| “Может ли агент работать без меня?” | Да, на поддержке и повторяемых задачах; нет, если не задана стратегия |
| “Как не получить хаос в коде?” | PR, тесты, review agent, маленькие diff, запреты |
| “Зачем GStack/Paperclip?” | Оркестрация и менеджмент вокруг coding agent |

## FAQ

### AI-агент может вести проект полностью автономно?
Поддержку — частично да. Продуктовую стратегию — только если вы заранее описали цели, ограничения и процесс принятия решений. Без CEO-loop агент будет чинить то, что видит, а не развивать продукт.

### Что лучше дать агенту первым делом?
Не весь проект. Дайте один повторяемый workflow: “если Sentry ошибка — сделать root cause, минимальный фикс, тесты, PR, review, отчет”. Так проще проверить качество.

### Нужен ли отдельный review agent?
Да, если агент меняет production-код. Один и тот же агент плохо ревьюит собственное решение: он уже вложился в гипотезу и часто защищает diff вместо поиска риска.

### Почему агенты меняют код туда-сюда?
Обычно нет жесткого критерия готовности или тесты не ловят реальное поведение. Агент видит симптом, фиксит локально, ломает соседний сценарий, потом чинит его и возвращает первую проблему.

### Что автоматизировать первым?
Баги из Sentry, flaky tests, changelog, release notes, weekly reports, triage GitHub issues. Новые фичи и стратегию лучше оставлять под человеческое решение до тех пор, пока процесс не стабилен.

## Читать ещё

- [GStack, /goal и office hours: рабочий цикл для AI-агента](/blog/gstack-goal-office-hours-ai-workflow/)
- [AI-агенты: с чего начать в 2026](/blog/ai-agents-s-chego-nachat/)
- [Claude Code vs Codex: почему я на две недели перешёл на Codex](/blog/claude-code-vs-codex-perehod/)
- [Что попросить AI-агента сделать, когда очевидные задачи закончились](/blog/improve-codebase-architecture-prompt/)