Transcription
Я инженер уже почти десять лет, и за все это время процесс никогда не был более важным. Сейчас у вас под рукой есть целый парк инженеров от среднего до хорошего уровня, которых вы можете задействовать в любое время. Но странность этих инженеров в том, что у них нет памяти. Они не помнят того, что делали раньше. И поэтому вам нужны чрезвычайно строгие и четко определенные процессы, чтобы эти агенты действительно делали полезные вещи. Это означает, что вы, как разработчик, постоянно ищете способы направить своих агентов, чтобы они оставались на правильном пути. А для меня это привело к развитию множества навыков. Вот репозиторий всех навыков, которые я использую прямо сейчас. Каждый из них я проработал и разработал. Некоторые из них я использую относительно редко, но некоторые я использую каждый день. И эти навыки помогают мне кодировать мой процесс. Таким образом, у ИИ есть действительно строгий путь, по которому он может идти каждый раз. И в результате использования всех этих навыков качество кода, которое производит ИИ, резко возросло.
Теперь, если вы думаете, что процесс важен и что реальные инженерные навыки важны, то, о боже, у меня есть курс для вас. Этот курс называется Claude Code для реальных инженеров. Это двухнедельный когортный курс, который начинается 30 марта, и еще семь дней на него действует скидка 40%. Если вы чувствуете, что отстаете от тренда в Claude Code и хотите значительно опередить его всего за две недели, то, черт возьми, это место для вас.
Давайте начнем говорить о наших навыках с первого, который, возможно, мой любимый. Это навык "Заставь меня пройти собеседование". Этот навык, да, он всего три предложения. И давайте просто прочитаем его полностью, чтобы описать, что он делает. "Допрашивай меня безжалостно по каждому аспекту этого плана, пока мы не достигнем общего понимания. Пройди по каждой ветви дерева проектирования, разрешая зависимости между решениями одно за другим. И, наконец, если на вопрос можно ответить, изучив кодовую базу, изучи кодовую базу вместо этого." Концепция дерева проектирования взята из этой книги Фредерика П. Брукса, "Проектирование проектирования". На самом деле, я не знаю, взята ли она из этой книги, но именно в этой книге я увидел ее впервые. Дерево проектирования — это идея, что при разработке дизайна вам нужно пройти по всем ветвям дерева проектирования. Например, вы можете разрабатывать страницу поиска и вам нужно решить, хотите ли вы расширенный поиск или текстовое поле. Если вы выберете расширенный поиск, то вам нужно будет выяснить все фильтры и все методы сортировки, которые вам нужны в расширенном поиске. И вы продолжаете идти вниз по дереву, пока не определите свой дизайн в полном объеме или настолько полно, насколько это возможно, прежде чем фактически приступить к написанию кода.
Этот навык "Заставь меня пройти собеседование", когда я его вызываю, я вызываю его, когда хочу достичь общего понимания с LLM. Я обнаружил, что относительно недавно Claude Code имеет тенденцию просто выдавать план очень рано, когда я перехожу в режим планирования, и он имеет тенденцию просто создавать документ до того, как я почувствую, что достиг общего понимания с LLM. Но навык "Заставь меня пройти собеседование" заставляет этот разговор. И он заставляет LLM допрашивать меня по каждой части. Вот разговор, который у меня был с Claude недавно о добавлении функции в кодовую базу моего редактора видеокурсов. Я дал ему некоторые исследования, которые я провел в файле markdown, и сказал: "Заставь меня пройти собеседование. Я хотел бы подумать о добавлении этого на правую страницу". Он загрузил навык, и то, что я хочу вам показать, это просто количество вопросов, которые он мне задал. Итак, первое, что он сделал, это просто изучил соответствующий материал в кодовой базе, что хорошо. Затем мы приближаем. Мы видим, что он задал вопрос 1: "Где находится документ?". Вопрос 2: "Каков макет пользовательского интерфейса?". Вопрос 3: "Какие режимы имеют панель документов?". Вопрос 4: "Жизненный цикл документа?". Вопрос 5: "Как выглядит инструмент правой документации?". Вопрос 6: "Форма инструмента редактирования?". Вопрос 7, вопрос до вопроса 9. Вопрос 10, вопрос 11, вопрос 12, вплоть до чертова 16-го вопроса здесь. И это относительно короткая сессия допроса, на мой взгляд. У меня были сессии, когда я сидел там почти полчаса, 45 минут, а ИИ отвечал на вопросы по действительно сложным функциям. Знаете, это могло быть 30, 40, 50 вопросов, все из этого абсолютно крошечного навыка. Это одна вещь, которую я хочу, чтобы вы взяли из этого. Навыки не обязательно должны быть длинными, чтобы быть эффективными. Вам просто нужно выбрать правильные слова для LLM в нужное время. И это дерево проектирования, разрешение зависимостей, было просто абсолютно великолепным для меня. Кстати, если вы хотите эти навыки, то они будут по ссылке ниже.
Как только я достигну общего понимания с LLM, как только я проработаю свою идею и пойму все ее последствия, если я затем решу реализовать ее, я вызову свой следующий навык, который называется "Написать PRD". Я на самом деле сделал это в разговоре, который мы только что рассматривали. Итак, он сказал, что я что-то упустил или сделал неправильно, и я сказал: "Написать PRD". Я добавлял к нему "пользователь", потому что у меня есть некоторые, которые как бы живут в проекте. Так что это причина, по которой я это сделал. Вот как выглядит этот навык. Он будет вызываться, когда пользователь хочет создать PRD. Вы можете пропустить шаги, если не считаете их необходимыми. Например, в предыдущем разговоре он сказал: "Мы уже провели глубокое интервью. Давайте перейдем к шагу 4". Итак, шаг 1 — попросить пользователя дать длинное подробное описание. Затем номер 2 — изучить репозиторий, чтобы проверить их утверждения. Шаг 3 — по сути, безжалостно допрашивать пользователя. Так что это просто копия навыка "Заставь меня пройти собеседование" снова. Далее, мы набрасываем основные модули, которые вам нужно будет создать или изменить для завершения реализации. Мы рассмотрим это позже, потому что это связано с навыками, которые я покажу вам немного позже в этом видео. И, наконец, когда у вас будет полное понимание проблемы и решения, используйте шаблон ниже, чтобы написать PRD, и PRD должен быть отправлен как проблема GitHub.
Мой рабочий процесс разработки заключается в том, что я беру эти PRD в GitHub. Я превращаю их в другие проблемы GitHub, которые ссылаются на родительский PRD, а затем у меня есть цикл Ralph, который просто проходит по каждой проблеме, пока она не будет выполнена. Если мы вернемся к разговору, где мы были раньше, мы можем увидеть, что он создал этот PRD здесь. Это было 4 дня назад. Как вы можете видеть, у нас есть постановка проблемы. Страница написания статей в настоящее время перегенерирует весь документ при каждом взаимодействии с ИИ. И решением было добавить опыт редактирования документов с разделенным окном в средство написания статей. Чат остается слева. Новая панель документов, бла-бла-бла. Так что это большая функция. Мы добавляем редактирование документов к своего рода функции чата ИИ. Важное здесь — это пользовательские истории. Есть много, много пользовательских историй как часть этого, и это исходит из гибкой методологии, и мы по сути пытаемся описать желаемое поведение нашей системы на языке, что нелегко сделать. Я до сих пор не совсем правильно определился с правильным форматом для них. Это просто то, что мне нравится, но вы легко можете использовать язык cucumber для этого или все, к чему вы привыкли. Затем мы приближаем к низу и просто передаем некоторые решения по реализации. Решения по реализации здесь мы не хотим быть слишком предписывающими, потому что мы хотим, чтобы они были долговечными, потому что если код в конечном итоге устареет по отношению к PRD, у нас возникнут проблемы, когда мы фактически будем его реализовывать. Но вы можете видеть теорию здесь. Это своего рода — это действительно хорошее описание места назначения, куда мы направляемся. Но чего у нас нет из PRD, так это фактического пути, это способ, которым мы собираемся добраться до этого места назначения.
И если мы вернемся к тому разговору, здесь я использую свой следующий навык, который называется "PRD в задачи". Что это делает, так это берет PRD, берет место назначения и превращает его в доску задач с различными задачами, которые могут быть независимо взяты. Итак, первый шаг здесь — это определение PRD. Если PRD еще не в вашем контекстном окне, получите его с помощью этой инструкции. Изучите кодовую базу, если вам это нужно. А затем составьте вертикальные срезы. Не всегда ясно, как следует разбивать PRD на отдельные задачи. Это то, чем разработчики занимаются уже целую вечность, верно? И мы разработали своего рода интуицию, как это делать. На мой взгляд, лучший способ сделать это — разбить его на задачи, которые очень быстро выявляют неизвестные неизвестные. Например, если вы интегрируетесь с новым типом сервиса или интегрируете две вещи, которые вы раньше не интегрировали, то вы должны сделать эту работу в первую очередь, потому что она даст вам обратную связь о том, действительно ли ваш подход действителен. Правильная аналогия здесь — аналогия с трассирующей пулей. Я не буду вдаваться в то, что это значит, но по сути каждая задача — это тонкий вертикальный срез, который проходит через все слои интеграции, а не горизонтальный срез одного слоя. В разговоре он разбил этот действительно сложный PRD всего на четыре среза. Сначала он создал своего рода движок с примененными к нему тестами. Это на самом деле довольно хороший вертикальный срез, потому что это был движок, который затем должен был питать остальную часть своего рода настройки. Если бы этот движок по какой-либо причине не работал или был невозможен, то мы бы быстро выявили это. И вот что делает эта разбивка. "PRD2 задачи" также устанавливает блокирующие отношения между задачами. Например, номер два здесь ничем не заблокирован. Так что его можно взять независимо от первого. Это очень полезно, если у вас есть параллельная настройка агентов, где вы можете фактически запустить два агента одновременно, например, в фоновых задачах. И это также означает, что в будущем вы можете добавить другие задачи, такие как задачи QA, которые вы найдете, или вещи, которые нужно улучшить. И вы можете установить блокирующие отношения между этим и всеми остальными вещами. Мы можем видеть, что номер три здесь заблокирован первым, редактирующим движком, а номер четыре, переключатель редактора Monaco, заблокирован номером два. Итак, я сказал "да" всем этим, и он создал все эти проблемы GitHub. Эти проблемы ссылаются на родительский PRD, чтобы локальный агент мог получить его и просмотреть, и он как бы просто разбивает, что нужно построить, и, что крайне важно, он ссылается на предыдущие пользовательские истории в PRD. Затем мы можем увидеть комментарий от Claude Code, который в итоге реализовал это. Он сказал: "Чистая функция редактирования документов с 28 тестами, охватывающими все критерии приемки". И затем мы можем взглянуть на коммит, который ссылается на эту проблему. Итак, это был, по сути, мой цикл Ralph, который пришел и просто реализовал это на основе проблемы, прокомментировал ее, закрыл ее, а затем следующая проблема была разблокирована.
Итак, до сих пор навык "Заставь меня пройти собеседование" может помочь вам проработать идею. Навык "Написать PRD" может помочь вам взять эту идею и превратить ее в документ, а затем навык "PRD в задачи" помогает вам превратить этот документ назначения в фактический путь. Но как тогда фактически выполнить этот навык? Как сделать так, чтобы реализация была действительно надежной и повысить качество кода, который производится? У нас есть навык TDD. TDD означает разработку, управляемую тестами. И когда вы вызываете этот навык, он по сути заставляет агента или, скорее, поощряет агента следовать циклу "красный-зеленый-рефакторинг". В отличие от моих навыков, здесь на самом деле много чего. Так что это не только сам навык. Это также идеи по рефакторингу, по мокированию, по тому, что такое глубокие модули. TDD делает действительно, действительно хорошую работу. TDD был самым последовательным способом улучшения вывода агентов. Так что давайте посмотрим, что на самом деле здесь есть. Что мы видим, я просто пропущу философские вещи. Я позволю вам прочитать это. Мы по сути смотрим на этот рабочий процесс. Да. Теперь первое здесь действительно важно. Подтвердите с пользователем, какие изменения интерфейса необходимы. Теперь я недавно снял видео об интерфейсах и реализациях, но позвольте мне просто дать вам краткое изложение. Когда ИИ смотрит на плохую кодовую базу, он увидит что-то вроде этого, где у него есть тонна крошечных модулей, которые как бы не дифференцированы. Они не действительно сгруппированы. Он не действительно понимает, как эти вещи связаны. И поэтому ему приходится делать много работы, чтобы выяснить, хорошо, что за что отвечает? Каковы зависимости? Как это на самом деле работает, как функционирует кодовая база? В то время как если вы переструктурируете это в несколько более крупных модулей с просто тонкими интерфейсами сверху, интерфейс — это функции, которые фактически экспортируются из этого, вещи, которые вызыватели фактически вызывают, тогда ИИ гораздо легче ориентироваться в этой кодовой базе, и гораздо легче понять, как тестировать эти модули, потому что вы просто тестируете их на их интерфейсах. Вы тестируете их на их границах. Вы можете посмотреть полное видео об этом ниже. Так что этот навык TDD поощряет здесь, по сути, попытку сделать эти изменения интерфейса действительно в центре внимания ИИ, чтобы он понял, что когда он меняет интерфейс, это важное решение, которое ему нужно принять время. Вы подтверждаете с пользователем, какие поведения тестировать. Вы проектируете интерфейсы для тестируемости, ссылаясь на документ, а затем у нас есть еще кое-что по планированию. Затем он входит в прекрасный цикл, где он пишет по одному тесту за раз и пишет тест первым. Теперь я уже говорил о "красный-зеленый-рефакторинг". Так что я дам ссылку на видео ниже, если вы заинтересованы. Но я обнаружил, что "красный-зеленый-рефакторинг" с агентами невероятен, и он по сути делает этот цикл до завершения. Он просто пишет проваливающийся тест, затем пишет код, чтобы этот тест прошел. Затем, наконец, он проходит и ищет кандидатов на рефакторинг. Я не обнаружил, что это потрясающе. Это не было блестяще, потому что часто LLM довольно — знаете ли, они довольно неохотно рефакторят свой собственный код. Если бы вы очистили контекст LLM, то он бы просто стер свою собственную память, и он был бы гораздо менее щепетилен в отношении кода, который он только что написал. Но пока его собственный код находится в его собственном контекстном окне, он довольно неохотно его меняет. Так что этот навык TDD — это то, с чем я прошу мои циклы Ralph, чтобы они выполняли "красный-зеленый-рефакторинг".
Теперь TDD требует от вас многого, или, скорее, требует многого от вашей кодовой базы. TDD очень трудно делать в плохо структурированной кодовой базе, потому что границы тестирования здесь действительно неясны. Должен ли он просто тестировать эти модули отдельно? Должен ли он тестировать эти модули отдельно? Каковы здесь границы? В то время как, когда ваша кодовая база выглядит более так, то ее гораздо легче тестировать, потому что границы модулей действительно ясны. Итак, не было бы здорово, если бы существовал навык, который делал бы вашу кодовую базу более похожей на это? Ну, разве это не приятно? У нас есть навык "Улучшить архитектуру кодовой базы". Процесс для этого заключается в том, что мы исследуем кодовую базу и исследуем ее как бы естественно, как это сделал бы агент. Мы пытаемся найти путаницу. Мы не пытаемся, мы пытаемся естественно выявить то, что ИИ находит запутанным, чтобы он мог помочь ему позже. Где понимание одной концепции требует переключения между многими мелкими файлами? Где чистые функции были извлечены только для тестируемости, но реальные ошибки скрываются в том, как они вызываются? Где тесно связанные модули создают риск интеграции в швы между ними? Все это вопросы, которые старший инженер задавал бы о вашей кодовой базе. Номер два — вы представляете кандидатов. Так что вы представляете нумерованный список возможностей для углубления. Другими словами, возможности для углубления мелких модулей в вашей кодовой базе в более глубокие. Затем пользователь выбирает кандидата, а затем вы проектируете несколько интерфейсов. Так что он говорит, чтобы запустить три под-агента параллельно, каждый из которых должен произвести радикально отличающийся интерфейс для углубляемого модуля. Другими словами, мы извлекаем этот код и проектируем возможные варианты того, как он может выглядеть в будущем. Проектирование его в нескольких разных формах — это действительно отличный способ, которым вы можете затем выбрать правильную идею. Я видел, как этот агент запускал около пяти разных под-агентов для действительно большого рефакторинга. Самое крутое в этом то, что вам не нужно много знать о проектировании интерфейсов, чтобы это работало. После сравнения дайте свою рекомендацию, какой дизайн вы считаете самым сильным и почему. И если элементы из разных дизайнов хорошо сочетаются, то предложите гибрид. Обратите внимание, что я сделал это действительно независимым от языка, действительно независимым от всего. Вы можете просто запустить это в любой кодовой базе и получить достойный ответ о том, как ее можно улучшить. Возможно, есть четыре или пять кандидатов, которые действительно могли бы использовать некоторую работу, но на самом деле я думаю, что вы должны делать только одно из этого за раз, потому что их действительно довольно трудно понять, и они требуют участия человека, чтобы сидеть с ними и улучшать кодовую базу, потому что эти решения действительно требуют вкуса. Наконец, он создает проблему GitHub. Так что он создает RFC рефакторинга как проблему GitHub, используя GH issue create. Обычно после того, как это сделано, я иду со своим навыком "PRD в задачи", ссылаюсь на эту только что созданную проблему GitHub и прошу его, знаете ли, это описывает место назначения. Затем нам нужен путь, чтобы добраться туда. Так что просто делая это время от времени в кодовой базе, знаете ли, раз в неделю, чтобы определить возможности, или если у вас есть внезапный всплеск разработки, и вы создаете целое своего рода дополнительное крыло функций, то этот навык будет очень, очень полезен, просто убедившись, что он соответствует остальной части кодовой базы. Убедившись, что он не слишком небрежен. И по мере того, как вы продолжаете запускать это, по мере того, как вы продолжаете совершенствовать свою кодовую базу, вы заметите, что качество вывода агентов повышается. Потому что старая поговорка действительно применима. Если у вас есть мусорная кодовая база, то ИИ будет производить мусор в этой кодовой базе. Потому что, честно говоря, если бы вы взяли все эти навыки и просто сказали: "Хорошо, это как маленькая мини-книга в формате markdown с процессами для людей", то это не выглядело бы неуместно. Я обнаружил, что самый успешный способ повысить качество кода от агентов — это просто относиться к ним как к людям. Людям с странными ограничениями. Конечно, людям, у которых нет памяти, и они просто клонируются из родильного пузыря и сразу же идут работать. Но если вы, как и я, думаете, что эти реальные инженерные навыки очень важны, то этот курс абсолютно для вас.
Что я заметил, когда создавал курс, так это то, что я на самом деле не так уж много учу Claude Code. Я учу, что такое под-агенты. Я говорю об ограничениях LLM, о своего рода странной умной зоне, глупой зоне с контекстным окном. Мы говорим об управлении, которое по сути является просто способом документирования вещей внутри вашей кодовой базы, как решать огромные задачи, понимание трассирующих пуль и встраивание их в наши навыки, понимание того, как строить действительно отличные циклы обратной связи и выполнять упражнения с ними, и, что крайне важно, как подключать их к автономному агенту. Каждая часть этого курса как бы ведет к другой, и я очень доволен тем, как он получился. Итак, в течение двух недель вы будете работать над этим материалом в своем темпе, а я буду вашим проводником в Discord и на живых офисных часах. И если это звучит для вас интересно, то ссылка ниже. Спасибо за просмотр, народ. Я вернусь с гораздо большим количеством материалов на этой неделе. Что бы вы хотели, чтобы я осветил дальше? Я нахожу пересечение между этим реальным инжинирингом и ИИ как потрясающее место для создания контента. Но в любом случае, спасибо за просмотр, и я увижу вас в следующем.