Field Guide to Fable — Thariq Shihipar, Anthropic

Компания официально возвращает модель Fable. Её выпуск запланирован на конец сегодняшнего дня, и слушателям предлагают следить за точным графиком выхода. Позднее, в 12:30, состоится дискуссия в формате беседы у камина (fireside chat) с участием Кэт Ву и Саймона Уилсона, где, возможно, будут озвучены дополнительные обновления.

Fable — это модель, вызывающая очень сильные эмоции и энтузиазм. Она относится к той линейке моделей Anthropic, которые запоминаются пользователям и разработчикам так же ярко, как Sonnet 3.5, Opus 4 или Opus 4.5.

Лучший способ описать Fable — это сравнение с моментом в ролевой игре (RPG), когда завершается обучение (tutorial) и перед игроком наконец открывается карта — начинается «открытый мир». В этот момент перед пользователем встает огромный, неизведанный мир, где появляется невероятное количество возможностей для действий и исследований. Однако этот переход может быть немного пугающим и запутанным, именно из-за того, насколько широким становится спектр доступных действий.

Цель данного выступления — представить «полевой путеводитель» (field guide) по Fable, который поможет понять, как именно работать с этим новым классом моделей. Данный материал изначально разрабатывался как серия статей и публикаций в блоге, но в связи с анонсом выхода Fable, лектор решил объединить всё это в рамках данной лекции, проведя своего рода «спидран» по теме.

Выступление состоит из четырех основных частей:

1. Unhobbling Claude (Снятие ограничений с Claude);
2. Finding your unknowns (Поиск ваших «неизвестных»);
3. Dealing with the grief (Работа с осознанием/принятием);
4. Being unreasonable (Быть неразумным).

«Раскрытие потенциала» Claude и природа роста моделей тесно связаны с тем, что мы их выращиваем, а не проектируем. Мы не просыпаемся с мыслью, что нам нужно достичь 99% успеха в SweeBench; модели — это то, что мы выращиваем осторожно, предоставляя им данные, обратную связь и вычислительные мощности. Это органический процесс: мы учимся вместе с моделью по мере того, как используем ее.

Из этого следует, что ограничивают модель именно мы — каркас, в который мы её помещаем, и способы, которыми мы её инструктируем, являются функцией нашего понимания Claude. Под термином unhobbling (распутывание, снятие пут) я имею в виду: как нам понять Claude лучше, чтобы раскрыть его потенциал? Мы всё ещё находимся на очень раннем этапе, и в возможностях моделей скрыто гораздо больше, что нам предстоит открыть.

Пример того, как модели становятся умнее, немного контринтуитивен. Несколько недель назад я видел вирусный твит с вопросом: «Почему большие языковые модели не могут назвать покемонов, чьи имена заканчиваются на "AW"?». Существует 1000 покемонов, и оказалось, что есть два, чьи имена заканчиваются на "AW": Croconaw и Dreadnought. Если вы спросите обычную чат-модель, она не сможет ответить, что сбивает с толку, ведь она определенно знает все имена покемонов. Но если вы спросите Claude Code, он может это сделать. Делает он это так: он находит каждого покемона и пишет скрипт для фильтрации по окончанию "AW".

Это именно то, что я имею в виду под unhobbling Claude. Мы называем это capability overhang (запас возможностей): Claude становится умнее «зубчато» или «всплесками» (spiky ways). Это значит, что модель не просто запоминает всех покемонов и рассуждает о них в памяти, но если вы дадите ей инструмент выполнения кода (code execution tool), она сможет найти тех самых двух покемонов. Часть задачи в работе с моделями — это выяснить такой «запас возможностей»: что стало возможным сейчас? Это то открытие, к которому я призываю присоединиться.

Чтобы прояснить это, стоит посмотреть на то, как модели прогрессировали в прошлом. Один из главных примеров — чат. Раньше моделям нужно было предоставлять контекст. Вы могли, например, вставить всю свою кодовую базу и наивно подумать: «то, как мы решаем задачи программирования, заключается в том, чтобы контекст стал очень большим, и я просто вставлю в него весь свой код, возможно, это будет контекстное окно в 100 миллионов токенов». Но оказалось, что если вместо этого дать модели «руки» — например, доступ к Bash-инструменту для работы с окружением — она может сама собирать и искать в своем контексте. Это озарение привело к созданию Claude Code. Опять же, это пример «зубчатого» роста, своего рода прорыв в том, как мы думаем о работе с моделью. Недавно мы также выпустили Claude Tag.

Недавно была представлена функция Cloud Tag (в контексте инструментов Claude). Главным нововведением стало обеспечение способности модели работать проактивно и в многопользовательском режиме. Если обычно Cloud Code требует явного запроса к модели для выполнения работы, то новая способность модели «самостоятельно просыпаться» и выполнять задачи рассматривается как ключ к новому поколению агентов.

Существует тенденция к изменению того, как модели используют системные промпты. Например, 80% системного промпта для Cloud Code было недавно удалено. Это демонстрирует, как потребности моделей меняются со временем. Ранее, на этапе Sonnet 3.5 New, лучшей практикой считался небольшой системный промпт, ограниченное количество инструментов и большое количество примеров. По мере того как модели становились умнее, им можно было предоставлять больше информации и инструкций, что вело к созданию более объёмных системных промптов с множеством примеров и инструментов.

Однако в последнее время стало ясно, что новый класс моделей предпочитает более компактные системные промпты. Примеры зачастую ограничивают модель, так как она обладает способностью к генерации идей, превосходящей предложенные примеры. Сейчас используется подход предоставления контекста, а не просто жестких ограничений. Разработчики стараются избегать формулировок вроде «не делай этого», которые были крайне необходимы для предыдущих поколений моделей. Таким образом, формат системного промпта постоянно эволюционирует.

В контексте эволюции взаимодействия с Claude, функция Ask User Question прошла заметный путь развития. Раньше, когда модель планировала спросить пользователя о чем-либо, она могла показать диалоговое окно со множеством вариантов выбора. С моделью Opus 4 лектору пришлось приложить усилия, чтобы настроить этот инструмент для корректной работы. На этапе Opus 4.5 появилась возможность запрашивать у пользователя до 40 вопросов одновременно, что позволяло модели буквально проводить интервью. Самая недавняя версия, Opus 4.8 и Fable, позволяет создавать полноценные HTML-отчёты с внедренными внутрь вопросами. Это кардинально меняет способ взаимодействия с пользователем.

Также меняется способ передачи информации от модели. Изначально Markdown был хорошим форматом вывода, показывающим некоторые элементы форматирования. Затем, с появлением режима планирования (plan mode), он стал средством, позволяющим пользователю понять, что собирается делать Claude. Теперь же модель способна создавать подробные HTML-отчёты.

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

Говоря о работе с моделью, необходимо учитывать не только оптимизацию самого ИИ (ранее обсуждалось «раскрепощение» или unhobbling Claude), но и «раскрепощение» самого пользователя. Ключевым концептом здесь является утверждение, что карта — это не территория.

Когда вы работаете над задачей по программированию, план, промпт и спецификация, которые у вас есть в голове, — это карта. Однако территория — это сама кодовая база, реальный мир и ограничения, в которых предстоит ориентироваться Claude. Всякий раз, когда Claude сталкивается на «территории» с чем-то, чего нет на «карте», возникает то, что можно назвать неизвестным (unknown). В этот момент перед моделью встает точка принятия решения, которую разработчик ранее не определил.

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

Для систематизации этого процесса можно использовать матрицу из четырех категорий:

• Known knowns (известные известные): это то, что вы уже знаете и обычно записываете в промпт — то есть ваше четкое понимание того, чего вы хотите получить.
• Known unknowns (известные неизвестные): это вещи, про которые вы понимаете, что еще не знаете ответа на них, просто пока не успели разобраться.
• Unknown knowns (неизвестные известные): это вещи, которые настолько очевидны, что вы бы даже не стали записывать их, но вы сразу узнаете их, когда увидите результат.
• Unknown unknowns (неизвестные неизвестные): это то, что вы вообще не рассматривали, то, о чем вы не имеете понятия. Это те вещи, открытие которых могло бы изменить ваш подход к промптингу Claude.

К счастью, можно использовать саму модель Fable, чтобы помочь себе обнаружить свои «неизвестные».

Для поиска неизвестного с помощью Fable существует несколько практических методов. Лектор выделяет следующие подходы:

Blind spot pass (проход по «слепым зонам») — это метод, позволяющий выявить скрытые проблемы. Вы можете сказать инструменту: «Я работаю над новым auth provider, о котором ничего не знаю в рамках данной кодовой базы. Можешь сделать blind spot pass, чтобы помочь мне определить неочевидные неизвестные (unknown unknowns) и лучше составить промпт?». В таком сценарии Claude изучает модуль аутентификации, находит сложные, запутанные места («dead-end»), которые часто встречаются, или обыскивает git diff и Slack. Вы можете подсказать модели, где именно находится контекст, чтобы она помогла разобраться со всеми подводными камнями (gotchas). Этот метод можно использовать очень широко: например, для изучения новых областей знаний (лектор недавно применял это для цветокоррекции при видеомонтаже). Fable невероятно эффективен в подобных задачах, поскольку в каком-то смысле модель знает больше обо всём, чем человек, нужно лишь правильно извлечь эту информацию.

Brainstorms and prototypes (мозговые штурмы и прототипы) — этот метод помогает разобраться с «неизвестными известными» (unknown knowns), особенно в дизайне, когда вы понимаете, что вам нужно, только когда видите результат. Вы можете попросить создать дашборд и сказать: «У меня нет визуального вкуса. Сделай мне HTML-страницу с четырьмя кардинально разными вариантами дизайна, чтобы я мог на них отреагировать». Идея состоит в том, чтобы получить представление о вещах, которые вы не можете описать словами, и работать с моделью, чтобы довести результат до нужного вида.

Interviews (интервью) — когда появляется понимание того, что именно нужно сделать, всё ещё остаётся много неизвестного. Возможно, вы что-то не учли или не конкретизировали. В таком случае стоит попросить Claude проинтервьюировать вас. Предоставьте модели немного больше контекста о своей работе и текущем этапе разработки. Особенно полезно попросить: «Приоритизируй вопросы, которые могут изменить архитектуру».

References (ссылки/референсы) — один из лучших способов дать Claude карту — передать ей другую карту. Вместо того чтобы самому писать спецификацию, можно сказать: «Вот код, который представляет то, что я хочу получить». Этот код может быть из другой системы или даже на другом языке. Модель должна прочитать и понять этот код, а затем использовать его для своей работы. Этот метод можно использовать множеством способов: например, при создании React-компонента в качестве референса можно передать HTML-макет.

Implementation notes (заметки о реализации) — если во время работы Fable сталкивается с чем-то неизвестным, попросите инструмент регистрировать такие моменты (записывать в лог). Это позволит увидеть, где именно произошли отклонения, и разобраться в причинах. Обычно модель предоставляет контекст о том, что именно произошло.

Quiz (квиз/опрос) — в завершение полезно попросить Fable устроить вам проверку знаний по тому, что было сделано. Это необходимо для того, чтобы убедиться, что вы понимаете выполняемую работу и сможете адекватно представить её при создании PR (pull request) или слиянии кода. Это отличный способ оставаться «в курсе событий» (in the loop) при работе с Fable, что является одной из самых важных частей процесса — сохранять контроль и быть уверенным, что вы получаете именно то, что хотите.

Первый опыт использования моделей класса LLM (в транскрипте ошибочно указано Mythos class model и Fable) вызвал у докладчика двойственное чувство: огромный прилив продуктивности, но одновременно и чувство утраты.

Программирование до появления LLM ощущается теперь как жизнь в другой стране. Докладчик вспоминает опыт руководства стартапом (участником YC — Y Combinator), в котором работало около 30 человек. В то время команда была постоянно вынуждена идти на компромиссы из-за сложности написания кода. Им приходилось выбирать: либо делать приложение быстрым, либо прототипировать новую функцию — причем реализация одной задачи могла занимать месяц, а другой — два месяца. Это было крайне тяжело.

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

Однако он также хорошо помнит бесконечные ночные отладки и недели работы над вещами, которые в итоге не функционировали. Это было состояние постоянного «плавания в неудачах». Большинство проектов, над которыми когда-либо работал докладчик, провалились, а большинство стартапов банкротятся. В целом, по его мнению, программирование и написание кода — это чрезвычайно сложный процесс. И даже несмотря на любовь к тем «взлетам» (состоянию потока при ручном кодинге), вернуться к прежнему способу работы невозможно.

Рефлексия докладчика заключается в следующем: «единственный путь вперед — это пройти сквозь это» (the only way out is through). Сейчас предстоит многое изучить в области генеративного программирования и работы с LLM, но если прилагать усилия и оставаться «в цикле» (stay in the loop), снимая ограничения, то можно достичь очень многого и выйти на совершенно новый уровень возможностей.

Одной из центральных идей является концепция «быть неразумным» (being unreasonable). В культуре компании Anthropic существует убеждение, что привычные компромиссы (trade-offs) не являются чем-то неизбежным. В прошлом, работая в других компаниях, лектор привык действовать «разумно»: составлял список приоритетов, выбирал, чем можно пожертвовать, и в рамках квартального планирования решал, что именно будет приоритетом. Однако концепция «быть неразумным» предлагает иной подход: что, если просто сделать всё сразу? Что, если заставить реальность показать, действительно ли существует этот компромисс? Лектор отмечает, что намерен в дальнейшем быть «гораздо менее разумным».

Математика моделей, таких как Claude и Fable, фундаментально меняет отношение к компромиссам. Существует множество компромиссов, которые люди привыкли совершать подсознательно, например, известная трилемма: «качественно, быстро, дешево — выбери любые два». Лектор утверждает, что лучший способ выполнять более амбициозную работу — это изменить рамки мышления и стать более амбициозными самими по себе. Единственный способ доказать, что агенты работают, — это выполнять лучшую работу в своей жизни быстрее, чем когда-либо прежде.

В качестве примера лектор приводит презентацию, которую подготовил накануне вечером всего за четыре часа с помощью Fable. Этот результат, который лектору очень нравится, был достигнут значительно быстрее, чем обычно. Лектор обращается к аудитории, состоящей из AI-инженеров, с мыслью, что мир ожидает от них доказательств продуктивности ИИ. ИИ — это не просто мимолетное увлечение, он способен сделать нас продуктивнее и сэкономить время. Личная резолюция лектора на этот год — быть более продуктивным, но при этом работать меньше (в смысле тратить меньше времени на сам процесс) и проводить больше времени с близкими людьми.

Важно отметить, что, хотя создание (building) чего-либо стало проще, создание ценности (generating value) по-прежнему остается сложной задачей. Часто AI-инженеры слишком увлекаются самим процессом разработки, настройкой инструментов и инфраструктуры, забывая, что конечная цель — это именно генерация ценности. Для нахождения действительно ценных решений требуется огромное количество попыток, «множество ударов по мячу». Мир ждет, что мы докажем способность ИИ к реальной трансформации.

В завершение лектор призывает аудиторию: исследуйте, воплощайте идеи в реальность и будьте менее разумными.