Этот материал не «теория про ИИ». Это практический разбор конкретной рабочей сессии, где мы последовательно вели блог на Hugo через Codex CLI: писали новые статьи, чинили продовые проблемы, настраивали тему и закрепляли правила процесса.

Именно такой формат, на мой взгляд, лучше всего показывает ценность автоматизации: не в красивых обещаниях, а в повторяемом результате. 🔧

Исходный контекст #

На старте у нас уже был рабочий блог на Hugo с темой typo, CI/CD через Forgejo Actions и поиском на Pagefind.

Дальше в рамках одной непрерывной сессии мы сделали:

  1. Написали и опубликовали новый пост про Hugo 0.157.0.
  2. Поймали проблему с невидимостью поста из-за времени публикации.
  3. Добавили правила в AGENTS.md, чтобы больше не ловить future-ошибки.
  4. Настроили и протестировали подсветку кода (в итоге перешли на dracula).
  5. Привели к dracula цвета выдачи поиска.
  6. Исправили некорректные заголовки в Pagefind (вместо названия поста показывалось имя сайта).
  7. Структурировали README.md и AGENTS.md как рабочую документацию процесса.

То есть это уже не «написать один пост», а полноценный операционный цикл контентного проекта.

Как выглядел рабочий цикл с Codex CLI #

Самый полезный паттерн из этой сессии:

1. Чёткая постановка задачи #

Каждый шаг формулировался как конкретный результат:

  • «Напиши новую статью про релиз».
  • «Почему статья не видна? Исправь».
  • «Сделай правило, чтобы проблема не повторялась».
  • «Сделай тему поиска в dracula».

Чем конкретнее цель, тем меньше «творческого шума» и выше скорость прохождения задачи.

2. Локальная диагностика перед правкой #

Перед изменением файлов Codex проходил короткий аудит:

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

Пример мышления: если цвета не применились, сначала проверить порядок подключения CSS, а не сразу «добавить ещё !important».

3. Точечная правка + обязательная валидация #

После каждого изменения шёл одинаковый технический минимум:

hugo list future
hugo --minify
git status --short

Это сильно снижает вероятность того, что в main улетит «логически верно, но технически сыро».

4. Фиксация в git маленькими коммитами #

Вместо одного гигантского коммита по итогам сессии:

  • каждый смысловой шаг фиксировался отдельно;
  • сообщения коммитов были предметными;
  • любой этап можно быстро отследить и откатить локально при необходимости.

Для блога это особенно удобно: контент, стили, шаблоны и правила не смешиваются в «одно большое изменение».

Реальные проблемы, которые мы поймали и закрыли #

Проблема 1: пост «не видно на сайте» #

Симптом: статья есть в репозитории, но не отображается в списке публикаций.

Причина: date в фронтматтере оказался в будущем относительно московского времени на момент деплоя.

Решение:

  • сдвиг даты в прошлое;
  • проверка hugo list future;
  • фиксация правила в AGENTS.md: новые посты ставить на 5-10 минут в прошлое и всегда проверять future-список перед коммитом.

Ключевой эффект: проблема устранена один раз на уровне процесса, а не «подкручена вручную» только для одного поста.

Проблема 2: подсветка кода «всё одним цветом» #

Симптом: HTML уже содержит chroma-классы, но визуально код почти монохромный.

Причина: базовый файл подсветки темы был близок к bw-палитре.

Решение:

  1. Включили работу через CSS-классы (noClasses = false).
  2. Добавили собственный assets/css/syntax-highlighting.css.
  3. Сначала проверили monokai, затем переключили на dracula.

Итог: читаемая цветная подсветка с контролируемой темой в репозитории.

Проблема 3: выдача поиска не в стиле сайта #

Симптом: поле и результаты поиска выпадали из общей цветовой схемы.

Причина: стили Pagefind подключались после custom.css, и часть переопределений не применялась.

Решение:

  • сначала добавили CSS-переменные Pagefind в custom.css;
  • затем сделали гарантированное переопределение после pagefind-ui.css прямо в шаблоне layouts/search/single.html.

Это важный вывод: иногда нужно исправлять не «цвета», а точку и порядок их применения.

Проблема 4: у результатов поиска заголовок «Evgeny Kushnarenko» #

Симптом: каждая найденная строка в выдаче имела одинаковый title (имя сайта).

Причина: Pagefind подхватывал h1 из шапки страницы.

Решение:

  • вынесли локальный layouts/partials/header.html и пометили шапку data-pagefind-ignore;
  • добавили data-pagefind-meta="title" на h1 поста в layouts/_default/single.html.

Итог: выдача начала показывать реальные заголовки материалов.

Что это даёт в ежедневной работе #

После такого цикла становится заметно:

  1. Время между идеей и публикацией сокращается.
  2. Ошибки переходят из категории «случайные и повторяющиеся» в «редкие и диагностируемые».
  3. Репозиторий становится документацией процесса, а не просто папкой с контентом.
  4. Снижается когнитивная нагрузка на автора: меньше ручной рутины, больше фокуса на смысле.

На длинной дистанции это важнее, чем «сэкономить 5 минут на одной статье».

Что точно не нужно автоматизировать #

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

Тональность и личный голос. Codex может собрать структурный черновик, но финальный тон — авторская вещь. Если читатель чувствует «это писал не человек», доверие к материалу падает мгновенно. Заменять автора на этом этапе — значит потерять то, ради чего блог вообще существует.

Спорные технические решения. Когда в дизайне есть выбор между двумя одинаково обоснованными подходами (положить компонент в layouts/_default/ или в layouts/posts/, использовать ли Hugo Pipes для CSS или статичную копию), Codex даст «средний разумный вариант». Это не плохо, но это не вы. На длинной дистанции архитектурные решения, принятые «средним способом», накапливают трение, которое в одиночку не разглядеть.

Решения про контент. Что писать, что не писать, какие посты убирать, какие оставлять, как переименовать раздел — это редакционные решения. Они должны проходить через автора. Инструмент здесь полезен только как «помощник по реализации», когда решение уже принято.

Размышления после сессии #

Главный вывод после нескольких часов работы в таком режиме: ценность автоматизации не в скорости, а в предсказуемости. До регулярной работы с Codex CLI каждая публикация поста была чуть-чуть разной: где-то забыл подвинуть дату, где-то не проверил подсветку, где-то не закоммитил отдельно стилевую правку. После — процесс стал ровным, что освободило внимание для содержания.

Это типичная история про инфраструктуру: когда она работает плохо, она занимает 60% мысленного бюджета на каждое действие. Когда хорошо — становится незаметной, и весь бюджет уходит на смысл.

Практический шаблон автоматизации под Hugo #

Если хотите повторить подход, можно взять такой минимум:

  1. Для каждой задачи: цель в 1-2 предложениях.
  2. Перед правкой: чтение текущего состояния (rg, sed, шаблоны, конфиги).
  3. После правки: hugo list future + hugo --minify.
  4. Фиксация: один смысл = один коммит.
  5. Публикация: git push сразу после проверки.
  6. Если баг повторяемый: правило в AGENTS.md, а не «устная договорённость».

Набор команд, который реально работал в этой сессии #

# Проверки контента и даты
hugo list future
hugo --minify

# Диагностика
rg -n "pagefind|highlight|chroma" -S .
sed -n '1,220p' layouts/search/single.html

# Публикация
git add <файлы>
git commit -m "Осмысленный коммит по одной задаче"
git push

Никакой экзотики: сила не в сложных командах, а в дисциплине последовательности.

Практические выводы #

Автоматизация блога через Codex CLI работает лучше всего, когда вы относитесь к ней как к инженерному процессу:

  1. Чёткая постановка задач.
  2. Наблюдаемость и проверки после каждого шага.
  3. Маленькие коммиты с понятной ответственностью.
  4. Фиксация правил в репозитории.

Тогда Codex становится не «генератором текста», а операционным партнёром, который помогает держать качество и темп публикаций одновременно. ✅