AI уже способен писать довольно большие объёмы рабочего кода. Но качество результата всё меньше зависит только от того, какую именно модель мы выбрали.
Особенно хорошо это видно при разработке на 1С-Битрикс и Битрикс24.
Можно взять современную coding-модель, попросить её написать модуль и получить вполне рабочий результат. Но если AI ничего не знает о конкретном проекте, версии Битрикса, существующем коде и правилах команды, часть решений ему неизбежно придётся угадывать.
Поэтому сегодня вопрос постепенно меняется.
Не только:
Какая AI-модель лучше пишет код?
А скорее:
Что нужно дать AI, чтобы он понимал конкретный проект и писал код примерно так же, как написал бы его разработчик из команды?
В простом случае достаточно дать AI доступ к проекту, исходникам Bitrix Framework нужной версии и нескольким понятным правилам.
В более крупной команде к этому можно добавить Agents.md, Skills, MCP, автоматические проверки и другие инструменты.
Почему с Битриксом у AI возникают проблемы
1С-Битрикс существует много лет. В реальных проектах часто одновременно встречаются разные поколения кода:
При этом просто работающий код ещё не обязательно является правильным решением именно для этого проекта.
AI может выбрать существующий, но устаревший API. Может создать код не там, где это принято в проекте. Может сделать новую архитектуру внутри системы, которая последние десять лет устроена совершенно иначе.
А иногда проблема ещё проще: модель знает более новую версию Битрикса, чем установлена на проекте, и предлагает метод, которого там просто нет.
Поэтому один хороший запрос вроде:
Напиши модуль для Битрикса.
обычно недостаточен.
AI нужно дать примерно ту же информацию, которую пришлось бы дать новому разработчику, пришедшему в проект.
Самый простой вариант: дать AI сам проект и ядро Битрикса
Начать можно вообще без MCP и без специальных Skills.
Если coding agent работает прямо с репозиторием и имеет доступ к исходникам Bitrix Framework, он может самостоятельно исследовать код.
Для разработчика Битрикса это вполне привычный сценарий.
Когда документации недостаточно, мы сами идём в ядро и смотрим:
какие методы действительно есть у класса;
какие параметры они принимают;
какие события вызываются;
как работает конкретный компонент;
что происходит внутри Sale;
как устроена ORM-сущность;
как похожая задача решена внутри самого Битрикса.
Современный AI-агент способен делать примерно то же самое.
Можно достаточно точно указать ему:
Посмотри реализацию этого класса и связанные с ним методы.
А можно поставить задачу более широко:
Исследуй, как в этой версии Битрикса правильно реализовать такую задачу. Посмотри исходники framework и существующий код проекта, после чего предложи решение.
Агент сам найдёт несколько связанных файлов, изучит реализацию и соберёт необходимую информацию именно под текущую задачу.
По сути, он временно создаёт себе небольшую документацию по тому участку системы, с которым сейчас работает.
💡 Необязательно заранее загружать всё ядро в индекс AI. В /bitrix/modules/ очень много файлов, большинство из которых для конкретной задачи не понадобятся. Обычно эффективнее позволить агенту самостоятельно искать нужные классы и методы по мере работы.
На практике лучше не индексировать /bitrix/ целиком, а:
Дать AI-агенту право искать по файловой системе по требованию (grep / file_search).
Или занести в постоянную индексацию только ключевые модули, с которыми работаете прямо сейчас (например, main, iblock, sale, catalog, highloadblock), добавив остальное в .cursorignore / .gitignore.
При подключении ядра к AI-агенту убедитесь, что у нейросети есть права только на чтение (read-only) директории /bitrix/, чтобы она случайно не попыталась "улучшить" или перезаписать файлы самого ядра при рефакторинге.
Важна версия конкретного проекта
Здесь есть принципиальный момент.
Источником истины должна быть не обязательно самая свежая версия Bitrix Framework, а та версия, которая реально установлена на проекте.
Если проект работает на более старом ядре, а AI ориентируется на последнюю документацию, он вполне может предложить API, которого в проекте ещё нет.
Поэтому хороший вариант:
проект + установленное ядро Bitrix Framework + AI-агент.
Тогда модель может проверить свои предположения непосредственно по исходному коду.
Но крайне рекомендуется работать на самых актуальных и последних версиях 1С-Битрикс и регулярно выполнять обновления, связано это не только с обновлением функционала, но и в первую очередь с обеспечением безопасности проекта.
Код проекта часто полезнее общей документации
Не все правила нужно описывать словами.
Если в проекте уже есть хорошо сделанный модуль, компонент или сервис, можно просто попросить AI сначала изучить его.
Например:
Изучи модуль X. Новый модуль должен быть устроен похожим образом, но работать с другой сущностью и решать следующую задачу...
Из существующего кода AI сразу увидит:
Для старого и большого проекта это особенно важно.
Общепринятый современный подход не всегда является лучшим способом доработать систему, которая развивается уже много лет.
Иногда правильнее продолжить существующую архитектуру, чем построить внутри неё небольшой островок совершенно другого кода.
Поэтому хороший пример из самого проекта нередко полезнее для AI, чем несколько страниц общих рекомендаций.
AGENTS.md: правила проекта в одном месте
Следующий уровень можно добавить, когда хочется перестать каждый раз повторять AI одни и те же инструкции.
Для этого используется AGENTS.md.
Если говорить совсем просто, это памятка для AI-разработчика.
В ней можно написать:
где должен находиться собственный код;
какую структуру модулей использовать;
когда применять D7;
где допустим старый API;
как работать с ORM;
как организованы сервисы и контроллеры;
как обрабатывать ошибки;
как устроено кеширование;
куда писать логи;
какие требования есть к безопасности;
как оформлять код;
какие части проекта нельзя менять;
что делать с существующим legacy-кодом.
То есть вместо постоянного:
Здесь мы так не делаем.
Этот код должен находиться в другом месте.
В этом проекте используется другой подход.
часть таких знаний можно один раз записать рядом с проектом.
И это полезно не только для AI.
Во многих командах значительная часть правил существует только в голове ведущих разработчиков и постепенно передаётся остальным во время code review.
Появление AI просто делает эту проблему более заметной: модель не сможет догадаться о внутреннем правиле компании, если оно нигде не записано.
В итоге AGENTS.md может одновременно стать инструкцией и для AI, и хорошей основой для адаптации новых разработчиков.
Нужен ли MCP
Не обязательно.
MCP, или Model Context Protocol, можно воспринимать как стандартный способ дать AI доступ к внешнему источнику информации или инструменту.
Вместо того чтобы надеяться, что модель помнит нужный API, можно разрешить ей проверить информацию непосредственно во время работы.
Для Битрикс24 уже существует официальный MCP-сервер, который предоставляет AI доступ к актуальной REST-документации.
Это особенно удобно при разработке интеграций.
Без внешнего источника:
AI вспоминает REST API → возможно ошибается → пишет код.
С MCP:
AI находит актуальный метод в документации → проверяет параметры → пишет код.
Модель в таком случае не обязана помнить весь REST API Битрикс24.
От неё требуется другое: уметь найти правильный метод и правильно им воспользоваться.
А для Bitrix Framework можно обойтись исходниками
При разработке непосредственно на «1С-Битрикс: Управление сайтом» ситуация немного другая.
Разработчики и без AI регулярно смотрят исходный код framework, потому что он часто является наиболее точным ответом на вопрос о работе конкретного метода или класса.
Поэтому если AI уже имеет доступ к ядру нужной версии, отдельный MCP для этой задачи не является обязательным.
MCP может сделать поиск удобнее, быстрее и более единообразным, особенно если нужно предоставить одинаковую среду нескольким разработчикам или агентам.
Но сама идея важнее конкретной технологии:
AI должен иметь возможность проверить, как система работает на самом деле.
Это может быть:
Главное, чтобы источник был актуален именно для выполняемой задачи.
Skills: готовые инструкции по типовым задачам
Есть ещё один уровень: Skills.
Сам термин звучит несколько сложнее, чем сама идея.
Skill можно представить как небольшую специализированную инструкцию для AI:
Если работаешь с такой задачей, обрати внимание вот на эти правила и используй примерно такой подход.
Например, отдельные Skills могут описывать работу с:
ORM;
компонентами;
кешированием;
безопасностью;
событиями;
контроллерами;
каталогом;
Sale;
Highload-блоками;
REST;
миграциями;
фоновыми задачами.
Для Bitrix Framework уже существуют открытые проекты с такими наборами инструкций, например 1c-bitrix-cms-skill и bitrix-framework-skills.
Всегда ли нужны Skills
Если опытный Bitrix-разработчик работает над проектом один, он вполне может обходиться без большого набора Skills.
Он сам знает, куда отправить агента:
Посмотри этот класс.
Изучи реализацию Sale.
Найди похожий компонент.
Проверь, как это реализовано в ядре.
В таком случае часть необходимых знаний разработчик фактически передаёт AI непосредственно во время постановки задачи.
Но в команде ситуация меняется.
Если разработчиков несколько, хорошо бы, чтобы качество результата не зависело от того, кто именно сейчас объясняет AI, куда смотреть.
Тогда Skills превращают личный опыт одного разработчика в повторно используемые инструкции для всех.
И именно здесь их ценность становится значительно выше.
Не обязательно использовать всё одновременно
AGENTS.md, Skills, MCP, исходники ядра и код проекта не являются обязательными ступенями одного процесса.
Это разные способы дать AI нужную информацию.
Условно:
Код проекта отвечает:
Как подобные задачи уже решены у нас?
Исходники Bitrix Framework отвечают:
Как эта часть Битрикса работает на самом деле в нашей версии?
AGENTS.md отвечает:
Какие правила приняты именно в нашем проекте?
Skills отвечают:
На что обычно стоит обратить внимание при решении задач такого типа?
MCP и документация отвечают:
Как выглядит актуальный API и какие возможности сейчас доступны?
Для конкретного проекта может быть достаточно только части этих источников.
Например:
AI-агент + репозиторий + ядро нужной версии.
Для другого проекта:
AI-агент + репозиторий + AGENTS.md + официальный MCP Битрикс24.
А в большой команде:
репозиторий + ядро + AGENTS.md + общие Skills + MCP + автоматические проверки.
Цель не в том, чтобы подключить как можно больше инструментов.
Цель в том, чтобы AI получал достаточно достоверной информации для самостоятельной работы и при этом не придумывал недостающие детали.
И только после этого нужны проверки
Даже если AI хорошо понимает проект, автоматически принимать его код всё равно не стоит.
Рабочий процесс может выглядеть примерно так:
Поставить задачу → дать AI исследовать проект → получить решение → проверить изменения → запустить тесты → при необходимости исправить → принять код.
При этом полезно поручить агенту перед завершением работы самостоятельно ещё раз проверить результат.
Например:
Просмотри весь сделанный diff. Найди возможные ошибки, лишнюю сложность, нарушения правил проекта и проблемы безопасности. Исправь найденное, если изменение действительно оправдано.
Современные coding agents довольно неплохо находят проблемы даже в коде, который только что создали сами.
После этого остаются обычные инженерные проверки:
AI не отменяет этот процесс.
Он сокращает объём ручной работы между постановкой задачи и готовой реализацией.
Что в итоге меняется в работе разработчика
При таком подходе разработчик постепенно меньше занимается механическим написанием кода и больше управляет самой разработкой.
Он:
формулирует задачу;
определяет ограничения;
показывает AI нужную часть системы;
выбирает архитектурный подход;
проверяет предложенное решение;
смотрит изменения в коде;
оценивает нестандартные ситуации;
проверяет бизнес-логику;
принимает итоговый результат.
Вместо:
Написать 500 строк PHP.
процесс всё чаще выглядит примерно так:
Понять задачу → показать AI нужный контекст → дать ему исследовать систему → получить реализацию → проверить → протестировать → принять.
Это не означает, что разработчику больше не нужно хорошо знать Битрикс.
Скорее наоборот.
Чем больше кода пишет AI, тем важнее способность человека понять, правильное ли направление он выбрал.
Как начать на существующем проекте
Причём для начала не нужно сразу строить сложную систему.
1. Дайте AI доступ к репозиторию
Работа со всем проектом обычно гораздо полезнее изолированных кусков кода, вставленных в чат.
Пусть агент видит структуру системы и может самостоятельно искать связанные реализации.
2. Дайте доступ к ядру нужной версии Битрикса
Особенно если работа связана непосредственно с Bitrix Framework.
Это позволит AI проверять реальные классы, методы и внутреннюю реализацию вместо догадок.
Важно именно соответствие ядра версии проекта.
3. Покажите хорошие примеры существующего кода
Выберите несколько модулей и компонентов, которые действительно стоит использовать как образец.
4. Создайте небольшой AGENTS.md
Не нужно сразу писать двадцатистраничный документ.
Начните с десятка действительно важных правил, которые вы и так регулярно объясняете разработчикам на code review.
5. Подключите документацию или MCP там, где это полезно
Особенно это актуально для REST API Битрикс24 и других интерфейсов, которые могут меняться.
Официальный MCP Битрикс24 как раз решает задачу доступа AI к актуальной REST-документации.
Для Bitrix Framework альтернативой может быть прямой доступ к исходникам.
6. Добавляйте Skills при необходимости
Если команда регулярно решает однотипные задачи, имеет смысл постепенно оформить лучшие практики в повторно используемые инструкции.
Особенно полезно это становится, когда с AI работают несколько разработчиков.
7. Оставьте обычные проверки
Тесты, статический анализ и code review никуда не исчезают.
Меняется способ получения первого варианта решения, а не ответственность за результат.
Чек-лист: безопасность при работе AI с проектом Битрикса
Когда вы даёте AI-агенту доступ к файловой системе проекта, убедитесь, что модель не «унесёт» чувствительные данные в контекст:
Исключите конфиги с доступами: Запретите агенту читать bitrix/.settings.php, bitrix/php_interface/dbconn.php и .env файлы (в них хранятся пароли к БД, ключи API и токены).
Исключите секреты, дампы и логи из доступа AI. Используйте механизм исключений конкретного инструмента (.cursorignore, .aiignore и т. п.), а для действительно чувствительных данных дополнительно ограничивайте доступ на уровне файловой системы и рабочей среды агента.
А какая модель лучше пишет код под Битрикс?
Это уже отдельный вопрос.
Есть, например, открытый проект Bitrix AI Challenge, где разные модели можно сравнивать на одинаковой задаче по разработке под Bitrix Framework.
Но даже результаты таких сравнений имеет смысл рассматривать вместе с тем, какой контекст получила модель, какие инструкции ей дали и какие инструменты разрешили использовать.
Потому что в реальной разработке всё чаще выигрывает не просто самая сильная модель.
Выигрывает связка:
хорошая модель + правильный контекст + доступ к реальному проекту + возможность проверить свои предположения + инженерный контроль результата.
Полезные ссылки