Привет. Меня зовут Александр Богданов, я основатель AGIMA. В 2020 мы перезапускали сайт AGIMA: работа заняла два года. В 2026 году мы снова решились на редизайн. Но это не будет скучный текст про то, как мы переделывали логотип 50 раз. Вместо этого я расскажу, как мы полностью отдали управление сайта агентам.

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

Проблема старого сайта была не в самом запуске, а в эксплуатации. Компания менялась быстрее витрины наших продуктов: изменения происходили долго и не устраивали бизнес ни по качеству, ни по срокам. При этом на поддержку ежегодно уходили существенный бюджет — с учётом полной стоимости кросс-функциональной команды: фронтенда, бэкенда, тестирования, дизайна, моушн-дизайна, копирайтинга, менеджмента и SEO. На новом сайте стейкхолдеры участвуют в развитии напрямую: меньше цепочка между задачей и результатом, больше автоматизированных проверок и прозрачных правил.

Кроме того, в этот раз мы взялись за объём, который раньше даже не стали бы планировать: обновить более 800 материалов ( библиотеку за 10 лет) по новой редакционной политике, подготовить их для поиска и ответов ИИ-систем, заново проиллюстрировать, переработать кейсы и услуги, встроить аналитику и открыть управление сайтом бизнес-заказчикам.

Снаружи многие операции теперь начинаются с одного сообщения в Mattermost.

Внутри работают база знаний, скиллы, типизированные инструменты, контроль версий, SecGuard и CI с автоматическим ревью.

Коротко: что изменилось за шесть лет

Почему мы взялись за такой объём работы

На 5 октября 2026 года в контентной платформе было 834 статьи и материала глоссария, 157 кейсов, 41 услуга, 297 событий и 96 страниц сотрудников.

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

Агенты и автоматизация изменили этот алгоритм. Один запрос запускает полноценный производственный процесс:

1. Найти материал и определить его тип.

2. Проверить источник, актуальность и права на публикацию.

3. Очистить текст от служебных блоков и старого оформления.

4. Применить новую редакционную политику.

5. Обновить структуру, метаданные и внутренние связи.

6. Подготовить иллюстрацию по правилам новой дизайн-системы.

7. Провести техническое и смысловое ревью.

8. Сохранить изменение с контролем ревизии.

9. Опубликовать или отправить человеку на проверку.

То есть промпт здесь — интерфейс к платформе, а не ее замена.

Один промпт снаружи, платформа внутри

Мы назвали эту архитектурную обвязку AGIMA SiteOS. Это не один чат и не генератор страниц, а операционная система корпоративного сайта: данные, дизайн, контентный контур, агенты, аналитика, правила публикации и проверки работают как один продукт.

У сайта есть публичный ИИ‑ассистент. В правой колонке он комментирует контент страницы, даёт контекстные подсказки и интерактивные виджеты, а в диалоге позволяет углубиться в тему и задать уточняющие вопросы. Ассистент подключён не только к контент‑хабу, но и к внутренней онтологии и внешним материалам об AGIMA — поэтому он способен объяснить больше, чем помещается на одной странице. Следующий уровень — гиперперсонализация: рекомендации будут учитывать уже просмотренные страницы, действия и источник перехода посетителя.

Каждое изменение проходит проверку типов и правил контента. Агент работает с файловой копией в Git: если исходный SHA устарел, изменение не продвигается поверх нового, а возвращается на пересборку. Перед завершением задачи агент проверяет diff и готовый preview.

Публичный ассистент сайта и внутренний редакторский агент разделены по правам. Внутренний агент готовит изменения в Git и проводит их через проверки. Публичный получает только опубликованный контекст и не имеет инструментов записи: черновики и выпуск в production для него недоступны.

Бизнес больше не передаёт замечания через человека-прокси

В прежней модели руководитель услуги или маркетолог не управлял сайтом напрямую. Он писал замечания менеджеру, менеджер превращал их в задачу, уточнял детали, искал свободного редактора или разработчика и возвращался с результатом через несколько недель или месяцев. Дальше — сбор обратной связи и новый круг.

Теперь бизнес-заказчик работает с сайтом в Mattermost. Он может попросить описать услугу, подготовить лендинг, разработать кейс, написать статью или собрать вакансию. Агент находит нужную сущность, задаёт недостающие вопросы, применяет правила и возвращает ссылку на готовый результат.

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

Мы перестали хранить знания только в регламентах

Регламент полезен, пока человек помнит о нём и применяет к конкретной задаче. Скилл делает профессиональное знание исполняемым: описывает входные данные, порядок работы, критерии качества, блокеры и формат результата.

Например, наш скилл ревью статей оценивает материал по семи критериям: экспертиза и техническая глубина, практическая польза, качество и доверие к фактам, редполитика и ясность, соответствие стратегии компании, оригинальная ценность и SEO/AEO/GEO.

Кроме баллов у проверки есть блокеры. Например, очевидную саморекламу, неподтверждённые факты или несогласованное упоминание клиента нельзя компенсировать хорошим стилем. 

Так редакционная политика перестаёт быть PDF-файлом, который открывают раз в год. Она используется в производстве каждого материала.

Дизайн-система и иллюстрации

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

Сначала мы собрали расширяемую дизайн-систему и сверстали её элементы, а уже потом приступили к страницам сайта. Поэтому агент не выбирает «похожий» стиль и не придумывает интерфейс заново, вместо этого он сверяется с UI-kit, использует разрешённые компоненты, их состояния и правила композиции.

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

Контур выпуска: аналитика, эксперименты и безопасность

Снизить стоимость производства недостаточно. Изменение должно быть измеримым, проверяемым и безопасным. Поэтому PostHog, CI и SecGuard работают как один контур выпуска.

PostHog замкнул контур от релиза до решения

В SiteOS мы встроили систему аналитики PostHog. Product Analytics и Web Analytics показывают, что происходит в воронке, Session Replay помогает увидеть место, где пользователь остановился, а Error Tracking — связать проблему с конкретным сценарием. Данные собираются с первого дня релиза.

Feature Flags и Experiments работают в том же контуре. Агент собирает вариант из компонентов дизайн‑системы и подключает предусмотренные события, а команда задаёт гипотезу, аудиторию и метрику успеха. В результате запуск продукта, его аналитика и эксперименты образуют один цикл производства.

Единый контур контроля для кода и контента

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

Изменения сайта проходят тесты, типизацию и CI. Для ревью безопасности мы разработали SecGuard — подключаемый гейт поверх Semgrep, Gitleaks, Trivy, Checkov и OWASP ZAP, дополненный собственным набором правил для ИИ-кода. Он сводит разноформатный вывод сканеров к единой модели находок, применяет версионируемую политику проекта и возвращает CI однозначный результат: pass или fail.

На merge request SecGuard сравнивает находки с зафиксированным baseline и ограничивает гейт файлами, изменёнными в этом MR. На основной ветке отдельный прогон собирает полную картину по коду, секретам, зависимостям и инфраструктурным конфигурациям. Он ничего не блокирует: его задача — вести учёт, а не останавливать релиз. Туда же относятся SBOM в формате CycloneDX с подписью cosign.

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

LLM-триаж не принимает решений. Он может пометить вероятное ложное срабатывание и снизить шум, но вердикт считает детерминированный движок по порогам из secguard.yml.

Пару слов про вайбкодинг

Claude Code или другой ИИ-harness может быстро собрать первый экран. Но он не создаёт сам по себе проверяемые данные, права доступа, редакционные правила, контракты виджетов, историю ревизий, аналитику, тесты и устойчивый процесс изменений. Именно для всего этого и нужна SiteOS — ограниченная, наблюдаемая и тестируемая платформа. Генеративная модель работает внутри неё и обеспечивает скорость, пока SiteOS поддерживает стабильность сайта. 

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

Основа платформы — Git-репозиторий с типизированным набором компонентов. Статьи, кейсы, услуги и страницы хранятся как версионируемые файлы, а Astro собирает из них статический выпуск по правилам дизайн-системы.

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

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

После проверок pipeline собирает неизменяемый release candidate, связанный с SHA коммита, и показывает его на preview. Если бизнес подтверждает результат, на production продвигается тот же артефакт — без повторной сборки. Если за время согласования появился новый коммит, старое подтверждение не сработает.

Рабочая агентская платформа требует первоначальных вложений:

• собрать контекст компании;

• разработать дизайн-концепцию и дизайн-систему;

• определить разрешённые компоненты;

• описать роли и права;

• формализовать скиллы специалистов;

• построить типизированные инструменты;

• настроить ревизии, аудит и откат;

• подключить CI и безопасность;

• определить события аналитики;

• создать наборы проверок и эталонных примеров.

Это дороже одного лендинга и сложнее большого промпта. Зато каждый новый материал использует готовый фундамент, а каждый новый скилл увеличивает возможности всей системы.

Как меняется экономика сайта

В проектной модели стоимость растёт вместе с числом изменений. Нужен новый лендинг — запускаем новый мини-проект. Нужны десять экспериментов — десять раз занимаем дизайнеров, разработчиков и тестировщиков.

В платформенной модели значительная часть затрат переносится в начало: дизайн-система, контекст, инструменты, безопасность и правила качества. После этого каждое повторяемое изменение требует меньше ручной работы.

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

• большой контентный хвост;

• регулярные кампании и спецпроекты;

• несколько бизнес-заказчиков;

• повторяемые страницы и компоненты;

• постоянные эксперименты;

• требования к аудиту, правам и безопасности;

• знания, которые важно не привязывать к одному сотруднику.

Вместо вывода

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

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

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

Подписывайтесь на канал моего товарища и ИИ-амбассадора — СТО AGIMA, Андрея Непряхина