Как находить свои «неизвестные» при работе с Claude

Когда инженер Anthropic Тарик Шихипар работает с Claude Code, он постоянно вспоминает старую фразу: карта — это не territория. Карта — это то, что ты даёшь модели: промпт, скиллы, контекст. А территория — это код, реальные ограничения, то, с чем на самом деле придётся столкнуться. Разница между картой и территорией — это твои «неизвестные»: моменты, где Claude вынужден догадываться, что ты имел в виду, потому что ты сам этого не проговорил.

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

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

Когда Тарик приходит к Claude с задачей, он делит свои неизвестные на четыре категории — классическая матрица, но она отлично работает и в агентном кодинге.

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

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

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

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

До реализации: слепые зоны, брейнштормы и референсы

Когда ты начинаешь работу в незнакомой части кодовой базы или в незнакомой для себя области (например, просишь Claude помочь с дизайном, хотя сам в дизайне не разбираешься), у тебя, скорее всего, полно неизвестных неизвестных. Ты даже не знаешь, какие вопросы задавать. В такой ситуации можно прямо попросить Claude сделать «blind spot pass» — буквально этими словами — и объяснить тебе твои слепые зоны. Например: «Я добавляю нового провайдера авторизации, но ничего не знаю о модулях авторизации в этом коде. Сделай blind spot pass, чтобы найти мои неизвестные неизвестные и помочь мне правильнее формулировать промпты».

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

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

Плюс план реализации перед стартом

Когда всё это сделано и ты чувствуешь готовность приступать, стоит попросить Claude собрать план реализации на ревью. В плане важно сфокусироваться на том, что скорее всего изменится: модели данных, интерфейсы типов, пользовательские сценарии. Так Claude выносит на поверхность именно то, что тебе может понадобиться поправить, а не тонет в механическом рефакторинге, который и так надёжен. Пример промпта из статьи: «Напиши план реализации в HTML, но начни с решений, которые я скорее всего захочу подкрутить: изменения модели данных, новые интерфейсы типов и всё, что видит пользователь. Механический рефакторинг спрячь в конец — тут я тебе доверяю».

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

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

Поэтому имеет смысл просить Claude вести временный файл implementation-notes.md (или .html), куда он записывает принятые по ходу дела решения — это пригодится и тебе, и следующей попытке. Пример: «Веди файл implementation-notes.md. Если наткнёшься на edge case, который вынуждает отклониться от плана, выбирай консервативный вариант, записывай это под заголовком “Отклонения” и продолжай работу». Такой подход перекликается с идеей субагентов — когда часть работы делегируется, но контроль и прозрачность решений остаются на твоей стороне.

После реализации: питчи и квизы

Одна из самых важных частей запуска чего угодно — получить одобрение и поддержку коллег. Финальный документ с прототипом, спецификацией и заметками реализации ускоряет понимание для тех, кто начинает с тех же неизвестных, что и ты сам, и ускоряет апрув для экспертов, которые хотят убедиться, что ты учёл типичные точки провала. Пример промпта: «Собери прототип, спецификацию и заметки реализации в один документ, который можно скинуть в Slack для получения одобрения. Начни с гифки-демо».

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

Как это сработало на запуске Fable

Видео для запуска Claude Fable было смонтировано от начала до конца при помощи Claude Code — и монтаж видео был для Тарика совершенно новой областью, где он далеко не эксперт. Он начал с того, что знал точно: Claude умеет монтировать и транскрибировать видео кодом, но было неясно, насколько точно. Он попросил Claude объяснить, как работает транскрипция вроде Whisper, и сможет ли ffmpeg аккуратно вырезать «эканья» и долгие паузы.

Дальше он хотел интерфейс, синхронизированный по времени со словами в речи, но не был уверен, что это реализуемо — поэтому попросил Claude собрать прототип видео на Remotion с транскрипцией, чтобы проверить гипотезу. Наконец, само видео выглядело приглушённым — Тарик понимал, что дело в цветокоррекции, но не знал, что это такое технически. Первая попытка — попросить Claude сделать несколько вариантов на выбор — не сработала, потому что он не понимал, как выглядит «хороший» результат. Тогда он попросил Claude объяснить ему саму цветокоррекцию — чтобы найти это неизвестное неизвестное прежде, чем оценивать варианты.

Совмещение карты и территории

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

Этот подход хорошо дополняет базовые навыки работы в терминале и с инструментами вроде grep, find и пайпов — умение искать в коде быстро освобождает время именно на поиск неизвестных, а не на механическую навигацию по файлам. А если ты только начинаешь путь с Claude Code, начать стоит с бесплатного курса zero2claude — там разбираются базовые привычки, которые потом складываются именно в такие продвинутые приёмы.

Частые вопросы