# GStack, /goal и office hours: рабочий цикл для AI-агента без бесконечной простыни текста

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

Я использую GStack как guardrail для этого цикла: агент меньше соглашается с мутной идеей и чаще показывает, где принял решение сам.

## Мой текущий loop

окей, ладно, это имба:

- **/office-hours скилл GStack**
  - прожарка любой идеи;
  - вопросы “нафига” и “зачем” до того, как агент начнет писать код.

- **[/improve-codebase-architecture](/blog/improve-codebase-architecture-prompt/)**
  - повышает шанс, что вайбкод проживет дольше одного вечера;
  - заставляет смотреть на границы, дублирование и будущую стоимость изменений.

- **/goal в Codex или /loop в Claude Code**
  - длинный ран после брейншторма;
  - агент работает автономно, но с понятным критерием готовности.

- **HTML-progress вместо простыни**
  - какие решения принял там, где спека мутная;
  - где отошел от плана и почему;
  - какие трейдоффы выбрал;
  - что еще не чекнул;
  - какая визуализация лучше подходит задаче.

Мой следующий шаг - понять, как неслопно задизайнить что угодно. [Разбирал это отдельно в статье про design engineering и AI-агентов](/articles/ai-tools-for-designers-design-engineering-agents/).

## Рабочий цикл

Вот как это можно собрать без магии:

| Шаг | Что делает |
| --- | --- |
| `/office-hours` | Заставляет сформулировать “зачем”, аудиторию, риск и первый эксперимент |
| `/improve-codebase-architecture` | Ищет неочевидные архитектурные долги после того, как “вроде все работает” |
| `/goal` или `/loop` | Дает агенту длинный автономный ран с понятной целью и критерием готовности |
| HTML progress | Превращает ход работы в читаемый артефакт: решения, трейдоффы, unchecked areas |

Главный смысл в том, чтобы не смешивать мышление, исполнение и отчетность в один чат. Сначала агент помогает сузить идею. Потом работает. Потом показывает, где именно принимал решения. Потом отдельный агент или тот же агент в свежем контексте ревьюит результат.

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

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

HTML-progress возвращает контроль. Нормальный progress artifact должен отвечать на вопросы:

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

Это особенно важно для `okhlopkov.com`: агент может генерировать статьи, но редактору нужен короткий обзор, почему страница создана, какие источники использованы, где текст требует ручной вычитки и какие внутренние ссылки надо поставить.

## Почему это важно для сайта

Такие workflow-посты хорошо ложатся именно в `blog`: личный опыт и твой стиль остаются внутри, а вокруг можно строить нормальную структуру:

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

## Читать ещё

- [AI-агенты: с чего начать в 2026](/blog/ai-agents-s-chego-nachat/)
- [Что попросить AI-агента сделать, когда задачи закончились](/blog/improve-codebase-architecture-prompt/)
- [AI-инструменты для дизайнеров: design engineering и агенты](/articles/ai-tools-for-designers-design-engineering-agents/)
- [Markdown мёртв — да здравствует HTML](/articles/markdown-vs-html/)