Гайд по Claude Fable 5 от инженера Anthropic: как находить свои неизвестные и ставить задачи агенту

Эссе, которое разлетелось за сутки

Тарик Шихипар работает в Anthropic над Claude Code. Позавчера он опубликовал в X эссе «A Field Guide to Fable: Finding Your Unknowns», и за сутки оно набрало больше миллиона просмотров. По каналам уже гуляют PDF-переводы, скриншоты и пересказы пересказов.

Оно того стоит. Это не очередной список «10 промптов, которые изменят твою жизнь», а внятная рамка мышления: почему агент делает не то, что ты хотел, и что с этим делать до, во время и после работы. Я перевёл эссе, разобрал по косточкам и добавил комментарии из своей практики.

Карта не равна территории

Работа с Claude Fable 5, пишет Тарик, снова и снова напоминает ему старый урок: карта это не территория.

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

Разницу между картой и территорией Тарик называет неизвестными. Когда Claude натыкается на неизвестное, ему приходится принимать решение самому, угадывая, чего ты хочешь. Чем больше объём работы, тем больше таких неизвестных встретится по пути.

Fable, по словам Тарика, первая модель, где качество работы упирается уже не в модель, а в его собственное умение прояснять свои неизвестные.

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

Четыре вида неизвестных

Приходя к Claude с задачей, Тарик раскладывает её на четыре части:

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

У лучших в агентном кодинге неизвестных сравнительно мало. Тарик пишет, что глядя, как промптят люди вроде Бориса или Джарреда (это создатели Claude Code), он сразу видит: они в деталях знают, чего хотят, и глубоко понимают и кодовую базу, и поведение модели.

Но и они закладываются на неизвестные. Навык агентного кодинга во многом в том и состоит, чтобы сокращать свои неизвестные и планировать с их учётом. И это навык, который можно прокачивать, работая с Claude.

Помоги Claude помочь тебе

В указаниях для Claude важно поймать баланс. Слишком конкретные инструкции, и Claude будет следовать им даже тогда, когда уместнее свернуть с курса. Слишком расплывчатые, и Claude начнёт додумывать за тебя, исходя из общепринятых в индустрии практик, которые могут не подходить твоей задаче.

Если не учитывать свои неизвестные, проигрываешь дважды: не знаешь, когда путь окажется усеян препятствиями, и не знаешь, когда путь чист, а тебе всё равно нужно, чтобы Claude свернул.

Хорошая новость: Claude сам может помочь тебе быстрее обнаружить свои неизвестные. Он молниеносно ищет по кодовой базе и интернету, о большинстве тем знает больше тебя и быстрее проходит путь от ошибки к исправлению.

Самое важное здесь: рассказать Claude, с чего ты начинаешь. Объясни, до чего уже додумался сам, опиши свой опыт с этой проблемой и этой кодовой базой, и работай с ним как с партнёром по размышлениям.

Дальше сами приёмы. Тарик подчёркивает, что не использует каждый из них всякий раз, но полезно держать весь набор под рукой.

До реализации

Проход по слепым зонам

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

В таком случае попроси Claude найти твои неизвестные неизвестные и объяснить их. Тарик называет такой запрос «проход по слепым зонам» и в промпте предпочитает буквальные английские слова "blindspot pass" и "unknown unknowns". И обычно важно дать Claude контекст о том, кто ты и что уже знаешь.

Я добавляю новый провайдер авторизации, но ничего не знаю про модули авторизации в этой кодовой базе. Сделай blindspot pass: помоги мне выявить мои unknown unknowns по этой теме и подскажи, как лучше формулировать промпты для тебя.

Я не знаю, что такое цветокоррекция, но мне нужно откорректировать это видео. Научи меня понимать мои unknown unknowns в цветокоррекции, чтобы я мог лучше формулировать промпты.

Брейнштормы и прототипы

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

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

Например, иногда хочется просто посмотреть, как кнопка выглядит во фрейме, не подключая роут на бэкенде и не заводя дополнительное состояние во фронтенде. Визуальный дизайн Тарику трудно описать словами, но он узнаёт нужное, когда видит. В таких случаях он просит несколько разных вариантов дизайна одного артефакта.

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

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

Прежде чем что-то подключать, сделай один HTML-файл с макетом новой панели инструментов редактора на фейковых данных. Я хочу отреагировать на компоновку до того, как ты тронешь настоящее приложение.

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

Интервью

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

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

Референсы

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

Если есть библиотека, где нужное поведение уже реализовано, или дизайн-компонент, который очень нравится, просто покажи Fable папку и скажи, что там искать. Даже если код на другом языке.

Так же устроен и Claude Design: можно показать понравившийся модуль на каком-нибудь сайте, и он прочитает код под капотом, а не просто посмотрит на скриншот. Так он узнает куда больше о разметке, структуре и о том, как компонент устроен на самом деле.

Этот Rust-крейт в vendor/rate-limiter реализует ровно то поведение backoff, которое мне нужно. Прочитай его и воспроизведи ту же семантику в нашем TypeScript API-клиенте.

План реализации

Когда кажется, что пора реализовывать, Тарик просит Claude написать план и отдать на ревью, с упором на те части, которые вероятнее всего придётся менять: модели данных, интерфейсы типов, UX-сценарии. Так Claude сразу показывает то, что реально может понадобиться поправить.

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

Во время реализации: заметки по ходу

Когда план устраивает, Тарик открывает новую сессию и передаёт в промпт все накопленные артефакты: например, файл со спекой и прототип, и просит агента всё это реализовать.

Но сколько ни планируй, неизвестные неизвестные всё равно где-то поджидают. По ходу работы агент может обнаружить, что нужно пойти другим путём из-за крайнего случая, который он нашёл в коде. Поэтому Тарик просит Claude Code вести временный файл implementation-notes.md, где тот фиксирует принятые решения, чтобы учесть их в следующей попытке.

Веди файл implementation-notes.md. Если наткнёшься на крайний случай, из-за которого придётся отступить от плана, выбери консервативный вариант, запиши его в раздел 'Отклонения' и продолжай работу.

После реализации

Питчи и объяснения

Когда что-то выпускаешь, едва ли не главное это заручиться поддержкой и получить одобрение коллег. Если собрать накопленные артефакты в финальный документ, питч с объяснениями, это ускоряет и понимание (ревьюеры стартуют с тех же неизвестных, с которых начинал ты), и одобрение (эксперты видят, что ты учёл неизвестные и типичные точки отказа, которые они бы сами предвидели).

Собери прототип, спеку и заметки по ходу работы в один документ, который я могу кинуть в Slack, чтобы заручиться поддержкой. Начни с демо-GIF.

Квизы

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

Приём Тарика: сначала Claude выдаёт подробный контекст по изменению, а потом устраивает квиз. Мерджит он только после того, как проходит квиз без единой ошибки.

Хочу убедиться, что понимаю всё, что произошло в этом изменении. Сделай мне HTML-отчёт по изменениям, чтобы я прочитал и разобрался: контекст, интуиция, что было сделано и так далее, а внизу квиз по изменениям, который я обязан пройти.

Как это выглядит вживую: запуск Fable

Видео к запуску Fable было полностью смонтировано в Claude Code. Для Тарика это была новая область, и экспертом в монтаже он себя не называет. Смотри, как он прошёл по собственному гайду:

1. Начал с известного. Он знал, что Claude умеет монтировать и транскрибировать видео кодом, но не был уверен в точности. Попросил объяснить, как работают системы распознавания речи вроде Whisper и получится ли аккуратно вырезать «эм» и паузы через ffmpeg. Это проход по слепым зонам.
2. Проверил гипотезу прототипом. Хотел интерфейс, синхронизированный с произносимыми словами, но не был уверен, что это возможно. Попросил собрать прототип видео на Remotion с транскрипцией.
3. Нашёл неизвестное неизвестное. Видео выглядело блекловато. Он знал, что дело в цветокоррекции, но что это такое, толком не понимал. Сначала попросил несколько вариантов на выбор и понял, что не знает, какой результат считать хорошим. Тогда попросил Claude научить его цветокоррекции.

Забавно, что этот путь мне знаком до деталей: я сам монтировал видео через Remotion и Claude Code и разбирал это в отдельной статье. Могу подтвердить: подход работает.

Что я забираю себе

Дальше уже не Тарик, а мои выводы.

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

Брейншторм до кода я могу только подтвердить. У меня это давно базовый режим: сначала обсуждаем задачу и подход, код потом. Ни одна строчка не пишется, пока мы не сошлись в том, что делаем. Что забираю у Тарика, так это формат: просить не описание вариантов текстом, а несколько живых прототипов, на которые можно ткнуть пальцем. Реакция на готовую картинку работает быстрее, чем воображение над абзацем.

Квизы забираю не глядя. Читать дифф и понимать изменение это разные вещи, я в этом убеждался не раз. Идея «мерджим только после квиза без ошибок» превращает приёмку из формальности в честную проверку самого себя.

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

Так что следующий проект начни с простого: попроси Claude помочь тебе найти твои неизвестные.