Vibe Coding — это способ работать с ИИ, при котором ты не пишешь код, а описываешь словами, что должно получиться, и ИИ сразу выдаёт готовый рабочий кусок программы. В отличие от Copilot, который подсказывает следующую строку кода, здесь ты формулируешь задачу целиком через структурированный промпт из четырёх частей: что сделать, какие требования, какие ограничения, что доработать.
Главная находка исследования: скорость растёт, а контроль падает незаметно. Когда разработчик просто диалогом получает готовый код, он перестаёт его внимательно проверять — как будто доверяет собеседнику, а не проверяет чертёж. Именно из-за этого падения бдительности, а не из-за "плохого кода от ИИ", растёт число уязвимостей и падает индекс поддерживаемости — то есть насколько легко потом код чинить и дорабатывать.
Метод из статьи — не хитрая техника, а чёткая структура промпта + обязательный этап ревью. Промпт всегда собирается из четырёх блоков (задача → требования → ограничения → доработка), а после получения кода нужно отдельно и явно попросить ИИ проверить безопасность и структуру — это компенсирует ту самую потерянную бдительность.
Схема метода
ШАГ 1: Составь промпт из 4 блоков (задача, требования, ограничения, доработка) → получи рабочий код целиком
ШАГ 2: Протестируй код на реальных данных → зафиксируй что работает / не работает
ШАГ 3: Отдельным запросом попроси ИИ явно проверить безопасность и поддерживаемость кода → получи список рисков
ШАГ 4: Уточняющим промптом попроси исправить найденные проблемы (валидация, оптимизация, разбиение на модули)
Все шаги выполняются в одном чате последовательно, отдельные запросы.
Пример применения
Задача: Предприниматель без опыта программирования хочет сделать простого Telegram-бота для сбора заявок с сайта, без найма разработчика.
Промпт:
Задача: создай Telegram-бота на Python, который принимает заявки от клиентов и сохраняет их в Google Sheets.
Функциональные требования: бот должен спрашивать имя, телефон и суть запроса по очереди,
затем подтверждать данные и записывать их в таблицу.
Ограничения: используй библиотеку python-telegram-bot, код должен быть читаемым
и разбитым на функции, без сложных зависимостей.
Доработка: добавь обработку ошибок (если пользователь ввёл пустое поле или отменил диалог),
и сделай так, чтобы бота легко было расширить новыми вопросами.
После получения кода — второй запрос:
Теперь проверь этот код отдельно на безопасность (утечка токена, инъекции, ошибки валидации)
и на то, легко ли его будет поддерживать через полгода. Дай список конкретных рисков.
Результат: В первом ответе — рабочий код бота целиком, разбитый на функции, с комментариями. Во втором — отдельный список рисков (например, "токен бота хранится в открытом виде в коде", "нет проверки формата телефона") и рекомендации по исправлению. Без второго запроса эти риски скорее всего останутся незамеченными — именно это и показало исследование.
Почему это работает
Языковая модель отлично генерирует целостный, работающий на первый взгляд код по смысловому описанию задачи — это её сильная сторона, она обучена на миллионах примеров кода и хорошо угадывает "типичное" решение. Но у неё нет встроенного механизма "остановись и проверь риски" — она выдаёт код и молчит про уязвимости, если её не попросить отдельно.
Слабость человека здесь зеркальна: когда код появляется "по волшебству" за один запрос, пропадает привычка построчно вычитывать и тестировать — то ощущение контроля, которое естественно возникает при ручном написании кода. Структурированный промпт снижает двусмысленность на входе, а отдельный запрос на ревью заставляет модель (и тебя) вернуться к тому, что при быстрой генерации выпадает из внимания.
Рычаги управления: блок "ограничения" в промпте — можно сузить (конкретный язык, конкретная библиотека) для более предсказуемого результата, или расширить для творческой свободы модели. Блок "доработка" — можно добавить конкретные критерии проверки (например "проверь на SQL-инъекции" вместо общего "оптимизируй"), это делает второй запрос-ревью точнее.
Шаблон промпта
Задача: {что нужно построить, одним предложением}
Функциональные требования: {что конкретно должно делать приложение/скрипт, по пунктам}
Ограничения: {язык программирования, инструменты, стиль кода}
Доработка: {что добавить после первой версии — обработка ошибок, читаемость, расширяемость}
После получения кода — второй промпт для проверки:
Проверь этот код отдельно на безопасность и на то, легко ли его будет поддерживать и менять в будущем.
Дай конкретный список рисков и что нужно исправить.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для получения кода через диалог с тобой (vibe coding). Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про язык программирования, конкретные функции и ограничения — потому что без этих деталей она выдаст обобщённое решение, которое придётся долго переделывать.
Ограничения
⚠️ Падение качества: чем быстрее получен код через диалог, тем ниже показатели поддерживаемости и выше число потенциальных уязвимостей — это системный побочный эффект скорости, не случайность.
⚠️ Не для критичных систем без проверки: метод хорош для прототипов, внутренних инструментов и разовых скриптов. Для продакшн-кода, который трогает деньги или личные данные, обязателен отдельный этап ручной или экспертной проверки.
⚠️ Ложное чувство готовности: работающий на первый взгляд код создаёт иллюзию завершённости — без явного запроса на ревью риски остаются невидимыми именно потому, что код "выглядит нормально".
Как исследовали
Исследователи собрали тридцать участников — пятнадцать практикующих разработчиков и пятнадцать студентов IT-специальностей — и дали каждому три равнозначные по сложности задачи (консольная система учёта товаров, модуль обработки CSV/JSON, форма с валидацией). Каждую задачу решали тремя способами: вручную, с Copilot и через чистый диалог с ИИ (vibe coding) по стандартизированному четырёхблочному промпту.
Замеряли время выполнения, число ошибок, индекс поддерживаемости кода и количество уязвимостей через автоматические инструменты анализа кода, а также усталость и удобство через опросники SUS и NASA-TLX. Плюс — интервью с участниками, разобранные через тематический анализ.
Результат интересен именно противоречием: диалоговый режим оказался быстрее на 27% против ручного кодирования и на 12% против Copilot — но именно в этом режиме упала поддерживаемость и выросли уязвимости. Из интервью выяснилось почему: участники говорили про "потерю контроля" — ощущение, что код появился из воздуха, и его меньше хочется перепроверять. Это и стало ключевым практическим выводом: дело не в качестве генерации самой по себе, а в том, что люди перестают проверять то, что не писали сами руками.
Адаптации
🔧 Техника: добавь роль "критика" после генерации → снижение слепого доверия
Вместо того чтобы просто просить "проверь безопасность", попробуй разделить получение кода и его проверку на два разных запроса с разной установкой:
Запрос 1: Напиши код для {задача}.
Запрос 2 (в новом сообщении): Забудь, что ты писал этот код. Представь, что ты код-ревьюер,
который получил чужой код и должен найти в нём проблемы безопасности и слабые места
в архитектуре. Будь максимально критичен.
Это имитирует смену роли модели с "автора" на "проверяющего" — по аналогии с тем, как в исследовании "потеря контроля" была связана именно с отсутствием отдельного этапа проверки.
Ресурсы
Aribe G. S. Jr., Labastida L. J. S. The Vibe Shift in Software Engineering: Evaluating AI-Led Conversational Programming for Performance, Cognition, and Responsible Adoption. Bukidnon State University, Philippines. Опубликовано в IJASEIT (International Journal on Advanced Science, Engineering and Information Technology).