Vibe coding и Битрикс: можно ли совместить старую CMS и AI-разработку

Vibe coding можно совместить с 1С-Битрикс, если использовать AI как помощника внутри инженерного процесса, а не как замену устройству CMS. Старый проект обычно содержит шаблоны, компоненты, события, обмен с 1С, доработки подрядчиков и зависимости от конкретной версии. Изменение одного файла без понимания связей способно сломать каталог или обновление.

Сначала составьте карту проекта

Перед генерацией кода определите редакцию и версию Битрикс, версию PHP, используемые модули, шаблоны, кастомные компоненты, обработчики событий, фоновые задания и интеграции. Отметьте, что относится к ядру, а что создано проектом.

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

Не редактируйте ядро

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

Если исторические изменения уже есть, сначала фиксируют их и поэтапно переносят в расширения. Просьба к AI «вынести весь legacy за один раз» слишком широка; перенос проверяют по одному поведению.

Где AI приносит пользу

• Объяснить конкретный компонент и его зависимости.
• Подготовить тест или воспроизводимый пример ошибки.
• Сгенерировать каркас локального модуля по принятой структуре.
• Найти повторяющийся код и предложить ограниченный рефакторинг.
• Составить миграцию с обратным действием.
• Обновить техническую документацию после проверенной правки.

Каждая задача включает файлы в области изменения, критерий готовности и запрет на лишние правки. Перед принятием результата разработчик смотрит diff, а не только обновлённую страницу.

Новый интерфейс можно отделить

Если нужно современное интерактивное приложение, необязательно переписывать весь Битрикс. CMS может оставаться источником каталога и редакторской частью, а новый интерфейс получать данные через контролируемый API. Такой подход полезен, если границы и ответственность за кеш, авторизацию и SEO определены.

Для публичных страниц нельзя забывать о серверном HTML, постоянных URL и метаданных. Отдельный frontend не должен превращать индексируемый каталог в пустой контейнер JavaScript.

Тестовое окружение обязательно

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

1. Воспроизвести исходный сценарий.
2. Добавить проверку ожидаемого результата.
3. Сделать небольшую правку.
4. Проверить кеш, права и интеграции.
5. Прогнать основные сценарии магазина.
6. Выпустить с мониторингом и планом отката.

Учитывайте обновления и производительность

Код может работать на текущей версии и использовать устаревший API. Проверяйте совместимость с целевой версией PHP и Битрикс. Запросы к базе внутри циклов, сброс всего кеша и загрузка больших выборок особенно опасны на реальном каталоге.

После изменений измеряют время ответа и число запросов на данных, близких к production. «На моей копии быстро» недостаточно.

Когда лучше не совмещать.

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

Иногда выгоднее построить отдельный сервис или постепенно заменить конкретный модуль. Решение принимают после карты связей и стоимости миграции, а не из-за моды на новый стек.

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