Прототип собрался за вечер: форма, таблица, выгрузка в Excel. Через полгода задачу нужно доработать — и оказывается, что половина логики продублирована, ошибки в запросах проглатываются, а человек, который писал, уже не помнит, почему здесь именно так. Правки идут в три раза дольше, чем в проекте, написанном руками.
Это не аргумент против ИИ в разработке. Это описание границы: вайбкодинг отлично ускоряет одно и очень дорого обходится в другом. Ниже — где именно проходит эта граница, как считать долг, который создаёт сгенерированный код, и по какому чек-листу его принимать.
Что такое вайбкодинг, если убрать маркетинг
Вайбкодинг — подход, при котором код пишет ИИ, а человек описывает задачу словами, проверяет результат и просит исправить. От классической разработки отличается не «кто печатает», а то, что автор решения и автор кода — разные стороны: модель не помнит, зачем вы это начали, и не отвечает за последствия.
Отсюда всё остальное. Скорость написания кода выросла в разы, скорость его понимания — нет. Пока проект маленький, разница незаметна: вы помните каждую строку. Когда файлов становится больше сотни, а через проект проходят два человека, понимание превращается в главный дефицит.
| Обещание вайбкодинга | Что происходит на практике |
|---|---|
| «Соберу сервис за выходные» | Собирается — если задача одноразовая и данные не жалко |
| «Не нужно быть разработчиком» | Не нужно печатать код, но нужно уметь его читать и проверять |
| «Доработки будет делать ИИ» | ИИ доработает то, что понимает. Чужой сгенерированный код он понимает хуже вас |
| «Кода много — значит, сделано много» | Объём кода чаще растёт от копирования, а не от функциональности |
| «Ревью не нужно, он же тесты проходит» | Тесты проверяют то, что в них описано. Крайние случаи в них обычно не описаны |
Где ИИ реально ускоряет: пять задач
Общее свойство всех пяти — ошибку видно сразу и она дешёвая. Проверить результат быстрее, чем сделать его руками.
1. Одноразовые скрипты и выгрузки
Свести два файла, пересчитать, разложить по папкам, поднять архив на новый сервер. Жизнь скрипта — один вечер, поддерживать его не нужно, поэтому техдолг не образуется.
2. Каркас интерфейса
Таблица, форма, список, фильтры. ИИ делает разметку и базовые стили за минуты, дальше человек доводит поведение. Главное — не тащить в проект то, что сгенерировалось «заодно».
3. Тесты и документация по готовому коду
Здесь ИИ особенно полезен: он описывает принятое поведение, а не придумывает новое. Это же и способ понять чужой код — попросить объяснить его по шагам и сверить с реальностью.
4. Разбор падений и ошибок
«Почему этот запрос возвращает пусто» — модель отвечает быстрее форумов, если дать ей лог, схему и кусок кода. Ответ нужно проверить, но гипотезы появляются быстрее.
5. Прототипы для проверки гипотезы
Собрать за день и выбросить, если не пошло. Ценность прототипа именно в том, что он не становится продакшеном. Проблема начинается ровно в момент, когда «пока оставим, потом перепишем» — а потом не переписывается.
Правило 70 %: почему «почти работает» — это не работает
Первые 70 % функциональности ИИ делает очень быстро. Остаток — крайние случаи: пустые значения, двойной клик по кнопке, обрыв сети, права доступа, часовые пояса, кириллица в именах файлов. Именно здесь живёт основная часть работы, и именно её модель делает хуже всего — потому что эти случаи не описаны в задаче.
Код, который никто не понимает, — это не актив, а обязательство. Разница видна ровно в тот день, когда нужно срочно исправить ошибку.
Практический вывод: планируйте не «сколько времени ИИ сэкономил на написании», а сколько времени уйдёт на понимание и приёмку. Если на понимание уходит больше, чем на написание руками, экономии не было.
Три вида долга, которые создаёт сгенерированный код
Дублирование логики
ИИ не знает, что в проекте уже есть функция проверки контрагента или форматирования суммы, и пишет вторую. Через полгода их три, и все три ведут себя по-разному. Найти это можно только ревью: в самом коде дубль выглядит нормально, потому что каждая копия корректна.
Молчаливые компромиссы
Задача решена способом, который не масштабируется: данные читаются целиком, запрос выполняется в цикле, ошибки проглатываются пустым `catch`, кеша нет. На десяти записях всё работает, на десяти тысячах ложится — обычно в самый неподходящий день.
Уверенный тон
Самая дорогая часть. Модель одинаково уверенно выдаёт правильное решение и функцию библиотеки, которой не существует. Читать нужно так, как будто код писал стажёр без опыта в вашем домене: аккуратно, сверяя вызовы и параметры.
Сколько стоит такой долг: считаем в часах
Долг удобно мерить не «качеством кода», а часами доработок. Возьмём внутренний сервис, собранный вайбкодингом за две недели: 6 000 строк, три таблицы в базе, выгрузка отчётов.
- Новая функция средней сложности. В проекте с понятной структурой — 8 часов, в сгенерированном без структуры — 20–24. Разница уходит на поиск места правки и на то, чтобы не сломать соседнее.
- Исправление ошибки в данных. Пока логика не продублирована, это 1–2 часа. После дублирования — 4–6: править надо в трёх местах и проверять, что все три согласованы.
- Передача проекта другому человеку. Без документации и тестов — от недели. С тестами и описанием — два-три дня.
При десяти доработках в год это 100–160 лишних часов. По ставке 3 000 ₽/час — 300–480 тыс. ₽, то есть больше, чем стоила бы нормальная разработка этого сервиса. Именно поэтому «дешевле и быстрее» верно только до первых серьёзных правок.
Чек-лист приёмки ИИ-кода: десять проверок
Этот список мы прогоняем перед тем, как сгенерированный код попадает в проект. Он не про красоту, а про то, что будет через год.
| Проверка | Как проверить | Что значит «не прошло» |
|---|---|---|
| Нет дублей логики | Поиск по названиям функций и по ключевым операциям | Вторая функция делает то же самое иначе |
| Ошибки не проглатываются | Поиск пустых блоков обработки ошибок | Сбой выглядит как пустой экран без записи в лог |
| Нет полной выборки данных | Проверить запросы без лимита и циклы с запросами | Работает на тесте, падает на реальном объёме |
| Права проверяются на сервере | Проверить, что доступ ограничен не только в интерфейсе | Данные доступны по прямой ссылке |
| Внешние вызовы с таймаутом | Есть таймаут, повтор и понятная ошибка | При недоступности сервиса страница висит |
| Данные валидируются на входе | Пустые значения, длинные строки, спецсимволы | Ошибка базы вместо сообщения пользователю |
| Есть тесты на поведение | Хотя бы основные сценарии и один крайний случай | Тестов нет или они проверяют только «не упало» |
| Повторное действие безопасно | Двойной клик, повторная отправка, обновление страницы | Создаются две записи или два списания |
| Понятно, что происходит | Человек, не писавший код, может объяснить поток | Объяснить может только автор — то есть никто |
| Есть план отката | Понятно, как выключить функцию и вернуть прежнюю | Откат — это «перепишем заново» |
Разбор одной задачи по этапам: где ИИ экономит, а где нет
Возьмём типовую доработку: добавить в локальное приложение импорт контактов из файла. Слева — оценка при написании руками, справа — при работе с ИИ. Цифры примерные, но порядок величин совпадает в большинстве проектов.
| Этап | Руками | С ИИ | Что проверить |
|---|---|---|---|
| Постановка задачи | 1 ч | 1 ч | Описание крайних случаев — ИИ его не придумает |
| Каркас и разметка | 3 ч | 0,5 ч | Лишние зависимости и стили «заодно» |
| Разбор файла и валидация | 4 ч | 1,5 ч | Пустые строки, лишние пробелы, кодировка |
| Запись в базу и дубли | 3 ч | 2 ч | Повторный импорт того же файла |
| Отчёт об ошибках | 1 ч | 0,5 ч | Понятность сообщений пользователю |
| Тесты | 2 ч | 1 ч | Тесты на основе кода проверяют его же ошибки |
| Ревью и отладка | 1,5 ч | 3 ч | Уверенные, но неверные вызовы |
Итог: около 16 часов руками против 9,5 с ИИ, то есть экономия примерно 40 %. Но она появляется только за счёт этапов производства — ревью и отладка, наоборот, дороже. Если ревью пропустить, экономия будет 60 %, а долг — тем больше, чем добрее был ревьюер.
Границы: где вайбкодингом пользоваться нельзя
Есть зоны, где экономия кажется большой, а цена ошибки — ещё больше. Здесь ИИ может помогать, но финальное решение и проверка остаются за человеком с опытом.
- Деньги и платежи. Списания, возвраты, счета: ошибка в ноль стоит дороже любой экономии.
- Персональные данные. Хранение, выгрузка, сроки — всё, что регулируется законом, а не удобством.
- Права доступа. Проверка роли должна быть на сервере и написана руками, а не «как получилось».
- Юридически значимые документы. Договоры, акты, согласия: шаблон может собрать ИИ, ответственность — нет.
- Интеграции с внешними системами. Тут ломается тихо: обмен работает, но теряет часть записей.
Отдельно про «сделаю сам, ИИ поможет». Внутренний сервис на коленке почти всегда переживает своего автора: человек уходит, а система остаётся, и поддерживать её некому. Если задача живёт дольше квартала — это уже проект, а не эксперимент.
Как встроить ИИ в разработку и не платить дважды
- Спецификация до кода. Сначала описать, что должно получиться, включая «а что если». Иначе модель придумает своё «а что если» — и это будет не то.
- Маленькие шаги с проверкой. Одна функция, один тест, один коммит. Не «сгенерируй модуль на тысячу строк».
- Ревью обязательно. Читать так, как будто код писал стажёр без опыта в вашем домене — сверяя вызовы, параметры и обработку ошибок.
- Свои конвенции в подсказке. Структура проекта, стиль, запрещённые библиотеки — всё это должно быть в инструкции для модели.
- Тесты как страховка. Единственное, что защищает от уверенных ошибок, — автопроверка поведения.
- Логи и метрики сразу. Если непонятно, что происходит в работающей системе, отладка превращается в гадание.
Вайбкод и Битрикс24: где это уместно
В экосистеме Битрикс24 у подхода есть отдельное применение: локальные приложения, встройки и небольшие сервисы для одного портала. Их не нужно публиковать в каталоге, они живут в вашем контуре и решают одну задачу.
- Услуги вайбкодинга — как мы собираем такие решения: прототип, приёмка, передача в эксплуатацию.
- Локальные приложения для Битрикс24 — если нужен свой экран и своя логика внутри портала.
- Разработка ИИ-агентов — когда ИИ не пишет код, а работает с данными и обращениями.
- REST API и вебхуки — как приложение разговаривает с порталом.
Важная деталь: скорость сборки не отменяет приёмки. Сгенерированное приложение проходит те же проверки, что и написанное руками — права, ошибки, повторные действия, журнал.
Что зафиксировать в договоре на разработку
- Кто отвечает за качество кода после сдачи, и что считается ошибкой, а что новой задачей.
- Передача исходников и доступов — вместе с документом «что и где настроено».
- Тесты и логи как часть результата, а не приятное дополнение.
- Сроки правок после запуска — первые недели всегда что-то всплывает.
- Правило «прототип — не продакшен»: если прототип переходит в работу, это отдельный этап с отдельной сметой.
Частые вопросы
Вайбкодинг заменит разработчиков?
Он уже заменил часть работы: шаблонный код, каркасы, тесты. Не заменил другое — постановку задачи, проектирование, приёмку и ответственность. Пока за результат отвечает человек, человек и остаётся в процессе.
Можно ли вести проект на вайбкодинге без программиста?
Можно, если задача одноразовая и цена ошибки низкая. Если система живёт дольше квартала, работает с деньгами, персональными данными или внешними системами — нужен человек, который будет читать и проверять код.
Сколько времени ИИ экономит на самом деле?
Написание кода — в разы быстрее. Полный цикл задачи — меньше, потому что остаются постановка, ревью, тесты и отладка. Ориентир из практики: экономия 20–40 % по циклу, а не по количеству строк.
Как понять, что проект уже обременён техдолгом?
Три признака: правка одного поля требует изменений в трёх местах, никто не может объяснить поток данных целиком, а любая доработка начинается с вопроса «а почему здесь так». Если хотя бы два совпали — пора заказывать ревизию, а не новую функцию.
Что делать, если код уже написан ИИ и никто его не понимает?
Заказать ревизию: описать поток, найти дубли и опасные места, добавить тесты на ключевые сценарии. Это дешевле, чем ждать сбоя в продакшене, и обычно занимает от нескольких дней до двух недель.
Вайбкод подходит для приложений Битрикс24?
Да, для локальных приложений под конкретный портал — особенно для внутренних инструментов и встроек. Ограничения те же: права, ошибки, повторные действия и журнал проверяются как в любом проекте.
Что сделать на этой неделе
- Определите, какие задачи у вас одноразовые, а какие будут жить дольше квартала — подход к ним должен быть разным.
- Возьмите один сгенерированный файл и пройдите по чек-листу из десяти пунктов.
- Посчитайте, сколько часов ушло на последние три доработки: это и есть ваша цена долга.
- Добавьте в инструкцию для модели структуру проекта и запрещённые библиотеки.
- Договоритесь, что прототип не идёт в продакшен без отдельного этапа приёмки.
Вайбкодинг — это ускорение гипотез, а не отмена инженерии. Схема, которая работает: ИИ пишет черновик, инженер делает из него систему — с тестами, логами, правами и документацией. Без второй половины вайбкодинг экономит неделю на старте и забирает месяц через год.
