Статьи про архитектуру, headless e-commerce и практичную продуктовую разработку.
Инвалидация кэша Bitrix через cron-polling — стандартное решение, которое работает. Пока не начинаешь считать. Это история про то, как MySQL binlog закрыл вопрос сам по себе.
Я написал статью про то, почему Elasticsearch — это UX-инструмент, а не просто скорость. С тех пор три клиента спросили одно и то же.
Я не устал от AI. Я перестал с ним разговаривать.
У нас один PHP-бэкенд. Два Next.js-фронтенда. Два домена. Два бренда.
Мне звонят, когда уже горит. Разработчик исчез. Дедлайн завтра. «Немного допилить» превратилось в «мы вообще не понимаем, что происходит».
Мы подключили Cloudflare к Bitrix-магазину в четверг вечером. В пятницу утром пошли жалобы: «корзина пустая, хотя добавлял». К субботе — «личный кабинет показывает чужие данные».
Нам предложили добавить vector search к каталогу. 40 000 SKU, Elasticsearch уже стоит. Fuzzy настроен. Синонимы работают. Function_score буст по марже и остаткам — тоже.
Microsoft отозвала корпоративные лицензии Claude Code у тысяч своих разработчиков. Один тикет в IT-отдел — и инструмент, на котором человек выстроил свой рабочий процесс, перестал открываться в понедельник утром.
Я дал Claude Code задачу: рефакторинг PHP-модуля синхронизации Bitrix с 1С. Прописал в начале: строгая типизация, никаких mixed, никаких глобальных переменных, все методы через dependency injection.
Каталог мы отдали в Next.js за девять дней. Корзину интегрировали за месяц. Оформление заказа — ещё семь недель.
Я понял, что что-то изменилось, когда перестал думать «сколько стоит моя работа» и начал думать «сколько стоит моя работа для этого бизнеса».
Мой коллега потратил три дня, чтобы поднять GitHub Copilot для команды из пяти человек. У каждого своя конфигурация VPN. Billing не проходит через карты. На корпоративный аккаунт нужен иностранный способ оплаты. Итог: двое работают с AI, трое — нет. Разрыв в скорости виден уже через неделю.
Когда мы переводили каталог на 28 000 позиций в headless-архитектуру, первые две недели прошли в одном режиме. Открываешь метод Bitrix REST, смотришь на документацию — документация отстаёт от текущей версии месяца на три. Открываешь дебаггер, вызываешь метод, смотришь на реальный ответ. Делаешь вывод о форме. Пишешь интерфейс вручную. На следующий день коллега делает то же самое с другим методом — чуть иначе, чуть другие предположения.
Мне нужно было, чтобы 13 cron-задач никогда не запускались параллельно. Все они работают с одним Chrome-профилем — той же сессией LinkedIn, которую я залогинил руками месяц назад. Два параллельных инстанса и профиль умирает.
Когда мы решили добавить русскую морфологию в индекс с 80 000 товаров, я понял, что у нас нет плана.
В апреле я открыл Google Analytics трёх e-commerce проектов, с которыми работаю давно. Органика Google: минус 23% год к году. Не у одного клиента — у трёх разных магазинов, разные ниши, разный размер, разный возраст сайта. Картина одинаковая.
Я потратил час на AI-сессию, только чтобы в конце обнаружить: агент исправил файл, который мы уже поправили в начале. Не потому что он плохой. Контекст переполнился, и модель «забыла» о том, что было в начале разговора. С тех пор я отношусь к контекстному окну как к оперативной памяти: когда кончается — начинаются свопы. И у меня появилась гигиена.
Клиент спрашивает: «Зачем нам headless, если Bitrix и так работает?»
На сдаче последнего большого проекта клиент спросил: «А ты можешь показать, где ты написал код сам, а где — нейросеть?»
Мы три дня искали, почему страницы каталога тормозят при конкурентных запросах. Профилировщик показывал: время уходит в ожидание. Nginx — чистый. MySQL — idle. FPM workers — свободны. Оказалось: session_start() ставит файловый lock, и все параллельные запросы одного пользователя выстраиваются в очередь. PHP ведёт себя именно так, как написано в документации. Просто эту страницу документации никто не читает перед деплоем в прод.
Демо выглядело убедительно. На экране — Kanban-доска, восемь карточек, каждая закрывается своим AI-агентом. Через 20 минут все тикеты зелёные. Зрители аплодируют.
Мы переехали на headless в феврале. В апреле SEO-специалист прислал выгрузку: 340 битых ссылок. Три года работавших редиректов. Ноль ошибок в логах — потому что Next.js не знал, что они вообще должны были существовать.
Три недели мы не могли понять, почему фильтр по цене не работает. Elasticsearch был жив. Запросы приходили. Результаты возвращались. Но диапазон цен от 1000 до 5000 рублей игнорировался полностью: в выдаче появлялись товары за 12 000 и за 300 рублей одновременно.
Когда мне говорят «вы скоро потеряете работу», я вспоминаю один конкретный баг.
Год назад я написал статью про то, что не отдаю AI в работе. В ней был список запретов: архитектуру не проектирует, контракты между слоями не меняет, решения по схеме БД не принимает. Список работает. Но за год добавилось кое-что ещё — понимание того, где Claude Code реально полезен. Это не там, где вы думаете.
Мы запустили headless Bitrix + Next.js. LCP вырос — но не так, как ожидали.
Я долго думал, что быть хорошим разработчиком — значит делать хорошо то, что попросили. Пишут задачу — я её реализую. Принимают работу — я иду дальше. Так работает большинство. Так работал и я. До трёх конкретных моментов.
В release notes Bitrix написано: «PHP 8.4 поддерживается». Первый клиент, который обновил staging, получил 47 deprecated notices за один запрос главной страницы и сломанный платёжный модуль. Ни одна из этих проблем не была в ядре Bitrix.
Мы провели A/B-тест. Контроль — поиск сортировал по текстовой релевантности. Вариант — по функции, которая учитывала маржу, остаток и скорость оборота. Кликабельность — почти одинаковая. Выручка с поискового сеанса — на 12% выше в варианте с бизнес-ранжированием.
Я суммировал расходы на AI-инструменты за год. Вышло $1 800. Сэкономил ли я больше? Честно — не знал. Пока не сел считать.
Вайбкодинг — это когда ты описываешь задачу, AI выдаёт код, ты смотришь «вроде работает» и деплоишь. Я так не работаю. Не потому что боюсь AI — Claude Code открыт у меня каждый рабочий день. Просто без структуры в legacy PHP-проекте это не ускорение. Это накопление долга с красивым интерфейсом.
Недавно мне написал клиент. Интернет-магазин, 30 тысяч SKU, Bitrix, «всё тормозит». Хотят уйти на headless. Я спросил: какой процент запросов превышает 2 секунды? Включён ли composite-режим? Смотрели slow_query_log за последние три месяца?
После каждого проекта я открываю одну и ту же заметку. Называю её «что не делать в следующем проекте». Там не «что прошло хорошо» — это в ретроспективу. Только одно: что именно я не повторю.
У меня в студии работает 13 автономных задач на Claude. Они ведут мой LinkedIn, пишут статьи для блога, мониторят SSI-систему, отправляют уведомления в Telegram. Я им доверяю — и сплю спокойно. Потому что если Claude напишет что-то не то в моём имени, я это увижу. Но если бы он написал это в ответ на вопрос покупателя о возврате товара на сайте моего клиента — это другая история. Именно поэтому у меня есть правило: никаких LLM на клиентской стороне. Пока.
Когда мы перенесли каталог 28 000 товаров на Next.js, первые два дня после деплоя были про CSS и перфоманс. На третий день пришёл тикет: «Авторизованные пользователи видят форму входа вместо личного кабинета».
У большинства Bitrix-сайтов TTFB выше 700 мс. Не потому что PHP медленный. Потому что Nginx-конфиг лежит нетронутым с того дня, когда хостер его положил — часто в 2016–2017 году.
Клиент спросил: «Что ищут наши покупатели?» Я открыл Elasticsearch и вытащил топ-40 поисковых запросов с нулём результатов за прошлую неделю. Среди них — три точных названия товаров, которые были в наличии. Просто записаны иначе, чем в каталоге.
Три месяца назад клиент спросил напрямую: «Ты же используешь Cursor и Claude Code — зачем мне платить полную ставку?»
Я настроил Claude Code писать и публиковать статьи в мой блог без моего участия. Каждые 20 минут. Автоматически.
У нас было три склада, 28K SKU и обещание клиенту: остатки в реальном времени.
Самый дорогой проект в моей практике обошёлся не в деньгах.
Планирование обновления Bitrix — это не то, о чём думают при запуске проекта. Думают об этом, когда в пятницу вечером приходит уведомление об окончании поддержки версии.
Мы три раза переделывали поиск на одном проекте.
За последний год я написал примерно втрое больше кода. Это правда. AI-инструменты реально ускоряют. Но если честно, значительную часть этого кода я потом удалил.
Я зашёл в проект с предубеждением.
Первое, что я написал в новой системе автоматизации — не задачу. Я написал файл STOP и папку Inbox/.
У меня 15 cron-задач. Из них 5 никогда не получат auto-publish — даже если я мог бы технически убрать approval gate за пару часов.
Когда я пишу задачу для агента, который будет запускаться по cron в 3 ночи — я думаю о формулировках иначе.
Когда клиент говорит «переходим на headless», первый вопрос не «какой фреймворк». Первый вопрос: что вообще остаётся на Bitrix?
Клиент пишет: «Мы всё перенастроили по вашим рекомендациям. OPcache включён, Redis-сессии работают. SQL-индексы тоже — проверяли отдельно. Вечерний пик всё равно роняет сайт».
Нулевые результаты — красный флаг в дашборде. Их сразу видят. О них сразу пишут задачи.
Когда ChatGPT только вышел, я слышал одно: «теперь джун напишет как мидл, а мидл — как сеньор». Красивый нарратив. Спустя полтора года с Claude Code у меня другой вывод.
Семь из тринадцати задач в моей системе проходят через меня. Пять работают сами. Одну я никогда не отдам алгоритму — даже на стадии «сначала покажи, потом сделаю».
Первый вопрос, который мне задают про headless Bitrix, всегда про архитектуру. Второй — про деплой. Третий никто не задаёт вслух, но все спотыкаются об него на первой неделе: как вообще разрабатывать, если у тебя нет Bitrix на машине?
Два года назад я взял проект, в котором с первого звонка было три признака, которые я уже умел распознавать. Взял, потому что деньги были хорошие, а я сказал себе: «Справлюсь». Четыре месяца спустя я выходил из этого проекта — нормально, без скандала, но с ощущением, что потратил время на работу, которую надо было не брать.
Bitrix выдаёт 504. Nginx логи чистые. MySQL загружен на 40%. OPcache прогрет. Composite cache включён. И всё равно сайт мёртв в час пик.
Покупатель ввёл запрос, нашёл нужный товар, кликнул — и увидел «нет в наличии». Ушёл. Написал в поддержку: «у вас сломан поиск». Я открыл логи — поиск работал правильно. Он показывал то, что было в индексе час назад. Проблема не в Elasticsearch. Проблема в том, что мы не подумали, как часто он должен узнавать о переменах.
В студии 13 автоматизаций. Они работают каждый день: собирают темы для блога, генерируют кандидатов, публикуют статьи, логируют, отправляют уведомления.
Когда клиент говорит «хотим headless», первое, что я спрашиваю — а что именно мы переносим?
У меня работают 13 агентов Claude без моего участия. На прошлой неделе двое из них упали. Я узнал об этом через 2 минуты — не потому что поставил сложный мониторинг, а потому что с первого дня вписал в каждую задачу пять строчек JSONL.
Я провёл с Bitrix REST API больше времени, чем планировал. Не потому что API плохой. А потому что документация описывает синтаксис, но молчит про поведение.
Три года назад я отвечал на вопрос «сколько это займёт?» одинаково: открывал Trello, декомпозировал на задачи, ставил story points. Потом суммировал, умножал на velocity, называл срок.
Три месяца мы знали: что-то тормозит. LCP каталога — 4.1 секунды. Где проблема — нет.
После трёх недель настройки Elasticsearch — шарды, реплики, mapping, кастомный токенайзер — мы разобрались с нечёткостью: добавили fuzziness AUTO и zero-results упали с 22% до 11%. Хорошо. Но 11% покупателей по-прежнему уходили ни с чем. Я полез в логи и обнаружил: большинство из этих запросов не были опечатками. Это были синонимы.
Мне периодически говорят: «Тебе надо масштабироваться». Я веду boutique-студию разработки и намеренно её не масштабирую. Соглашаюсь кивком и не делаю ничего. Не потому что лень. Потому что я пробовал.
Когда клиент говорит «хочу AI-агента для обработки заказов», я задаю один вопрос: сколько стоит один обработанный заказ сейчас?
Первая жалоба пришла на третий день после запуска headless. Менеджер обновил цену в Bitrix в 10:47. Покупатель положил товар в корзину в 11:20 — по старой цене. В Next.js была страница, закэшированная на один час.
Три месяца назад мне написал разработчик: «Ты до сих пор пишешь на PHP? Не жалко времени?»
Наш сервер лёг в 23:00. Прямо во время маркетинговой акции.
Я замерил. Когда я пишу спецификацию перед тем, как открыть Claude Code, итерация занимает в среднем 40 минут. Когда сажусь сразу писать промпт — около двух с половиной часов и три откатa.
Мы перешли на headless. Фронт стал деплоиться за 3 минуты. Бэк — нет.
Первый нетривиальный запрос после запуска нового поиска на каталоге в 28 000 SKU: «самсунк телефон».
Когда клиент спрашивает «сколько это стоит?», стандартный ответ — считать часы. Умножить на ставку. Прибавить 20% буфер. Написать число.
Когда я отдал 7 из 13 cron-задач Claude, первое, что я сделал — написал STOP-файл и папку Inbox. Не промт. Не систему мониторинга. Именно это.
Первый вопрос, который я задаю до любого КП: «Кто будет редактировать контент после нас — и на чём?»
В 2020 году я нанял разработчика, который на собеседовании безупречно объяснил архитектуру microservices, правильно ответил на все вопросы по PHP и произвёл впечатление на двух людей в команде. Через четыре месяца я его уволил. Не потому что он был плохим человеком — он просто не умел работать в нашем реальном контексте.
Три месяца мы смотрели в slow query log. Перекраивали индексы. Добавляли Redis-кеш там, где его раньше не было. Сайт становился чуть лучше, но страницы каталога иногда виснули на 800-900ms без видимой причины.
Мы добавили Elasticsearch в каталог на 28 000 SKU и решили, что дело сделано. Поиск работает, товары находятся, скорость нормальная. Через месяц я открыл аналитику поиска — конкретно логи no-results запросов.
Проект считается закрытым, когда последний коммит ушёл в прод. Это рабочее определение для джуниора.
Три месяца назад я начал прогонять все pull request через code review с помощью AI прежде, чем смотреть самому.
За последние два года я трижды отговорил клиента от headless-миграции. Не потому что headless плохой — я люблю его строить и видел, что он даёт. А потому что ответы на пять вопросов делали результат очевидным ещё до того, как мы открывали Figma. В четвёртый раз ответы были другими, и проект получил полноценный Next.js + Bitrix на бэкенде. Сейчас это один из лучших ecom-проектов, с которыми я работал.
Первые три раза я объяснял рефакторинг через «архитектуру» — и получал вежливое «окей, но давайте сначала сделаем фичи». Потом я поменял одну вещь: вместо «архитектурного долга» сказал «вот эта часть системы сейчас стоит нам дополнительных 6 часов на каждый новый тип доставки. За квартал это 60 часов, которые мы теряем». Клиент ответил: «ладно, выдели неделю».
Когда вышел MCP, я поставил четыре сервера за день. Потом убрал два. Потом добавил один другой. Через три месяца понял: Model Context Protocol не делает тебя умнее. Он убирает трение — в конкретных местах, за конкретные минуты.
Я строю headless-сайты на Next.js + Bitrix уже несколько лет. Мигрировал каталог на 28 000 SKU. Отказался от $40K-контракта, потому что переписывать монолит там не имело смысла. И когда клиент приходит с запросом «хотим headless», первый вопрос всегда один: «А почему именно headless?»
Каждую ночь в 02:00 у нас сбрасывается кеш.
Фильтр по цвету был. Он стоял двадцать вторым в боковой панели.
Один мой клиент пришёл с запросом: «Нам нужно переписать бэкенд. Он старый». Я спросил: «Что конкретно сломано?» Пауза. «Ну... он старый».
Код выглядел правильно. Тесты были зелёными. CI прошёл без замечаний.
Три года назад клиент написал: нам нужно обновить Bitrix — нашли критическую уязвимость в модуле оплаты. Когда сможем?
Через три недели после запуска ivanpin.com я посмотрел на источники трафика. LinkedIn дал на порядок больше визитов, чем поисковая органика. Сайту три недели, это нормально. Молодые домены так не работают. Но я всё равно задал себе следующий вопрос: а что будет, когда индексация устаканится?
Каждый третий разговор про Bitrix начинается с «он медленный». Я перестал спорить. Вместо этого прошу показать profiler.
Claude написал мне 340 строк тестов за восемь минут. Хорошие тесты. Я бы писал их два часа. Но когда я попросил его предложить структуру модулей для нового проекта на Bitrix, он выдал что-то симметричное, логичное и совершенно неработающее в нашем контексте. Разрыв между этими двумя результатами стал для меня рабочим определением: где заканчивается задача для Claude и начинается задача для меня.
Зимой мне позвонили с предложением, от которого не отказываются.
Три года назад я мог с гордостью показать 40 закрытых тикетов за спринт. Клиент всё равно был недоволен.
Мы потратили три недели на Elasticsearch. Первые две — на инфраструктуру: mapping, шарды, репликация, анализаторы для русской морфологии. Технически всё работало.
За неделю мой LinkedIn SSI упал с 38 до 37. Я к этому готов. Только что собрал систему из 13 cron-задач, и первое, что в ней появилось, это файл STOP и approval-папка.
Веду параллельно семь проектов на четырёх стеках. Документация по каждому актуальная. Не потому что я аккуратный. Потому что её больше не пишу я.
Rewrite — не всегда решение. Я модернизировал high-load e-commerce на 1С-Битрикс через Headless-подход: быстрее, безопаснее, без SEO-потерь. В статье — архитектура, риски, результаты и технический deep dive.