Два промпта для Vibe Coding, которые я использую почти каждый день

На выходных ужинал с друзьями.

Разговор быстро ушёл в AI, а потом в Vibe Coding. Почти никто за столом не был профессиональным программистом: фондовый менеджер, дизайнер, преподаватель, продакт, человек из медиа. Зато у всех уже накопился свой опыт. Кто-то собрал маленький внутренний инструмент, кто-то пытался автоматизировать рутину, кто-то уже успел обжечься на коде, который вроде бы «написал AI», но потом всё развалилось.

В какой-то момент меня спросили: ты почти каждый день что-то кодишь, пишешь туториалы и заметки. Если выбрать пару самых полезных приёмов для Vibe Coding, что бы ты посоветовал?

Я правда завис на пару минут.

В итоге выбрал два промпта:

Свои эксперименты с Claude Code и Codex я часто гоняю через LLMEasy.ru: один API Key, Base URL и понятная история token usage в dashboard, без shared accounts.

Для меня эта пара закрывает весь цикл. First principles помогает найти решение. Adversarial review проверяет, где оно сломается.

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

Приём до смешного простой.

Пишете задачу как обычно, а в конце добавляете:

Исходи из first principles.

И всё.

После этой фразы агент заметно лучше пишет планы, ищет причины багов и меньше хватается за первое похожее решение из памяти.

У меня недавно был такой случай.

В одном рабочем проекте сломалась отправка важных новостей в командный чат. Из-за бага новость уровня «OpenAI выпустила GPT-5.6» не попала в подборку. Пользователи начали писать в комментариях под другими карточками, и к обеду у меня уже висело больше двадцати сигналов.

Я попросил агента разобраться. Он посмотрел код и сказал примерно так: при тестировании одной модели кто-то сломал сбор источников OpenAI, поэтому сайт не парсился несколько дней. Нужно просто починить конкретный источник.

Звучит правдоподобно. Но у меня внутри щёлкнуло: нет, это слишком поверхностно.

Я дописал:

Найди причину, исходя из first principles.

И вот тут ответ стал другим.

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

Можно было быстро починить один источник. Через неделю сломался бы другой. Потом третий. В итоге получилась бы система из заплаток, которую страшно трогать.

Я потратил полдня и переписал нижний слой маршрутизации. С тех пор эта часть выглядит спокойнее.

Вот в этом разница.

Обычный промпт лечит симптом. First principles заставляет спросить: почему эта система вообще устроена так, что один маленький сбой роняет важный поток данных?

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

Но он легко пропускает главный вопрос:

Эту задачу вообще нужно решать таким способом?

Фраза про first principles ломает этот автопилот. Она возвращает модель к базовым фактам: что мы знаем, какие ограничения реальны, что должно быть истинным, чтобы решение работало.

В инженерии это старый подход. Сначала не «как принято в отрасли», а «из чего это состоит на самом деле». Так SpaceX когда-то пересобирала экономику запусков: не с отраслевых ценников, а с материалов, производства и процесса.

С AI этот приём работает удивительно хорошо. Не нужно ставить отдельный skill, писать длинный system prompt или устраивать ритуал. Когда задача сложная, просто добавьте в конец:

Исходи из first principles.

Для багов, архитектуры, технических решений, странных продакшен-инцидентов — это один из самых полезных коротких промптов, которые я знаю.

Второй промпт я использую почти в каждом финальном проходе перед релизом.

Сделай adversarial review.

First principles помогает найти хорошее решение. Но хорошее решение ещё нужно довести до состояния, где оно не развалится от первого странного входа.

Adversarial review отвечает на другой вопрос:

Как это сломать?

В начале июня я устроил большой прогон одного проекта через adversarial review. Цель была простая: найти баги. Запустил много агентов параллельно, они довольно долго копались в коде и нашли пачку рисков.

Один из них — OOM-цикл.

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

Обычная проверка может это пропустить.

Adversarial review задаёт вопрос иначе:

Если я злой пользователь и отправлю HTML на 50 MB, как я могу положить worker?

И агент проходит весь путь: вход, очередь, обработчик, лимиты, retry, падение. Так он находит дыру. Позже я действительно видел HTML размером около 100 MB, так что сценарий оказался не теоретическим.

Ещё был смешной баг с будущим временем.

Если источник публикует материал, а из-за ошибки часового пояса дата оказывается в будущем, например завтра, такой материал улетает в самый верх ленты. У него же самый свежий timestamp.

Одна статья из будущего загрязняет всю выдачу.

Когда пишешь код, ты обычно не думаешь о таком. А adversarial review думает. Он спрашивает: что будет, если дата публикации больше текущего времени?

Потом нашлись и другие странные вещи: performance bomb в HTML-cleaning, похожая проблема в модуле перевода, ложный зелёный статус у health check из-за кеша. Всё это не выглядит как «главный сценарий». Поэтому такие баги и живут долго.

Я не профессиональный программист. Поэтому в Vibe Coding мне особенно важно, чтобы AI не только писал код, но и атаковал его.

Если просто бросить сгенерированный код в продакшен, платить будут пользователи. Не модель. Не агент. Пользователи.

Поэтому adversarial review лучше запускать несколькими агентами. Один смотрит безопасность, другой входные данные, третий производительность, четвёртый деплой, пятый соответствие документации.

В Claude Code можно попросить динамический workflow с несколькими агентами. В Codex тоже можно прямо сказать:

Запусти несколько агентов и сделай adversarial review этой функции.

И начинается чистая атака на собственную работу.

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

Сейчас я стараюсь раз в 2–3 недели делать общий прогон проекта:

Проведи adversarial review, исходя из first principles.

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

Самое интересное: почти каждый раз находится что-то, что раньше лежало тихо.

Технический долг, хрупкая связка, странный fallback, невидимое расхождение между кодом и документацией. Если это не искать, оно будет ждать своего часа.

Эти два промпта полезны не только в Vibe Coding.

Написали статью — попросите AI сделать adversarial review. Он найдёт логические дыры, слабые места, спорные факты, рыхлую аргументацию. Это лучше, чем «посмотри, нормальная статья?».

Собрали бизнес-план — попросите разобрать его через first principles. Модель снимет красивую обёртку и спросит: на каких фактах это вообще держится?

Даже в личных решениях это работает.

Менять работу или нет? Сначала first principles: чего я хочу на самом деле, какие ограничения реальны, какие страхи я путаю с фактами. Потом adversarial review: где я себя обманываю, какие риски не хочу видеть, какой сценарий мне неприятно проговаривать.

В этом и сила пары.

First principles возвращает к базовым фактам.

Adversarial review ставит напротив тебя силу, которая говорит: ты можешь ошибаться.

Звучит почти романтично.

Но работает.

Когда эти две привычки входят в голову, AI становится не просто машинкой для текста и кода. Он превращается в собеседника, который помогает думать жёстче.