Коротко
Одна из главных ошибок в работе с AI-агентами: просить “сделай проект” и потом читать километровую простыню. Нормальный флоу выглядит как цикл: прожарить идею, зафиксировать цель, дать агенту автономный ран, заставить его показывать прогресс в удобной форме и отдельно ревьюить архитектуру.
Эта страница не про “что такое GStack”. Это про практический рабочий loop, который можно повторить в Codex, Claude Code и похожих агентных инструментах.
Мой текущий loop
окей, ладно, это имба:
• /office-hours скилл gstack прожарка любой идеи. ответишь на вопросы нафига, а главное зачем
• /improve-codebase-architecture повысь шанс того, что у твоего вайбкода будет долгая жизнь
• /goal в Codex или /loop в Claude Code ральф луп после брейншторма идеи — пусть пыхтит часами & make no mistakes
• пока лупишься - рисуй html с прогрессом какие решения принял там, где спека мутная где отошёл от плана и почему какие трейдоффы выбрал что еще не чекнул выбери лучшую визуализацию под задачу, а не простыню текста
Мой следующий шаг - понять, как неслопно задизайнить что угодно. Разбирал это отдельно в статье про design engineering и AI-агентов.
Рабочий цикл
Вот как это можно собрать без магии:
| Шаг | Что делает |
|---|---|
/office-hours | Заставляет сформулировать “зачем”, аудиторию, риск и первый эксперимент |
/improve-codebase-architecture | Ищет неочевидные архитектурные долги после того, как “вроде все работает” |
/goal или /loop | Дает агенту длинный автономный ран с понятной целью и критерием готовности |
| HTML progress | Превращает ход работы в читаемый артефакт: решения, трейдоффы, unchecked areas |
Главный смысл в том, чтобы не смешивать мышление, исполнение и отчетность в один чат. Сначала агент помогает сузить идею. Потом работает. Потом показывает, где именно принимал решения. Потом отдельный агент или тот же агент в свежем контексте ревьюит результат.
Что добавилось из обсуждений
В community много раз всплывала одна и та же боль: агент может работать долго, но человек теряет ощущение контроля. В итоге ты либо прерываешь его слишком рано, либо читаешь гигантский лог и уже не понимаешь, где важное.
HTML-progress решает не “дизайн ради дизайна”, а контроль. Нормальный progress artifact должен отвечать на вопросы:
- какие решения агент уже принял;
- где спека была мутной;
- какие допущения он сделал сам;
- где отошел от первоначального плана;
- что не проверил;
- какие файлы или страницы стоит посмотреть человеку.
Это особенно важно для okhlopkov.com: агент может генерировать статьи, но редактору нужен короткий обзор, почему страница создана, какие источники использованы, где текст требует ручной вычитки и какие внутренние ссылки надо поставить.
Почему это важно для сайта
Такие workflow-посты хорошо ложатся именно в blog, а не в articles. Они основаны на личном опыте и твоем стиле, но вокруг них можно строить нормальную структуру:
- заголовок отвечает на практический запрос;
- живой текст остается ядром статьи;
- обсуждения добавляют мясо;
- внутренние ссылки ведут в статьи, где тема раскрывается глубже;
- короткие прикладные ответы лучше добавлять прямо в текст, если они не ломают тон.