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