К 2026 году граница между разработчиком и не-разработчиком размылась настолько, что Gartner прогнозирует: «citizen developers» превысят число профессиональных программистов в соотношении 4:1. Маркетологи строят лендинги, аналитики — дашборды, владельцы бизнеса — CRM-интеграции. По данным Second Talent, 63% практикующих вайбкодинг вообще не считают себя разработчиками. Порог входа упал до умения сформулировать задачу.
Вайбкодинг — неформальный термин для подхода, при котором человек описывает задачу в чате с ИИ, получает код, проверяет, работает ли он, и при необходимости возвращает ошибку обратно в диалог. Никакого проектирования, никаких промежуточных этапов — только итерации между запросом и результатом. Скорость высокая, ощущение продуктивности — тоже. Именно поэтому проблемы такого подхода долго остаются невидимыми.
| Источники | Уверенность | Действие |
|---|---|---|
| Код проекта + аналогичный кейс | 🟢 HIGH | Реализуем уверенно |
| Код проекта без кейса | 🟡 MEDIUM | Реализуем осторожно |
| Только документация | 🟠 LOW | СТОП – нужна верификация |
| Нет источника / предположение | 🔴 VERY LOW | СТОП – не включаем |
Главная из них — безопасность. Исследование Стэнфордского университета «Do Users Write More Insecure Code with AI Assistants?» зафиксировало парадокс: разработчики, использующие ИИ-ассистентов, писали значительно менее защищённый код — и одновременно были более уверены в его надёжности. ИИ по умолчанию не ставит валидацию на пользовательский ввод, не экранирует SQL-запросы, оставляет XSS-уязвимости и генерирует API-эндпоинты без авторизации. Хуже того — прописывает ключи и пароли прямо в коде. По данным GitGuardian, только за 2023 год в публичных репозиториях GitHub обнаружено 12,8 млн новых секретов — рост на 28%. Последствия видны в статистике 2024 года: утечка National Public Data затронула около 2,9 млрд записей, атаки через Snowflake — Ticketmaster (560 млн) и AT&T (110 млн). Среднее время обнаружения утечки через украденные учётные данные — 292 дня.
Разработчики с ИИ-ассистентами писали менее безопасный код и при этом были более уверены в его безопасности — данные Стэнфорда.
Вторая системная проблема — архитектура. ИИ генерирует код, который выглядит аккуратно: понятные имена переменных, структурированные файлы. Но внутри компонент авторизации напрямую обращается к таблице заказов, обработчик формы пишет в три разные базы, бизнес-логика живёт в контроллере. Профессионалы называют это «спагетти-кодом», но здесь он замаскирован под чистый стиль. Изменение в одном месте ломает три других, тестировать модули изолированно невозможно. ИИ не мыслит архитектурой — он генерирует файл за файлом, оптимизируя под «работает сейчас», а не под «будет работать через год».
Третья проблема — технический долг, который накапливается с первого коммита. Захардкоженные идентификаторы, скопированные функции вместо общих модулей, пропущенная обработка ошибок — каждое такое решение по отдельности выглядит мелочью. Вместе они образуют снежный ком: в какой-то момент любое изменение обходится дороже, чем переписать проект с нуля. По данным Standish Group CHAOS Report, основанному на 50 000+ проектах, 39% провалов в IT вызваны плохим сбором требований. ИИ требования не собирает — он делает то, что сказано, даже если это неправильно.
Отрасль начала реагировать. В 2025 году AWS выпустила Kiro — IDE, построенную на принципе «сначала спецификация, потом код». Плагин Superpowers набрал 93 000 звёзд на GitHub именно потому, что не позволяет ИИ прыгать сразу в реализацию. Серия материалов HumanLayer зафиксировала консенсус: ИИ-агентам нужны человеческие контрольные точки и документированные решения на каждом этапе. Методология RDPI (Research → Design → Plan → Implement) формализует этот подход: каждый этап порождает артефакт — документ, который загружается в контекст на следующем шаге. Это решает две проблемы одновременно: ИИ не теряет наработанный контекст, а у команды есть точки возврата, если что-то пошло не так. Код при таком подходе пишется последним — и это принципиальная позиция, а не методологическая деталь.
