Transcription
Режим планирования в коде Claude невероятен, но я всегда обнаруживаю, что мои глаза стекленеют от этого огромного эссе в формате markdown в моем терминале. И я понял, что после того, как я реализую вещи, я совершенно упускаю некоторые важные мелкие детали, которые не были мне ясны с самого начала, потому что это было просто слишком много всего для чтения, честно говоря. Я экспериментировал с этим новым навыком, который я создал, под названием "визуальный план". Он частично вдохновлен тем постом о том, как HTML лучше, чем markdown, но HTML может быть медленным и многословным в написании, он плохо выглядит при проверке в репозитории, и я обнаружил, что могу создавать гораздо лучшие визуальные планы с повторно используемыми компонентами. Итак, я создал навык под названием "визуальный план". Он генерирует планы в формате MDX с супервизуальными компонентами, диаграммами, интерактивными спецификациями API, изменениями в дизайне схемы, аннотированным кодом и даже панорамируемыми и масштабируемыми каркасами. Каждый пользовательский интерфейс позволяет вам сначала посмотреть на каркас, прокомментировать его, внести итерации, визуально и интерактивно ответить на открытые вопросы, а затем дать агенту работать. Я обнаружил, что это гораздо более интуитивно понятный интерфейс для меня, чтобы рассуждать о том, что делает агент. Это действительно заставило меня почувствовать, что люди и инженерия как бы вступают в эту новую фазу абстракции, где мы рассуждаем о вещах на уровне плана. Пока план соответствует тому, что мы хотим, агенты становятся все более и более надежными в его выполнении. Почти до той степени, до которой мы доверяем C-компилятору надежно компилировать в ассемблер. Пока план хорош, и мы делаем план ясным, понятным, легким для понимания, легким для людей для рассуждения, обмена, комментирования и т. д., все больше и больше мы можем доверять агентам для его реализации, как ожидается. Я также создал навык для обратного. Я называю его "визуальный обзор". Что он может сделать, так это после того, как агент поработает, дать вам обзор всего, что он сделал. Та же идея. Каркасы, интерактивные спецификации API и различия, схемы, аннотированный код и т. д. Итак, теперь, когда вы просматриваете то, что агент сделал для вас, или смотрите на что-то вроде pull request для кода кого-то другого, вместо того, чтобы смотреть на небольшое резюме или супергранулярный беспорядок построчно, вы можете увидеть визуальный обзор. Интерактивный, легкий, интуитивно понятный. Вы можете даже делиться ими с другими для комментирования, а затем передавать комментарии и отзывы агенту для улучшения. Это позволило мне ловить вещи гораздо раньше. Так, прежде чем агент сделает что-то, чего я не осознавал, потому что, возможно, текст звучал нормально, но каркас заставляет меня понять: "О, подождите. Нет, это не то, что я имел в виду." Или более ясным и визуальным способом я вижу, какие типы API я хочу создать. И я хотел бы, чтобы они были сформированы по-другому. Я могу ловить вещи раньше, а также позже в обзорах моей работы или работы кого-то другого. Я могу сопоставить вещи, которые, возможно, не так очевидны в коде, просто глядя на код React и Tailwind, на самом деле являются тем, что я хотел или ожидал, прежде чем он выйдет в продакшн, и я попробую его и скажу: "О, подождите секунду. Это не то, что я имел в виду. Это не то, что я думал, что сказал агенту. Это не то, что я думал, что увидел в коде." И я буду честен, утомительно вручную тестировать каждую мелочь каждый раз. Наличие снимка на первый взгляд, который ясен и который я могу интерактивно изучить, для меня стало революцией по сравнению с простым статическим markdown. И все это настраивается. Вы можете добавлять свои собственные компоненты, настраивать компоненты. Это MDX. Это лучший формат для проверки. Он может делать гораздо больше классных вещей, и есть также единообразие. Это не просто случайный HTML каждый раз. Этот переход от HTML к MDX, ранее от markdown, я думаю, является полным кругом, который, по крайней мере, мне был нужен. Я бы предпочел видеть необработанные файлы MDX в коде, а не HTML. И есть так много больше, что вы можете сделать с повторно используемыми компонентами, чем генерировать, честно говоря, своего рода HTML-хлам каждый раз, разный каждый раз. Это также означает, что когда вы меняете агентов или модели, вы также получаете единообразие. Я открыл исходный код всего этого. Навыки, приложение, которое генерирует MDX, которое вы можете форкнуть и настроить со своими собственными компонентами. Вы можете проверить это на GitHub, установить и попробовать с помощью CLI, который я сделал, и я хотел бы узнать ваше мнение. Не только о том, нравятся ли вам планы или обзоры, или удобно ли это, включая тот факт, что вы можете установить GitHub action с помощью CLI, но и о том, имеет ли смысл эта новая идея о том, как мы рассуждаем как инженеры. Я действительно верю, что уровень плана — это действительно реальный уровень рассуждения, в котором мы будем думать, говорить и работать. И я хочу сделать это ясным и красивым, и хорошим опытом. Таким образом, поскольку мы больше доверяем агентам в правильном выполнении, а другие агенты проверяют работу по плану, по спецификации реализации, мы можем работать быстрее, мы можем избавиться от деталей. Как люди больше не смотрят на ассемблер. Они рассуждали на уровне C, и это открыло все новые возможности и абстракции, а также способность быстро двигаться по сравнению с предыдущим, но безопасно. И я думаю, что это открывает новые способы сотрудничества. Вы можете поделиться тем же самым с вашими продакт-менеджерами, дизайнерами и т. д., что позволит вам рассуждать об этом подобно вам. По крайней мере, те области, которые заботятся о дизайне или каркасе, и PM — о поведении. И еще одна вещь, которую я считаю классной, это то, что есть также GitHub action, который я сделал, который может запускать это автоматически при каждом pull request и показывать вам снимок визуального плана прямо там в комментариях каждый раз. Вы можете щелкнуть и взаимодействовать, чтобы сделать обзор pull requests более легким и понятным. Итак, опять же, это не просто выбор между кратким описанием и длинным гранулярным построчным, а фактически просмотр визуальных материалов, диаграмм, интерактивных спецификаций API, более понятного кода и даже аннотированного кода. В любом случае, все это бесплатно и с открытым исходным кодом, вы можете найти на моем GitHub. Дайте мне знать, что вы думаете.