Есть два способа лишиться контроля над собственным интернет-магазином.
Первый - это арендовать платформу (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 или конструкторе и хотите магазин, который принадлежит вам и развивается свободно, могу провести бесплатный разбор
Комментарии (8)
Spyman
16.07.2026 16:29Идея интересная, но ниша вызывает сомнения. Помню я разрабатывал сервис для супер маленького заказчика, и даже он на фразе - ну вот тут можно открыть базу данных (в вебе как таблицу) открыть и редактировать данные - панически выдал, нет - делаем админку, я тут сам все сломаю.
А когда речь о магазине (т.е. публичные оферты, прямые денежные отношения) - я слабо представляю себе заказчика, которому нужно решение для доработки своими неприспособленными руками (разве что это прямо микро ИП или уже it компания), и куда более вижу такого, для которого именно поддержка и стабильность сервиса представляют большую часть ценности. Взяв тот-же битрикс с поддержкой - вы снимаете со своей головы все риски и платите за это деньги, взяв какой-то движок пусть и дружественный для агентов но предоставляемый малоизвестным вендором - вы получаете точно такой-же (и даже больший) ведор-lock, или как альтернатива - возможность прострелить себе колено.
yakov_etern8 Автор
16.07.2026 16:29Отличный комментарий, спасибо.
Про «заказчик не хочет копаться руками», соглашусь полностью. Большинству владельцев магазинов это не нужно, и мы это не продаём. Три режима (сами / агентом / мы) - это не «разрабатывай сам или никак», а страховка от лок-ина, а не обязанность. Дефолт для большинства как раз «через нас» на поддержке плюс админка для контента. Ваш пример с «открыть таблицу в БД» ровно поэтому в ядре есть админка: руками в базу никто не лезет, для этого и сделан интерфейс.
Теперь ключевое про вендор-лок, тут поспорю аккуратно. Лок-ин определяется не известностью вендора, а двумя вещами: у вас ли код с данными и насколько ходовой стек. Битрикс: код у вас есть, но он битриксовый, вы завязаны на саму платформу, её специалистов и цикл обновлений/лицензий. Пул большой, согласен, но это лок именно в Битрикс: уйти с него = переписать.
А «вендор» в нашем случае (мы) как раз не является замком потому что стек боринг-стандартный: Next.js, TypeScript, PostgreSQL. Если ETERN8 завтра исчезнет, проект подхватит любой Next.js-разработчик или агентство, ровно как любое другое приложение на этом стеке. Это меньше привязки, чем платформенное решение, а не больше. Вы были бы правы, если бы мы отдавали проприетарный фреймворк собственного изобретения, но мы сознательно этого не делаем, в этом и смысл.
«Прострелить колено»... честно, да: с полным доступом к коду сломать можно. Поэтому не-технари работают через админку (в прод не залезешь), а путь «сам/агент» - он опциональный и с оговорёнными границами (оплату, миграции, катаут руками не трогаем). Большинство просто берёт поддержку у нас. Это ваш тезис про стабильность, и он справедлив.
Итог: кому важнее всего готовая стабильность «под ключ» - Битрикс с поддержкой рабочий выбор, не спорю. Наш подход для тех, кого лок-ин уже кусал или кто не хочет зависеть от одного поставщика. Ниша не «все подряд» - тут вы правы, и это нормально.
Zivaka
Все написанное в статье по большей степени касается InSales, так как это saas сервис, а OpenCart и Битрикс это не арендуемые платформы и возможностей для развития там куда больше и они обойдутся дешевле в перпективе, чем неизвестный движок какой-то студии.
yakov_etern8 Автор
Справедливо про аренду. Соглашусь частично. Чистая «аренда», где платишь, но ничем не владеешь - это про SaaS и конструкторы: InSales, Tilda. OpenCart (open-source) и Битрикс (лицензия) по форме сюда не попадают, тут вы правы, в статье я смешал их слишком широко.
Но тезис не столько «аренда против владения», сколько зависимость и реальная возможность развивать. И это к OpenCart/Битрикс тоже применимо: даже когда код формально ваш, монолит на Битрикс или магазин на OpenCart с десятком ocmod-правок редко получается спокойно передать другому разработчику, а ИИ-агенту тем более. «Больше возможностей для развития» у них чаще «больше готового из коробки», а не простота кастомной доработки: связанность, легаси, конфликты расширений.
Про «неизвестный движок какой-то студии» тут как раз наоборот, и это ключевое. Мы не отдаём проприетарный чёрный ящик с завязкой на нас. Стек максимально ходовой: Next.js, TypeScript, PostgreSQL. А репозиторий с кодом и данными уходит клиенту. Любой Next.js-разработчик продолжит с ним без нашего участия. Это и есть анти-лок-ин, ради которого всё и затевалось: не «наш движок», а ваш проект на общеизвестном стеке.
По «дешевле в перспективе» - это зависит от случая. У Битрикс лицензия и продления, у OpenCart бесплатное ядро, но платные модули и поддержка. Универсального ответа нет, надо считать под конкретный магазин. И да, если коробки хватает и оборот небольшой, свой движок не окупится; про это в статье есть отдельный блок «кому не нужно».
Zivaka
Никакой проблемы нет с Битриксом и другими популярными cms, если код написано корректно - документации хватает, разработчики тоже доступны. И да, многие задачи можно решить готовыми модулями, которые будут стоить кратно дешевле, чем делать аналогичное с нуля.
Магазин не заканчивается на моменте, когда вы его выкатили и передали клиенту. Работа интернет-магазина - это всегда процесс разработки, без исключений по сути. А вот поддержка "кота в мешке" после вмешательства клода или кого-то еще без особого понимания - в таком ковыряться уже мало кто захочет и поиск исполнителя будет сложнее.
Ну и по лицензии Битрикса и стоимости модулей - это высосано из пальца)
yakov_etern8 Автор
Тут во многом соглашусь, и это не противоречит статье.
Битрикс при грамотном коде правда поддерживаемый, разработчиков на рынке много, готовые модули для типовых задач часто дешевле кастома. Не спорю. И «магазин не заканчивается на передаче, это всегда процесс разработки» - согласен полностью, статья ровно об этом: как отдать проект, чтобы процесс можно было продолжать, не будучи привязанным к одному исполнителю.
Главное здесь про «кота в мешке» после ИИ. Вы описываете ровно то, против чего статья. «Клод поковырялся без понимания» и «agent-ready репозиторий» - это противоположности. Кот в мешке получается, когда агента пускают в проект без типов, тестов и структуры. Смысл подхода в том, чтобы код оставался обычным и читаемым, покрытым проверками, на ходовом стеке (Next.js/TS/PostgreSQL) который ищется на общем рынке, а не только среди тех, кто знает именно этот проект. Если после доработки получилась нечитаемая каша, то это уже провал дисциплины, а не «ИИ виноват».
Про лицензию и модули. Это не из пальца: у коммерческих редакций Битрикса есть стоимость лицензии и продления, платные модули на Маркетплейсе тоже деньги. Не утверждаю, что это дорого-плохо, просто это честная статья расходов, которую стоит класть в TCO рядом со своим движком. Что перевесит - считается под конкретный проект.
Zivaka
То что вы пишете - это на словах красиво, так как чисто маркетинг. Вы это описываете, как будто любой с Клодом сможет развивать это и все будет хорошо. Но после 4-5 итераций правок не будет ничего хорошего и нормальный разработчик не очень захочет в этом куске кода копаться, будем честны.
По лицензиям - их можно не оплачивать каждый год, ужасного ничего не случится, точно вам говорю)
yakov_etern8 Автор
Справедливо, и спасибо, что дожимаете.
Про деградацию после нескольких итераций. Согласен, риск реальный, и «любой с Клодом, и всё будет хорошо» я как раз не утверждаю. В статье это есть в блоке оговорок: агент снимает рутину, но ревью, тесты и живой разработчик никуда не деваются, а сложную логику и деньги трогает человек. Без дисциплины код скатывается в кашу, тут спорить не с чем. Поэтому обещаю не «магию», а обычный читаемый репозиторий на ходовом стеке как отправную точку; дальше всё решает то, как с ним обращаться.
Про лицензии принято, продлевать не обязательно, сайт работает и без этого (теряешь обновления, поддержку и часть маркетплейса). Согласен, «обязательные ежегодные», перегнул, спасибо за поправку.
По делу поговорили. Многое тут и правда считается под конкретный проект, а не общими словами. На том и сойдёмся.