Автор рассказывает, как его рабочий процесс с Claude Code прошёл путь от простого до, пожалуй, чересчур автоматизированного. Сначала всё было синхронно: он сидел в терминале, вместе с ИИ мозговой штурм, он же — реализация и ревью. Чтобы не ждать, он начал открывать несколько окон параллельно, тасовать worktree'ы и работать над разными фичами одновременно. Помогал плагин superpowers с цепочкой brainstorm → spec → plan → implement.
Но пришла усталость от переключения контекста — держать в голове 3–4 фичи и жадно жать «Yes» на каждое предложение ИИ стало невыносимо. От проектов вроде OpenClaw или Clawdbot автор сперва шарахался из-за безопасности, пока AWS не выпустил однокнопочный деплой на Lightsail. Разговоры с Сергеем Рысевым подтолкнули к мысли «убрать себя из уравнения» — делегировать, не следя за каждой мелочью.
Автор взял EC2, подключился через SSM, изолировал каждый проект в отдельную машину (чтобы уменьшить радиус взрыва при ошибках) и начал убирать ручное подтверждение. Сначала было больно: контекст репозиториев перемешался, CLAUDE.md-файлы запутались, ИИ тупил без истории прошлых диалогов. Но изоляция дала спокойствие.
Главный прорыв — переход на GitHub Issues как на доску планирования. Метки стали состояниями, комментарии — логами. Скрипт tick.sh на cron каждые 15 минут берёт задачу, переключает метку, запускает claude -p неинтерактивно, ждёт результата, записывает статус. Каждая фаза (спека, план, реализация) идёт в изолированном контексте — автор подсмотрел эту идею у Lina Edwards. Мозговые штурмы перестали съедать утро: автор пишет в issue пару строк, ставит метку needs-enrichment, а демон сам подтягивает код, находит приоритеты, задаёт вопросы. Утром автор читает обогащённую версию и принимает решение.
В итоге осталось пять человеческих точек касания: подтвердить enriched issue, принять spec, принять план, принять дифф, выставить метку merge. Всё остальное — автоматическое ночное исполнение. Утром автор пробегается по меткам: needs-attention — фикс, branches-ready — ревью и мёрж.
Автор честно признаёт: не уверен, что этот путь быстрее или дешевле ручной работы. Он просто хочет проверить, как далеко можно зайти в делегировании, не переходя черту, где ИИ начинает думать за тебя. Пайплайн уже производит технический долг — тесты порочны, архитектура иногда идёт вразрез. Следующие узкие места — QA (проверка того, что не тестируется), обзоры архитектуры и безопасности, которые пока поверхностны. Но главное — автор убеждён: нельзя делегировать само мышление. И если кто-то говорит, что знает единственно верный рецепт использования ИИ в разработке — бегите от него.