Вайбкодинг занял ленту. Каждый второй пост — «я запустил Claude и написал свой аналог X». 100× девелоперы, которые по факту больше менеджеры, стремительно множат GitHub-репозитории. Но один автор на Habr задался неудобным вопросом: а что если посчитать, насколько это устойчиво — не на ощущениях, а через теорвер?
Контекст
Вайбкодинг — это паттерн работы с LLM, при котором пользователь не читает и не понимает генерируемый код: просто промпт → принять → следующий промпт. Claude, GPT, Cursor — всё это инструменты, которые реально снизили порог входа в разработку. Но снижение порога и снижение сложности системы — разные вещи.
Проблема не в том, что инструменты плохие. Claude Code и agentic-режимы действительно дают прирост скорости опытным разработчикам. Проблема — в иллюзии, что вероятностная модель выдаёт детерминированный продукт. LLM галлюцинирует. Иногда опасно.
Статья вышла в мае 2026 года — в момент, когда дискуссия о вайбкодинге достигла пика. Автор намеренно берёт «потолочные» цифры и честно об этом говорит — но формулы работают с любыми входными данными.
Аналитика
Первый расчёт — риск деструктивных инцидентов. Если вероятность галлюцинации модели — 0.01, деструктивной галлюцинации — 0.1, пропуска фильтром — 0.1, пропуска усталым оператором — 0.5, то на одну операцию получается ~0.00005. Звучит безопасно. Но при миллионе пользователей по 20 запросов в день — это порядка 4–5 инцидентов ежесуточно глобально. Данные никто публично не раскрывает, но логика верна независимо от конкретных вероятностей.
Второй расчёт — срок жизни проекта. Код, написанный через LLM итерационно, накапливает ошибки нелинейно: каждый новый шаг опирается на все предыдущие. Автор моделирует это как произведение вероятностей выживания на каждом шаге с линейно растущей вероятностью ошибки. Результат: при консервативных допущениях проект начинает деградировать около 118-й итерации, а к 372-й становится неуправляемым — ни человек, ни LLM уже не может его поддерживать.
При 20 правках в день это 6–18 дней реальной работы. Тесты, линтеры и типизация замедляют коллапс, но не отменяют. Архитектурный долг не исчезает от того, что его не видно в git diff.
Кейсы применения в бизнесе
B2B-SaaS стартап. Команда из 3 человек использует Claude Code для ускорения фич. Риск: через месяц кодовая база станет лапшой, если нет архитектурных решений до начала вайбкодинга. Что делать: задавать Claude явные архитектурные ограничения в каждом промпте, вести ARCHITECTURE.md с инвариантами системы и запрещать LLM их нарушать. Результат — скорость сохраняется, деградация замедляется в разы.
Корпорация с legacy. Разработчик интегрирует новый модуль в 10-летний монолит через agentic-инструменты. Опасность: Claude не видит полного контекста и генерирует код, который локально работает, но ломает соседние сервисы. Решение: изолировать область изменений, тесты на интеграцию писать до, а не после. Без этого — классический сценарий «починили левое крыло, уволились уборщицы правого».
SMB / локальный бизнес в КР и СНГ. Небольшая компания нанимает джуниора «с курсами по Python» и подпиской на Claude. Сценарий из статьи почти буквальный. Практический выход: либо нанимать хотя бы одного мидла, который будет делать code review каждые 50 итераций, либо строить систему на no-code платформах с заранее известными ограничениями — предсказуемее, чем вайбкод в production.
Кейсы в личной жизни
Разработчик. Используешь Claude Code для ускорения рутины — это разумно. Но если не читаешь сгенерированный код, ты перестаёшь понимать свою же систему. Практика: раз в 50 коммитов делать «архитектурную паузу» — читать что реально написано, а не что показывает диффа.
Контент-мейкер или фрилансер. Делаешь небольшой инструмент для автоматизации через вайбкодинг — нормально, пока проект маленький. Критическая точка — когда появляются зависимости между модулями. До этого момента — полёт, после — экспоненциальный хаос. Держи проекты маленькими и изолированными.
Студент или начинающий. Вайбкодинг даёт иллюзию понимания. Реально учишься только когда читаешь код, понимаешь почему написано именно так, и можешь объяснить это без помощи LLM. Используй Claude как ментора («объясни что делает эта функция»), а не как автопилот.
Как применить сегодня
- Перед каждой сессией вайбкодинга определи архитектурные инварианты системы и явно передавай их в контекст: «не трогай модуль X», «все запросы к БД только через репозиторий Y».
- Введи правило «читай каждый 10-й коммит» — не весь код, но хотя бы diff ключевых модулей. Так успеваешь поймать лапшу до того, как она стала монолитом.
- Пиши интеграционные тесты до фичи, не после. Claude отлично генерирует тесты по спеке — используй это как страховку, а не как afterthought.
- Если проект живёт дольше 2 недель активного вайбкодинга — запланируй рефакторинг-сессию: попроси Claude объяснить архитектуру того, что он же и написал. Несоответствие между объяснением и реальным кодом — сигнал тревоги.
- Для production-критичных компонентов (авторизация, платежи, удаление данных) — никакого вайбкодинга. Пиши руками или делай детальный review каждой строки.