Вайб-кодингом называют разработку через диалог с ИИ: вы описываете нужное поведение, получаете код, запускаете приложение и просите изменить результат. Для первого эксперимента это позволяет начать с задачи на обычном языке. Когда приложение используют другие люди, нужно разобраться в его устройстве и проверить поведение за пределами удачного первого запуска.
Термин используют по-разному. В узком смысле человек почти не читает код и ориентируется на результат на экране. В широком смысле так называют любую разработку с активной генерацией кода. В исследовательской работе об этом подходе автор рассматривает описание намерения на естественном языке как основу процесса. Единого названия недостаточно, чтобы судить о качестве готовой программы: узнайте, кто проверял изменения и какими сценариями.
Как проходит работа с ИИ
Вы задаёте исходную функцию, запускаете полученную версию и сравниваете её с ожиданием. После этого просите исправить конкретное расхождение. Такой цикл удобнее вести небольшими изменениями, которые можно проверить отдельно.
Условный пример: вы собираете внутренний калькулятор стоимости доставки. Сотрудник выбирает зону и вводит вес. Программа должна применять таблицу тарифов и показывать состав расчёта. В первом задании перечислите поля, источник тарифов и правила для пограничных значений. Дизайн можно уточнить после проверки арифметики.
Попросите ИИ перед изменением назвать затрагиваемые файлы и объяснить, где выполняется расчёт. После правки сравните её с заданием. Если ответ содержит только «готово», спросите, какие проверки выполнены и что осталось непроверенным. Сообщение агента о завершении не заменяет ваш просмотр результата.
Дайте ИИ проверяемую задачу
Сравните два задания. «Исправь калькулятор, он считает неправильно» не указывает ожидаемое поведение. «При весе 5 кг программа должна применить строку тарифа до 5 кг включительно; сейчас она выбирает следующий диапазон» описывает ошибку, вход и результат.
Для следующей правки можно использовать такую структуру:
Задача: исправить выбор тарифа на границе диапазона. Вход: зона А, вес 5 кг. Ожидание: тариф для диапазона до 5 кг включительно. Источник правила: приложенная таблица. Ограничение: не менять интерфейс и остальные тарифы. Проверка: случаи ниже границы, на границе и выше неё. Покажи изменённые файлы и результаты проверок.
Это условное задание, а не действующий тариф. В своём проекте укажите реальные правила. Если бизнес-правило ещё не согласовано, сначала согласуйте его с ответственным сотрудником: ИИ может выбрать правдоподобный вариант, который вам не подходит.
Проверяйте значения, а не только внешний вид
Для калькулятора подготовьте набор примеров до исправления. Ожидаемые ответы рассчитайте по согласованным правилам независимо от генерируемой программы.
| Проверка | Что выясняете |
|---|---|
| Значение внутри диапазона | Применяется ли нужная строка тарифа |
| Точная граница диапазона | Нет ли ошибки в сравнении «до» и «включительно» |
| Пустое поле | Понимает ли сотрудник, что заполнить |
| Отрицательное или текстовое значение | Отказывается ли программа от недопустимого ввода |
| Повторное открытие приложения | Сохраняются ли только предусмотренные данные |
| Изменение таблицы тарифов | Понятно ли, откуда программа берёт новую версию |
Для другого приложения набор будет другим. У формы записи проверьте занятое время, отмену и повторную отправку. У каталога проверьте отсутствие товара и длинные названия. Критерии должны следовать вашей задаче.
Сгенерированный тест может повторить ошибку сгенерированного расчёта. Поэтому попросите человека, который знает правила, проверить ожидания. Автоматические тесты затем помогут замечать повторное появление уже найденной ошибки.
Читайте изменения и сохраняйте версии
Перед следующей правкой сохраните рабочую версию в системе контроля версий. Разработчик сможет увидеть, какие строки изменились, и вернуть предыдущее состояние. Если вы не пользуетесь такой системой, попросите настроить её и объяснить порядок сохранения.
Проверяйте, не затронул ли ИИ соседние функции. Исправление расчёта не должно без необходимости менять вход в систему, хранение данных или оформление. Чем больше несвязанных изменений в одной версии, тем труднее найти причину новой ошибки.
GitHub в документации Copilot предупреждает, что агент может предложить неточный или небезопасный код; пользователь отвечает за проверку и тестирование результата. Возможности конкретного продукта отличаются, но для приёмки любого приложения полезно запросить объяснение правок и подтверждение нужных сценариев.
Когда подключить разработчика
Начните с обратимого эксперимента на тестовых данных. Подключите профильного специалиста до работы с реальными платежами, доступами пользователей и данными, потеря которых остановит процесс. Обсудите, как организовать хранение, восстановление и права, а не только добавить следующий экран.
Признаки, что проект требует разбора: одна правка ломает другую, непонятно место хранения данных, никто не может объяснить расчёт, приложение запускается лишь в окружении создателя. Продолжение генерации без понимания причин может увеличить объём переделки.
Если нужен именно сайт, вопросы приёмки разобраны в статье о создании сайта с помощью ИИ. Здесь мы рассматриваем работу с кодом приложения и отдельными изменениями.
Что передать при проверке проекта
Подготовьте исходные файлы, инструкцию запуска, список зависимостей и сценарии с ожидаемыми ответами. Перечислите известные ошибки. Доступы передавайте по согласованному защищённому способу; секреты не вставляйте в публичное описание проекта.
Для обсуждения разработки и доработки проекта полезнее показать одну воспроизводимую ошибку и рабочую версию, чем всю историю переписки с ИИ. Разработчик сможет оценить состояние приложения, проверки и дальнейшие работы.