Вайбкодинг на практике - бесплатный курс. Урок 2. Исправляем ошибки
Что это за курс
Я решил на практике показать, как создать приложение с помощью вайбкодинга — от идеи до готового продукта. Это не строгий курс с пошаговой инструкцией «как надо». Мы пройдём весь живой процесс со всеми ошибками, сложностями и решениями. Весь курс будет опубликован здесь бесплатно, поэтому ставьте реакции на пост, задавайте вопросы в комментариях — так больше людей сможет увидеть курс.
Первую часть и описание идеи продукта можно найти здесь:
Привет! Меня зовут Николай Шкута. Я отвечаю за направление «Слияния и поглощения» в крупной брокерской компании и руковожу командой профессиональных консультантов.
Параллельно запускаю свои пет-проекты — например, BJJConnect (платформа для занимающихся бразильским джиу-джитсу).
Результаты первой итерации
В прошлом уроке мы сделали первые шаги и получили не очень хороший результат.
Ожидания не совпали с реальностью по простой причине: мы поленились подробно описать желаемый результат. Нейросеть что-то додумала сама, что-то не сделала — потому что мы этого не потребовали. В итоге получили то, что получили.
Давайте попробуем это исправить
Напишем промпт: по порядку укажем, что нам не понравилось и как должно быть. Просто своими словами, но для начала используем скилл /prompt-master описанный в прошлом уроке
Здесь я использовал один из приёмов, который мне помогает: перед реализацией попросил изучить лучшие практики и статьи в интернете по нужной теме.
То, что выдал Prompt Master, я сначала запустил в режиме планирования. В результате получился большой подробный план реализации — я утвердил его без изменений. Весь план приводить не буду, но, например, модель сама выбрала материалы, на которые будет опираться:
Источники (URL + зачем):
NN/G: AI prototyping — без явного языка экраны шаблонные. UXmatters: Calm screens — спокойствие от сетки, не от пустоты.
925 Studios: AI slop — признаки слопа.
SmoothUI: AI design slop — градиент, стекло, одинаковые карточки. Carbon color — синий как действие, серые слои.
Carbon expressive — 16px чтение, 14px хром.
Primer color — белая бумага, акцент #0969da.
Google Docs: suggest — правка в потоке.
Word: modern comments — комментарий у якоря.
Contractbook — suggested change + comment в продукте.
Conga compare — markup в одном просмотрщике.
Kontrak IQ — документ и статус пункта вместе; дашборды портфеля не копировать
Если бы в промпте не было явного указания изучить источники, агент, скорее всего, не стал бы собирать и разбирать такую подборку.
Этот подход заметно повышает качество результата у недорогих моделей.
Давайте посмотрим, что получилось:
И в мобильном представлении чтобы проверить адаптивность:
Сейчас интерфейс уже не вызывает отторжения и больше похож на то, что хотелось бы видеть в итоге.
Обратная связь
В прошлом уроке в комментариях я получил несколько ценных рекомендаций. Спасибо за это.
Их суть заключалась в том, что описанный подход к разработке выглядит стихийным. Это действительно так. Я сознательно делаю продукт не так, как это делал бы профессиональный разработчик.
Нам важно не только получить готовый результат, но и не потерять мотивацию в процессе. Для этого на раннем этапе можно позволить себе некритичные ошибки. Со временем, когда продукт обрастёт архитектурой и кодом и появятся реальные пользователи, такой подход станет недопустимым. Я постараюсь вовремя показать, когда нужно повышать стандарты качества.
А на ранних этапах просто наслаждаемся творчеством.
Что дальше?
Следующий этап — продумать user flow: разные сценарии того, как продукт будут использовать в реальной жизни, — и сделать прототип более похожим на настоящее приложение, прежде чем приступать к разработке.
Версия документации по результатам данного урока здесь
Не забудьте подписаться на мой канал «Своими словами». Там я не только пишу про нейросети, но и делюсь своей практикой в управлении командой консультантов по сделкам M&A
Предыдущие уроки:
Урок 0
Урок 1. Первые шаги и разочарование в результате
Следующий урок:
Урок 3. Продумываем user flow