Czytaj książkę: «Вайбкодинг»

Предисловие

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

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

За последние два года изменился сам набор инструментов. Ещё недавно было разумно говорить, что обычная нейросеть только выдаёт код, который затем приходится самостоятельно переносить в редактор, однако на момент подготовки книги, осенью 2026 года, эта граница почти исчезла. Существуют среды, которые создают работающий веб-проект прямо внутри разговора, программные агенты, способные читать и менять полноценный репозиторий, игровые движки со встроенными ИИ-помощниками и сервисы, которые позволяют прототипировать приложение без локальной установки среды разработки. Именно поэтому в книге не будет одной «правильной» нейросети. Мы будем выбирать инструмент под задачу.

ChatGPT и Codex удобны, когда нужен разговор о проекте и затем работа с файлами и репозиторием; Grok Build и похожие среды позволяют быстро получить интерактивный проект внутри самой ИИ-среды; Gemini Canvas и Claude Artifacts подходят для небольших веб-приложений, инструментов и прототипов; Replit Agent удобен, когда нужно сразу получить работающий облачный проект. Для игр мы отдельно разберём GDevelop, Godot и Unity, потому что эти движки позволяют пройти путь от почти полного отсутствия навыков до настоящего проекта, при этом каждый показывает программирование с другой стороны.

Главная задача книги состоит не в том, чтобы научить писать особенно хитрые промпты. Формулировка запроса имеет значение, но гораздо важнее приобрести привычку работать с программой как с системой, которую можно исследовать, менять и проверять. Если после прохождения книги вы сможете открыть незнакомый проект, понять его основные части, объяснить нейросети требуемое изменение, проверить созданный ею код и самостоятельно определить следующий шаг, значит обучение выполнило свою задачу.

Часть I. Что сейчас можно сделать внутри нейросети

Глава 1. Три разных вида вайбкодинга

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

Самый простой уровень можно назвать генерацией автономного результата. Для небольшой браузерной игры иногда достаточно одного index.html, внутри которого находятся разметка, стили и JavaScript. Такой проект легко отправить другому человеку, быстро открыть и так же быстро выбросить, если идея оказалась неудачной. Именно поэтому однофайловые прототипы полезны не только новичку: опытный разработчик тоже может проверить механику быстрее, чем создаст полноценный проект в движке.

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

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

Полезно уметь пользоваться всеми тремя режимами. Однофайловая генерация хороша для идеи, которую хочется увидеть сегодня; готовая папка проекта нужна, если результат должен жить в Godot, GDevelop или другом движке; агентная работа становится особенно ценной после того, как проект перестал помещаться в одном разговоре и количество связанных файлов выросло.

Глава 2. ChatGPT и Codex: от разговора к проекту

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

Codex следует воспринимать не как «чат, который пишет побольше кода», а как программного агента. Его ценность проявляется тогда, когда задача затрагивает несколько файлов и требует понимания существующей структуры. Вместо того чтобы вручную копировать Player.gd, Enemy.gd, сцену и конфигурацию, можно открыть репозиторий и поставить задачу на уровне проекта: добавить систему здоровья, не менять управление, использовать уже существующий HUD и проверить сценарий перезапуска. Агент сначала изучает код, затем вносит изменения там, где они действительно нужны.

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

Когда однофайловый прототип становится неудобным, попросите разделить его на несколько файлов, но явно запретите менять игровую механику. Это полезное упражнение: вы увидите, что одна и та же программа может быть организована по-разному, а рефакторинг не должен автоматически означать изменение поведения.

С игровыми движками агента можно использовать ещё интереснее. Godot хранит значительную часть проекта в текстовых форматах, поэтому модель способна создать project.godot, текстовые сцены и GDScript-файлы. Unity требует большей осторожности из-за структуры проекта и импортируемых метаданных, поэтому для новичка обычно надёжнее сначала создать пустой Unity-проект в самом редакторе, а затем позволить агенту добавлять скрипты и работать с уже существующей структурой.

Глава 3. Grok Build: приложение или игра внутри разговора

Среды вроде Grok Build показывают другой тип вайбкодинга: пользователь описывает приложение или игру и сразу получает работающую версию внутри самого сервиса. Такой подход особенно хорош для первой проверки идеи, потому что между запросом и реальным взаимодействием почти нет промежуточных шагов. Не нужно создавать папку, ставить зависимости и запускать локальный сервер только для того, чтобы выяснить, что выбранное управление неудобно.

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

Главное достоинство интерактивной генерации заключается в скорости обратной связи. Фраза «персонаж слишком медленный» появляется не из абстрактного чтения кода, а после реальной попытки играть. Если кнопка на мобильном экране оказывается неудобной, это видно сразу. Поэтому такие среды полезно рассматривать не только как конструкторы, но и как лаборатории, где проверяется сама идея продукта.

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