Введение
В последние годы разработка программного обеспечения начала меняться быстрее, чем за предыдущее десятилетие. И дело не только в новых фреймворках или языках программирования. Появился принципиально новый способ создавать код — через диалог с нейросетями. Это называют вайбкодингом.
Я не буду рассказывать, что нейросети умеют писать код. Это и так все знают. Я расскажу о том, что находится в центре вайбкодинга — о системе промптов.
Промпты в разработке — это не магические заклинания и не секретные фразы, которые нужно выучить. Это инструмент управления. Через промпты вы не просто общаетесь с моделью. Вы ставите задачи, задаёте границы, корректируете движение. По сути, промпт — это техническое задание, только написанное живым языком.
И здесь важно сразу снять одно ожидание. Вам не нужен идеальный промпт. Вы не обязаны писать «правильные» запросы с первого раза. В реальной работе это почти не играет роли. Результат рождается не из одного точного запроса, а из процесса. Вы написали, получили ответ, посмотрели, что не так, поправили. Этот цикл «запрос — ответ — корректировка» и есть основа вайбкодинга. Если вы его не выстроили, никакой идеальный промпт не спасёт.
Как меняется ваша роль
В классическом программировании вы сидите и пишете код руками. Строчка за строчкой. Вы сами контролируете каждую переменную и каждый отступ.
В вайбкодинге всё иначе. Вы перестаёте быть тем, кто пишет. Вы становитесь тем, кто управляет.
Вы задаёте направление. Вы проверяете результат. Вы постепенно доводите его до нужного состояния. Модель при этом выступает как исполнитель. Иногда очень талантливый, иногда тупящий в элементарных вещах. Но это не важно. Важно то, что промпт становится вашим техническим заданием. Чем лучше вы умеете ставить задачи и управлять процессом, тем стабильнее получается результат.
Это как разница между тем, чтобы самому копать яму, и тем, чтобы руководить экскаватором. Вы не махаете лопатой, но вы решаете, куда копать, насколько глубоко и когда остановиться.
Ошибка, которая мешает большинству
Самая частая ошибка новичков — попытка написать идеальный промпт.
Человек сидит, переформулирует, подбирает слова, читает статьи про «магические фразы». На это уходит время, появляется напряжение, а результата это почти не даёт. Потому что идеального промпта не существует. Модель всё равно не угадает с первого раза, как бы вы ни старались.
На практике всё работает проще. Можно писать обычным языком. Можно формулировать не идеально. Можно менять задачу по ходу. Важно не то, как вы написали запрос. Важно то, довели ли вы результат до рабочего состояния.
Проблема не в том, что модель «не поняла». Проблема в том, что работа остановилась на первом ответе. Вы получили фигню, вздохнули, подумали «нейросеть глупая» и пошли пить чай. А надо было просто поправить запрос и отправить снова.
Вайбкодинг — это диалог. Если вы после первой реплики замолчали, вы не ведёте диалог.
Базовый принцип работы с кодом
Есть одно жёсткое правило, которое отделяет стабильные проекты от постоянной отладки. Запомните его.
Не переписывайте код. Дополняйте его.
Звучит просто, но новички нарушают это постоянно. Они пишут «переделай», «перепиши красиво», «сделай лучше». И модель, получив такой запрос, начинает менять всё подряд. Она переименовывает переменные, перестраивает функции, выкидывает куски кода, которые ей кажутся лишними. Внешне может выглядеть аккуратно. Но внутри появляются ошибки, которые потом сложно отследить. Что-то сломалось, но где — непонятно.
Если же вы формулируете задачу как добавление или изменение, работа становится точечной. Модель не трогает то, что уже работает. Она просто вставляет новый кусок в существующую структуру. Логика сохраняется. Контроль остаётся за вами.
Вот простой пример.
Вы пишете:
перепиши бота с добавлением профиля
Модель с высокой вероятностью пересоберёт большую часть проекта. Потратит кучу токенов. И всё равно что-нибудь сломает.
А теперь напишите:
добавь обработчик профиля в существующую структуру и не трогай остальной код
Изменения будут локальными и предсказуемыми. Модель добавит только то, что вы попросили.
Этот принцип — «не переписывай, а дополняй» — чаще всего и отличает стабильный проект от бесконечной отладки.
Когда вы начинаете уверенно работать с этим процессом, логичный следующий шаг — перейти к готовым инструментам. Я сделал бесплатного Telegram-бота с ИИ, который объединяет несколько моделей: ChatGPT, Gemini, Grok и DeepSeek. Он помогает с кодом, отвечает на вопросы, распознаёт голос и анализирует изображения.
Сам бот: https://t.me/ChatGPTAIAssistantBot
Тонкости работы с нейронками: что нужно знать перед тем, как писать промпты
Прежде чем мы перейдём к конкретным техникам, давайте разберём несколько тонкостей, которые сильно влияют на результат. О них мало говорят в обучалках, но на практике они всплывают постоянно.
Первая тонкость: модели не понимают отрицания так, как люди.
Звучит странно, но это факт. Когда вы пишете «не делай X», модель часто всё равно делает X. Потому что она видит слово X и подсознательно тянется к нему. Гораздо эффективнее формулировать через «делай Y». То есть вместо «не переписывай весь код» лучше написать «работай только в этом файле» или «добавь новый код без изменения существующего». Позитивная формулировка работает стабильнее.
Вторая тонкость: модели любят «додумывать» там, где не надо.
У моделей есть побочный эффект — они хотят быть полезными. Если вы не дали чётких границ, она начнёт фантазировать. Попросили «улучшить код»? Она подключит новую библиотеку, переименует все функции, добавит «крутой» паттерн проектирования, который вы никогда не использовали. Чтобы этого избежать, нужно явно запрещать додумывание. Фразы вроде «работай только с тем, что я показал», «не добавляй новых сущностей», «используй только уже подключённые библиотеки» работают как тормоза.
Третья тонкость: контекст имеет срок годности.
Модели помнят примерно последние 4-10 страниц текста (зависит от модели). Всё, что было раньше, она забывает или помнит плохо. Это значит, что если вы 20 сообщений назад объяснили архитектуру проекта, через 20 сообщений модель про неё уже не вспомнит. Поэтому важно повторять ключевые ограничения каждый раз, когда вы даёте новую задачу. Не надейтесь, что она запомнила с первого раза.
Ключевые слова, которые реально работают (и которые не работают)
Давайте конкретно. Какие слова и фразы действительно меняют поведение модели, а какие просто создают видимость работы.
Красный список (избегайте):
«сделай лучше» — модель не знает, что для вас «лучше». Для неё «лучше» может означать больше кода, больше абстракций или просто другой стиль форматирования.
«перепиши красиво» — то же самое. Красота в программировании субъективна. Модель решит, что нужно переименовать всё в CamelCase и добавить декораторы, потому что в обучающей выборке это часто шло рядом со словом «красиво».
«оптимизируй код» — модель начнёт «оптимизировать» там, где не надо. Она может выкинуть проверки, упростить логику до некорректной, заменить понятные конструкции на короткие, но нечитаемые. Оптимизацию лучше делать руками или очень конкретными промптами.
«улучши архитектуру» — самый опасный запрос. Модель пересоберёт весь проект. Вы получите код, который будет сложнее, чем был, и почти наверняка сломается.
Зелёный список (используйте):
«не переписывай остальной код» — прямой запрет на глобальные изменения.
«покажи только изменённые части» — экономит токены и упрощает копипаст.
«добавь в существующую структуру» — явно говорит, что вы не хотите ничего ломать.
«работай только в этом файле/только с этим хендлером» — сужает фокус модели.
«напиши без объяснений, просто код» — если вам нужен только код, без лирики.
«объясни куда вставить» — если вы не уверены, как интегрировать ответ.
«используй только уже подключённые библиотеки» — запрет на новые зависимости.
«скажи, что именно изменить, а не переписывай всё» — для точечных правок.
Русский против английского: что лучше для промптов?
Вопрос, который возникает у всех. Я дам честный ответ без мифов.
Разница есть, но она не критичная для большинства задач.
Модели обучались в основном на английских текстах. Кода в обучающей выборке тоже больше на английском — имена переменных, комментарии, документация, вопросы на Stack Overflow. Поэтому если вы пишете на английском, модель чуть точнее понимает технические нюансы и чуть реже галлюцинирует.
Однако русский язык работает хорошо. Модели отлично знают русский. Вы можете писать сложные промпты на русском, и модель почти всегда поймёт правильно.
Практический совет такой.
Для простых вещей — добавить кнопку, поправить название переменной, написать простую функцию — можно смело писать на русском. Это быстрее для вашего мышления, вы тратите меньше энергии.
Для сложных задач — архитектурные решения, нестандартная логика, интеграция нескольких систем, генерация сложных алгоритмов — лучше писать на английском. Чуть выше точность, чуть меньше вероятность, что модель что-то недопоняла.
Ещё один нюанс: если вы пишете на русском, а модель отвечает кодом на английском (с английскими комментариями и названиями переменных) — это нормально. Так и должно быть. Код почти всегда пишется на английском вне зависимости от языка промпта.
Если модель вдруг ответила на английским текстом вместо русского, просто скажите «переведи ответ на русский» (но код оставь на английском). Это работает.
Как экономить токены: практические приёмы
Токены — это то, за что вы платите (или бесплатный лимит). И то, что влияет на скорость работы. Больше токенов — дольше ответ, дороже запрос. Поэтому экономить токены полезно.
Первый принцип: никогда не просите переписать весь код.
Если у вас файл на 500 строк, а вы просите переделать одну функцию в середине, не кидайте модель весь файл и не просите «перепиши всё». Модель сгенерирует 500 строк ответа. Вы потратите кучу токенов. Вместо этого покажите только ту функцию, которая нуждается в изменении, и скажите «дай только изменённую версию этой функции, остальное не трогай».
Второй принцип: работайте кусками.
Не пытайтесь одной промптом объять весь проект. Разбейте его на маленькие задачи. Сначала попросите сделать один хендлер. Потом второй. Потом базу данных. Потом связь между ними. Это не только экономит токены, но и упрощает контроль.
Третий принцип: не отправляйте лишний контекст.
Модели часто советуют давать много контекста. Это не всегда правильно. Если вы пишете простую функцию, не надо скидывать всю архитектуру проекта. Модель отвлечётся на лишние детали и может сделать не то. Давайте ровно столько контекста, сколько нужно для решения задачи.
Четвёртый принцип: используйте точечные правки.
Вместо того чтобы просить переписать функцию целиком, скажите: «в этой строке замени X на Y». Или: «добавь проверку после 15-й строки». Модель это понимает. И ответ будет коротким.
Пятый принцип: запрашивайте только изменения.
После каждого промпта добавляйте фразу: «покажи только изменённые части, без повторения всего кода». Это резко сокращает объём ответа и экономит токены на следующем запросе.
Как выглядит реальная работа
Работа с ИИ почти никогда не происходит за один запрос. Если вы ждёте, что модель с первого раза выдаст идеальный код, вы разочаруетесь.
Реальная работа выглядит как диалог. Вы начинаете с простой формулировки, получаете результат, видите неточности и уточняете. Потом ещё раз проверяете и снова корректируете.
Давайте на примере. Задача — добавить кнопку профиля в телеграм-бота.
Первый запрос может быть максимально простым и даже ленивым:
добавь кнопку профиль
Ответ, скорее всего, будет сырым. Модель может не учесть структуру вашего проекта. Может вставить код не туда. Может забыть про существующие хендлеры.
Вы смотрите на ответ и понимаете, что не так. Тогда вы уточняете:
не переписывай код, добавь кнопку профиль в существующий хендлер и скажи, куда именно вставить
Результат становится заметно лучше. Появляется конкретика. Код привязывается к структуре. Модель не ломает остальную логику.
Если что-то всё ещё не так, вы повторяете процесс. Может быть, через два шага. Может быть, через пять. Это нормально.
Так выглядит настоящая разработка в вайбкодинге. Не идеальный запрос, а последовательное уточнение. Не магия, а управление.
Готовые шаблоны промптов
Чтобы не тратить время на формулировки каждый раз с нуля, удобно иметь под рукой базовые заготовки. Это не строгие правила, а просто отправные точки.
Для создания нового проекта с нуля:
Напиши телеграм-бота на Python с использованием библиотеки aiogram, базы данных sqlite, логирования и конфигурации через .env. Раздели проект на части, не пиши всё в одном файле. Суть бота в том, что ...
Для сайта одной страницей:
Создай чёрно-белый сайт-визитку с крутым шрифтом и именем автора в шрифте Syne ExtraBold 800. Все формы на сайте сделай округлёнными. Добавь анимацию liquid glass, тёмную тему, прозрачность. Всё в одном файле index.html. Сделай страницу с информацией: телеграм, вк, почта. Добавь моковые данные и красивое оформление.
Когда проект уже существует и нужно внести изменения:
Нужно внести изменения в проект. Добавь новую функцию, не переписывая остальной код.
Когда случилась ошибка:
Вот лог ошибки. Исправь её и скажи, что именно нужно изменить. Не переписывай всю программу.
Когда нужно точечное исправление:
В этом коде [вставка кода] на строке [номер] замени [что] на [на что]. Покажи только исправленную строку.
Эти шаблоны не делают результат идеальным. Но они позволяют быстрее начать и держать процесс под контролём.
Почему иногда всё равно получается плохо
Даже при нормальных промптах результат может быть неидеальным. И это не ваша вина и не вина модели. Просто так устроен процесс.
Модель может сделать не то допущение. Может проигнорировать часть условий. Может использовать устаревший подход. Иногда она просто неправильно понимает контекст, потому что вы не рассказали какую-то важную деталь.
Это нормально. Это не ошибка. Это часть работы.
Здесь главное — не пытаться исправить всё сразу одним запросом. Если вы напишете супер-промпт на три страницы, где попросите учесть все возможные нюансы, модель запутается. Гораздо эффективнее двигаться постепенно. Сначала решить одну проблему. Потом вторую. Потом третью.
Попытка решить всё одним запросом почти всегда приводит к ухудшению результата. Проверено.
Практические принципы (памятка)
Чтобы работа спорилась, держите в голове несколько простых правил.
Первое. Лучше разбивать задачу на маленькие шаги. Не пытайтесь сделать всё сразу. Когда изменения маленькие, их легче контролировать. Легче откатить, если что-то пошло не так. Легче объяснить модели.
Второе. Полезно явно повторять ограничения, если модель их игнорирует. Это не значит, что модель тупая. Это значит, что она забыла, а вы ей напомнили. «Не трогай базу данных» — можно повторить через каждые два-три сообщения.
Третье. Не стоит смягчать формулировки. Если результат неправильный, не пишите «может быть, ты не мог бы...». Напишите прямо: «это неправильно, исправь вот здесь». Модели всё равно. Она не обижается. Чем прямее вы скажете, тем точнее она поймёт.
Четвёртое. Всегда указывайте формат ответа. Хотите только код? Скажите. Хотите объяснения? Скажите. Модель не угадает, что вы предпочитаете.
Пятое. Если модель три раза подряд выдаёт фигню — сделайте паузу, переформулируйте задачу полностью, возможно, вы упустили какой-то важный контекст.
Новый уровень
Когда процесс становится понятным и вы начинаете чувствовать, как управлять моделью, возникает естественное желание — автоматизировать рутину.
Я создал бесплатного телеграм-бота, который генерирует ботов под ключ. Вы описываете идею, а он выдаёт готовый проект с логикой, базой данных, настройками и зависимостями. По сути, это тот же вайбкодинг, только упакованный в инструмент. Он использует те же принципы: итеративность, ограничения, дополнение вместо переписывания. Но делает это автоматически.
Если вы освоили ручное управление промптами, попробуйте автоматизировать то, что делаете часто.
Сам бот: https://t.me/GenerateYourAIBot
Итог
Промпты в разработке — это не отдельная сложная дисциплина. Это не магические слова. Это не то, чему нужно учиться месяцами.
Промпты — это способ управления процессом разработки.
Вы ставите задачу. Вы задаёте ограничения. Вы доводите результат до нужного состояния в несколько итераций. Вот и всё.
Этот навык — управление процессом, а не написание идеального запроса — и определяет, насколько эффективно вы работаете с ИИ.
Проблема редко в модели. Модели работают примерно одинаково у всех. Проблема в том, что процесс останавливается слишком рано. После первого ответа. После первой неудачи.
Хороший вайбкодинг — это когда вы не бросаете после первого шага. Второй, третий, четвёртый. Уточнили, поправили, добили. Вот тогда результат появляется.