Transcription
Привет, друзья? Я собираюсь сделать это кратко и по существу. Я выделил семь этапов разработки с ИИ. Другими словами, когда вы работаете над кодированием с вашим ИИ-помощником по кодированию, в моем случае, Claude code обычно, то это семь этапов, о которых вам следует думать при выпуске отличной работы. То, как вы достигаете этих этапов, в некотором роде зависит от вас. Существует множество различных реализаций, но это те, которые, как я понял, являются своего рода общими для множества различных подходов. Независимо от того, используете ли вы циклы Ральфа, как я в основном, используете ли вы GSD, используете ли вы SpecKit, вы, вероятно, будете использовать эти семь этапов. Если вам нравится эта тема, и вы считаете, что основы инженерии действительно важны в эпоху ИИ, то угадайте что? Я тоже. И это то, что я освещаю и подробно описываю в своей рассылке. Это не для "вайбовых" кодеров. Мы люди, которые серьезно относятся к инженерии ИИ и серьезно относятся к созданию приложений, которые созданы на века. Так что, если это звучит как вы, и вы хотите улучшить свои навыки, то это место для вас. Но без дальнейших церемоний, давайте перейдем к списку.
Этап первый, мы начинаем с идеи. У вас есть какая-то идея, какая-то причина, по которой вы инициируете этот прогресс, что-то, что вы хотите, чтобы ИИ сделал для вас. Это может быть идея всего приложения, которое вы хотите создать. Или у вас может быть только узкая задача, которую вы хотите выполнить в кодовой базе, в которой вы находитесь, например, исправление ошибки или новая функция. Я также считаю рефакторинг частью этого. Так что, если у вас есть кодовая база, которую вам нужно рефакторить, то этот процесс будет работать и для вас. Эта идея может быть такой маленькой или такой большой, какой вы хотите. Мы можем расширить эту идею, и этот процесс может воплотить в реальность очень, очень большие идеи, или он может быть крошечным, очень узким и очень сфокусированным, не имеет значения.
Теперь, чтобы дать вам представление о будущей настройке, идея будет преобразована в набор задач, которые своего рода ИИ будет выполнять. Этот набор задач может состоять из множества различных видов ИИ, работающих одновременно, или, возможно, просто большого списка задач, которые ИИ будет выполнять последовательно. Так что, если эта идея включает в себя какое-либо исследование, какие-либо сложные этапы исследования как часть создания кода, то вы можете захотеть включить этап исследования. Например, если вы делаете интеграцию Stripe или, возможно, интегрируетесь с API, который не очень распространен, то вы можете создать ресурс, который собирает все исследования об этой вещи, основанные на вашей идее, кэширует ее и помещает в репозиторий или куда-то еще, к чему ваш агент может получить доступ. По сути, каждый раз, когда ваш агент выполняет работу, ему может потребоваться исследовать репозиторий в новом контекстном окне. И если это исследование затруднено, то есть через внешний API или где-то, куда трудно получить доступ, тогда вы захотите кэшировать его в ресурсе research.md, и вы определенно захотите запустить этап исследования в этот момент.
Следующий шаг после исследования — перейти к прототипированию. Теперь, на этапе прототипирования, мы все еще не совсем уверены, что именно мы строим, и даже, возможно, почему мы это строим. Прототипирование очень важно, если вам нужно наложить свой вкус на результат. Другими словами, возможно, вам нужен пользовательский интерфейс, который должен выглядеть определенным образом или вести себя определенным образом. Вы не совсем уверены, какой из них выбрать. Что я обычно делаю, так это просто выбрасываю кучу разных идей в одноразовый маршрут, который своего рода является тем, как LLM показывает мне все различные способы, которыми он может придумать для создания прототипа. Затем я итерирую прототип в течение нескольких сессий и говорю: "Хорошо, нет, этот выглядит лучше всего". Я обнаружил, что делать это на раннем этапе абсолютно необходимо, потому что тогда вы можете фактически зафиксировать прототип в своей кодовой базе, а затем сделать его доступным для агента, когда он фактически приступит к его реализации.
Следующий шаг, мы находимся на этапе четыре, — это создание PRD. Теперь, когда мы немного больше понимаем внешние API, которые мы используем на этапе исследования, теперь, когда мы немного больше понимаем прототип и фактически видели некоторый код, пришло время начать правильно описывать конечную цель. Теперь мы должны чувствовать себя уверенно в себе, чтобы мы могли понять конечный результат, то, что мы пытаемся создать в итоге. Мы еще не будем знать всех решений по реализации. мы просто будем знать основные вещи, которые увидит пользователь, и то, как он будет себя вести. Кстати, нам не обязательно называть это PRD. PRD — это документ с требованиями к продукту, но на самом деле это просто какой-то документ, описывающий конечный результат того, куда мы движемся.
Теперь, в процессе создания этого конечного результата, нам действительно нужно проработать дизайн. И это означает, что нам нужно побудить агента полностью проанализировать нас, пройдя по каждому пункту нашего дерева решений. У меня есть навык написания PRD, который специально разработан для этого, и я дам ссылку на него ниже, если вам интересно. Но после того, как мы создали PRD, пришло время фактически начать разбивать PRD на какой-то план реализации. Для тех из вас, кто не является разработчиком или никогда не использовал, я не знаю, канбан-доску или доску Jira или что-то подобное, канбан-доска — это просто список задач, между которыми существуют блокирующие отношения. Мы, по сути, просто описываем работу, которую необходимо выполнить.
Затем у меня есть отдельный навык для преобразования моего PRD в отдельные задачи. Мы могли бы создать единый последовательный план, который преобразует PRD в фактический код. Но с канбан-доской вы фактически можете эффективно распараллеливать. И поэтому я могу просто буквально зайти на свою канбан-доску, найти все задачи, которые не блокируются, и запустить для каждой из них агента, чтобы он ее решил. Но, конечно, то, о чем я начинаю говорить здесь, — это выполнение. Так что в каком-то цикле здесь запустите кодирующий агент для выполнения всех задач на канбан-доске. В большинстве случаев вам не нужно будет распараллеливать это. В большинстве случаев последовательного агента, работающего над каждой задачей, будет достаточно. И для меня это цикл Ральфа, который очень, очень эффективно работает с этой настройкой. И я оставлю несколько ссылок ниже о написании о Ральфе, которое я сделал.
Наконец, после того, как вы закончили выполнение, у вас есть готовый ресурс для фактического просмотра, затем вы просите агента создать план QA для человека, чтобы проверить завершенную работу. И обычно это приводит к появлению новых задач на канбан-доске и повторному прохождению цикла выполнения. Таким образом, вы будете склонны повторять эти последние три шага довольно много раз, пока не итерируете к идеальному продукту. И QA здесь также включает в себя человека, который фактически читает код, который был создан во время цикла выполнения. Это может быть не всегда необходимо, особенно если вы используете своего рода архитектуру "серого ящика", о которой я говорил в предыдущих видео. Но в целом, эти семь этапов — это то, о чем я думаю, когда работаю с агентом ИИ.
Мы начинаем с идеи — какого-то приложения, функции или рефакторинга. Если мы знаем, что существуют внешние зависимости и сложные этапы исследования, то мы кэшируем их на этапе исследования. И, кстати, это исследование обычно существует только в течение жизненного цикла этого спринта, по сути, или в течение жизненного цикла идеи, которую мы накладываем на приложение. Причина этого в том, что исследование может устареть или фактически привести к тому, что наш агент свернет не туда, где это необходимо. Если мне нужно наложить свой вкус, то я буду использовать прототип. Поэтому я действительно просто посижу с агентом, человек в цикле, чтобы проработать некоторые идеи. Это не только для дизайна. Это может быть и для архитектуры программного обеспечения, или, скажем, для тестирования чего-либо с внешним сервисом. Это важный шаг, потому что к моменту, когда мы дойдем до PRD, это будет немного слишком абстрактно. Вам действительно нужна конкретная обратная связь сначала.
Затем я пишу PRD, который является документацией, спецификацией того, куда мы движемся. Далее я составляю своего рода понимание пути к PRD, преобразуя его в канбан-доску. Я обычно использую GitHub Issues как для PRD, так и для канбан-доски. Кстати, это просто легкая вещь, которую я нашел, хотя GitHub еще не имеет встроенного способа представления блокирующих отношений между задачами. Так что, возможно, вам будет лучше с чем-то вроде Linear, который это делает. Как только канбан-доска будет готова и настроена, я выполняю ее в каком-то цикле. Для меня это цикл Ральфа. Вы также можете, я полагаю, делать выполнение в стиле "человек в цикле", где вы сидите и выполняете задачи индивидуально, но я обычно нахожу, что со всей этой настройкой с исследованием, с прототипом, с канбан-доской, с помощью PR, вы можете полностью запустить этот цикл выполнения AFK, и результаты будут действительно хорошими.
И чтобы убедиться, что они действительно хороши, мы затем входим в этап QA, где мы просим агента создать план QA. Затем человек, да, человек, да, мы здесь, фактически проходит и проверяет завершенную работу, а затем создает больше задач для канбан-доски, которые затем выполняются, и проводится больше QA. Вы поняли. Но что вы думаете об этом? Что я упустил и что я упускаю здесь? Я предполагаю, что эти этапы вырастут до восьми и девяти этапов, когда у меня появятся новые идеи. Здесь нет явного упоминания об обзоре кода. Я полагаю, я мог бы сделать это как часть процесса выполнения. Я полагаю, возможно, это относится к QA, но, знаете ли, это определенно важный шаг для создания хорошего кода. В любом случае, вы можете сказать, что я забочусь о хорошем коде, и если вы тоже, то вам следует ознакомиться с моей рассылкой. Но независимо от того, подпишетесь вы или нет, спасибо за просмотр, и я увижусь очень скоро.