Разработчик сделал интернет-магазин с реал-тайм интеграцией 1С, которую агентства обычно продают как отдельный дорогой проект. Ему помог Claude Code и три жёстких правила

Спроси любого разработчика в России, как сделать сайт, синхронизированный с 1С, и услышишь один и тот же совет: возьми Битрикс. Штатный модуль обмена, коробочные тарифы, армия интеграторов, которые уже умеют это ставить и на этом зарабатывать. Совет звучит одинаково каждый год, хотя ситуация клиента чаще всего одна и та же: небольшой магазин, ограниченный бюджет, дизайн, который нужен точь-в-точь, а не «примерно похоже».

19 июля 2026 года в прод ушёл магазин, который обошёл это правило целиком. Заказчик, бренд женской одежды из Екатеринбурга, получил интернет-магазин на WordPress с реал-тайм обменом с 1С, кастомной блочной темой, повторяющей React-прототип пиксель в пиксель, и полным набором того, что обычно называют «взрослым магазином»: вариативные товары, платежи, доставка, комплаенс по 152-ФЗ. Сделал это один разработчик. Я. Не агентство, не битрикс-интегратор по профессии, просто человек с open-source стеком и AI-агентом вместо команды.

Большую часть кода писал не я. Писал Claude Code, агент Anthropic, а я проектировал архитектуру, ставил задачи и проверял результат. Работы от этого меньше не стало, скорее наоборот: вместо набора текста весь день превратился в решения и ревью, а это, как выяснилось, устаёт по-другому.

С деньгами всё просто. Лицензия «1С-Битрикс: Малый бизнес», ежегодные продления, работа интегратора: в сумме бюджет, сопоставимый со всей разработкой на open source. Для одной розничной точки такие траты тяжело оправдать чем угодно, кроме привычки.

С дизайном сложнее. У заказчика уже был готовый React-прототип в эстетике quiet luxury: четыре цвета в палитре, Lora и Raleway, нулевые радиусы, воздушная сетка. Натянуть это на коробочную тему можно, но выйдет дольше, чем написать свою тему с нуля, и результат всё равно будет «примерно похоже», а не точной копией.

При этом ни один пункт из списка требований никуда не делся из-за маленького бюджета: реал-тайм остатки из 1С (у одежды каждый размер и цвет свой сток), приём платежей с картами и СБП, доставка, cookie-баннер и согласия по 152-ФЗ, ecommerce-разметка для аналитики. Полный список требований взрослого магазина, при бюджете, который такой список обычно не потянет.

Первое: файл правил, который агент читает каждую сессию. У Claude Code есть CLAUDE.md, файл инструкций проекта. Я вынес туда всю дизайн-систему в виде прямых запретов, без «постарайся»: палитра ровно из четырёх цветов, сырые hex-коды запрещены, радиус ноль, отступы только из 8px-шкалы. Без такого файла LLM с удовольствием импровизирует, и именно эта импровизация убивает жёсткую дизайн-систему за пару итераций. С правилом агент не подбирает оттенок на глаз, он выводит его через функцию `oklch()` от существующего токена, потому что файл прямо говорит: другого пути нет.

Второе: память между сессиями. Контекст агента конечен, а проект шёл месяцами, и каждый реальный урок («в WooCommerce Blocks не грузится jQuery», «дельта-выгрузки 1С тихо стирают вариации товаров») уходил в markdown-файл, который агент перечитывает на следующем запуске. Новая сессия начинается не с нуля, а с конспекта всех прошлых граблей.

Третье, и это правило я бы отстаивал жёстче всего: проверка в браузере, а не на глаз. У агента есть доступ к Playwright через MCP, он сам открывает страницу, кликает по реальному сценарию, снимает скриншот и сравнивает с прототипом. Правило простое: вывод «баг починен» не принимается без живой проверки. Оно окупилось на истории с карточками товаров: клики по ссылкам не работали только на десктопе и только на проде, довольно неприятное сочетание «только». Агент воспроизвёл баг реальным кликом через Playwright и нашёл причину: `setPointerCapture` в карусели перехватывал pointer-события и ретаргетил клик со ссылки на трек карусели под ней. По коду карусели это было не видно вообще, он выглядел абсолютно корректным.

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

Самая дорогая по времени часть проекта, и та, где проверка человеком была нужна больше всего.

Обмен построен на CommerceML: 1С выгружает XML-пакеты по расписанию и по событию, плагин на стороне WordPress их разбирает и обновляет каталог. На витрине висели неверные остатки, хотя обмен отрабатывал без единой ошибки. Причина нашлась только диффом сырого XML с тем, что реально доехало до базы: парсер плагина ждал плоский `<Количество>` уровнем выше и молча пропускал вложенную структуру, в которой на самом деле приходили остатки, разбитые по складам. Ошибок нет нигде в цепочке, обмен рапортует об успехе, данные просто неверные. С тех пор я диффаю код плагина перед каждым обновлением, потому что следующий релиз может тихо вернуть старое поведение без единой строчки в changelog.

Ещё две проблемы всплыли почти рядом. Свойства номенклатуры и характеристики вариаций в CommerceML это два независимых механизма с разными путями обработки в плагине, поэтому цвет как свойство и размер как характеристика приезжают в WooCommerce по совершенно разной логике. А быстрый обмен шлёт дельта-чанки вместо полного каталога, и плагин на каждый чанк пересоздавал набор вариаций товара целиком, из-за чего вариации, не попавшие в чанк, просто исчезали. Размерная сетка потихоньку пустела, и, если честно, подозреваю, что заметил это раньше меня заказчик, а не мониторинг. За время отладки в базе накопилась почти тысяча вариаций-сирот, пока не нашли и не поправили режим сохранения при частичных выгрузках.

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

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

Подходит малому и среднему магазину: кастомный дизайн, учёт в 1С без глубокого ERP-контура, бюджет, который реально ограничивает выбор платформы, разработчик, готовый читать XML обмена, а не только ставить плагины через админку. Не подходит высоконагруженному маркетплейсу с тысячами заказов в день, резервированию по складам в реальном времени или заказчику, которому по процедуре закупки нужна вендорская поддержка на бумаге. Там коробка или другой стек оправдывают свою цену.

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

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

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

Я делаю такие проекты: интернет-магазины и внутренние инструменты на open-source стеке, в паре с AI-агентами, чтобы уложиться в бюджет, который студия за похожие деньги не потянет. Пишу об этом на butakov.dev Если у вас похожая задача, сайт с интеграцией 1С, бюджет, который не тянет коробочное решение, или просто хочется обсудить, где вайб-кодинг реально экономит деньги, а где нет, пишите в мессенджер или на почту.