Что такое вайбкодинг и как довести идею до приложения

Допустим, у вас небольшая мастерская, где заказы пока живут в переписке. Один клиент прислал фотографию, второй уточнил стоимость по телефону, а третий забрал готовую вещь, и об этом забыли написать мастеру. Хочется собрать всё в одном месте, чтобы сразу видеть, кто обратился и на каком этапе его заказ. Вы объясняете это ИИ, и он делает экран со списком, статусами и кнопкой «Добавить заявку». На первый взгляд осталось немного: подобрать цвета и можно пользоваться.

Затем вы добавляете заказ, обновляете страницу и обнаруживаете, что список снова пустой. Или даёте ссылку сотруднику, а он видит совсем другие записи. Агент вполне мог сделать рабочую демонстрацию экрана, оставив хранение данных и доступ сотрудников за пределами задачи. Это неприятно, но теперь у вас есть конкретный вопрос для следующего шага: куда уходит созданная заявка и как её потом найдёт мастер. Именно такие вопросы помогают постепенно превратить первое впечатление в приложение, которым можно пользоваться.

Разработку через такой разговор с ИИ часто называют вайбкодингом. Вы описываете желаемое поведение, агент предлагает изменения в коде, а после запуска вы смотрите, что получилось, и уточняете задачу. У слова есть разные трактовки: кто-то имеет в виду эксперимент без чтения кода, кто-то называет так любую работу с ИИ-агентом. Здесь нас интересует практический путь от идеи к версии, которую вы можете проверить и объяснить другому человеку.

Удобнее всего начать с одной операции, которая сегодня доставляет неудобство. В мастерской это может быть потерянный заказ: администратор принял его по телефону, а мастер узнал о нём только после повторного звонка клиента. Для первой версии достаточно сделать так, чтобы обращение сохранялось и попадало в общий список. Когда этот путь заработает, будет гораздо понятнее, какую функцию стоит добавить следующей.

Поэтому просьбу «Сделайте CRM для мастерской» лучше немного раскрыть. Из неё пока не видно, оставляет ли заявку сам клиент или сотрудник записывает её со слов клиента, кто может менять стоимость и кому доступен телефон. Все эти решения влияют на приложение, и без уточнений агенту придётся выбирать за вас. Можно получить аккуратный набор экранов и только потом обнаружить, что он рассчитан на совсем другой порядок работы.

Возьмём более конкретную первую задачу. Сотрудник входит в приложение и записывает имя клиента, контакт и описание работы; новое обращение появляется в общем списке со статусом «Новая». Позже мастер переводит его в «В работе», а после обновления страницы видит сохранённый результат. Люди без доступа к мастерской этот список не читают. Теперь вы можете пройти всю последовательность и проверить, выполняется ли каждый шаг, вместо того чтобы оценивать CRM по общему впечатлению.

Остальные пожелания удобно держать рядом в отдельной заметке. Учёт деталей, склад, оплата и сообщения клиенту могут оказаться нужны, но пока они отвлекут от первой проблемы. Если сотрудники по-прежнему не находят принятый заказ, добавление ещё нескольких экранов ситуацию не исправит. Зато после работы с настоящим списком вы увидите, где именно возникает следующее затруднение, и сформулируете задачу на основе того, что происходит в мастерской.

Чтобы понять, почему заявка теряется, полезно представить её путь внутри обычного веб-приложения. Браузер показывает форму, сервер принимает отправленные сведения и проверяет доступ, а хранилище сохраняет запись между посещениями. Ещё приложение нужно разместить по адресу, который смогут открыть сотрудники. Платформа может собрать эти части в одном интерфейсе, но у каждой всё равно остаётся своя работа, и удачная форма не подтверждает, что выполнены остальные шаги.

Например, список заказов может быть заранее записан в коде, чтобы вам было проще оценить экран. Новые записи иногда остаются только в памяти страницы и исчезают при обновлении. Хранилище браузера позволяет пережить перезагрузку, но само по себе не создаёт общую базу для сотрудников на разных устройствах. Когда мастер должен увидеть заказ, принятый администратором, нужен общий серверный источник данных и понятные правила обращения к нему.

Не обязательно сразу разбирать каждый файл проекта, чтобы выяснить, как это устроено. Попросите агента проследить одну заявку: что происходит после нажатия кнопки, где сервер сохраняет запись и как она попадает обратно в список. Если в объяснении есть только показ уведомления «Успешно», уточните шаг сохранения. Такое уведомление можно вывести даже без записи в базу, поэтому нужно связать его с фактическим результатом отправки.

Следом разберитесь с доступом. Если сотруднику нельзя удалять заказы, скрытая кнопка сделает интерфейс понятнее, но запрет должен действовать и на сервере. Иначе тот же запрос можно отправить другим способом. Сервер проверяет, кто обратился и почему этому человеку разрешено менять именно эту запись; значение isAdmin из браузера для такой проверки не подходит, потому что его может прислать сам пользователь.

Чтобы агент продолжал уже начатое приложение, дайте ему контекст проекта. Нужно объяснить, что существует сейчас, где хранятся записи, как входят сотрудники и в какой среде можно проверять изменения. Без этого новая форма может получить отдельное хранилище и другой вход, хотя на экране всё будет выглядеть как часть одной системы. Данные между этими частями сами не свяжутся, и вам придётся переделывать то, о чём можно было договориться заранее.

Обычно для такого контекста хватает короткой рабочей заметки. Напишите, для кого делаете приложение, какой шаг сейчас нужен и по каким действиям вы будете проверять результат. Например: «Сотрудники входят по учётной записи, список хранится на сервере, новая заявка получает статус “Новая”, клиентского кабинета пока нет». После согласованного изменения обновляйте эту заметку, чтобы следующий разговор начинался с текущего состояния проекта. Пересказывать всю историю переписки каждый раз не потребуется.

Перед правкой попросите агента прочитать существующую реализацию и объяснить, какие её части придётся изменить. Тогда вы сможете сопоставить предложенный план со своим ожиданием. Полезно увидеть конкретный обработчик, текущую схему или обнаруженное ограничение; одна фраза «контекст изучен» ещё не говорит, что агент нашёл нужный код. Пароли и ключи в рабочую заметку не добавляйте — для них используются настройки подключения и секретов выбранной среды.

Дальше двигайтесь небольшими законченными шагами. Сначала добейтесь, чтобы форма сохраняла заявку, потом подключите чтение списка и затем добавьте смену статуса. После каждого шага можно проверить отдельный результат. Если одновременно менять дизайн, авторизацию, календарь и оплату, при ошибке придётся выяснять, какая из четырёх правок её вызвала, и разговор с агентом быстро станет менее понятным.

Работающий шаг стоит сохранить, чтобы было к чему вернуться. Если проект использует Git, это может быть commit с простым описанием вроде «Сохраняем новую заявку»; в платформе для этого может быть свой механизм версий. Перед следующей проверкой посмотрите различия с предыдущим состоянием. Даже без подробного чтения всего кода можно заметить, что при смене цвета кнопки неожиданно исчез файл авторизации, и обсудить это до выпуска.

Если новая правка сломала сохранение, зафиксируйте, как повторить ошибку, и сравните версии. После этого можно отменить конкретное изменение или вернуть проверенный код. У такого возврата есть границы: он не восстановит сам по себе удалённую запись и не отменит уже отправленное письмо. Поэтому эксперименты с данными лучше проводить в отдельной среде, где есть запасные записи для проверки, а не заказы, с которыми сотрудники сейчас работают.

Такой порядок помогает точнее ставить и задачу на исправление. Вместо «поправь всё, что мешает» можно попросить: «Исправь сохранение этой формы, сохрани существующий вход и список, а после покажи изменения и результат повторной проверки». У агента появятся границы работы, а у вас — возможность понять, что изменилось после очередной попытки.

При проверке попробуйте пройти приложение в обычных рабочих условиях. Сотрудник может забыть контакт, дважды нажать отправку или закрыть вкладку раньше, чем пришёл ответ. Создайте заявку, обновите список и войдите заново; затем выйдите из аккаунта и попробуйте открыть прежний адрес. Так вы увидите, сохраняется ли результат между посещениями и что доступно человеку без входа. Именно это поведение потом встретят пользователи, даже если первый показ прошёл гладко.

С отправкой формы есть ситуация, которую легко неправильно понять. Если браузер не получил ответ, это ещё не означает, что сервер ничего не сохранил. Повторный запрос может создать вторую заявку, хотя человек всё время пытался отправить одну. Поэтому приложению нужен способ узнать повтор того же действия или проверить его результат. Блокировка кнопки на время загрузки полезна для интерфейса, но сама по себе не обрабатывает потерянный ответ сервера.

Когда обнаружите ошибку, опишите агенту последовательность, которую можно повторить. Например: «Создал заявку с описанием “Замена тормозов”, получил подтверждение, обновил список, но заявки там нет. Ожидаю увидеть её со статусом “Новая”». Можно добавить адрес среды и снимок сообщения без чужих контактов. Такое описание позволяет искать место, где оборвалось действие, и после исправления пройти ровно тот же путь ещё раз.

Повторяющиеся правила постепенно можно закрепить автоматическими тестами. Для мастерской это допустимые статусы, запрет чтения чужой записи и обработка повторного запроса. Попросите агента объяснить, какое поведение проверяет каждый тест, и показать, сколько тестов действительно выполнилось. Отдельно остаётся сборка: её успешный результат подтверждает, что приложение собрано, а сохранение заказа и удобство формы на телефоне нужно проверить соответствующими действиями.

Пока вы пробуете приложение на запасных данных, ошибки обычно можно спокойно исследовать. Перед переходом к реальным заказам стоит привлечь разработчика, который проверит доступ, хранение секретов, восстановление данных и действия при сбое. Это особенно полезно, если появятся платежи или несколько организаций с разными правами. Агент может подготовить код и описание для такой проверки, а человек сможет оценить конкретную реализацию и её последствия.

Если в какой-то момент стало трудно объяснить, где хранится заявка и почему её видит определённый сотрудник, вернитесь к одной операции и разберите её путь. Добавление новых функций на этом этапе обычно приносит ещё больше вопросов. Когда вы снова понимаете сохранение, чтение и публикацию текущей версии, следующую задачу и поставить, и проверить становится проще.

Пройти этот путь можно и в Agnostic. Проект с выбранным окружением задаёт место работы, Data хранит записи, а App Auth используется для входа пользователей приложения. Внешний агент подключается через MCP; для работы с кодом проекта локально есть CLI. С такой основой вы можете обсуждать с агентом уже поведение мастерской: кому видны заявки, кто меняет статус и при каких условиях заказ считается закрытым.

Ниже приведена задача для первой версии списка заявок. Мы начнём с сохранения обращения и работы сотрудников, а к оплате и бронированию времени можно будет вернуться отдельными шагами. Если App ещё не создан, в Agnostic его сначала создают в Live; это подготовка приложения, которая сама по себе ничего не публикует для пользователей. После этого согласуйте с агентом работу над существующим App и проверку его версии в Preview.

Подготовь первую версию учёта заявок мастерской в Agnostic.

Сначала назови выбранные проект и окружение, прочитай текущий
контекст и доступные действия. Если работаешь во внешнем редакторе,
проверь Agnostic MCP. При отсутствии подключения помоги выбрать
проект и окружение, получить инструкцию из меню MCP и покажи план
настройки. Продолжи после авторизации в браузере.
Инструкция: https://agn0.ru/blog/connect-cursor/.
Для изменений кода используй workspace выбранного проекта;
если его нет, помоги получить через Agnostic CLI.
Если стартового App нет, сначала объясни его создание в Live.
Создание App не считай разрешением на публикацию в Live.

Сотрудник входит через App Auth Agnostic, создаёт заявку
с именем, контактом и описанием работы, затем видит её в списке.
Статусы: новая, в работе, закрыта. Данные сохраняй в Data Agnostic
через текущий Runtime SDK на сервере. Сервер проверяет права
на чтение и изменение; клиент не получает runtime-токен.
Используй тестовые контакты. Сначала покажи план и ограничения,
затем реализуй небольшими проверяемыми шагами.
Опиши и проверь защиту от повторного создания одной заявки,
не обещая неподтверждённых возможностей хранилища.

Подготовь Preview существующего App в согласованной среде,
дай адрес и проверь создание, обновление страницы, повтор,
ошибку ввода и доступ без входа. Live публикуем отдельно.

Когда получите адрес Preview, создайте заявку с описанием, которое легко найти, и проверьте её после обновления страницы и нового входа. Затем предложите будущему пользователю записать заказ без ваших подсказок. Возможно, он не поймёт название поля или не заметит, где меняется статус. У вас появится конкретное наблюдение для следующей правки, и вы сможете продолжить работу с понятной задачей.