Подрядчик предлагает вайбкодинг: как заказчику проверить скорость, качество и риски

Автор: Владимир Белозеров, заместитель коммерческого директора KODE

Компания получает два предложения на разработку сервиса. Один подрядчик оценивает проект в шесть месяцев, другой обещает собрать его с помощью ИИ за два и заметно дешевле. Такое ускорение возможно. Но заказчику важно понять, за счёт чего сократились сроки: ИИ снял рутину или вместе с ней из проекта исчезли архитектура, тестирование и документация.

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

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

Вайбкодинг и разработка с помощью ИИ — не одно и то же

Термин «вайбкодинг» используют слишком широко, поэтому подрядчики могут вкладывать в него разный смысл.

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

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

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

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

Быстро написать код — не значит быстро создать продукт

ИИ действительно ускоряет отдельные задачи. В опросе METR, проведённом с февраля по апрель 2026 года среди 349 технических специалистов, участники оценили медианный рост скорости работы примерно в три раза. Когда речь шла не о скорости, а о ценности выполненной работы, оценка снижалась до 1,4–2 раз.

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

Код ещё нужно встроить в систему, проверить, защитить, развернуть и передать заказчику. Иногда именно эти этапы занимают значительную часть работы.

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

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

Подробнее о том, почему с распространением ИИ инженерное мышление становится важнее, мы писали в статье «Почему AI делает инженерное мышление ценнее».

Как читать смету подрядчика, который использует ИИ

Если ИИ сокращает время написания кода, заказчик вправе спросить, как это отразилось на оценке. Но сравнивать только количество часов разработки опасно. В смете должны остаться задачи, которые генерация кода не отменяет:

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

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

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

И наоборот: более высокая маржа подрядчика сама по себе не означает переплату. Если команда за меньший срок выдаёт проверенный результат и принимает на себя ответственность, заказчик покупает ценность, а не человеко-часы. Важно, чтобы ускорение было видно в сроках, объёме результата или стоимости, а обязательные инженерные работы не исчезали из сметы молча.

Почему запрет в промпте не защищает рабочую систему

Летом 2025 года основатель SaaStr Джейсон Лемкин девять дней создавал приложение с базой бизнес-контактов с помощью агента Replit. После команды заморозить изменения агент всё равно удалил записи о 1206 руководителях и более чем 1196 компаниях. Данные удалось восстановить, но сам инцидент показал слабость словесных ограничений. Подробности приводило Fast Company.

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

Проблему решили не более строгой просьбой «ничего не удалять», а техническим ограничением доступа. Этот принцип применим к любому проекту:

• ИИ не должен самостоятельно менять рабочую среду без необходимости;
• тестовые и рабочие данные нужно разделять;
• доступ к секретам и инфраструктуре должен быть минимальным;
• критичные изменения должен подтверждать человек;
• систему нужно уметь восстановить после ошибки.

Поэтому один из первых вопросов подрядчику звучит просто: к каким системам и данным имеет доступ ИИ?

Как понять, на чём подрядчик экономит

Заказчику необязательно уметь читать код. Качество подхода можно проверить по нескольким вопросам.

Попросите объяснить архитектуру

До договора не нужен документ на сто страниц. Достаточно схемы, на которой видно:

• из каких частей состоит продукт;
• где хранятся данные;
• как устроены авторизация и права;
• какие внешние сервисы используются;
• что произойдёт при росте нагрузки.

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

Разберите несколько аварийных сценариев

Спросите:

• что произойдёт, если платёж пройдёт, но система не получит подтверждение;
• что будет, если внешний сервис перестанет отвечать;
• может ли один пользователь увидеть данные другого;
• как откатить неудачное обновление;
• как восстановить данные после ошибки.

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

В июле 2026 года Veracode протестировала код разных моделей. Синтаксически корректный результат они выдавали почти всегда, но около 44% проверенных задач содержали известную уязвимость, а средний показатель успешного прохождения проверки безопасности составил 56%. Это исследование поставщика средств безопасности, поэтому цифры нельзя автоматически переносить на любой проект. Но оно хорошо показывает разницу между кодом, который запускается, и кодом, который безопасно выпускать.

Узнайте, кто отвечает за результат ИИ

Полезнее спросить не «какая модель пишет код», а «кто из команды отвечает за это решение».

У проекта должен быть конкретный инженер, который понимает код, проверил его и готов подтвердить выпуск. Проверка другим ИИ-инструментом тоже допустима, но финальная ответственность не должна растворяться между агентами.

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

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

Уточните, что останется кроме репозитория

Работающий продукт ещё не означает, что его сможет поддерживать другая команда. В зависимости от проекта заказчику понадобятся:

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

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

Проверочный вопрос: если завтра проект примет другая команда, что вы передадите ей кроме исходного кода?

Спросите, что произойдёт при росте

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

Спросите, что придётся менять, если пользователей, операций или данных станет в десять раз больше. Хороший ответ не обязан содержать план на три года. Важно, чтобы команда видела возможные узкие места и понимала, какие сегодняшние решения могут затруднить развитие.

Как ИИ может действительно ускорить разработку

Показательный пример есть у Rakuten. По данным клиентского кейса Anthropic, команды компании использовали Claude Code для создания компонентов, модульных тестов, имитаций API, исправления ошибок, документации и проверки кода.

Компания сообщила, что для некоторых функций срок выхода сократился с 24 до 5 рабочих дней, то есть на 79%. В одном эксперименте агент семь часов работал над изменением в большой открытой кодовой базе, а разработчик периодически направлял его.

Эти цифры опубликованы производителем Claude вместе с клиентом, а не получены в независимом эксперименте. Но кейс полезен устройством процесса. Rakuten не измеряет количество строк, созданных ИИ. Компания смотрит, насколько быстрее функция дошла до пользователя, при этом сохраняет тесты, проверку кода и участие инженеров.

ИИ здесь не заменяет разработку, а помогает команде быстрее пройти её обязательные этапы.

Проверьте подрядчика на небольшом пилоте

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

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

После пилота запросите не только ссылку на экран. Проверьте:

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

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

Что закрепить в техническом задании и договоре

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

Критерии приёмки

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

Ответственность подрядчика

Использование ИИ не должно освобождать команду от ответственности за архитектуру, качество кода и выпуск изменений. Конкретных ответственных и порядок проверки лучше закрепить заранее.

Доступы и среды

Репозитории, облачные аккаунты и инфраструктура не должны существовать только в личных профилях разработчиков. Отдельно определите доступ к рабочей среде и возможность ИИ-агентов вносить туда изменения.

Тестирование и безопасность

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

Дополнительные примеры ошибок ИИ в коде разобраны в статье KODE «Ошибки ИИ, которые спасают вашу работу».

Данные и внешние ИИ-сервисы

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

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

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

Передача проекта

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

Юридические формулировки зависят от договора и продукта, но технические требования нужно определить до передачи документа юристам.

Чек-лист перед подписанием договора

1. На каких этапах подрядчик использует ИИ?
2. Какие решения агент принимает самостоятельно?
3. Кто отвечает за архитектуру и сгенерированный код?
4. Какие проверки обязательны перед выпуском?
5. Имеет ли ИИ доступ к рабочей среде, реальным данным и секретам?
6. Где находятся репозитории, инфраструктура и ключевые аккаунты?
7. Какие документы, инструкции и доступы получит заказчик?
8. Что придётся менять при росте нагрузки?
9. Сможет ли другая команда продолжить разработку?
10. По каким критериям стороны будут принимать результат?

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

Вопросы и ответы

Стоит ли запрещать подрядчику использовать ИИ?

Обычно нет. Запрет сложно контролировать, а сам инструмент может заметно ускорить работу. Надёжнее зафиксировать требования к данным, доступам, проверкам, документации и ответственности подрядчика.

Подходит ли вайбкодинг для рабочего продукта?

Он подходит для прототипов и проверки гипотез. Для промышленного продукта нужны архитектура, тестирование, безопасность, документация и инженерная приёмка независимо от способа создания кода.

Должен ли подрядчик снизить цену, если использует ИИ?

Не обязательно пропорционально сокращению времени написания кода. Цена включает анализ, проектирование, тестирование, управление, инфраструктуру и ответственность. Но подрядчик должен объяснить, какой эффект ИИ даёт срокам и стоимости.

Кто отвечает за ошибку в коде, который написал ИИ?

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

Заказчику не нужно контролировать каждую строку

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

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

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