Аутсорсер предлагает вайбкодинг вместо разработки: как заказчику оценить риски

Такое ускорение может быть вполне реальным, но важно понять, за счет чего оно появилось: AI убрал рутину или вместе со сроками из проекта исчезли архитектура, тестирование и приемка?

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

У AI‑разработки есть еще одна сторона, важная именно для заказчика. Подрядчик тоже получает экономию. Если раньше на часть задач разработчик тратил несколько дней, теперь их можно сделать за несколько часов. Для подрядчика это означает меньше трудозатрат и потенциально более высокую маржу проекта. Само по себе в этом нет ничего плохого: заказчик платит не за количество часов программиста, а за результат.

Проблема начинается, если вместе с трудозатратами сокращается и сам объем инженерной работы. Например, подрядчик быстрее генерирует код, но заодно отказывается от части тестов, архитектурного проектирования, документации или полноценного code review. Снаружи оба предложения могут звучать одинаково: «сделаем быстрее благодаря AI». Но риски у них совершенно разные.

Вайбкодинг как этап и вайбкодинг вместо разработки — это не одно и то же

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

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

Но если сервис будет принимать платежи, хранить персональные данные, интегрироваться с ERP, CRM или другими системами компании, одной проверки «в браузере все открывается» мало. Поэтому проблема не в самом вайбкодинге. Если его используют, чтобы быстро проверить гипотезу, сделать прототип или proof of concept, это может сэкономить бизнесу время и деньги. Риск появляется, когда подход, подходящий для прототипа, незаметно переносят на весь продукт.

Скорость написания кода и скорость создания продукта — это не одно и то же

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

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

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

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

Поэтому предложение «сделаем быстрее благодаря AI» само по себе не красный флаг. Красный флаг начинается, если подрядчик не может объяснить, что он будет делать с кодом после того, как AI его написал.

Почему одного запрета для AI недостаточно

Летом 2025 года основатель SaaStr Джейсон Лемкин тестировал AI‑агента Replit и собирал с его помощью приложение с базой бизнес‑контактов. Проект разрабатывался девять дней. В какой‑то момент Лемкин ввел code freeze и запретил агенту вносить изменения. Несмотря на это, агент удалил данные из рабочей базы, где находились записи о 1206 руководителях и 1196 компаниях. Позже данные удалось восстановить через rollback. Здесь особенно интересна не сама ошибка, а то, что произошло после нее.

Replit изменила устройство платформы: development- и production‑базы стали разделяться, а агент во время разработки больше не должен иметь возможности менять production‑базу. То есть проблему решили не более строгим промптом «ничего не удаляй», а техническим ограничением доступа.

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

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

Поэтому один из первых вопросов подрядчику может звучать очень просто: «К чему AI вообще имеет доступ?».

Как отличить экономию на рутине от экономии на самой разработке

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

Если разговор постоянно возвращается к «AI сам подберет оптимальную архитектуру по ходу работы», то стоит задать больше вопросов.

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

«Что произойдет, если сломается вот это?». Например:

1. «Что будет, если платеж пройдет, а наша система не получит подтверждение?».
2. «Что случится, если внешний сервис не ответит?».
3. «Может ли один пользователь получить данные другого?».
4. «Что произойдет, если во время обновления приложение упадет?».

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

В отчете Veracode за июль 2026 года исследователи проверяли код, который генерировали разные AI‑модели. Синтаксически корректный код модели выдавали почти в 100% случаев, но около 44% проверенных задач приводили к коду с известной уязвимостью. Средний security pass rate составил 56%. Это тесты поставщика решений по безопасности, а не универсальная оценка любого AI‑кода, но разница между «код запускается» и «код безопасен» здесь видна хорошо. Поэтому вопрос «работает ли функция?» и вопрос «можно ли безопасно выпускать ее в production?» лучше не смешивать.

Узнайте, кто принимает работу у AI. Это, пожалуй, самый полезный вопрос. Не «какая модель пишет код?», а «Кто из вашей команды несет ответственность за этот код?»

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

Если подрядчик отвечает, что AI сам делает code review другим AI, это еще не означает, что проверки нет. Такие инструменты действительно используют. Но дальше стоит спросить, где появляется человек и кто принимает финальное решение.

В опросе Stack Overflow 2025 года 84% разработчиков уже использовали или собирались использовать AI‑инструменты. Но 46% респондентов не доверяли точности AI‑ответов, а доверяли им 33%. Еще 66% называли одной из главных проблем ответы, которые выглядят почти правильными, но содержат ошибку. 45% сталкивались с ситуацией, когда разбираться в AI‑сгенерированном коде было дольше, чем ожидалось.

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

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

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

Хороший проверочный вопрос здесь простой: «Если завтра проект примет другая команда, что вы ей передадите кроме репозитория?»

Что придется менять, если продукт вырастет?. Не каждому MVP нужно выдерживать миллион пользователей. Но подрядчик должен понимать ограничения выбранного решения. Можно спросить: «Что произойдет, если пользователей станет в десять раз больше?»

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

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

А вот как AI может работать хорошо

Противоположный пример есть у Rakuten. По данным опубликованного Anthropic кейса, команды Rakuten использовали Claude Code для написания компонентов, unit‑тестов, mock API, исправления ошибок и документации. AI подключили и к code review, но сам процесс разработки не свели к одному агенту.

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

Нужно учитывать, что это customer case самого производителя Claude, поэтому цифры здесь стоит воспринимать именно как данные компании и поставщика, а не как независимый эксперимент.

Но пример полезен по другой причине. Rakuten измеряет не количество строк, которые написал AI. Компания смотрит, как быстро функция дошла до пользователя, сохраняет тесты и code review и встраивает AI в существующий инженерный процесс. То есть AI позволяет инженерам сделать больше работы, но не заменяет сам процесс разработки.

Самый простой способ проверить подрядчика — небольшой пилот

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

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

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

Посмотрите:

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

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

Что прописать в ТЗ и договоре, если подрядчик использует AI

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

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

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

Третье — доступы и среды. Репозитории, облачные аккаунты и критичная инфраструктура не должны существовать только в личных аккаунтах разработчиков подрядчика. Для production лучше отдельно определить, кто имеет доступ и могут ли AI‑агенты самостоятельно вносить туда изменения.

Четвертое — тестирование и безопасность. Стоит договориться, какие проверки должны пройти перед релизом. Для одного проекта хватит автоматических тестов критических сценариев. Для другого потребуются анализ зависимостей, поиск уязвимостей, нагрузочные тесты или pentest. Тут нет универсального набора, он зависит от продукта.

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

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

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

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

Если времени мало, подрядчику можно отправить несколько вопросов:

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

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

Не нужно контролировать, кто написал каждую строку

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

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