Управление агентом без approve: 134 rules вместо permission prompts

Типичное permission rule из поста:

Never `git push` unless the user asks for it in that message.
One "push" authorizes exactly one push. Permission is never standing.

Для соло без отдельного DevOps это узнаваемая боль: агент, который пушит в GitHub по привычке, раздувает GitHub Actions и счёт — а вы узнаёте об этом постфактум.

Девять практик: роли, рестарт и память вместо итераций

Childress нумерует девять практик между вводными секциями про «оргчарт из одного сотрудника» и итоговой «оценкой единственного сотрудника». Суть — не ускорение, а перенос решений раньше по цепочке.

#	Практика (суть)	Зачем агентному workflow
1	Роли и permissions; чёрный список вместо approve	Агент автономно, без потери границ
2	Несколько AI-ревьюеров (Codex, Copilot, Claude)	Второй смотрит ветку и риск, не эхо первого
3	Рестарт вместо починки: /new при «отравленном» контексте	Три неудачные правки или одна ложная посылка — стоп
4	Писать от outline, не от сгенерированного драфта	Skills с примерами стиля и banned phrases
5	Агент спрашивает при развилке смысла; вкус решает сам	Меньше лишних вопросов про hex-цвета
6	Ошибки → постоянные rules; самопроверка памяти	Аналог .cursor/rules и project-level prompts
7	Proof шире «тесты зелёные»	Spec-based тесты, runtime, сломанный ввод
8	ИИ говорит, когда не действовать	Молчание, отказ от фичи — валидный output
9	Mining chat history	Факт подтверждается rule files и репо, не памятью чата

Принцип omission is better than correction: лучше не допустить ошибку в prompt/memory, чем десять раз её чинить в итерациях.

«I use AI to write code, review the AI-written code, review the review against the live branch, test the corrections, and then record whatever went wrong as a rule for the next AI. Apparently I recreated management.»

Один и тот же prompt автор гонял отдельно через Codex, ChatGPT, Claude Code, Cowork и Gemini — системы не видели ответы друг друга. Это перекрёстная независимая проверка без ручного diff-review: второй ревьюер получает ветку и риск, а не вердикт первого.

Rules, skills и MCP как намеренная память агента

Постоянные инструкции живут в skills, AGENTS.md, memory и rule files — по команде вроде «update your permanent memory for this user». Примеры имён из поста: push-only-when-explicitly-told, no-unverified-pushes, never-ask-to-remove-dead-code, dont-decide-ux-unilaterally, feedback_silence_is_acceptance.

Периодически Childress запускает самопроверку памяти агентом: противоречия, устаревшее, нерелевантное. Для соло-разработчика с длинными agent-сессиями это ближе к дисциплине project rules, чем к разовым system prompts в начале чата.

Из инструментов в тексте явно названы GitHub Copilot, Codex, Claude Code, Cowork, Gemini; Spec Kit не использовал — «к моменту появления уже был свой вариант». В proof-репозиториях упомянута миграция экспериментов в github/awesome-copilot с MCP — как пример осознанного контекста для агента, не случайного набора промптов.

Точная файловая иерархия rules в посте не расписана: только memory files, skills и AGENTS.md. Вывод для переноса — собирать систему безопасности заранее, а не надеяться на запросы разрешения в рантайме.

Proof сильнее зелёных тестов — и честные границы

Автор не продаёт «ИИ ускорил меня». Цель rules — чтобы решение не пересматривалось «в полночь чем-то, что не знает, что вы имели в виду». Подход сдвинул принятие решений раньше, а не сократил календарь.

«Proof» в посте — несколько слоёв:

• Награды проектов, где код писал ИИ, а архитектуру — автор: Save the Sun (Best Google AI Usage, June Solstice Game Jam), Carbon Trace (Frontend Art, WeCoded 2026), Unearthed (Overall Winner, DEV Weekend Challenge: Earth Day Edition).
• Технический след: кейс Carbon Trace — commit fix(perf): enforce frame-0 overlay invariant at startup, rereview с runtime invariant, ADR, unit, browser, lint, Lighthouse.
• Контрпример тестов: clipboard vs SVG на Dev.to — зелёные тесты вокруг неверного слоя не ловили баг; доказательство — server-side PNG rasterization в реальном месте сбоя.
• Артефакты после споров: RAI Commit Attribution Badge (rai-commit-badge) после аргумента о naming.

Практика №7 требует spec-based тесты, runtime, fixtures и «сломанный» ввод — не доверять «the tests passed» как единственному сигналу.

Важная оговорка из первоисточника: весь материал — personal projects и portfolio; «no critical prod system anywhere in this post». Для prod «a few of these answers would shift». Соло на пет-проектах может экспериментировать с чёрным списком и multi-agent review; на критичном контуре те же приёмы потребуют ужесточения.

Что перенести в соло-workflow с агентами

Редакционный вывод по фактам поста — три переносимых паттерна без выдуманных инструментов:

1. Rules вместо standing permissions — границы в AGENTS.md/rule files до сессии; push и UX-решения — с явными запретами, не с диалогом на каждый чих.
2. Рестарт вместо починки — при трёх неудачных правках или одной ложной посылке новая сессия дешевле, чем «лечить» отравленный контекст.
3. Развести смысл и вкус — агент обязан спросить при развилке смысла; эстетику hex и мелочи решает сам.

Childress около года активно работал с ИИ до серии постов; footer лонгрида ироничен: «Yes, AI wrote this article» — сам текст как meta-proof подхода.

Если вы один в «оргчарте» и гоняете агента через Copilot, Codex или аналог в IDE — вопрос не в том, доверять ли модели, а где зафиксированы запреты, когда вас нет у клавиатуры. 134 rules звучат как перебор, пока не вспомните последний неожиданный push в main.

---

Источники

• Ashley Childress (@anchildress1), «I Recreated Management With AI: 9 Things I Do Differently» — Dev.to (доступ: 2026-08-06)