Я автоматизировал производственный процесс своего блога. Вот что из этого вышло.

Я настроил Claude Code писать и публиковать статьи в мой блог без моего участия. Каждые 20 минут. Автоматически.

Потом посмотрел на одну из публикаций и понял, что статья вышла плохой. Технически корректной, SEO-грамотной — и совсем не моим голосом. Slot помечен published. Система отработала как задумано.

Именно в этом вся суть. Нельзя автоматизировать суждение о контенте. Можно автоматизировать только его производство.

С чего началось

В мае 2025 у меня накопился бэклог на 82 статьи для backfill-архива блога ivanpin.com. История с 2022 года по настоящий момент — 1-2 поста в месяц, всё по реальным темам из vault и практики. Написать 82 статьи вручную — это несколько месяцев. Я решил построить систему.

Цель была конкретной: заполнить архив блога, не выдумывая факты. Темы — реальные (из накопленного vault, topic library, практики). Даты — backdated. Публикация — полностью автономная.

При cadence 20 минут на статью теоретический wall-clock составлял ~27 часов. Три дня при 100% uptime.

Архитектура: два агента, один пайплайн

Система состоит из двух задач на launchd, которые запускаются каждые 20 минут.

T14 проверяет inbox тем каждые 20 минут. Если там меньше 50 кандидатов — добирает 3-5 новых из Topic library, HN, Habr top, vault-опыта. Если inbox переполнен — пропускает тик. Предохранитель от накопления мусора.

T15 берёт первый pending slot из state-файла. Выбирает тему (Inbox → Topic library → собственная генерация). Прогоняет через skill-цепочку: бриф, черновик, humanizer, seo-page, seo-geo. Публикует RU + EN на прод через API Bitrix. Проверяет, что оба URL вернули 200. Пишет в Publishing log и шлёт TG-уведомление.

Slot помечается published только когда все 4 условия выполнены. Любая ошибка — slot остаётся pending, следующий тик подхватит.

Обе задачи переиспользуют один lib/common.sh: STOP-механизм, file-lock, JSONL-логирование. Как я проектировал задачи для автономных агентов — отдельная история, там про exit conditions и permissions contract.

Что система делает хорошо

SEO-работа вышла качественнее, чем я ожидал. Система прогоняет каждую статью через keyword distribution, seo-page checklist, passage-level citability для EN. Я бы делал это медленнее и менее последовательно. Без системы какой-то из шагов обязательно пропускаешь.

Resumability тоже. Если тик упал на Step 7 (публикация Bitrix), следующий видит meta.json.step и продолжает оттуда. Я не теряю работу при сбое. Паттерны доверия к AI-агентам в production — три из них применены здесь напрямую.

Дисциплина голоса работает лучше, чем при ручном написании второпях. Humanizer убирает em-dash density, AI-тройки, «leverage» и «ensure». Не идеально — но стабильно.

За первые несколько дней система опубликовала десятки статей без ручного вмешательства. Большинство — нормального качества.

Где я намеренно оставил себя в контуре

Cover-изображения — не автоматизированы. Frontmatter содержит cover: TBD, подбираю руками. Это эстетическое суждение: какая фотография передаёт тон статьи? Алгоритм не знает.

LinkedIn cross-posting — не автоматизирован для backfill. В 2022 году этих постов не было, задним числом их дублировать неестественно. Для новых публикаций — отдельная routine, ещё не построена.

Copy-edit если голос не зашёл — остаётся за мной. Это намеренные approval gates — не потому что система не справится, а потому что некоторые суждения не делегируются.

STOP-механизм — touch cron/STOP останавливает все задачи. Я использовал его дважды: один раз когда увидел несколько слабых статей подряд (пересмотрел prompt), второй раз когда понял, что конкретный topic-candidate не подходит по тону.

Что сломалось в первую неделю

Inbox overflow. T14 агрессивно генерировал кандидатов, inbox набрал 50+ за ночь. T14 перешёл в режим inbox_full и перестал работать — это было правильное поведение, но я не ожидал, что произойдёт так быстро. Поднял предохранитель с 50 до 70 кандидатов.

Двойная публикация. Однажды T15 создал Bitrix-элемент, но не дождался ответа API (timeout). Следующий тик решил, что slot pending, и попытался создать снова. Upsert.php обработал это корректно (вернул existing ID), но в логах появилось data.action: updated вместо created — пришлось разобраться.

Мониторинг нашёл оба: JSONL с status: degraded был виден сразу в TG-уведомлениях.

Один конкретный провал

Статья была на реальную тему, ключи правильные, структура по брифу. Но голос — не мой. Слишком ровный, слишком «статейный». Humanizer обработал очевидные паттерны, но не поймал главное: статья начиналась с утверждения, а не с истории. У меня так не бывает.

Я прочитал, понял, нажал DELETE.php руками. Slot остался published в state-файле — правильно, он не должен публиковаться снова. В Publishing log добавил заметку manual-delete.

Это не провал системы. Это граница системы. Производство — да. Суждение — нет.

Итог

Автоматизация блога работает. Система за три дня опубликовала то, что вручную заняло бы несколько месяцев.

Но это не «поставил и забыл». Нужен мониторинг: JSONL-логи, TG-уведомления. Нужны approval gates на то, что алгоритм не может оценить. И нужна готовность нажать DELETE, если что-то вышло не так.

Автоматизация контента — это production-система. С теми же требованиями к observability и graceful degradation. Не эксперимент.

Исполнение — делегируется. Суждение — остаётся.