Вы описываете трекер откликов обычными словами, а ИИ создаёт форму, список и фильтры. Это вайбкодинг: приложение собирают через запросы, запуск и уточнения результата. Начать можно с небольшого проекта, постепенно разбираясь в коде и проверяя, что происходит после каждого изменения.
Разберём учебный трекер откликов: от первого запроса до проверки сохранения, фильтров и удаления. По ходу станет понятно, какие знания помогают управлять ИИ, почему красивый экран ещё не доказывает готовность приложения и что показать в портфолио.
Что такое вайбкодинг
Вайбкодинг, или vibe coding, обычно означает создание программы через запросы к ИИ с короткими циклами проб и исправлений. Термин употребляют по-разному: от почти полного доверия генерации до обычной разработки с активным участием ассистента. Для учебного проекта полезно заранее определить свою границу: какие решения вы принимаете самостоятельно и что способны проверить.
Главное изменение касается способа постановки задачи. Вместо самостоятельного написания каждой строки вы описываете нужное поведение, изучаете изменения и проверяете их на примерах. Язык программирования остаётся внутри проекта, даже если первый результат получен обычным русским запросом.
Представьте трекер откликов. Вы просите добавить компанию, должность и статус, а ИИ создаёт форму и список. На экране всё выглядит убедительно, но после перезагрузки записи могут исчезнуть. Именно проверка сохранения отделяет демонстрацию интерфейса от работающего сценария.
В инженерной работе с ИИ разработчик понимает устройство системы, проверяет изменения и отвечает за последствия. В экспериментальном вайбкодинге часть этих знаний может появляться по ходу. Это удобный способ исследовать идею, если ошибки ограничены учебными данными и результат не выдают за проверенный продукт.
Какие задачи подходят для вайбкодинга
Для старта подходят задачи с понятным результатом, небольшим числом состояний и обратимыми ошибками. Например, калькулятор на вымышленных данных, интерактивный прототип или личный список. Если сбой затрагивает чужие деньги, доступы или рабочие документы, требования к реализации и проверке резко возрастают.
| Задача | Что можно получить | Что обязательно проверить |
|---|---|---|
| Учебный трекер откликов | Форма, статусы, фильтр, локальное сохранение | Восстановление записей и отсутствие реальных персональных данных |
| Прототип страницы мероприятия | Композиция, адаптивная вёрстка, навигация | Читаемость, клавиатура, узкий экран, работа ссылок |
| Калькулятор по известной формуле | Ввод значений и расчёт результата | Формула, единицы измерения, ноль и недопустимые значения |
| Внутренний рабочий сервис | Черновик сценария и интерфейса | Права, данные, журналирование, поддержка и согласование с владельцем системы |
| Платёжный или медицинский продукт | Только изолированная демонстрация идеи | Полноценная предметная и инженерная экспертиза до реального использования |
Ограничьте первую версию одним главным действием. Для трекера это добавление отклика и изменение его статуса. Синхронизация, автоматическая рассылка, импорт резюме и аналитика по работодателям могут подождать: каждая функция добавляет новые данные, сбои и правила доступа.
Удобный признак подходящей задачи: результат можно проверить вручную по короткому сценарию. Если вы не знаете, каким должен быть правильный ответ, ИИ легко создаст правдоподобную ошибку. Для сложной предметной области сначала найдите человека, который поможет сформулировать критерии.
Запишите и то, что проект не делает. Учебный трекер не отправляет отклики, не подключается к почте, не хранит резюме и не работает для нескольких пользователей. Эти ограничения уменьшают объём работы и не дают случайно превратить упражнение в систему с чужими данными.
Какие инструменты нужны для старта
ИИ для вайбкодинга можно использовать через чат, редактор кода с ассистентом или сервис сборки приложений. Выбирайте среду, где видны созданные файлы, изменения и ошибки запуска. Возможность сохранить рабочую версию важнее впечатляющей демонстрации на главном экране.
| Формат | Когда удобен | Где потребуется внимание |
|---|---|---|
| Чат с генерацией кода | Небольшой пример и разбор отдельной функции | Нужно самостоятельно переносить файлы и запускать проект |
| Редактор с ИИ-ассистентом | Работа с существующей папкой и последовательными изменениями | Смотреть список изменений в файлах и понимать команды перед запуском |
| Визуальный конструктор с генерацией | Быстрый прототип интерфейса | Уточнить экспорт, хранение данных и условия размещения |
Возможности конкретного инструмента зависят от тарифа, клиента и настроек организации. Не выбирайте среду только по списку моделей. Проверьте, можно ли забрать исходники, вернуться к предыдущему состоянию и продолжить работу без текущего сервиса.
Понадобятся редактор с ИИ-ассистентом, браузер и Git, система сохранения версий проекта. Браузер показывает интерфейс и ошибки, редактор хранит файлы, Git позволяет вернуться к рабочему состоянию. Для начала выберите обычные HTML, CSS и JavaScript без дополнительных библиотек.
Создайте папку проекта и откройте её в редакторе. Ассистенту достаточно доступа к этой папке. Попросите сначала перечислить файлы, которые он создаст, затем просмотрите изменения, сохраните их и откройте приложение. Команды установки выполняйте после объяснения, зачем они нужны.
Различия между форматами подробнее разобраны в материале про AI-ассистентов в разработке. Здесь важнее выбрать одну среду и научиться получать воспроизводимый результат, чем постоянно переносить задачу между сервисами.
Как подготовить задачу для ИИ
Хороший запрос описывает пользователя, действие, данные, ограничения и признак успеха. Он помогает проверить результат, даже если ИИ выберет другой способ реализации. Фраза «сделай красиво и удобно» не задаёт ни поведения формы, ни правил сохранения.
Слабый запрос. Сделай современный трекер поиска работы со всеми нужными функциями. Пусть всё работает и выглядит профессионально.
Рабочий запрос. Создай учебное приложение для одного человека. Можно добавить компанию, должность и статус отклика. Обязательны компания и должность. Статусы: «Отправлен», «Собеседование», «Отказ», «Оффер». Записи сохраняются в этом браузере. Без регистрации, внешних API, рассылок и реальных контактов. Сначала предложи структуру и критерии приёмки, затем дождись решения по реализации.
Следующим сообщением уточните спорные места. Допустимы ли одинаковые компания и должность? Что происходит при пустой строке из пробелов? Когда очищается форма? Ответы должны попасть в требования до генерации, иначе разработка превратится в исправление разных догадок.
Опишите состояния интерфейса отдельно. У списка есть пустое состояние, у формы есть ошибка, у фильтра есть результат без совпадений. Если эти состояния не заданы, ИИ часто показывает только счастливый путь, где пользователь ввёл корректные данные и сразу получил ожидаемый результат.
Попросите перечислить допущения и предложить минимальный план. Для каждого шага нужен наблюдаемый результат: сначала форма и отображение, затем сохранение, затем фильтр. Общее обещание «реализовать приложение» плохо помогает выяснить, на каком этапе появилась ошибка.
Сохраните исходное описание рядом с проектом. При следующем запросе ссылайтесь на конкретное правило, а не пересказывайте задачу по памяти. Если решение поменялось, обновите требования: противоречивые сообщения заставляют ассистента выбирать, какой версии верить.
Первый проект: трекер откликов
Для учебного трекера попросите ИИ создать index.html со структурой страницы, styles.css с оформлением и app.js с логикой. Уточните, что CSS и JavaScript должны подключаться к HTML. Сначала получите пустую форму и список, затем добавляйте поведение.
Запускайте страницу по одному адресу через небольшой сервер на своём компьютере. Если установлен Python 3, откройте терминал в папке с этими файлами и выполните команду ниже. Затем введите в браузере http://127.0.0.1:8000: должна появиться ваша форма.
python3 -m http.server 8000 --bind 127.0.0.1Если вместо формы виден список файлов, проверьте, что терминал открыт в папке с index.html. Если оформление не загрузилось, сверяйте имя CSS-файла и путь подключения. При ошибке JavaScript откройте инструменты разработчика браузера и вкладку Console, затем передайте ассистенту текст сообщения.
Опишите данные и правила
Одна запись содержит идентификатор, название компании, должность, статус и заметку. Идентификатор отличает записи, даже когда названия совпадают. Заметка необязательна: отсутствие комментария не должно мешать добавить отклик.
В этом упражнении разрешим повторные отклики, включая одинаковые компанию и должность: человек может вернуться к той же вакансии позже. У каждой записи остаётся отдельный идентификатор. Удаление и изменение статуса должны относиться к нему, а не к совпадающему названию.
Запрос на первый шаг. Реализуй форму и список без сохранения. Используй вымышленные примеры «Северная студия» и «Маяк». Поля «Компания» и «Должность» обязательны после удаления пробелов по краям. При ошибке сохрани введённый текст и покажи сообщение рядом с полем. Пока не добавляй фильтры и редактирование.
Проверьте ввод с клавиатуры и порядок фокуса. Добавьте запись, убедитесь, что значения попали в нужные поля списка. Затем отправьте пустую форму. Ошибка должна объяснять исправление, а не просто выделять рамку красным цветом.
Добавьте сохранение без лишних обещаний
Сохраним список в localStorage, встроенном хранилище браузера. Данные привязаны к браузеру и адресу сайта: протоколу, домену и порту. Поэтому открывайте трекер по тому же адресу 127.0.0.1:8000. Другой порт или другой браузер покажет отдельное хранилище.
В запросе потребуйте обработать недоступное или повреждённое хранилище. Если чтение не удалось, интерфейс должен объяснить проблему. Молчаливое создание пустого списка может выглядеть как потеря всех откликов, хотя приложение просто не разобрало сохранённые данные.
Добавьте вымышленную запись и обновите страницу: запись должна остаться. Откройте тот же адрес в браузере, где трекером ещё не пользовались: там список будет пустым. Вернитесь в первый браузер и проверьте исходную запись. Так вы увидите, чем сохранение в браузере отличается от синхронизации между устройствами.
Реализуйте изменение статуса и фильтр
Попросите менять статус по идентификатору записи. Фильтр должен выбирать отображаемые строки, сохраняя полный список отдельно. Если хранить только отфильтрованный результат, переключение статуса может случайно удалить данные из памяти приложения.
Критерий приёмки фильтра. Есть отклики со статусами «Отправлен» и «Собеседование». После выбора «Собеседование» видна подходящая запись. После возврата к «Все» видны обе. Перезагрузка страницы не удаляет скрытую запись. Изменение статуса относится к выбранному отклику, а не к строке с таким же номером на экране.
Удаление добавляйте после проверки этих сценариев. Уточните способ подтверждения или отмены действия. Для учебного проекта допустимо простое подтверждение, если текст объясняет, какая запись исчезнет. Само наличие диалога ещё не доказывает, что удаляется нужный объект.
В конце каждого этапа сохраняйте рабочую версию. Название изменения должно передавать результат: «добавлено сохранение откликов», а не «исправления». Тогда можно вернуться к последнему исправному состоянию, не пытаясь угадать, какой из длинных запросов всё сломал.
Как исправлять ошибки в сгенерированном коде
Передавайте ИИ воспроизводимый сценарий, ожидаемый результат и фактическое поведение. Приложите текст ошибки и нужный участок кода, если он известен. Просьба «проверь всё и почини» расширяет изменение и затрудняет поиск причины.
Допустим, после фильтрации меняется статус другого отклика. Возможная причина в учебном примере: обработчик использует индекс строки отфильтрованного списка для доступа к исходному массиву. Это гипотеза до чтения кода. Её надо подтвердить по обработчику, а не объявлять причиной только по похожему симптому.
Сообщение об ошибке. Добавлены «Северная студия / frontend» и «Маяк / верстальщик». Первая запись имеет статус «Отправлен», вторая «Собеседование». Фильтрую по собеседованию и меняю видимый статус на «Оффер». Ожидаю изменение записи «Маяк», фактически меняется «Северная студия». Найди обработчик и объясни причину до правки. Сохранение и форму не перерабатывай.
После исправления повторите исходный сценарий, затем соседний: изменение статуса без фильтра. Так вы проверите и исчезновение ошибки, и сохранность обычного поведения. Если ассистент переписал весь проект ради одной строки, остановитесь и разберите необходимость каждого изменения.
При ошибке запуска сохраните полное сообщение, команду и рабочую папку. Последняя строка лога не всегда содержит причину. Перед отправкой удалите секреты и реальные данные. Скриншот красного экрана полезен как дополнение, но текст ошибки удобнее искать и анализировать.
Если после правки возникла новая проблема, сравните файлы с рабочей версией. Такой список изменений называют diff. Найдите, что затронуло сломанный сценарий: обработчик формы, фильтр или сохранение. Отмените неудачный шаг, если его проще сделать заново, чем чинить цепочку случайных правок.
Как проверить результат вайбкодинга
Проверьте ввод, сохранение, фильтры и управление с клавиатуры на вымышленных записях. Начните со сценариев из таблицы. Рядом с каждым запишите фактический результат и ошибку, если она появилась.
| Сценарий | Ожидаемый результат | Какую ошибку обнаруживает |
|---|---|---|
| Пустая компания или одни пробелы | Запись не создаётся, текст остальных полей сохранён | Формальная проверка только длины строки |
| Длинная должность на узком экране | Название читается, кнопки доступны | Сломанная вёрстка и выход за пределы экрана |
| Перезагрузка после изменения статуса | Сохраняется новое значение | Расхождение состояния интерфейса и хранилища |
| Фильтр без совпадений | Показано объяснение, общий список не удалён | Потеря данных при фильтрации |
| Удаление одной из одинаково названных записей | Удаляется выбранный идентификатор | Ошибочная привязка действий к тексту или позиции |
| Работа только клавиатурой | Видимый фокус, доступные поля и кнопки | Зависимость интерфейса только от мыши |
Отдельно проверьте текст, похожий на разметку. Название компании должно отображаться как текст, а не выполняться как код страницы. Не вставляйте случайные опасные примеры в рабочий сервис: для такой проверки нужна отдельная учебная среда.
Проследите путь одной записи: значение из поля попадает в объект, затем в список и хранилище. Попросите ассистента показать соответствующие участки кода. Если на экране новый статус, а после обновления старый, ищите, где изменение не дошло до сохранения.
Автоматические тесты полезны для повторяемой логики, например проверки полей или выбора записи по идентификатору. Они не доказывают удобство интерфейса и не охватывают неизвестные требования. Начните с проверок тех ошибок, которые реально возможны в вашем сценарии.
Попросите другого человека открыть проект по вашей инструкции. Если он не нашёл нужный файл или команду, дополните описание. Такой прогон быстро показывает пропущенные шаги, которые автор выполняет по памяти.
Когда прототипу нужна инженерная доработка
Доработка нужна, когда приложение выходит за пределы изолированного упражнения. Совместная работа, реальные контакты, авторизация и интеграции требуют отдельного проекта хранения, доступа и восстановления. Добавить экран входа недостаточно: система должна проверять права при каждом обращении к защищённым данным.
В трекере для нескольких людей нельзя доверять переданному из браузера идентификатору владельца. Сервер должен установить пользователя и разрешённые действия самостоятельно. Иначе визуально скрытая чужая запись может оставаться доступной через запрос.
Ключ внешнего API не должен попадать в общедоступный код страницы. Для интеграции потребуется безопасное хранение секретов и ограничение полномочий. До подключения выясните, какие данные уйдут провайдеру, где они сохранятся и кто отвечает за удаление.
Зависимости тоже требуют внимания. Генерация может предложить ненужный пакет, устаревший способ настройки или имя, похожее на известную библиотеку. Проверяйте официальный источник, назначение и условия использования до установки, особенно если пакет просит широкий доступ.
Перед совместным использованием решите, как восстанавливать список после сбоя и кто будет исправлять ошибки. Попробуйте вернуть данные из резервной копии на отдельном примере. Это следующая задача после учебного трекера, когда появляются сервер и настоящие пользователи.
Что учить помимо промптов
Обучение вайбкодингу полезнее строить вокруг объяснения собственных решений. Для браузерного проекта начните с HTML, CSS, JavaScript и инструментов разработчика. Затем добавьте Git, HTTP и базовую работу с данными. Глубина нужна такая, чтобы находить границу ошибки и проверять предложенную правку.
| Тема | Задача на трекере | Признак понимания |
|---|---|---|
| HTML и доступность | Подписать поля, настроить кнопки и фокус | Можете объяснить отличие кнопки от декоративного блока |
| CSS | Уместить длинные названия на узком экране | Находите правило, вызывающее переполнение |
| JavaScript | Обновить запись по идентификатору | Понимаете массив, объект, условие и обработчик события |
| Браузерные инструменты | Найти ошибку и проверить хранилище | Отличаете сбой кода от отсутствующего сетевого ответа |
| Git | Сохранить этап и отменить неудачную правку | Читаете diff и возвращаете нужную версию |
| HTTP и сервер | Спроектировать будущую синхронизацию | Различаете данные клиента, сервера и права доступа |
На курсах вайбкодинга ищите разбор ошибок и задания с самостоятельной доработкой. Например, нужно добавить редактирование записи и сохранить работу фильтра. Преподаватель должен помочь понять причину сбоя и проверить решение, а не только показать красивую демонстрацию.
Оценивайте прогресс по задачам: можете добавить поле без потери записей, понять изменение и вернуть рабочую версию. Если для каждого сбоя приходится заново генерировать приложение, вернитесь к устройству списка и обработчикам. Они дают больше самостоятельности, чем очередной набор промптов.
Следующий полезный шаг после личного трекера: выполнить ограниченную задачу с чужими требованиями. Сравните её с разбором тестового задания frontend-разработчика. Такая работа показывает, умеете ли вы соблюдать согласованные требования, а не только развивать собственную идею.
Как показать проект в портфолио
Показывайте задачу, результат и границы своей ответственности. Работодателю полезнее увидеть понятный репозиторий с запуском и проверками, чем переписку с сотней запросов. Прямо напишите, где использовали ИИ и какие решения проверяли самостоятельно.
В README, инструкции к проекту, опишите назначение трекера, основные сценарии, установку и ограничения хранения. Добавьте изображения интерфейса и короткую демонстрацию добавления, фильтрации и восстановления записи. Скриншот должен соответствовать той версии, которую человек получит после запуска.
Приведите один содержательный разбор ошибки. Например: фильтр менял не ту запись, потому что обработчик опирался на индекс отображаемого массива. Затем покажите подтверждение причины, изменение и сценарий проверки. Это раскрывает вашу работу убедительнее, чем фраза «разработал приложение с ИИ».
Отдельно перечислите незавершённое: нет синхронизации, совместного доступа и гарантий восстановления после очистки браузера. Такая запись помогает честно оценить проект. Не приписывайте учебному инструменту реальных пользователей и экономию времени, если вы их не измеряли.
Оформление репозитория можно сверить с руководством по GitHub и pet-проектам для junior-разработчика. После этого сравните свои навыки с требованиями в вакансиях frontend-разработчиков: учитывайте задачи позиции, а не одно упоминание ИИ.
