Ключевой тезис статьи: ИИ повышает потолок продуктивности инженера, но не заменяет ответственность, доменную экспертизу, эксплуатацию и доверие. «Вайбкодинг» — это отказ от инженерного контроля.
Введение: откуда взялся «вайбкодинг» и что именно мы критикуем
В последние месяцы в профессиональной среде набрал популярность термин vibe coding — стиль разработки, в котором человек задаёт направление и принимает результат, а детали реализации «пусть сделает модель», без глубокой проверки и понимания кода. Автор термина подчёркивал ключевой момент: разработчик перестаёт внимательно смотреть на код и «плывёт по течению».
Эта статья — не против ИИ в разработке.
- Не критикуем: использование ИИ как инструмента — автодополнение, поиск по коду, генерацию черновиков тестов и документации, ускорение рефакторинга.
- Критикуем: отказ от инженерного контроля — когда решения принимаются «потому что модель так написала», а ответственность размыта.
Для стартапа с одним сервисом и короткой историей это может быть допустимым экспериментом. Для промышленного ИТ — особенно в системах, которые живут годами, имеют обязательства перед клиентами и несут риски — это опасная иллюзия.
1. За что в промышленном ИТ платят деньги
Главная ошибка лозунга «мы перепишем легаси за пару недель» — подмена товара.
1.1. Покупают не код, а предсказуемость
Код — только часть продукта. В корпоративной разработке покупают:
- доверие к поставщику и репутацию;
- поддержку и способность восстановить сервис при инциденте;
- дорожную карту развития и совместимость;
- возможность адаптации под процессы клиента;
- гарантии уровня сервиса (SLA), сроки реакции, ответственность;
- соблюдение требований безопасности и комплаенса;
- понятную стоимость владения.
«Навайбкодил и готово» не закрывает ни один из этих пунктов. Даже если приложение работает сегодня, клиента интересует вопрос: что будет завтра, когда упадёт база, изменится регуляторика или понадобится интеграция?
1.2. Ключевая стоимость — вокруг кода
В зрелом продукте львиная доля стоимости сидит в:
- данных, миграциях и обратной совместимости;
- сценариях эксплуатации, мониторинге, аварийных процедурах;
- интеграциях и договорённостях с внешними системами;
- поддержке пользователей и обучении;
- знаниях о «краях» поведения, которые не описаны в требованиях.
ИИ может ускорить производство кода. Но «продажа результата» и «стоимость владения» от этого не исчезают.
2. Почему «переписать с нуля» почти всегда плохая идея — даже без ИИ
Соблазн переписать систему с нуля возникает регулярно. История разработки накопила много горьких уроков: переписывание уничтожает накопленные знания и скрытые исправления, а параллельная поддержка старой и новой системы удваивает нагрузку.
ИИ меняет скорость набора текста, но не отменяет главных причин провалов:
- Эквивалентность поведения: новая версия должна вести себя так же в тысячах деталей.
- Миграции данных: перенос схем, правил, истории, отчётности, аудита.
- Догонялки по функциям: пока вы переписываете, бизнес просит новые возможности.
- Непредвиденные зависимости: интеграции, особые режимы, нестандартные договорённости.
Если «платформа» существует несколько лет, то большая часть её ценности — это память о реальном мире, а не только архитектурная схема.
3. Пределы современных моделей: что показывают бенчмарки
Публичные демонстрации «модель написала компилятор» почти не отвечают на главный вопрос промышленной разработки: способен ли ИИ безопасно и предсказуемо менять чужой продукт в большой кодовой базе.
Чтобы обсуждать это без религии, полезно опираться на репозиторные бенчмарки — задачи, где модели дают репозиторий, описание проблемы и проверяют результат запуском тестов.
3.1. Что говорят цифры (7 опорных фактов)
Ниже — числа, которые неплохо «калибруют ожидания».
- SWE-bench: 2 294 задачи из реальных GitHub-issues в 12 популярных Python‑репозиториях.
- Средний масштаб репозитория в SWE-bench: ~3 010 исходных (не тестовых) файлов и ~438 000 строк кода; максимум доходил до ~5 890 файлов и ~886 000 строк.
- При этом «золотой» исправляющий патч в SWE-bench обычно маленький: в среднем ~1,7 файла и ~33 строки правок.
- SWE-bench Verified — это 500 задач, вручную проверенных разработчиками на адекватность постановки и тестов.
- На SWE-bench Verified в отчёте OpenAI GPT‑4o решал 33,2% задач (в одном из лучших открытых каркасов/обвязок этот результат сопоставим).
- SWE‑Bench Pro (профессиональные репозитории, «длинный горизонт»): 1 865 задач из 41 репозитория; в оценке Scale даже лучшие системы остаются ниже 25% Pass@1, а максимальный результат в их отчёте — 23,3%.
- ContextBench (узкое место «найти нужный контекст»): 1 136 задач из 66 репозиториев и 522 115 строк человечески размеченного «эталонного контекста».
3.2. Что эти цифры означают на практике
Бенчмарки дают простой вывод: модели уже умеют быстро решать часть локальных задач в больших репозиториях — особенно когда исправление небольшое и проверка чётко задаётся тестами.
Но промышленная разработка ломает эту картину там, где начинается «длинный горизонт»:
- правки размазаны по компонентам (интерфейсы, миграции, интеграции);
- нужно удерживать инварианты, которые не выражены в тестах;
- успех измеряется не «тесты прошли», а стоимостью владения, устойчивостью и безопасностью.
SWE‑Bench Pro и ContextBench ровно про это: не хватает не “умения писать код”, а умения находить нужное, удерживать контекст, объяснять решения и доводить цепочку изменений до предсказуемого результата.
4. Почему «зелёные тесты» не равны «можно не смотреть в код»
Один из популярных аргументов вайбкодинга: «если тесты зелёные, значит всё нормально». В промышленной разработке это опасное упрощение.
4.1. Полное покрытие — редкость, и дело не в лени
Даже сильные команды редко имеют 100% покрытие. Причины обычно практические:
- часть требований невозможно формализовать без «экспертного знания предмета»;
- нагрузочные, отказоустойчивые и стресс‑испытания дорогие и долго готовятся;
- критичные сценарии проявляются только на реальных данных и в реальной интеграционной среде.
4.2. Что может сломаться при «зелёном CI» — три коротких примера
Пример 1: производительность. Все функциональные тесты зелёные, но в одном месте модель заменила ручной SQL на удобный слой доступа, и незаметно появился N+1 запрос. На стенде — тишина. На бою — рост p95/p99 задержек и перерасход вычислений.
Пример 2: эксплуатация. Исправление «логически верное», но удалило/переименовало диагностические логи или метрики. Через месяц инцидент повторяется, а расследовать нечем: причина есть, но следов нет.
Пример 3: безопасность. Тесты не ловят, что строка из внешнего источника теперь выводится «как есть» (или формируется команда оболочки), и вы получаете инъекцию там, где раньше её не было. Пользователь этого не тестирует — он это эксплуатирует.
Отдельная проблема — человеческий фактор. В крупном пользовательском исследовании участники с AI‑ассистентом чаще писали менее безопасный код и при этом сильнее верили, что сделали всё правильно. Это прямо описывает риск вайбкодинга: скорость растёт, а критичность проверки падает.
5. Блокеры вайбкодинга в промышленном ИТ
Ниже — причины, почему «дать ИИ репозиторий и не смотреть» в промышленной разработке не проходит. Формат — максимально прикладной: миф → как ломается → чем страховаться.
5.1. Миф: «код не важен — важны тесты; если зелёное, можно не разбираться»
Как ломается: тесты редко покрывают нагрузку, отказоустойчивость, безопасность, наблюдаемость и крайние сценарии пользователей. В итоге растут инциденты и стоимость изменений.
Чем страховаться: явные эксплуатационные требования (SLO), профили нагрузок, регрессионные сценарии на реальных данных, обязательные требования к логированию/метрикам для критичных путей.
5.2. Миф: «ответственность можно размыть: “модель сделала”»
Как ломается: через полгода возникает дефект или регрессия, и бизнесу нужен конкретный ответ: кто принял решение, почему, и кто исправит. «Модель написала» — не ответ.
Чем страховаться: владелец компонента (code owner) подписывает изменения; решения фиксируются короткими техническими записками; для агентных правок сохраняется журнал: какой контекст читался, какие команды выполнялись, какие тесты запускались.
5.3. Миф: «всё можно отдать в облако, безопасность — не проблема»
Как ломается: у многих организаций периметр закрыт: код, данные, секреты и журналы должны оставаться внутри. Плюс — регуляторика, договоры, требования клиентов.
Чем страховаться: классификация данных/кода (что можно выносить, что нельзя), отдельный контур для ИИ‑инструментов, запрет на попадание секретов в промпты, аудит обращений к репозиториям.
5.4. Миф: «чем больше агенту дать прав, тем быстрее он сделает»
Как ломается: как только агент получает инструменты (доступ к файлам, сборке, внешним сервисам), вы получаете новую поверхность атак: подмена контекста, утечки, заражение цепочки зависимостей. Это уже выделено как отдельный класс рисков в практиках безопасности для LLM‑приложений.
Чем страховаться: принцип минимальных прав (по умолчанию чтение, запись — только в песочницу/ветку), белые списки инструментов и команд, изоляция, сканирование зависимостей, строгие правила обновления и поставки (цепочка поставки).
5.5. Миф: «экономика очевидна: меньше людей — больше прибыли»
Как ломается: растёт стоимость вычислений/инфраструктуры, увеличивается время ревью, появляется больше “широких” диффов и долга. Вы экономите на наборе текста и платите за переделки, расследования и простои.
Чем страховаться: считать эффект через метрики поставки (скорость изменений и доля неудачных), отдельно учитывать стоимость ревью и переделок, вводить лимиты на размер и размах правок от ИИ, начинать с зон низкого риска.
5.6. Миф: «чёрный ящик — это нормально, “главное, работает”»
Как ломается: без воспроизводимости и расследуемости вы теряете управляемость. В критичный момент бизнесу нужны ответы: какой контекст был подан, почему внесли именно эти изменения, и можно ли повторить результат той же версией модели.
Чем страховаться: фиксация версии модели/обвязки, регламент обновления, воспроизводимые прогоны, хранение артефактов (логи/тесты/диффы) и “цепочки решения” для критичных изменений.
6. Управляемый путь: как повышать эффективность разработки с ИИ
Идея простая: сначала делаем процесс измеряемым и безопасным, потом добавляем ускорение. Ниже — практичный роадмэп без «магии».
6.1. Этап 0: сделать разработку измеряемой (и честной)
Без цифр любой разговор об эффективности превращается в веру.
Минимум, который стоит собрать:
- DORA‑метрики: частота поставок, время от изменения до поставки, доля неудачных изменений, время восстановления.
- метрики кода и процесса: медианный размер PR, время ревью, доля откатов/хотфиксов, повторные правки (churn).
Важно: эти метрики можно собрать даже без идеальной “аналитики” — из Git/CI и истории деплоев.
Критерий перехода дальше: метрики считаются автоматически и не вызывают споров «как считали».
6.2. Этап 1: ИИ как инструмент низкого риска
Разрешаем то, где ошибка дешёвая:
- автодополнение, шаблоны, рефакторинг локальных функций;
- объяснение и поиск по коду (read‑only);
- черновики документации и тестов.
Запрещаем: широкие многофайловые диффы и изменения в критичных контурах без опытного ревью.
Критерий успеха: уменьшается время на рутину и подготовку PR, а доля неудачных изменений не растёт.
6.3. Этап 2: ИИ внутри конвейера качества
Здесь ИИ помогает не «писать вместо», а поднимать планку качества:
- подсказки по статанализу/линтеру и быстрые исправления;
- предложения по зависимостям и совместимости;
- генерация небольших PR с ясной целью и пояснением «что/почему».
Критерий успеха: уменьшается “время до первого зелёного прогона”, PR становятся меньше, ревью ускоряется.
6.4. Этап 3: ограниченная автономность (агентные режимы) — только с ограждениями
Только после того, как процесс стабилен.
Разрешаем:
- агент создаёт PR в заранее ограниченной области (папка/модуль/пакет);
- агент запускает тесты и фиксирует результаты;
- агент предлагает миграции только вместе с планом отката.
Ограждения (обязательные):
- принцип минимальных прав; секреты исключены;
- белые списки инструментов и команд;
- журналирование действий и сохранение артефактов;
- владелец компонента подписывает изменения.
Критерий успеха: растёт скорость поставки без роста change failure rate и без ухудшения MTTR.
6.5. Этап 4: экономический расчёт и кадровые решения
Сокращения — не стартовая точка, а финал.
Решения по штату имеют смысл только когда:
- улучшения метрик держатся несколько циклов поставки;
- качество и безопасность не просели;
- стоимость вычислений, ревью и переделок учтена;
- вклад ИИ виден в цифрах, а не в ощущениях.
6.6. Что смотреть специально про ИИ (короткий список)
Чтобы не купить «скорость набора текста» ценой долга:
- доля PR, где правки от ИИ приняты без существенной переделки;
- средний размер диффа и число затронутых модулей;
- число регрессий после релиза и откатов;
- время ревью (если выросло — «ускорение» фиктивное).
6.7. «Как лекарство»: применять под руководством опытных — и проверять по метрикам
На упаковке сильнодействующих лекарств пишут: «применять под наблюдением врача». С ИИ в разработке ситуация похожа: инструмент мощный, но у него есть побочные эффекты — от размывания ответственности до роста уязвимостей и долга.
Проблема в том, что рынок ещё не успел вырастить “людей с 10+ годами опыта управления ИИ”. Модели, агентные режимы, инструменты и практики меняются быстрее, чем успевают сформироваться устойчивые школы эксплуатации.
Отсюда практическое правило: в ИИ нельзя “верить” — его можно только измерять.
Что это означает в управляемом внедрении:
- должен быть ответственный владелец контура ИИ (как минимум: инженерная платформа/безопасность/архитектура), который определяет границы доступа, правила обновления моделей и критерии допустимого риска;
- внедрение идёт через гипотезы и ограниченные эксперименты: что ускоряем, на каком участке, какой ценой;
- до старта фиксируются метрики “до” и критерии “после” (DORA + качество + безопасность + стоимость ревью/переделок);
- обязательно есть кнопка остановки: если растёт доля инцидентов, откатов или security findings — эксперимент прекращается, причины разбираются.
Если к вам приходит консультант и обещает «+50% производительности», единственный взрослый способ разговора — контракт на измеримый результат:
- методика расчёта метрик согласована заранее и воспроизводима;
- данные и инструменты измерения принадлежат вам, а не подрядчику;
- все изменения и настройки документированы; нет «магии» без аудита;
- улучшение подтверждается не презентацией, а динамикой метрик на нескольких циклах поставки.
ИИ можно и нужно внедрять. Но — так же, как сильное средство: под руководством людей, которые понимают риски, умеют строить ограждения и отвечают за последствия, а не «по вайбу».
Если вам ближе управляемый подход без «магии» — его можно поставить как инженерную практику: мы помогаем командам провести диагностику (метрики поставки, качество, риски), настроить контур безопасности для ИИ‑инструментов, запустить пилот на ограниченном участке и вывести контроль в цифры — так, чтобы решения принимались по динамике метрик, а не по обещаниям.
7. Практический чек-лист для руководителя ИТ
Если вам продают «перепишем за пару недель», задайте пять вопросов:
- Как будем проверять эквивалентность поведения и миграции данных?
- Какие обязательства по поддержке и SLA берёте?
- Как устроен контроль безопасности и цепочки поставки?
- Кто конкретно отвечает за изменения и инциденты?
- Какие метрики качества и поставки улучшатся, и как это измерим?
Если на эти вопросы нет точных ответов — перед вами не план, а вера.
Заключение
ИИ действительно делает инженеров сильнее. Он ускоряет анализ, снижает стоимость рутины, помогает держать в голове больше деталей.
Но промышленная разработка — это не соревнование по скорости написания кода. Это дисциплина управления рисками, ответственности и доверия.
ИИ имеет смысл внедрять так же, как сильнодействующий инструмент: под руководством опытных людей и под контролем метрик. В этой области пока слишком мало «устоявшегося опыта на десятилетия», поэтому вера в обещания — плохая стратегия, а измеримость и ограждения — хорошая.
Вайбкодинг обещает «быстро и без боли», но в обмен требует отказаться от контроля. Для промышленного ИТ это слишком высокая цена.
Примечания и источники
- Андрей Карпати — исходное описание термина «vibe coding»: https://x.com/karpathy/status/1886192184808149383
- SWE-bench (оригинальная статья и статистика по размеру репозиториев/патчей): https://arxiv.org/pdf/2310.06770
- OpenAI: Introducing SWE-bench Verified (500 задач; GPT‑4o — 33,2%): https://openai.com/index/introducing-swe-bench-verified/
- Scale AI: SWE‑Bench Pro (1865 задач, 41 репозиторий; <25% Pass@1; 23,3% максимум): https://scale.com/research/swe_bench_pro
- Scale AI: лидерборд/описание датасета SWE‑Bench Pro (Public): https://scale.com/leaderboard/swe_bench_pro_public
- ContextBench (1136 задач; 522 115 строк «эталонного контекста»): https://arxiv.org/html/2602.05892v1
- Perry et al., Do Users Write More Insecure Code with AI Assistants? (исследование про снижение безопасности и рост уверенности): https://arxiv.org/abs/2211.03622
- NIST AI RMF 1.0 (управление рисками ИИ как социотехнической системы): https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
- NIST SP 800‑218 (SSDF) — практики безопасной разработки: https://csrc.nist.gov/pubs/sp/800/218/final
- OWASP Top 10 for LLM Applications (классы рисков: инъекции, утечки, цепочка поставки и др.): https://owasp.org/www-project-top-10-for-large-language-model-applications/
- Joel Spolsky, Things You Should Never Do, Part I (про риски переписывания с нуля): https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
- SLSA (практики защиты цепочки поставки артефактов): https://slsa.dev/
- Model Context Protocol: security best practices (если подключаете агентам инструменты): https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices