Знакомая картина: вы пишете Claude или Codex две бодрые строчки. Агент уверенно отвечает «понял задачу», создаёт 19 файлов — и делает вообще не то.
Вы объясняете ещё раз. Он переделывает. Теперь не работает то, что работало раньше.
Хочется сказать, что модель тупая. Но чаще модель просто слишком рано начала писать код. Половина требований оставалась у вас в голове, а вторую половину она радостно додумала сама.
Grill Me меняет порядок: сначала допрос, потом план, и только после подтверждения — реализация.
Что такое Grill Me
Grill Me — навык из набора Мэтта Покока. Его задача — пройтись по дереву решений и вытащить неявные требования до того, как агент начнёт что-то строить.
Важно: цифру про «250 тысяч звёзд», прозвучавшую в ролике, я здесь не повторяю. Она не относится к самому навыку и не нужна, чтобы объяснить механику.
Сам подход очень простой:
- агент не пишет код;
- задаёт вопросы по одному или небольшими независимыми группами;
- предлагает рекомендуемый вариант ответа;
- читает кодовую базу сам, если ответ уже лежит в проекте;
- продолжает, пока критические решения не станут явными;
- в конце просит подтвердить общее понимание.
В новых версиях набора есть отдельный примитив grilling; формат вопросов может отличаться. Но принцип тот же: не разрешать реализации обгонять понимание.
Самый простой вариант без установки
Скопируйте этот промпт в Claude или Codex:
Пока не пиши код и не меняй файлы. Проведи допрос по моей идее: [ОПИШИТЕ ИДЕЮ]. Твоя задача — найти все решения, которые сейчас существуют только у меня в голове. Задавай по одному вопросу за раз. К каждому вопросу предложи 2–4 варианта ответа и отдельно укажи свой рекомендуемый вариант с коротким объяснением. Если ответ можно найти в текущем проекте, сначала изучи файлы и не спрашивай меня. Проверяй: - для кого мы это делаем; - какой конкретный результат нужен; - основной сценарий пользователя; - ошибки и крайние случаи; - данные и доступы; - ограничения интерфейса; - безопасность; - критерии готовности; - что точно не входит в задачу. После допроса собери краткий бриф: цель, сценарии, решения, ограничения, открытые вопросы и проверка результата. Не начинай реализацию, пока я явно не подтвержу бриф.
Этого уже достаточно, чтобы резко сократить количество «я думал, ты сделаешь по-другому».
Пример: бот для записи клиентов
Плохой запрос:
Сделай Telegram-бота для записи клиентов в салон.
Кажется, задача понятная. Но внутри спрятана куча решений:
- один мастер или несколько;
- услуги разной длительности или одинаковой;
- можно ли отменять запись;
- за сколько часов;
- нужны ли напоминания;
- где хранится расписание;
- что делать, если два человека выбрали одно время;
- кто меняет график;
- нужен ли аванс;
- какие данные клиента можно сохранять.
Нормальный Grill Me не спросит «расскажите подробнее». Это ленивый вопрос. Он предложит варианты:
Где хранить расписание на первой версии? A. Google Calendar — быстрее запустить. B. Простая база внутри приложения — больше контроля. C. CRM салона — если API уже доступен. Рекомендую A для прототипа: меньше интеграций и администратор сразу видит записи.
На такой вопрос легко ответить. Вам не нужно писать техническое задание на пять страниц — достаточно согласиться, выбрать другой вариант или добавить ограничение.
Какие ветки обязательно пройти
1. Пользователь и момент использования
Не «для клиентов», а кто именно открывает продукт, с какого устройства, в какой ситуации и зачем. Интерфейс для администратора салона и форма для клиента — две разные задачи.
2. Успешный сценарий
Что должно произойти от первого действия до результата. Не список экранов, а цепочка: выбрал услугу → увидел свободные слоты → подтвердил номер → получил запись.
3. Ошибки
Что делать, если API не отвечает, слот уже заняли, платеж завис, пользователь прислал мусор или закрыл окно на середине.
4. Данные и доступы
Что сохраняем, где храним, кому показываем, как удаляем. Тут часто всплывает половина реальной сложности.
5. Границы первой версии
Что сознательно не делаем. Без этого AI построит космолёт, хотя вам нужен работающий календарь к пятнице.
6. Проверка результата
Фраза «всё должно работать» бесполезна. Нужны наблюдаемые критерии: пользователь может записаться, занятый слот нельзя выбрать дважды, администратор видит запись, отмена освобождает время.
Когда допрос нужно остановить
Grill Me тоже можно довести до абсурда. Если агент задаёт двадцатый вопрос о цвете редкой ошибки, а основной сценарий уже понятен, скажите:
Останови ветки, которые не влияют на первую версию. Покажи пять решений с самым большим влиянием и оставшиеся допущения. Затем собери бриф на одну страницу.
Цель не в том, чтобы ответить на все вопросы Вселенной. Цель — убрать решения, которые дорого переделывать после написания кода.
Когда этот подход особенно полезен
- новый продукт или функция;
- интеграция с оплатой, CRM, почтой или внешним API;
- автоматизация, которая действует от вашего имени;
- задача с несколькими ролями пользователей;
- миграция данных;
- всё, где ошибка стоит денег или доверия.
Для исправления очевидной опечатки такой допрос не нужен. Иначе вы будете сорок минут обсуждать философию кнопки, которую можно поправить за тридцать секунд.
Что делать после допроса
Попросите агента записать итог в файл проекта: SPEC.md, CONTEXT.md или обычный бриф. Затем откройте его глазами и проверьте пять вещей:
- цель можно пересказать одним предложением;
- основной пользовательский сценарий не имеет дыр;
- ошибки описаны;
- границы первой версии видны;
- критерии готовности можно проверить.
Только после этого дайте отдельную команду на реализацию. Так между «мы договорились» и «агент начал делать» появляется нормальная контрольная точка.
Частые ошибки при допросе
Первая — соглашаться с рекомендуемым вариантом просто потому, что он звучит уверенно. Рекомендация нужна как черновик для реакции, а решение всё равно ваше. Если агент предлагает Google Sheets, а у компании уже есть CRM, скажите об этом сразу.
Вторая — отвечать «как-нибудь потом» на важные ветки. Если решение можно отложить, зафиксируйте условие возврата: «В первой версии оплаты нет; возвращаемся к ней после 20 подтверждённых записей». Тогда неопределённость становится управляемой.
Третья — смешивать факты и решения. «API поддерживает webhooks» — проверяемый факт. «В первой версии используем polling» — ваше решение. В брифе они должны лежать отдельно.
Четвёртая — после хорошего допроса снова дать команду «ну теперь сделай красиво». Реализация должна ссылаться на согласованный бриф и проверяться по его критериям. Иначе вся полезная работа растворится в новом расплывчатом запросе.