Я программист. Мог написать игру руками. Но когда понадобилась мультиплеерная “Угадай мелодию” для семейных вечеров, я взял Claude Code и описал ему задачу - а не открыл редактор и не начал писать код с нуля.
За 3 дня и 57 промптов появилось полноценное приложение с WebSocket-синхронизацией между ТВ и телефонами. Первый день ушёл на планирование и основной функционал. Дни второй и третий - на фикс багов, редизайн и загрузку треков.
Ниже - как это работает, и почему вы тоже можете это сделать.
Вайб-кодинг - это не “скопировал из ChatGPT”
Вайб-кодинг ввёл в обиход Andrej Karpathy в феврале 2025 - бывший AI-лид Tesla, соучредитель OpenAI. Он описал подход одной фразой: “The hottest new programming language is English”. Collins Dictionary назвал “vibe coding” словом года 2025.
Суть простая. Вместо того чтобы писать каждую строку самому, вы описываете AI, что хотите получить, - и проверяете результат. Работает? Хорошо. Не работает? Следующий промпт описывает проблему.
Это радикально отличается от “я нашёл код в ChatGPT”. Там вы берёте чужой фрагмент и пытаетесь вставить его в свой контекст. Здесь AI строит для вас. Разница - как между “нашёл кирпич” и “попросил архитектора спроектировать здание”.
Три вещи, на которых держится подход. Первое - намерение: вы думаете о результате, а не о деталях реализации. Второе - итерация: каждый промпт уточняет предыдущий, приложение растёт маленькими шагами. Третье - обучение в процессе: вы видите, что сломалось, описываете это, видите, как исправилось.
К 2026 году большинство крупных компаний используют AI-инструменты разработки. По данным нескольких отраслевых отчётов за конец 2025 - начало 2026 года, значительная часть нового кода уже создаётся с участием AI. Это уже не эксперимент - это рабочий процесс.
Что я построил: “Угадай мелодию”
Party game для семьи или компании. Ведущий управляет игрой с телефона, гости смотрят на большой экран.
На ТВ - тёмный неоновый дизайн: подсказки, анимированные музыкальные волны, счёт команд, ответы после раскрытия. Экран проходит через пять состояний - лобби, воспроизведение, раскрытие ответа, таблица результатов, финал. Только отображение, никаких кнопок.
На телефоне - светлая тёплая тема, компактная админ-панель для управления одной рукой. Play, Stop, Reveal, навигация между треками, начисление очков командам (+1, +2, +3, -1). Всё под большим пальцем.
Когда ведущий нажимает Play на телефоне, на ТВ мгновенно начинает играть музыка. Это WebSocket: не ждём запроса, не опрашиваем сервер раз в секунду - постоянный канал, сигнал проходит за миллисекунды. Обновил счёт команде - все экраны увидели новое число одновременно.
Для подключения устройств - QR-код. Навёл камеру телефона, попал на нужный адрес. Нет приложений, нет установки - обычный браузер.
Под капотом: монорепо с Express + better-sqlite3 + Socket.io на сервере, React + Tailwind + DaisyUI на клиенте. База данных - шесть таблиц SQLite: треки, игры, этапы, связи треков и этапов, сессии, команды. Редактор игр с drag-and-drop и waveform-визуализацией через wavesurfer.js. Идентификатор сессии - шестизначный nanoid вроде A3F9K2.
Момент, который часто забывают уточнить: AI помог мне построить это приложение. Но когда семья садится играть, никакого AI внутри нет. Обычный веб-сервер, SQLite-файл, браузер. AI был инструментом строительства - как молоток при возведении дома. Дом потом стоит сам.
Почему 57 промптов, и как они организованы
Один большой промпт “сделай мне игру с WebSocket” не работает. AI сгенерирует что-то, но это будет хаотично, половина деталей будет додумана не так, как вам нужно, и первые же правки потребуют переписывать большие куски.
57 промптов - это не случайное число. Структурированные маленькие шаги, каждый из которых решает одну задачу и опирается на контекст предыдущего.
Как выглядела последовательность. Сначала - инициализация монорепо, схема базы данных, конфигурация. Потом REST API для треков, для игр и этапов, для сессий и команд. Затем WebSocket-события - как синхронизировать Play, Stop, Reveal между устройствами. Параллельно с бэкендом - UI: экран для ТВ, панель администратора, редактор игр. Под конец - детали: QR-код, анимации счёта, drag-and-drop в редакторе, редизайн интерфейсов.
Отдельно про анимации - хороший пример того, как итерация работает на практике. Первая версия анимации счёта была сделана на CSS keyframes. На большом количестве команд начинало лагать. Claude Code предложил переписать на requestAnimationFrame с Math.sin() - и анимация стала плавной даже при максимальной нагрузке. Два промпта, пять минут, проблема решена. Вручную на такое отладочное исследование ушло бы полдня.
Первый день дал основной функционал. Остальное время ушло на то, что всегда занимает время независимо от способа разработки: доводить детали, чинить баги на реальном устройстве, загружать контент. Это честная картина: вайб-кодинг ускоряет написание кода, но не устраняет реальность разработки - тестирование, правки, полировка.
Технические концепции на пальцах
Если вы не программист, вот три ключевые идеи.
WebSocket - это рация, не почта. Обычный HTTP работает как почта: вы отправляете запрос, сервер отвечает, соединение закрывается. Для каждого следующего вопроса - новое соединение. Для игры это слишком медленно. WebSocket открывает постоянный канал: сервер может отправить сообщение в любой момент, без запроса с вашей стороны. Ведущий нажимает Play - все устройства получают сигнал за миллисекунды.
База данных - это связанные таблицы. SQLite здесь выбран осознанно: не PostgreSQL, не облачная база, а файл на диске. Для локальной сети это быстрее и проще. Шесть таблиц, WAL mode для надёжности - и всё развёртывается за секунды. Синхронная библиотека better-sqlite3 вместо асинхронной, потому что на локальных операциях это быстрее.
Синхронизация - это сервер как источник истины. Когда ведущий начисляет очко команде, телефон не обновляет счёт сам. Он отправляет команду серверу. Сервер проверяет, обновляет базу, рассылает новое состояние всем подключённым устройствам. ТВ, все телефоны - показывают одно число одновременно. Побочный эффект - читинг невозможен: нельзя послать себе “+1000 очков”, сервер это не пропустит.
Socket.io при этом управляет “комнатами”. Каждая сессия - отдельная комната по коду A3F9K2. Событие score:updated в вашей игре не попадёт в другую игру, которая идёт на том же сервере. Изоляция автоматическая.
Что реально помогло при разработке
CLAUDE.md в корне проекта. Первый же день я создал файл, который описывал архитектуру: стек, таблицы базы, список WebSocket-событий, соглашения по коду. Claude Code читает этот файл при каждом обращении. Вместо того чтобы объяснять “у нас монорепо, ES modules, сервер на 3101” в каждом промпте - один раз написал, дальше AI следовал правилам автоматически.
Планирование до первой строки кода. День ушёл на то, чтобы описать точно: два интерфейса, шесть таблиц, какие события ходят по WebSocket, как выглядят экраны. Это скучно. Зато потом промпты шли чётко, потому что AI знал, куда идти - и я знал тоже.
Один промпт - одна задача. Не “добавь drag-and-drop, анимации счёта и QR-код”. А три отдельных промпта, каждый с чётким описанием задачи. AI лучше справляется с узкими задачами, и вы лучше видите, что именно изменилось.
Чтение кода после каждого промпта. Быстро пробежать глазами, что AI сгенерировал - не обязательно понимать каждую строку, но понять структуру. Это экономит время на отладку позже. Исследования показывают, что AI-сгенерированный код без проверки чаще содержит уязвимости безопасности - просматривать выдачу стоит всегда.
Подводные камни, которых я ждал
“Vibe coding hangover”. Создал быстро - не понимаешь свой код через месяц. Это реальная проблема, не теоретическая. Решается документированием: не только что сделано, но почему именно так. Зачем SQLite, а не PostgreSQL? Почему server-authoritative, а не client-side prediction? Эти ответы должны быть где-то записаны - в CLAUDE.md, в README, хоть в комментарии в коде.
Энтропийные циклы. Каждое изменение ломает что-то другое. Происходит, когда нет архитектуры - только куча фич, которые не знают друг о друге. Три промпта добавили три несвязанных куска кода, и теперь непонятно, почему авторизация не видит сессию. Архитектурный файл с первого дня эту проблему решает: AI знает контекст всего проекта, а не только текущей задачи.
Вайб-кодинг работает не везде. Отлично - для MVP, внутренних инструментов, прототипов, проектов до десятка тысяч строк. Плохо - для критичного кода в медицине или финансах, высоконагруженных систем, старых проектов с тысячами строк legacy-кода.
Как начать свой проект
Конкретный путь, который работает.
Первое - идея, которая нужна лично вам. Не “сделаю что-нибудь с AI”, а “хочу вот это для вот этой задачи”. Мне нужна была игра для семейных вечеров - понятная мотивация. Хорошие варианты: синхронизированный список задач, quiz-приложение для учёбы, трекер расходов, простая игра.
Второе - выбор инструмента. Для акцента на UI - Lovable или Bolt.new. Для проектов с бэкендом, базой данных, реальной логикой - Claude Code. Именно его я использовал для “Угадай мелодию”: terminal-based, хорошо работает с файловой структурой монорепо.
Третье - день на планирование. PRD: что это, для кого, какие функции. Wireframes хотя бы в виде ASCII. Tech stack: какие технологии, почему. Архитектура: как части соединяются. Скучно только пока пишешь - потом окупается.
Четвёртое - первый промпт длинный, два-три параграфа с требованиями, интерфейсами, технологиями. Пятое - итерация: один промпт, одна задача, проверил, следующий.
Я программист, и мог написать “Угадай мелодию” руками. Традиционная разработка такого приложения с WebSocket, базой данных и двумя интерфейсами заняла бы у меня пару недель. Claude Code и 57 промптов дали рабочий MVP за три дня.
Если вы не программист - порог входа сейчас ниже, чем когда-либо. Начните с чего-то конкретного, опишите AI точно что нужно, итерируйте маленькими шагами. Планирование в первый день и CLAUDE.md с архитектурой - и хаос превращается в проект.