Мы отдаём интернет-магазин клиенту как репозиторий, который дорабатывает AI-агент

Есть два способа лишиться контроля над собственным интернет-магазином.

Первый — это арендовать платформу (InSales, OpenCart, Битрикс, конструктор). Вы платите за тариф и приложения, а код, данные и правила здесь не ваши. Второй, менее очевидный — это заказать разработку «под ключ» и получить чёрный ящик, который знает только подрядчик. Формально код ваш, но тронуть его без той же команды нельзя. Лок-ин просто переехал с платформы на агентство.

Мы перевезли собственный магазин (fashion-бренд IWANT) с InSales на свой движок и на этом опыте собрали переиспользуемый пакет переезда. Один из принципов пакета, отдавать клиенту не «сайт», а agent-ready репозиторий: проект, устроенный так, что дорабатывать его можно самому через админку, силами AI-агента по инструкции в репозитории либо через нас. Ниже пишу что за этим стоит и где границы.

Почему «agent-ready» — это не «просто открыть проект в Cursor»

Ярлык «AI-friendly codebase» обычно ничем не подкреплён. Чтобы AI-агент (да и новый живой разработчик) мог безопасно дорабатывать магазин, репозиторий должен обладать несколькими свойствами. Перечислю их на уровне принципа:

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

• Данные и контракты типизированы сквозь весь стек. Ошибка «передал не то поле» ловится компилятором, а не в проде.

• Паттерны предсказуемы и однообразны. Чем ниже разброс, тем меньше шансов сгенерировать «правдоподобно неправильно».

• Есть замкнутый цикл проверки (типы, линт, тесты), по нему агент понимает, что не сломал сборку, и чинит себя сам.

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

Звучит несложно. Но собрать это и, главное, поддерживать в актуальном состоянии — это отдельная работа; без неё «доработка агентом» превращается в рулетку. Клиенту важен результат: репозиторий, в который не страшно пустить агента.

Три режима развития на одной кодовой базе

Одна и та же кодовая база поддерживает три сценария, и клиент выбирает по ситуации, а не навсегда:

• Своими силами. Контент, товары, акции и SEO ведутся через админку без разработчика.

• С AI-агентом. Новые функции добавляются агентом по инструкции в репозитории, без большой команды. Это работает именно потому, что репозиторий к этому подготовлен, а не «просто открыт в редакторе с ИИ».

• Вместе с нами. Если удобнее отдать поддержку и развитие.

Момент про поддержку, который проговариваем заранее: self-serve силами своего агента или разработчиков и платный ретейнер от нас это разные зоны ответственности. Если агент клиента сломал что-то в проде, это не наш SLA. Границу фиксируем на старте, чтобы не было сюрпризов.

Почему это невозможно на платформе

На InSales, OpenCart или Битрикс агенту не за что зацепиться: нет доступа к полному коду, нет типизированной схемы, поведение задаётся чужими настройками и приложениями. Максимум это правки в разрешённых местах шаблона. «Дорабатывать магазин ИИ-агентом» на арендованной платформе технически негде, потому что кодовая база не ваша. Собственный движок это меняет: есть репозиторий — есть чему быть agent-ready.

Как это связано с переездом

Agent-ready репозиторий не отдельная услуга, а следствие того, как устроен наш пакет переезда. Ядро (каталог, чекаут, оплата, доставка, retention-письма, админка) обкатано на IWANT и отдаётся с картой проекта и типами. Сам переезд: перенос данных под конкретную выгрузку платформы, 301-редиректы по аналитике, катаут без остановки продаж (об инженерии миграции будет отдельная статья). На выходе бизнес получает не «сайт под ключ от подрядчика», а актив, который волен развивать как угодно.

Честные оговорки

• Agent-ready не делает разработчика лишним. Сложная доменная логика, интеграции с 1С и CRM, безопасность и деньги — по-прежнему человек.

• Дисциплина стоит усилий: карту проекта, типы и тесты нужно поддерживать, иначе agent-ready деградирует.

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

Мы прошли этот переезд на своём магазине и отдаём клиентам ровно такой репозиторий. Если вы на InSales, Битрикс, OpenCart или конструкторе и хотите магазин, который принадлежит вам и развивается свободно, могу провести бесплатный разбор