Почему 9 правил, а не «попробуйте»
С декабря 2025-го я веду собственный VPS почти полностью через Claude Code. Это почтовый стек, WordPress, nginx, бэкап по таймеру, интеграции, контент. За шесть месяцев и несколько сотен коммитов я выработал девять правил, без которых AI-кодер ломает чаще, чем чинит.
Эта запись для CIO или техлида, который думает внедрить Claude Code или его аналоги. Каждое правило выросло из реального инцидента на моём сервере, у каждого есть точка в моём CLAUDE.md (около 800 строк правил для AI-ассистента) и понятная стоимость, если правило не работает. Как этот подход переносится на команду, я разбираю отдельно в конце. Там я честно отделяю прожитое от прогноза.
Контекст. Что я делаю на собственном VPS
VPS у Timeweb, Debian 13, multi-tenant. На нём почта и веб нескольких живых боевых проектов, собственных и клиентских. Я веду этот сервер сам как раз для того, чтобы не терять руки на инфраструктуре и иметь живой полигон для обкатки AI-кодинга в боевом режиме.
Стек: Postfix 3.7, Dovecot 2.4, Rspamd, MariaDB 11.8, nginx 1.28, PHP 8.4-FPM, Valkey 8, WordPress + WP Super Cache. Всё под Let's Encrypt. Бэкап ежедневный через собственный shell-скрипт по таймеру systemd. Claude Code работает с правами моего пользователя на ноутбуке + SSH-ключ на root@server.
Этого контекста достаточно, чтобы понять, почему правила выглядят именно так. Каждое из них родилось из конкретного инцидента или близкого попадания. Я не пишу абстрактных «лучших практик». У меня под рукой история всех коммитов и журнал, в какой день какое правило родилось.
Правило 1. Явное «ок» владельца перед WRITE на проде
Любая команда, которая меняет состояние production (конфиг, БД, файл сайта, пакеты, перезапуск сервиса), не выполняется без явного подтверждения. Не «мы это уже обсуждали выше», не «по логике плана это следующий шаг», а отдельный вопрос «делаю?» и ответ «делай» на каждый WRITE-шаг.
Это не про AI, это про процесс. AI-ассистент просто заставляет правило проявиться острее. Когда инженер сидит в SSH, он сам себе и автор плана, и исполнитель. Гейт может пропустить незаметно. AI-кодер всегда работает с человеком в петле, и гейт получает явную форму.
Правило 2. Read-only сначала, действие потом
Перед любым WRITE-шагом AI обязан сделать разведку. Прочитать текущий конфиг (cat / nginx -T), посмотреть статус сервиса (systemctl status), проверить состояние пакетов (dpkg -l), снять журнал (journalctl --since "5 min ago"). Только после этого идёт план изменений в чате, мой «ок» и затем правка.
Это убирает целый класс ошибок «изменил конфиг, не зная, что в нём уже есть». На своём VPS я начинал каждую сессию с того, что забывал, что Дима из прошлой сессии оставил в /etc/nginx/. AI с read-only-первичным шагом восстанавливает контекст за 30 секунд, не лезет править вслепую. Дешевле правила нет. Read-only-команды бесплатны по риску, разведка стоит AI секунды. А пропуск шага стоит иногда часов восстановления.
Правило 3. apt purge только с --dry-run и снапшотом
На 24 апреля 2026 я выполнил apt purge dovecot-sieve dovecot-managesieved в 02:48 ночи. APT по транзитивным зависимостям удалил dovecot-core, dovecot-imapd, dovecot-lmtpd и обнулил /etc/dovecot/dovecot.conf. Почта легла на 12 минут. Восстановил из бэкапа в 03:00.
После этого инцидента в CLAUDE.md появился обязательный протокол из трёх шагов перед любым apt purge или apt remove. Шаг 1, это apt-get purge --dry-run и проверка списка REMOVED. Если apt тянет что-то с суффиксом -core или -common, тут стоп, ищем другой способ. Шаг 2, это tar-снапшот всех conffiles затронутых пакетов в /root/backups/. Шаг 3, это собственно purge и сразу smoke test критичной функции.
С тех пор AI-ассистент не запускает apt purge без всех трёх шагов. Я разобрал инцидент целиком в отдельной записи с хронологией по минутам и полным RCA.
Правило 4. Git commit с RCA после каждого фикса
Каждая завершённая правка фиксируется коммитом немедленно. Не «потом одним большим коммитом», не «когда закончу серию», а сразу после verify. Сообщение коммита включает причину (зачем фикс), что именно изменилось (до → после), как проверено (curl-output, wp-cli, sitemap lastmod), технические детали (backup path, syntax check), что осталось в техдолге.
Это меняет психологию работы с AI. Когда коммит идёт каждые 15–30 минут, AI и я держим в голове только текущий шаг. Сорвалось, откатился на предыдущий чистый коммит. Получилось, движемся дальше с чистого листа. Это та самая разница между мелким git workflow и big-bang-коммитом из 40 файлов «вечером в пятницу».
В корпоративной команде правило усиливается ещё больше, потому что коммит работает ещё и каналом общения с ревьюером. RCA в сообщении коммита даёт пол-страницы описания запроса на слияние, которую не надо писать отдельно.
Правило 5. БД сервера как единственный источник правды
Перед правкой контента в WordPress (post, page, CPT, мета, опции) AI делает обязательный снапшот текущего состояния из БД сервера. Не из локального файла, который остался от прошлой сессии. Не из git-репозитория с предыдущей версией. Из живой БД сейчас.
Правило сводится к одной команде. wp post get <ID> --field=post_content в начале каждой сессии редактирования контента. Если файл из прошлой сессии и БД-снапшот не совпадают по MD5, работаем с БД, не с файлом.
Правило 6. sitemap + transients после правки контента
После любой правки поста, страницы, CPT или шаблона темы, который меняет публичный вид страницы, AI обязан выполнить три шага. Сбросить transients (wp transient delete --all), проверить, что post_modified обновился (если правка через wp db query, обновить вручную), убедиться, что lastmod в sitemap совпадает с post_modified.
Yoast SEO генерирует lastmod в sitemap из поля post_modified. Google использует lastmod для решения о повторной индексации. Если post_modified не обновился, поисковики не узнают об изменении, и правка фактически невидима.
На моём VPS лежит ещё и WP Super Cache (статические HTML) + Valkey object cache. Поэтому к шагам выше добавляется ручной DEL ключей по ID поста в Valkey. Иначе path-hashed query keys остаются stale до 7 суток. Это правило подняли после конкретного инцидента 4 мая, когда правка поста 808 не отразилась на сайте из-за stale Redis-ключей.
Правило 7. Диагностика 30–60 секунд до отката
При обнаружении проблемы сначала идёт диагностика, не откат рефлекторно. AI должен за 30–60 секунд собрать картину: systemctl status <service>, journalctl -u <service> --since "5 min ago" | tail -50, nginx -t, php -l, tail логов, curl на проблемный URL. Понять причину, а не симптом.
Если причина понятна и фикс дешёвый (одно слово в конфиге, одна команда, перезапуск сервиса), чиним на месте. 'self' в frame-src CSP, восстановить пароль Valkey из wp-config.php, добавить недостающее extension. Это секунды. А откат на бэкап стоит минимум минуты плюс повторный прогон всех операций после.
Откат остаётся как последнее средство. Catastrophic data corruption, повреждённая БД, диск в read-only, тут да, откатываем. А простое 500 на сайте после правки почти всегда быстрее разобрать и починить.
Правило 8. Browser Console первым, бэкенд потом
Когда жалоба звучит «в UI не работает», AI должен начать с Console и Network в браузере, а не с PHP / nginx / Postfix. Через Playwright или Chrome MCP за 10 секунд видна CSP-violation, CORS, 404 на ассет, JS-exception. Эти ошибки часто не доходят до бэкенда, режутся на уровне браузера.
Правило 9. Документация продукта до настройки
Перед любой настройкой нового продукта или major-апгрейдом существующего AI обязан открыть официальную документацию актуальной версии. Проверить текущий синтаксис параметров, breaking changes против предыдущей major, deprecated-опции, best-practices для нашего use case. Только потом идёт правка конфига.
В CLAUDE.md теперь жёсткое правило. Для SPA-документации использовать Chrome MCP с JS-render и явным extract main article, не curl, который вернёт 1–3 КБ HTML-shell. Для plain HTML и man pages берём curl. Для open-source берём GitHub raw markdown как primary source.
Сводная таблица. Правило и ущерб без него
| Правило | Что ломается без правила | Случай-триггер |
|---|---|---|
| 1. Явное «ок» на WRITE | Самодеятельные правки. Поисковик ловит, что страница на 30 секунд была публичной. | 28 апреля, переключение draft → publish без «ок». |
| 2. Read-only сначала | Правка вслепую поверх чужих изменений. Конфликты, потеря данных. | Регулярно при возврате к серверу после паузы. |
| 3. apt purge с --dry-run | Транзитивные зависимости сносят -core пакеты. Минуты-часы простоя. | 24 апреля, почта 12 минут down. |
| 4. Git commit после каждого фикса | Невозможно откатиться точечно. RCA восстанавливается через неделю-две. | Жёсткое правило в CLAUDE.md: «движение — запись». |
| 5. БД как источник правды | Откат правок поверх чужих правок через панель управления. Потеря работы. | 19 мая, сверка фактов на устаревшем v2-файле. |
| 6. sitemap + transients | Правка контента не видна Google. Stale Redis-кэш до 7 суток. | 4 мая, пост 808 не индексируется после правки. |
| 7. Диагностика до отката | Откат там, где хватало одной команды. Потеря работы после отката. | 16 мая, на апгрейде ОС. |
| 8. Browser Console первым | Часы гипотез на бэкенде, когда ошибка живёт в браузере. | 24 апреля, два часа на Roundcube smtp при CSP-violation. |
| 9. Документация до настройки | Workaround вместо штатной фичи. Время впустую. | 17 мая, ложный вывод про deprecated local_name в Dovecot 2.4. |
Сколько на самом деле сохраняет
На рутинной операционке, по моей субъективной оценке, выходит 2–3 часа в день. Это типовые задачи: техдолг по конфигам, мелкая разработка темы WordPress, обновление контента, проверка логов, ответы на однотипные обращения. AI снимает рутинную часть, я делаю проверку и одобрение. По грубой прикидке на моих задачах темп раза в два выше, чем без AI. Секундомер я при этом не держал.
На сложном фиксе теряю, если правила не работают. Цепочка гипотез AI без read-only-первичного шага и без браузерной диагностики ведёт в тупик за 30–40 минут. Откат состояния и ручная починка добавляют ещё 30–40 минут. Сложный фикс с правилами по ощущению занимает 20–30 минут от первого симптома до зелёного smoke test.
Как я переношу это на команду 3–10 инженеров
Базовый принцип переноса один. Это общий CLAUDE.md в корне репозитория. Каждый инженер запускает AI-кодер с правами, которые ему доступны по обычному RBAC, и получает в подгрузке те же правила. Это та же механика, что работает у меня, просто файл правил становится общим, а инцидентов, которые его наполняют, больше.
По моему прогнозу первые два-три месяца уйдут на сбор первоначального CLAUDE.md. Команда работает с AI, ловит свои инциденты, формулирует правила. Дальше файл выходит на плато, по порядку величин это сотни строк, не тысячи, и закрывает большую часть типичных рисков. Потом наступает спокойный режим, где новые правила добавляются изредка, по факту новых инцидентов. У меня на одиночке кривая выглядела именно так. На команде жду ту же форму, только более пологую. Людей больше, граблей тоже.
От экономии я жду не «сократите инженеров», а высвобождение мощности на работу, до которой обычно не доходят руки: рефакторинг, тесты, инфраструктура разработки. Назвать точную цифру в FTE я не могу. За плечами нет командного замера, на который можно сослаться. По ощущению от того, как правила экономят время мне одному, эффект на команде должен быть заметным, но проверять его надо на конкретном пилоте, а не верить моей экстраполяции.
Зачем читал
Если вы CIO или техлид и думаете внедрить AI-кодер в команду, запишитесь на 30-минутный первый созвон через форму контакта. На созвоне отдам полный текст моего CLAUDE.md (около 800 строк) как точку старта. Без подписки, без условий. Дальше обсудим, на каком репозитории начать пилот и как организовать первые два месяца с командой.
По смежным темам у меня есть запись про сдвиги в роли CIO к 2027 году. Там MCP, ИИ-агенты с SLA, 152-ФЗ и 187-ФЗ. Есть и конкретный RCA-кейс с моего VPS, 12 минут даунтайма почты после apt purge. Он сформировал правило номер три из этого списка.
Я работаю с этим напрямую — ознакомительный звонок 30 минут
Расскажете ситуацию — отвечу за 4 часа в рабочее время. Звонок бесплатный, без обязательств. Если задача не моя — порекомендую коллег, у которых она хорошо ляжет.