Как я разрабатываю с ИИ-агентом: опыт этого сайта и Zyvra CMS

Этот сайт и Zyvra CMS, на которой он работает, я делаю вместе с ИИ-агентом Claude Code. Это не автодополнение в редакторе: агент работает в терминале с моими репозиториями, читает код, запускает тесты, делает коммиты и выкладывает изменения на сервер — по моим задачам и в рамках моих правил.

Первый коммит CMS появился 8 октября, а 12 октября на ней уже работал этот сайт. С тех пор добавились формы с файлами и письмами, блог, услуги и заголовки безопасности. В двух репозиториях сейчас около 470 автотестов. Ниже — как это устроено и что я понял по ходу.

Кто что делает

Я ставлю задачу и решаю, что считать готовым. Выбираю архитектуру и стек, принимаю решения, у которых есть цена: что публиковать, какие данные хранить, кого куда пускать. Смотрю диффы и проверяю результат в браузере.

Агент пишет код, тесты и документацию, гоняет проверки, читает логи и чужой код. Когда понадобилось открывать ответ на заявку в веб-почте SOGo, он не стал гадать: прочитал JavaScript самой SOGo и нашёл адрес, по которому она открывает новое письмо.

Правила вместо промптов

Хорошие результаты дают не удачные формулировки, а постоянные правила. У меня это файл инструкций, который агент читает в начале каждой сессии:

• сначала подумать и назвать допущения, а при неясности — спросить;

• минимум кода под задачу, ничего «на будущее»;

• менять только то, что относится к задаче, и подчищать за собой;

• превращать задачу в проверяемую цель: «исправить баг» — значит «написать тест, который его воспроизводит, и сделать его зелёным».

Там же стиль: БЭМ в SCSS, цвета только через переменные, коммиты в формате Conventional Commits. Решения по проекту агент записывает в свою память: например, что кейсы клиентов публикуются анонимно — без названий в текстах и с размытыми логотипами на скриншотах. Через неделю правило применяется само, без напоминаний.

«Готово» — значит проверено

Агент охотно говорит «сделано». Поэтому готовым считается только то, что прошло проверки: типы, линтер, unit-, интеграционные и e2e-тесты, а для интерфейса — скриншоты из настоящего браузера. Агент не видит страницу, пока не снимет её через Playwright, и это правило ловит много ошибок.

Пример: когда я добавил сайту Content Security Policy, упали e2e-тесты. Стандартная страница ошибки Nuxt вставляла встроенный скрипт, и политика его блокировала. Ослаблять политику не стали — у сайта появилась своя страница 404. Без теста, который падает на любой ошибке в консоли, это нашли бы посетители.

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

Как выглядит одна задача

Недавний пример — кнопка «Ответить» в карточке заявки: она должна была открывать веб-почту, а не почтовую программу.

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

2. Нашёл в коде SOGo формат ссылки на новое письмо.

3. Добавил миграцию, схему, поле в админке, тесты всех уровней и обновил документацию.

4. Проверил всё в браузере, закоммитил и выложил на сервер, сделав перед миграцией резервную копию базы.

С моей стороны — постановка задачи и проверка результата.

Где агент ошибается

• Угадывает вместо того, чтобы прочитать. Название поля в ответе API, версия записи, путь к файлу — первая догадка часто неверна. Лечится требованием сначала заглянуть в код или документацию.

• Делает выводы по неполному поиску. Однажды агент сказал, что успешная отправка формы не попадает в аналитику. Она попадала: искал он umami.track, а в коде стояло umami?.track.

• Не знает окружения. Письма из CMS не уходили, хотя тесты были зелёными: библиотека отправки ищет адрес сервера через DNS и не читает /etc/hosts. Нашли по логам на сервере, исправили настройкой имени для TLS.

• Ошибается в мелочах оболочки. Команда pkill -f однажды завершила ту самую оболочку, из которой её запустили.

Все эти ошибки ловятся одинаково: проверкой, а не верой.

Что остаётся за мной

• Доступы и секреты. Пароли не попадают ни в чат, ни в историю команд: агент передаёт их через файлы с правами 600 или через stdin.

• Продакшен. Запись в боевую базу, sudo, публикация — только с моего явного разрешения. Когда сайт упал из-за маршрутизации на домашнем сервере, агент нашёл причину, но команду с sudo выполнил я.

• Решения с последствиями. Цены, тексты о клиентах, что публиковать, а что нет. Агент предлагает варианты и предупреждает о рисках, выбираю я.

Итог

ИИ-агент не заменяет разработчика, но меняет его работу: меньше набора кода, больше постановки задач, архитектуры и ревью. Скорость появляется, когда у агента есть правила, тесты и обязанность проверять результат. Без этого он так же быстро делает неправильные вещи.

Как устроена сама CMS — в кейсе Zyvra CMS. А если хотите так же быстро запустить свой сайт или кабинет — напишите мне.