Как начать вайбкодить и не дать ИИ построить космический корабль: алгоритм первого сервиса

Первый шаг вайбкодинга — не вайбкодинг

Как начать вайбкодить, если ты не программист? Александр Коренев — техдиректор, программист и автор канала «GPT в тапочках» — отвечает на NeyroSummit 16 неожиданно: «Первый шаг для вайбкодинга — не вайбкодинг». Сначала не код, а разговор. Его доклад — пошаговый вайбкодинг для начинающих: что сказать ИИ до первой строчки кода, как резать проект на куски, что делать, когда «не работает», и как не утонуть в собственном проекте через месяц.

Вайбкодинг для Коренева — создание сервисов, скриптов и программ, где код за тебя генерирует ИИ, а ты ставишь задачи обычным человеческим языком. Что это за слово и откуда оно, разобрано в гайде «Что такое вайбкодинг», здесь — сам порядок действий, вайбкодинг с нуля. Живого кода на экране в докладе не было, зато есть правила, которые спикер вынес из своих сервисов с LLM под капотом — их у него, по его словам, больше десятка.

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

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

Выговорись и заставь ИИ задать вопросы

Первый шаг Коренев называет «держим себя в руках». Не просить код, а рассказать идею подробно: что хочешь сделать, примеры, как это видит пользователь, как это видишь ты. Можно голосом — свой кейс спикер начинал с голосовых сообщений Claude.

Когда «исповедь закончилась», нужны два вопроса:

1. «Задай мне ещё 10 вопросов, чтобы лучше разобраться, что я хочу». Можно попросить несколько серий вопросов.
2. «Расскажи теперь, как ты понял, что я хочу».

Второй вопрос важнее, чем выглядит. Ты можешь изложить всё ясно — а модель всё равно что-то «напридумывает» или додумает лишнего. Выяснить это сейчас дешевле, чем потом переделывать готовый код.

Хочу сделать с тобой небольшой сервис. Пока не пиши код — сначала разберёмся, что я хочу.

Идея: [что должен делать сервис].
Для кого: [кто будет пользоваться — например, только я].
Как это выглядит для пользователя: [что он видит, что нажимает, что получает].
Примеры: [похожие вещи или как это делается сейчас руками].

Теперь:
1. Задай мне ещё 10 вопросов, чтобы лучше разобраться, что я хочу. По одному вопросу за раз.
2. Когда вопросы закончатся, расскажи своими словами, как ты понял, что я хочу, — и что ты добавил от себя, чего я не говорил.

Скажи «я новичок»: как не дать ИИ построить космический корабль

Второй шаг — договориться о технологиях. Разбираться в них не обязательно. Достаточно сказать прямо: «Я новичок, это домашний проект, я буду единственным пользователем — расскажи, как это можно реализовать и на каких технологиях». Без этой оговорки, по словам Коренева, ИИ насоветует микросервисы и прочее, в чём ты «поплывёшь». Тебе нужно другое — чтобы заработало как можно быстрее.

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

Третий шаг — порезать проект на части, чтобы «слона съесть по кускам»: «дели его на три–пять модулей, которые можно отдельно собрать и потом соединить». Зачем — станет ясно на сборке: маленький модуль легко проверить и довести до ума отдельно от остального.

Я новичок, это домашний проект, я буду единственным пользователем.
Проект: [короткое описание из нашего разговора].

1. Расскажи, как это можно реализовать и на каких технологиях — самый простой вариант, который заработает быстрее всего. Без микросервисов и всего, что нужно только большим командам.
2. Покритикуй своё предложение: что тут можно ещё упростить или убрать?
3. Раздели проект на 3–5 модулей, которые можно собрать и проверить по отдельности, а потом соединить. Для каждого модуля: что он получает на входе, что отдаёт на выходе и как я проверю, что он работает.

Три документа проекта: концепция, стек, план

По итогам разговора Коренев собирает три документа, которыми потом постоянно пользуется:

1. Концепция проекта — что делаем, для кого, как это работает с точки зрения пользователя.
2. Технологический стек — на чём собираем и почему именно так.
3. План — модули и порядок, в котором их делаем. План, по словам спикера, не всегда обязателен, но лучше его иметь.

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

В агентах для кода у этого приёма есть штатное место. Claude Code сам читает файл инструкций проекта CLAUDE.md (или AGENTS.md) в начале сессии и умеет копить заметки о проекте между сессиями (документация Claude Code), — сложи три документа в папку проекта и сошлись на них в этом файле. Но и тогда сверяй, что агент понял их так, как ты задумал. Дополнение редакции, 22.10.2026.

По итогам нашего разговора собери три документа для проекта [название] — я буду прикладывать их в начале каждого нового диалога.

1. КОНЦЕПЦИЯ: что делает сервис, для кого, как выглядит для пользователя, чего в нём точно НЕ будет.
2. СТЕК: технологии простыми словами — что это, зачем нужно, что мне установить.
3. ПЛАН: модули по порядку, от самого простого к сложному; для каждого — как проверить, что он работает.

Пиши коротко, без того, о чём мы не договаривались. Если что-то не решено — так и отметь: «не решено».

Модуль за модулем: самый простой блок первым

Только теперь — код. Писать его удобнее не в веб-чате, а в среде разработки или агенте с папкой проекта, — какие бывают, разобрано ниже, в разделе «Где лучше вайбкодить новичку». Просьба Коренева: «Давай код для самого простого блока, желательно на Python, с комментариями, чтобы я мог быстро проверить результат». Сорвать «низко висящий фрукт», порадоваться, что получилось, и только потом идти к сложному.

Дальше — собирать пазл. «У нас есть модуль А, который мы сделали, а теперь добавим к нему модуль Б» — соединили, проверили, работает. Потом модуль В, и так с проверкой на каждом шаге. На выходе получится, как шутит спикер, «Франкенштейн, собранный из кусков, но тем не менее он работает». Это лучше, чем сразу собрать весь проект, не понять, почему он не работает, и бросить.

Кейс Коренева: сервис берёт новости с одного ресурса, отсеивает лишнее и по каждой новости ищет, у кого она создаёт проблему, какой бизнес на этом можно построить и какой продукт сделать. Результат публикуется в Telegram-канал несколько раз в день. Идея пришла из практики насмотренности: читать новость и думать, кто от неё теряет и как ему помочь. По словам спикера, сервис он собрал за вечер накануне доклада, и у канала уже было 39 подписчиков. Порядок был такой:

1. Первым — модуль, который собирает новости и проверяет, подходят ли они по критериям. Проверка — на выходе нормальные новости, а не ноль. Но и пустой результат бывает нормой — в день, когда подходящих новостей нет, — поэтому в промпте ниже редакция добавила просьбу заранее назвать, что ты увидишь в обычном случае, при пустом входе и при ошибке источника.
2. Первый прогон дал 500 новостей. Коренев посчитал это лишней работой и попросил резать поток по своему принципу.
3. Потом — анализ одной новости. Не устроило — доработал промпт. Маленький изолированный блок легко «огранить».

Вот документы проекта: [концепция, стек, план — вставь или приложи файлы].

Давай сделаем код для самого простого модуля: [название модуля из плана].
- На стеке, о котором мы договорились (если не решили — желательно на Python), с комментариями.
- Так, чтобы я мог быстро проверить результат: выведи в консоль, что пришло на вход и что получилось на выходе.
- Объясни простыми словами, как запустить и что я должен увидеть: в обычном случае, если подходящих данных нет и если источник недоступен или вернул ошибку.
- Другие модули пока не трогай.

Не работает — это нормально: ошибку из консоли обратно в чат

Не заработало — не паникуй. Рецепт Коренева простой: берёшь ошибку из консоли целиком, вставляешь в чат и рассказываешь, что делал. Одно правило от редакции: если в тексте ошибки видны ключи доступа, токены, пароли или чужие личные данные, замени их на *** перед отправкой. «Не работает, давай думать, что происходит: я сделал то-то, нажал то-то, ввёл то-то». Частая причина — не хватает библиотеки: Claude её не поставил, «понадеялся на вас». Бывает, что заводится с третьей-четвёртой попытки — особенно если ты увлёкся и давно не проверял, что получается.

Чтобы консоль не пугала, спикер разбирает интерфейс среды разработки — на примере Google Antigravity, но так же устроены Cursor и VS Code. Пять зон:

1. Файлы проекта — всё, из чего состоит проект.
2. Открытый файл — код с «непонятными символами»: это надо «пережить», как первые попытки поехать на велосипеде.
3. Кнопка запуска — запускает файл, который сгенерировал ИИ.
4. Консоль — сюда выводятся результаты и ошибки.
5. Чат с нейросетью — здесь же выбирают модель.

Не работает. Давай думать, что происходит.

Что я делал: [запустил файл / нажал кнопку / ввёл данные].
Что ожидал: [что должно было произойти].
Что получил — ошибка из консоли целиком (ключи, токены и личные данные заменил на ***):
[вставь текст ошибки]

Объясни простыми словами, в чём причина. Если не хватает библиотеки или настройки — скажи, что и как установить. Исправь только то, что связано с этой ошибкой.

Где лучше вайбкодить новичку

Подборку для первых шагов Коренев дал на 16.04.2026:

Если речь о сервисе, а не о разовом скрипте, спикер советует специализированные среды: сначала кажется, что в них сложно разобраться, «но потом… всё полетит как ракета». И планировать проект лучше сразу в среде разработки или агенте, а не в веб-чате: там есть режимы, заточенные под программирование. Google Colab спикер упомянул как вариант без установки, в браузере, но оговорился, что из России он на апрель открывался не напрямую, — основным путём его не делаем. Как поставить Claude Code или Codex и войти по подписке, разобрано в гайде про агентов в терминале, как получить доступ к Claude из России — в статье про Claude через API.

Какую модель выбрать? Коренев смотрит народный рейтинг Arena: пользователи решают свои задачи сразу в нескольких моделях и голосуют за лучший ответ, есть отдельные зачёты — программирование, веб-интерфейсы, тексты. На его скриншоте в день доклада сверху были Claude Opus 4.6 и GLM, дальше модели Claude, а GPT-5.4 и Gemini Pro — примерно на шестом месте. Но вывод спикера не «бери первую»: модель с первого места не обязательно лучше решит твою задачу, и та, что на шестом, может понять тебя точнее.

Git — машина времени вайбкодера

Git Коренев объясняет как «машину времени»: работает — сделал «фотографию» состояния файлов, потом следующую. Что-то пошло не так — а оно, предупреждает спикер, скорее всего пойдёт — откатываешься к стабильной версии, когда всё ещё работало. Второй плюс — видна история: даже если ты не читаешь код, полезно посмотреть, как менялись, например, промпты внутри проекта.

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

Как не утонуть в техдолге: правила на вырост

Почему вайбкодить одновременно быстро и долго? Первый «вау-эффект», по словам Коренева, можно поймать «буквально там за 30 минут»: что-то наговорил — и оно появилось, работает «из палок». Но на первую работоспособную версию, по его оценке, уходит 20, «а то и 5 процентов» времени. Всё остальное — «вылизывание»: чтобы работало «тютелька в тютельку», как задумано.

Для тех, кто хочет идти дальше, у спикера «роскошный максимум» — правила, которые повышают шанс на успех:

1. Час на основы. Короткое введение в Python и в свою среду разработки по бесплатным видео — по словам спикера, YouTube переводит англоязычные ролики на русский. Первый шок проходит быстрее.
2. Архитектурный режим. Сначала думаем, как должно быть, и только потом делаем. «Побольше говорильни — это полезно».
3. Спецификация по факту. Попроси ИИ: «Изучи этот проект, собери спецификацию», — и сам сверяй, насколько написанное соответствует реальности и твоим ожиданиям.
4. Один модуль — свой файл. Не пихать всё в один файл: тебе сложнее отлаживать, модели — работать.
5. Файлы по 200–500 строк, не больше. Это оптимум, который спикер советует «найти для себя», а не закон: иначе тратится больше токенов и модель начинает теряться.
6. Докстринги. Пусть ИИ описывает каждую функцию: что делает и что ожидает на входе. При переделках модели проще разобраться.
7. Мелкие задачи. Не решать всё «кавалерийским наскоком»: «оно не будет работать. Хотя вам бодро отрапортует».
8. Фиксация изменений. После правок: «Актуализируй спецификацию и зафиксируй, что ты изменил» — так проще понять, насколько ты идёшь по плану.

Отдельно — технический долг. Когда кода становится много, он начинает дублироваться: появилась функция обработки текста для одного источника, потом такая же для другого, потом ещё. Модель путается, что за что отвечает, вносит правки «не туда» или создаёт всё заново — и проект перестаёт работать без вмешательства. Лечение у Коренева — цикл: сохранить в git → попросить почистить дубли → убедиться, что всё работает (тесты или «руками потыкать») → снова сохранить. Запускать его стоит, когда дубли и правки «не туда» действительно появились, а не по расписанию; а что именно проверять, договорись до чистки — тогда прогонишь одни и те же проверки до и после. Сохраняться часто: если Claude начнёт бороться с техдолгом без страховки, он может «набороться» так, что проект перестанет подниматься.

Перед началом сделай коммит текущего рабочего состояния проекта [название].

Потом:
1. Скажи, как мне проверить, что всё работает сейчас: какие запуски сделать и что я должен увидеть. Я прогоню это до чистки и после.
2. Изучи проект и найди дубли — функции и куски кода, которые делают одно и то же.
3. Предложи, как их объединить, и подожди моего «да».
4. После чистки: каждый модуль — в своём файле, файлы не длиннее 200–500 строк, у функций — докстринги.
5. Актуализируй спецификацию и зафиксируй, что ты изменил.

Что можно так собрать? По словам Коренева, «практически всё, кроме серьёзного сервиса типа Авито с биллингом»: простые и непростые сайты, Telegram-боты, мини-приложения, расширения, макросы для Excel. Сам он незадолго до доклада сделал первое приложение для Android: оно достаёт звук из видео, превращает его в текст и отправляет в его Telegram-канал. Проект может разрастись до задачи для программиста — но первую версию, уверен спикер, ты «можешь всегда сделать, потрогать её руками и, как минимум, отдать программисту». И разговаривать с разработчиком будет проще: по шутке спикера, фраза «я тут не разбираюсь» сразу делает «x2 к цене».

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

С чего начать сегодня

Вопросы и ответы