Пару месяцев назад я навайбкодил свою первую мини-игру, в которой машинка бесконечно уезжает в закат по пустынной дороге. Игра доступна в виде Telegram Web App.

Игру сделал с помощью Cursor, весь код сгенерирован моделью claude-3.7-sonnet. На примере этой игры хочу рассказать, с какими сложностями я столкнулся и так ли это просто — писать код с помощью нейросетей.

Не пытайтесь уместить огромное ТЗ со всеми нюансами реализации в один промпт Лично в моём случае более результативным оказалось строить маленький MVP и шаг за шагом его улучшать. Мой стартовый промпт выглядел так:

Создай веб игру на threejs, где нужно с помощью WASD управлять машинкой и уезжать в закат по пустынной дороге. Дорога всегда идёт вперёд и генерируется динамически перед игроком.

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

Используйте чекпоинты и перефразируйте промпты Если нейросеть не может исправить ваш баг, не нужно бесконечно писать ей «всё равно не работает», «до сих пор ошибка» и т.д. — она просто нагенерит костылей поверх костылей и вы быстро всё сломаете.

Вместо этого вернитесь в курсоре на тот чекпоинт, где вы только начали исправлять ошибку, и перефразируйте свой промпт.

Проверяйте код, который генерирует нейросеть Если знать нюансы реализации, становится гораздо проще просить нейросеть вносить изменения.

Например, в моей игре был баг: если проехать достаточно далеко от старта, у неба ломался градиент. И я мог бы бесконечно продолжать просить нейросеть «почини градиент», если бы в какой-то момент не решил заглянуть в код. Оказалось, что градиент на небе — это сфера, которая просто стоит на месте. И градиент не ломался, просто игрок выезжал за пределы этой сферы.

Используйте git Да, в Cursor есть чекпоинты, но я всё же рекомендую коммитить изменения в git каждый раз, как вы получаете какой-то стабильный инкремент. Иначе есть риск, что нейросеть поломает вам что-нибудь, над чем вы долго работали.

Не пытайтесь быть вежливыми Не нужно говорить нейронке «пожалуйста», «спасибо», по всякому её хвалить и быть учтивым — этим вы только потратите свои силы, время и токены.

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

При этом, свои идеи по добавлению новых функций тоже можно разбить на более мелкие этапы.

Например, такую задачу: Добавь автомобилю шкалу здоровья и отнимай по 10% при каждом столкновении. Когда здоровье доходит до 0, показывай экран Game Over

Я разбил на несколько более простых задач: - Добавь коллизии; - Добавь автомобилю шкалу здоровья, отнимай здоровье машины при столкновении; - При достижении 0 показывай экран Game Over; Разрабатывая фичи по отдельности, мы меньше рискуем что-то сломать и упрощаем себе тестирование этих доработок.

Создавайте новый чат под каждую новую доработку Нет смысла обсуждать доработку фар автомобиля в том же чате, в котором вы обсуждали цвет неба. Эта информация будет только засорять контекст.

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

Выводы Интересно, что в вайб-кодинге на первый план выходят фундаментальные вещи: использование git, соблюдение принципов KISS, DRY или SOLID. Без них вайб-кодить будет гораздо сложнее, а результат — менее стабильным.

О судьбе игры я буду периодически писать здесь или у себя в телеграм-канале)