Вайбкодинг в 1С и Битрикс24: руководство для разработчиков

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

Про вайбкодинг вообще написано много. Про вайбкодинг на 1С и Битрикс24 — почти ничего, хотя ошибается помощник там заметно чаще. Это руководство закрывает пробел.

Содержание

1. Что такое вайбкодинг и чем он не является
2. Кому подходит, а кому навредит
3. Рабочее место: инструменты и доступы
4. Как ставить задачу, чтобы код был рабочим
5. Вайбкодинг в 1С: встроенный язык и запросы
6. 1С: обмен через OData и типовые конфигурации
7. Битрикс24: доработки без потери обновлений
8. Как проверять код, который написал помощник
9. Где вайбкодинг не работает

Глава 1. Что такое вайбкодинг и чем он не является

Коротко

Вайбкодинг — это работа, при которой основную часть кода печатает ИИ-помощник, а программу задаёт, проверяет и отвечает за неё человек. Разработчик описывает словами, что нужно сделать. Помощник пишет код. Разработчик читает результат, находит ошибки и правит.

Слово появилось в феврале 2025 года: его пустил в оборот Андрей Карпатый, один из основателей OpenAI, в короткой заметке о том, как он собирает мелкие программы, почти не набирая код руками. Термин прижился быстрее, чем успело сложиться понимание, что он означает.

Чем вайбкодинг не является

Здесь больше всего путаницы, поэтому начнём с того, чем он не является.

• Это не «нейросеть напишет программу за вас». Помощник пишет фрагменты. Собрать из них работающий продукт, проверить и запустить — работа человека.
• Это не программирование без знаний. Чтобы найти ошибку в чужом коде, надо уметь этот код читать. Помощник ошибается регулярно, и без проверки его ошибки уезжают в работающую систему.
• Это не замена разработчиков. Меняется распределение времени внутри работы, а не потребность в человеке.
• Это не автодополнение. Подсказка следующей строки существует давно. Вайбкодинг — про другое: вы описываете задачу целиком и получаете целиком решение, которое надо разобрать.

Что меняется на практике

Меняется самое дорогое в разработке — часы человека.

В контролируемом эксперименте GitHub на 95 разработчиках типовая задача с ИИ-помощником закрывалась за 1 час 11 минут вместо 2 часов 41 минуты — почти вдвое быстрее (GitHub Research).

По оценке McKinsey, на понятных и небольших задачах генерации нового кода помощник экономит около половины времени разработчика. На сложных и непривычных задачах выигрыш падает до 10% и меньше.

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

Что стало окупаться

Раньше многие небольшие задачи не делали не потому, что они трудные, а потому что ставить на них разработчика было невыгодно. Медиана зарплаты backend-разработчика в России в 2026 году — 251 тыс. ₽ в месяц, около 1 500 ₽ за рабочий час (Хабр Карьера, 2026). Неделя работы на внутренний калькулятор — это примерно 60 тыс. ₽, и такие задачи годами лежали в очереди.

Когда та же работа занимает день, очередь начинает разбираться. Обычно первыми делают вот это:

• внутренний калькулятор или конвертер, которым пользуется один отдел;
• панель с цифрами для руководителя вместо ручной выгрузки в таблицу;
• разовый отчёт, который просили полгода;
• мелкая доработка старой системы, до которой не доходили руки;
• скрипт, переносящий данные из одного места в другое.

Кто за это отвечает

Отдельно и прямо, потому что это главный источник проблем.

Помощник не несёт ответственности за код. Если написанное им уронило продажи или испортило данные, объяснять это будет человек, который нажал кнопку. По опросу Stack Overflow за 2025 год 66% разработчиков называют главной проблемой ИИ-кода то, что он «почти правильный, но не совсем» — и тратят на проверку больше времени, чем рассчитывали.

«Почти правильный» — самое опасное состояние кода. Явно сломанный код падает сразу и его чинят. Почти правильный работает, проходит беглый просмотр и ломается через месяц на данных, которых никто не ждал.

Глава 2. Кому подходит, а кому навредит

Коротко

Вайбкодинг помогает тому, кто умеет читать код. Он вредит тому, кто читать код не умеет, — потому что такой человек не заметит ошибку и узнает о ней, когда она уже что-то сломала.

Это единственное деление, которое имеет значение. Не язык, не опыт в годах, не размер компании.

Кому подходит

• Разработчику с опытом. Самый выигрышный случай. Вы и так знаете, каким должен быть результат, и быстро видите, где помощник соврал. Экономия времени максимальная, риск минимальный.
• Разработчику на незнакомой платформе. Вы умеете программировать, но пришли в новую для себя систему. Помощник ускоряет вход в неё в разы — при условии, что вы проверяете каждый шаг по документации.
• Аналитику, который пишет запросы к данным. Отчёты, выгрузки, обработка таблиц. Ошибка видна сразу по результату, цена ошибки невысокая.
• Технически грамотному владельцу небольшого бизнеса. Если вы понимаете, как устроены ваши данные, и готовы разбираться — соберёте себе рабочий инструмент. С оговорками из следующего раздела.

Кому навредит

Здесь придётся быть неприятно прямым.

• Тому, кто не программирует совсем. Обещание «соберите приложение без знаний» продаётся хорошо, а заканчивается одинаково: получается то, что запускается и выглядит рабочим, но содержит ошибки, которые человек не в состоянии увидеть. Пока это личный проект — не страшно. Когда там деньги или чужие персональные данные — страшно.
• Тому, кто спешит и не проверяет. Вайбкодинг ускоряет и написание, и накопление ошибок. Без проверки вы получаете не быструю разработку, а быстрый технический долг.
• Тому, кто работает с нагруженной или критичной системой. Расчёт зарплаты, склад, касса, медицинские данные. Здесь цена «почти правильного» кода несопоставима с экономией часа.
• Команде без код-ревью. Если код никто не смотрит перед тем, как он уходит в работу, вайбкодинг просто увеличит поток непроверенного кода.

Как понять, что задача подходит

Четыре вопроса. Если на все четыре ответ «да» — отдавайте помощнику.

1. Я могу описать словами, что должно получиться? Не «сделай красиво», а «на вход список заказов, на выход таблица с суммой по каждому клиенту за месяц».
2. Я пойму, что результат неправильный? Если проверить нечем, вы не узнаете об ошибке.
3. Что случится, если это сломается? Отчёт покажет неверную цифру — переживём. Клиенту уйдёт неправильный счёт — уже нет.
4. Задача обычная или редкая? На типовых вещах помощник силён. На редких и специфичных для вашей системы — слаб, и это подтверждается оценкой McKinsey: на непривычных задачах выигрыш падает до 10% и меньше.

Правило одного шага

Начинать стоит не с продукта, а с задачи, которая не страшно если не получится.

Внутренний отчёт, который сейчас собирают руками. Скрипт, который переносит данные. Черновик формы. Сделайте одну такую вещь целиком: поставьте задачу, получите код, проверьте, запустите. После этого станет понятно, сколько времени уходит именно у вас — а это единственная цифра, которая имеет значение для решения.

Глава 3. Рабочее место: инструменты и доступы

Коротко

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

Три вида инструментов

Все помощники для кода делятся на три группы по тому, сколько они видят.

• Чат в браузере. Вы вставляете кусок кода и вопрос, получаете ответ. Видит только то, что вы вставили. Ничего не устанавливается, начать можно за минуту. Подходит, чтобы попробовать и разобрать отдельный фрагмент.
• Помощник внутри редактора кода. Видит открытый файл и соседние. Понимает, как устроен ваш проект, и предлагает правки на месте. Основной рабочий инструмент для большинства задач.
• Агент, который сам правит файлы. Получает задачу, сам открывает нужные файлы, вносит изменения, запускает проверки. Экономит больше всего времени и требует больше всего внимания: он меняет то, о чём вы не просили, если задача описана неточно.

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

Что нельзя отдавать наружу

Главная глава этой книги для тех, кто работает в компании, а не над личным проектом.

Когда вы вставляете код в чат или подключаете помощника к проекту, содержимое уходит на чужой сервер. Дальше зависит от условий сервиса: где-то данные удаляют, где-то хранят, где-то используют для обучения. Разбираться в этом надо до первого запроса, а не после.

Что не показывают помощнику никогда:

• Пароли, ключи доступа и токены. Даже в примере, даже «на минуточку». Ключ, попавший в чужой лог, считается скомпрометированным — его надо менять.
• Персональные данные людей. Реальные фамилии, телефоны, адреса, номера документов, медицинские сведения. Для примеров есть выдуманные данные.
• Коммерческую тайну. Формулы расчёта цен, условия договоров с поставщиками, клиентские базы.
• Код, закрытый соглашением о неразглашении. Если вы подписывали NDA, отправка кода наружу — его нарушение, независимо от намерений.

Как работать, если показывать нельзя

Три рабочих способа, от простого к сложному.

1. Обезличить. Замените реальные данные выдуманными, названия полей оставьте. Помощнику для написания кода нужна структура, а не содержимое.
2. Спросить про кусок, а не про систему. Вместо «вот наш модуль расчёта скидок» — «как отсортировать список по двум полям». Задача решается, тайна остаётся.
3. Поставить помощника внутри компании. Модель работает на вашем сервере, наружу не уходит ничего. Дороже и требует администрирования, но для банков, медицины и госсектора часто единственный допустимый вариант.

Что настроить до первой задачи

Полчаса, которые потом экономят дни.

• Система контроля версий. Обязательна. Помощник иногда меняет то, что вы не просили. Без возможности откатиться вы будете восстанавливать файлы руками.
• Отдельная ветка для его правок. Не работайте помощником сразу в основной ветке.
• Автоматические проверки. Даже простейшие. Если код запускается и базовые проверки проходят, часть ошибок отсеется без вас.
• Правила проекта в отдельном файле. Многие помощники читают файл с описанием проекта: какой стиль кода принят, чего делать нельзя, куда не лезть. Один раз написали — перестали повторять в каждой задаче.

Чего не надо делать на старте

Не покупайте пять инструментов сразу, чтобы сравнить. Возьмите один и проработайте им месяц. Разница между инструментами меньше, чем разница между «умею ставить задачу» и «не умею» — а это следующая глава.

Глава 4. Как ставить задачу, чтобы код был рабочим

Коротко

Помощник пишет плохой код, когда задача поставлена плохо. Это самая частая причина разочарования, и она чинится не сменой инструмента, а привычкой описывать задачу целиком.

Хорошо поставленная задача содержит четыре вещи: что на входе, что должно получиться, чего делать нельзя, как проверить результат.

Четыре части задачи

1. Что на входе. Откуда берутся данные, как они устроены, что в них может быть не так. Пустые поля, пропуски, повторы — про это надо сказать заранее, иначе помощник напишет код для идеальных данных.
2. Что должно получиться. Не «отчёт», а какие именно колонки, в каком порядке, в каком виде, куда сохранить.
3. Чего делать нельзя. Не трогать соседние файлы, не менять структуру базы, не подключать сторонние библиотеки, не переписывать то, что работает.
4. Как проверить. На каких данных прогнать и что должно получиться. Если проверить нечем — вы не узнаете об ошибке.

Плохо и хорошо

Плохо: «Сделай выгрузку заказов».

Помощник не знает, откуда брать заказы, за какой период, какие поля нужны и куда класть результат. Он всё это додумает — и почти наверняка не так.

Хорошо: «В таблице заказов есть поля: номер, дата, клиент, сумма, статус. Нужен файл с заказами за прошлый месяц в статусе „оплачен“. Колонки: клиент, количество заказов, общая сумма. Отсортировать по сумме, по убыванию. У части заказов клиент не заполнен — такие собрать в отдельную строку „без клиента“. Не меняй саму таблицу заказов, только читай».

Длиннее в десять раз. Экономит час.

Одна задача за раз

Соблазн описать всё сразу и получить готовый продукт — самая дорогая ошибка новичка.

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

Разбивайте. Сделали шаг — проверили — зафиксировали в системе контроля версий — следующий шаг. Медленнее ощущается, быстрее получается.

Как разговаривать, когда не получилось

Помощник ошибся. Дальше есть два пути, и один из них тупиковый.

Тупиковый: «не работает», «всё ещё не работает», «ты неправильно сделал». Помощник не видит вашего экрана и не знает, что именно сломалось. В ответ он будет переписывать код наугад, каждый раз по-новому, и вы уйдёте дальше от рабочего варианта, чем были.

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

Если после двух-трёх попыток не сдвинулось — остановитесь. Начните новую задачу с чистого листа и опишите её заново, подробнее. Это почти всегда быстрее, чем спорить дальше.

Правила проекта вместо повторов

Если вы каждый раз пишете «у нас отступы в четыре пробела», «не подключай сторонние библиотеки», «комментарии по-русски» — вынесите это в файл с правилами проекта. Помощник прочитает его сам, и задача сократится до сути.

Чего не ждать

Хорошая постановка задачи повышает долю рабочего кода, но не доводит её до сотни. Проверять всё равно придётся — про это следующая глава.

Главы про 1С и Битрикс24 — отдельно

Три главы про конкретные платформы вынесены на свои страницы: там подробнее и есть что искать по названию.

Глава 8. Как проверять код, который написал помощник

Коротко

Проверка — это не последний этап вайбкодинга, а его основная часть. Код, который написал помощник, чаще всего выглядит правильным. Проблема именно в этом.

По опросу Stack Overflow за 2025 год 66% разработчиков называют главной трудностью ИИ-кода то, что он «почти правильный, но не совсем». Почти правильный код проходит беглый просмотр, запускается и ломается позже — на данных, которых не ждали.

Пять типичных ошибок помощника

1. Выдуманные функции и методы. Помощник уверенно вызывает то, чего в вашей системе не существует. Выглядит правдоподобно, называется логично, но такого нет. Ловится запуском и проверкой по документации.
2. Код для идеальных данных. Работает на аккуратном примере и падает на реальных: пустое поле, пропуск, повтор, неожиданный формат даты.
3. Молчаливое проглатывание ошибок. Помощник любит обернуть опасное место так, чтобы оно не падало. В результате ошибка происходит, но никто о ней не узнаёт, а данные тихо портятся.
4. Правки не там, где просили. Особенно у агентов, которые сами открывают файлы. Попросили поменять одно — заодно переписано соседнее, которое работало.
5. Устаревший способ. Помощник предлагает то, что было правильным несколько лет назад. Код рабочий, но по нынешним меркам плохой или небезопасный.

Порядок проверки

Пять шагов, по возрастанию затрат времени. Первые два обязательны всегда.

1. Прочитать целиком. Не по диагонали. Если в коде есть места, которые вы не понимаете, — это не «сложно написано», это места, где вы не заметите ошибку. Просите объяснить или переписать проще.
2. Посмотреть, что именно изменилось. Сравнение с прошлой версией показывает все правки, включая те, о которых не просили. Здесь ловятся правки не там, где надо.
3. Запустить на настоящих данных. Не на примере из задачи. На тех, что реально приходят, со всей их грязью.
4. Проверить края. Пустой список, ноль, отрицательное число, очень длинная строка, повторяющаяся запись, дата 29 февраля. Здесь ломается чаще всего.
5. Дать посмотреть человеку. Для всего, что уходит в работу. Свой код после долгого сидения над ним читается плохо.

На что смотреть отдельно

• Работа с деньгами. Округление, копейки, валюты. Ошибка на копейку в отчёте за год превращается в расхождение, которое потом ищут неделю.
• Удаление и перезапись. Любое место, где что-то стирается или заменяется, читается дважды.
• Права доступа. Помощник по умолчанию не думает о том, кому что можно видеть.
• Запросы к данным без ограничений. Работает на сотне записей, кладёт систему на миллионе.

Приём: попросить объяснить

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

Второй приём — попросить его самого назвать слабые места: где этот код сломается и каких проверок в нём не хватает. Отвечает он на такое честно.

Сколько времени закладывать

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

Экономия при этом остаётся реальной: в эксперименте GitHub на 95 разработчиках задача с помощником закрывалась за 1 час 11 минут вместо 2 часов 41 минуты — и это уже с учётом того, что результат доводили до рабочего состояния.

Глава 9. Где вайбкодинг не работает

Коротко

Вайбкодинг помогает не везде. Есть задачи, где он экономит половину времени, и задачи, где он не экономит ничего, а риск добавляет.

По оценке McKinsey, на понятных и небольших задачах генерации нового кода помощник экономит около половины времени разработчика, а на сложных и непривычных выигрыш падает до 10% и меньше. Эта разница и определяет границу.

Где не работает

• Редкие и специфичные для вашей компании вещи. Помощник силён на том, что встречалось часто. Ваш самописный обмен, доставшийся от подрядчика семь лет назад, ему не встречался ни разу.
• Большие изменения в старой системе. Чтобы переделать то, что связано со всем остальным, надо держать в голове всю систему. Помощник видит фрагмент.
• Задачи, где важна каждая цифра. Расчёт зарплаты, налоги, начисления, медицинские дозировки. Не потому что помощник обязательно ошибётся, а потому что цена ошибки несопоставима с экономией часа.
• Производительность под нагрузкой. Помощник пишет код, который работает. Код, который работает на миллионе записей и не кладёт базу, — другая задача, и она требует понимания, как устроены данные именно у вас.
• Безопасность. Помощник не знает вашей модели угроз. Он напишет вход по логину и паролю, но не подумает, кто и что должен видеть после входа.
• Архитектура. Решение, как устроить систему, чтобы её можно было развивать три года, помощнику отдать нельзя. Он ответит уверенно, но это будет усреднённый ответ, а не ответ про ваш случай.

Где выигрыш максимальный

Для равновесия — обратная сторона.

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

Честно о том, чего вайбкодинг не отменяет

Он не отменяет систему контроля версий, тестирование, код-ревью и приёмку. Наоборот: чем быстрее появляется код, тем нужнее становится всё, что его проверяет.

Он не отменяет знание предметной области. Помощник не знает, что в вашей компании скидка не может быть больше 30%, а заказ без склада не оформляется. Эти правила приносит человек.

Он не отменяет ответственности. За код, который ушёл в работу, отвечает тот, кто его туда отправил.

Как решить в конкретном случае

Один вопрос, который заменяет все остальные: если этот код тихо ошибётся, я об этом узнаю — и во что это обойдётся?

Узнаю сразу и обойдётся дёшево — отдавайте помощнику. Узнаю через месяц из отчёта или от клиента — пишите руками или проверяйте так, как проверяют критичный код.