AI-агенты ведут проект, пока я в отпуске: Claude Code, Paperclip и GStack без магии
Как я настроил AI-агентов на проект, что сработало во время отпуска, что сломалось и какой workflow нужен, чтобы агент не просто менял код туда-сюда.
Короткая версия: AI-агент может поддерживать проект без вас, если вы дали ему не “делай бизнес”, а узкий operational loop: найти баг → проанализировать → исправить → открыть PR → отревьюить другим агентом → задеплоить → проверить прод. Стратегия, новые эксперименты и продуктовые решения сами из воздуха не появляются.
Это пост по мотивам видео “Я в отпуск — AI агенты работают за меня”, исходного поста 1654 и follow-up 1659 с итогами отпуска.
Что было в исходном посте
Я в отпуск — AI агенты работают за меня
Рассказал, как засетапил GStack + Paperclip. Застримил без купюр, как юзаю и дебажу этот AI-сетап.
Видео: youtu.be/E3P0a03mN8A
После отпуска стало понятнее, где это работает, а где нет.
Что реально работало
Работал не “автономный бизнес”, а конкретный цикл поддержки:
- Баг появляется в Sentry.
- Агент в роли CTO анализирует ошибку.
- Агент делает фикс.
- Создается PR.
- Другой агент ревьюит изменения.
- Изменения деплоятся.
- Агент проверяет, что на проде все ок.
- В параллель регулярно постится build in public в канал проекта.
Для проекта вроде 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 чеклист
Перед тем как оставлять агента работать без вас, проверьте:
- Есть понятный “definition of done”: тесты, деплой, прод-проверка, формат отчета.
- Есть список запретных действий: не удалять данные, не менять оплату, не деплоить миграции без ревью.
- Есть триггеры: Sentry, CI, GitHub issues, cron, ручная очередь задач.
- Есть отдельный ревью-раунд другим агентом.
- Есть журнал решений: что сделал, почему, какие файлы трогал, что проверить человеку.
- Есть способ не ждать input, если сценарий должен идти автономно.
- Есть бюджет и лимиты, чтобы агент не сжег деньги за ночь.
- Есть простой 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 важнее очередного промпта “сделай лучше”.
Карта интентов
Для запроса 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. Новые фичи и стратегию лучше оставлять под человеческое решение до тех пор, пока процесс не стабилен.