Промпты слишком маленькие: как Claude Code выжать в 10–100 раз больше

Одна и та же модель, одни и те же инструменты, а результат у разных людей отличается в 10–100 раз. Ray Amjad в разборе статьи Феликса, инженера из команды Claude, показывает, где проходит эта граница. Дело не в хитрых трюках, а в масштабе замысла. Если вы всё ещё просите «сделай эту функцию», ваши амбициозные промпты для Claude Code пока слишком малы.

У Феликса амбиции бывают четырёх типов: скорость, высота, глубина и широта (в видео её называют «диапазоном»). Скорость очевидна: тот же код пишется быстрее, и на этом этапе уже почти все. Интереснее три остальных.

Высота: от задачи к цели, а затем к цели за целью

Первый шаг знаком многим: вместо задачи («добавь индекс в запрос к таблице заказов») ставить цель («каждая страница грузится быстрее 200 мс у реальных пользователей»). Тогда Claude сам решает, нужен ли индекс. Но Феликс предлагает пойти дальше и спросить: а зачем нам эта цель? Здесь ответ такой: чтобы пользователи быстрее делали свою работу. Из этого вытекает совсем другая постановка.

Дайте агенту инструменты, а не только цель

Чем выше уровень автономности, тем важнее среда. Просьба «сделай так, чтобы приложение не падало» бессмысленна без доступа к отчётам о сбоях (например, в Sentry) и к реальным машинам с Windows, Mac и Linux, где можно проверить исправление. Практичный приём автора: заранее спросить у самого агента, что ему нужно для достижения цели. Он может попросить отдельный аккаунт AWS с лимитом бюджета, тестовые логины или доступ к сервисам только на чтение. Агент не всегда сам попросит недостающее, поэтому ему стоит разрешить писать вам.

Перестаньте быть «белковым прокси»

Если вы пересылаете баг-репорты из поддержки в Claude Code и обратно с уточнениями, вы просто посредник. Автор собрал систему, где агент по расписанию читает обращения через MCP-сервер, сопоставляет их с событиями в Sentry, воспроизводит баг на реальной машине, при необходимости задаёт пользователю уточняющие вопросы, вносит исправление и сообщает, что проблема решена. Вопрос, который стоит задавать себе постоянно: где я сейчас посредник?

Пусть ИИ помогает задавать вопросы, а не только отвечать

То же с дашбордами. Вместо того чтобы просить агента нарисовать очередной дашборд, попросите придумать десять вопросов, ответы на которые помогут росту выручки и удовлетворённости клиентов, найти на них ответы по всем MCP-серверам и прислать отчёт. Так автор узнал, например, что покупка одного из его продуктов совершается в среднем за 4 минуты после первого визита, а удержание аудитории видео отрицательно коррелирует с доходом. Дополнительный шаг вверх: закрепить за агентами зоны ответственности (доход, регистрации, возвраты, отток, ошибки), чтобы они сами запускались раз-два в сутки и беспокоили владельца только при аномалиях. Ещё один рычаг: править не приложение, а систему, из которой оно собрано. Исправление в системе получат все приложения сразу.

Глубина: работать как лучший специалист

Иногда нужен не больший объём, а уверенность, что одна задача сделана так, как сделал бы лучший в своём деле. Если просто попросить модель «вести себя как профессионал», она часто меняет лексику, но не метод: вместо статистической модели выдаст таблицу в Markdown. Просьба «ускорить приложение» даст ленивую загрузку и memo, а требование использовать инструменты инженера по производительности приведёт к профилированию, чтению трассировок и поиску реальных медленных запросов. Знать эти инструменты вам не нужно, Claude их знает, надо лишь настоять на их применении.

Есть и психологический приём: поставить заведомо «неразумную» цель (не 5 секунд загрузки, а 200 миллисекунд) и на «это невозможно» отвечать «возможно, продолжай». Похожий подход использовал создатель Bun, когда подбадривал Claude в работе над гипотезой Римана.

Для переписывания своих промптов Феликс предлагает мета-запрос: попросить более глубокую, а не более объёмную версию задачи; сначала назвать, что сделал бы ведущий профессионал и о чём вы не просите, какой первичный материал он взял бы за основу, какие методы и инструменты применил бы и что, кроме вас двоих, докажет правильность результата. Последний пункт по сути требует хорошего верификатора.

Широта: чему научились в соседних профессиях

Самая трудная идея. Приём такой: заменить существительное глаголом. «Сообщение об ошибке» превращается в «помочь растерянному человеку справиться самому, ни с кем не связываясь», и это уже работа агентов поддержки. Результат: вместо «упс, попробуйте позже» пользователь видит «видео весит 6 ГБ, лимит 5 ГБ, ничего не сохранено, сожмите файл или смените тариф». Чтобы найти, что чинить в первую очередь, можно поднять тикеты за полгода и посчитать: обычно четыре ошибки порождают большинство обращений.

Аналогия с врачом работает и для запросов функций. Пользователь просит экспорт в CSV, как пациент просит антибиотики. Хороший врач расспросит о симптомах. Выяснится, что люди каждый понедельник грузят CSV в Google Таблицы или пересылают бухгалтеру, и нужна синхронизация с таблицами и регулярные отчёты, а кнопка CSV будет лишь частью решения. Если вы не знаете, какие профессии решили вашу проблему, попросите Claude провести интервью и подсказать это.

Вывод: растите планку быстрее моделей

Модели делают скачок каждые пару недель, а ожидания растут куда медленнее. Этот разрыв и есть возможность. Пример с первой милей быстрее четырёх минут (следующий человек повторил рекорд всего через 46 дней) напоминает: увидев, что кто-то это сделал, вы перестаёте считать задачу невозможной. Практический итог: ставьте цель за целью, настраивайте агенту среду и доступы, требуйте методов экспертов и ищите решения в чужих областях. Часть материала автор вплетает в рекламу своего курса, но сами идеи работают независимо от него.