Transcription
Будущее программного обеспечения заключается в том, что большая часть, если не вся, кодировка будет передана ИИ, и я умру на этой позиции. Но также, это не так просто. У нас никогда не будет этой волшебной коробки, этого единого ввода чата, где мы можем сказать ИИ, что мы хотим, чтобы он построил, и он будет делать это правильно каждый раз. Это просто никогда не будет существовать. И главная причина этого в том, что нам всегда понадобится то, что я называю уровнем оркестровки. Это место для нас, чтобы выполнять управление задачами, отслеживать изменения в нашей кодовой базе, управлять версиями, даже назначать разные задачи разным кодирующим агентам, которые у нас есть в нашей команде разработчиков ИИ. И GitHub или что-то похожее на GitLab — идеальное решение для этого. Вот почему я говорю, что GitHub — это будущее ИИ-кодирования. И поэтому в этом видео я собираюсь дать вам представление о будущем ИИ-кодирования и о том, как вы можете начать работать с этим прямо сейчас, потому что мы будем интегрировать три разных ИИ-помощника по кодированию в репозиторий GitHub. И я дам ссылки на рабочие процессы в описании. Так что вы можете взять их, настроить для своего проекта, а затем встроить их буквально куда угодно. И вот у нас есть Cloud Code, Codeex и Cursor. Мы можем даже запускать все это одновременно, обрабатывая разные проблемы и запросы на слияние. Мы можем расширить это для работы с другими кодирующими агентами, такими как Klein. Это действительно мощные вещи. И да, называйте меня сумасшедшим за то, что я встроил столько кодирующих помощников в наш рабочий процесс здесь, но я делаю это по двум причинам. Во-первых, я хочу показать вам, что мы можем делать больше, чем просто использовать Cloud Code. Я знаю, что я постоянно рассказываю о нем на своем канале, но я хочу показать, что действительно любой ИИ-помощник по кодированию может работать с тем, что я вам здесь показываю. А затем вторая причина, и это рабочие процессы, которые я рассмотрю с вами в этом видео, каждый из них структурирован немного по-разному. Итак, я использую трех кодирующих помощников, чтобы продемонстрировать три разных подхода к встраиванию наших кодирующих агентов в наши репозитории GitHub. И поэтому мы разберем все это, потому что на самом деле я хочу, чтобы это не просто показало вам, как встроить ИИ-помощника по кодированию в репозиторий GitHub, но и помогло вам подумать о разных подходах и о том, какой из них лучше всего подойдет вам. Итак, давайте приступим. Я покажу вам, как это было сделано, а затем мы перейдем к различным структурам наших рабочих процессов здесь. И поэтому для всех этих интеграций ИИ-помощников по кодированию я использую GitHub Actions. Это инструментарий для CI и CD, встроенный прямо в GitHub, что чертовски здорово. И на самом деле так легко создавать эти рабочие процессы. Как только я углублюсь в каждый из них с вами, я думаю, вы будете приятно удивлены, насколько они просты. Итак, каждый из этих рабочих процессов имеет триггер. Итак, я делаю определенный комментарий в проблеме или запросе на слияние, и тогда это запускает этот поток, который вызывает одного из моих ИИ-помощников по кодированию. Итак, позвольте мне показать вам это прямо сейчас. Итак, я перейду к корневой директории моего репозитория. Я просто использую агента Pantic AI, которого я построил в предыдущем видео, в качестве демо, и давайте перейдем к одной проблеме здесь. У меня есть что-то настроенное заранее, чтобы показать вам, как все это работает. И вот эта проблема, которую я на самом деле заметил в своем репозитории GitHub. И технические детали этого не имеют значения. Я просто нашел какую-то проблему и создал проблему в своем репозитории GitHub, чтобы сообщить об этом. И теперь, что я могу сделать, посмотрите на это. Я могу сделать @claude-fix. Это ключевое слово триггера, которое вызывает этот рабочий процесс, где claude code. Он проанализирует проблему, а затем начнет копаться в кодовой базе, проводя анализ первопричин, а затем реализуя исправление, и даже сделает так, что я смогу нажать кнопку прямо здесь, чтобы создать запрос на слияние для исправления, которое он сделал. Это так круто. И это очень похоже для наших других кодирующих помощников. Я могу сделать @codeex fix, @cursor fix, и бум. Оба этих, я сделал это проще намеренно, но они также создают запрос на слияние, и даже ссылаются на него. Итак, теперь я могу перейти к своим запросам на слияние, и у меня их два здесь, потому что я не нажал на эту кнопку, чтобы создать один для Cloud Code, но для Codeex и Cursor у меня есть реализованное исправление от каждого из них. И тогда другая вещь, которую я могу сделать, это иметь моих кодирующих помощников, которые также рецензируют мои PR. Итак, @claude-review. Итак, я прошу Claude рецензировать запрос на слияние, сделанный Cursor. И я делаю это всего за несколько минут. Это так круто. И поэтому он выполняет полный обзор здесь. А затем, переходя к запросу на слияние от Codeex, я только что попросил Cursor рецензировать его @cursor review, и вот оно. И все очень хорошо отформатировано. Все очень быстро переходит в вкладку "Действия" для GitHub. Также очень легко отслеживать прогресс. Итак, я могу фильтровать задачи, которые находятся в процессе, те, которые успешны. Так что я могу посмотреть и прошлые запуски. Так что у нас много логирования и наблюдаемости, но это все равно очень удобно и встроено прямо в GitHub. Красивая вещь в этом то, что я ничего не запускаю на своей собственной инфраструктуре. Это все среды, которые запускаются в инфраструктуре GitHub всякий раз, когда мы вызываем одного из наших кодирующих помощников. Итак, с этим давайте углубимся в детали. Я хочу показать вам, как выглядят эти разные процессы, даже немного углубиться в код рабочего процесса. И поэтому я покажу вам, как все это работает, а затем я проведу полную демонстрацию в конце. И снова, все эти рабочие процессы доступны для вас для скачивания и встраивания в ваши собственные репозитории. И поэтому, начиная с Cloud Code, это мой пример для вас гибридного подхода. И под гибридным я подразумеваю, что есть части процесса, которые мы запрашиваем у кодирующего помощника, чтобы он выполнил. И есть другие части, которые мы встроили непосредственно в рабочий процесс, такие как детерминированный код, или мы обрабатываем как пользователь. И поэтому для Cloud Code, возвращаясь к проблеме здесь, вместо того, чтобы автономно создавать запрос на слияние, как это сделали Cursor и Codeex, и я покажу это немного позже, он просто делает комментарий здесь в проблеме с кнопкой, которую мы можем нажать. Так что мы все еще в цикле. Мы решаем, когда создавать запрос на слияние, и мы можем даже итерировать с Cloud Code по проблеме в комментариях прямо здесь. И поэтому поток выглядит следующим образом: мы открываем проблему GitHub. Это может быть ошибка или даже функция, которую мы хотим, чтобы он создал. А затем мы упоминаем @cloudfix, верно? А затем мы можем даже добавить любой дополнительный контекст, который мы хотим, например, как мы хотим исправить проблему. Так что мы не ограничены только включением этого в наш комментарий, как я показывал ранее. И поэтому на этом этапе Cloud Code создаст ветку функции для выполнения своей реализации. Он проанализирует кодовую базу и исправит все, что нужно исправить. И поэтому он фактически клонирует репозиторий в этой маленькой среде Docker, которую он создает для обработки вещей как одноразовую реализацию. И затем, как только он сделает свое исправление, он создаст комментарий, который мы видели, с кнопкой для нас, чтобы создать запрос на слияние. И затем, если мы довольны его изменениями, мы можем нажать эту кнопку, и бум, запрос на слияние готов. Так что это довольно полный процесс, но мы также остаемся в цикле. И поэтому, безусловно, этот процесс не такой быстрый, потому что мы должны быть его частью. Но если вы хотите проверить вещи, то гибридный подход очень мощный. Итак, теперь, когда кодовая база открыта, я хочу показать вам эти рабочие процессы, по крайней мере, дать вам хороший обзор того, как части собраны вместе. И поэтому я дам ссылку в описании на папку рабочего процесса напрямую, чтобы у вас был доступ ко всем им. Вы можете принести их прямо в свои репозитории GitHub и даже попросить ИИ-помощника по кодированию помочь вам настроить его для вашего проекта. И я также дам ссылку на видео здесь, где я создал этого исследовательского агента Pantic AI. Это довольно крутой агент, но не фокус этого видео, потому что я хочу поговорить о наших рабочих процессах. И поэтому давайте на самом деле откроем первый здесь. Это claude fix. И поэтому всякий раз, когда у нас есть комментарий к проблеме, мы запускаем этот рабочий процесс. И у меня есть безопасность на месте сразу же, где только определенным пользователям разрешено вызывать Claude в проблеме. И поэтому таким образом я могу фактически иметь этот рабочий процесс в общедоступном репозитории, и не каждый может просто пойти и использовать мою подписку Claude и заставить Claude вносить изменения в мою кодовую базу. И поэтому я фактически взял вдохновение из рабочих процессов, которые у меня есть в Archon, для того, что я показываю вам сейчас. Итак, у нас есть точно такая же вещь, но мы просто защищаем, чтобы только сопровождающие могли вызывать Cloud Code с этой командой. Мы даем ему необходимые разрешения, а затем начинаем с проверки репозитория. Итак, мы создаем эту изолированную среду для этого запуска GitHub Action. Мы приносим кодовую базу в нее, и именно там Cloud Code будет реализовывать свое исправление. И поэтому все, что мы делаем здесь, это просто загружаем этот предварительно настроенный запрос, который у меня есть, описывающий, как он может исправить эту проблему. И поэтому вы можете думать об этом как о слэш-команде. Это многоразовый запрос, который мы фактически используем между всеми нашими различными кодирующими помощниками. И поэтому, если мы исправляем с помощью Claude, Codeex, Cursor, это не имеет значения. Все они будут ссылаться на этот конкретный запрос, чтобы пройти через процесс, который также включает чтение нашего agents.md, например. Итак, мы приносим глобальные правила, которые являются стандартом для каждого кодирующего помощника как часть этого процесса. А затем у нас также есть некоторые параметры, которые мы заменяем как часть нашего рабочего процесса для таких вещей, как имя ИИ-помощника. Таким образом, все наши ветки называются с суффиксом, представляющим кодирующего помощника, который фактически работает над этой веткой. Так что мы сохраняем все очень организованным и можем различать разных членов команды разработчиков, которых у нас есть, наших разных членов команды разработчиков ИИ. Итак, после того, как мы загрузили инструкции, фактическая часть рабочего процесса для вызова Cloud Code очень, очень проста, потому что у нас есть это предварительно настроенное действие, которое мы можем принести в наш поток. Итак, Anthropic имеет свое официальное действие Cloud Code для GitHub Actions. Нам просто нужно передать наш токен GitHub, чтобы он мог делать такие вещи, как комментировать нашу проблему. А затем я передаю свой токен ooth Cloud Code, который, если вы не знали, вы можете просто перейти в свой терминал и выполнить команду `claude setup-token`. Он даст вам этот постоянный токен, или, по крайней мере, он не истекает в течение всего года. И поэтому таким образом я могу использовать свою подписку Anthropic. Так что мне не нужно использовать API-ключ, который намного дороже. У нас есть фаза триггера. Затем у нас есть пользовательские инструкции, где я просто передаю запрос, который я загрузил из документа markdown. А затем просто сообщение о несанкционированном доступе, которое я делюсь, если пользователь не входит в этот список одобренных людей наверху. И вот и все. Это едва ли более ста строк кода. Очень просто. Но это вся мощь Cloud Code, работающая над любой проблемой, для которой мы обращаемся за его помощью. И что-то интересное об интеграции Cloud Code заключается в том, что ничего в нашем рабочем процессе фактически не создает ветку и не делает комментарий к проблеме. Все это делается самим Cloud Code. И поэтому он в значительной степени автономен в этом отношении, помимо гибридной вещи, где мы можем создать запрос на слияние. Но иногда вы не хотите, чтобы кодирующий помощник отвечал за создание ветки, создание запроса на слияние или комментирование проблемы. Вы хотите, чтобы это было встроено в рабочий процесс, а затем вы хотите использовать кодирующего помощника только для фактического кодирования. Так что, если вы хотите максимальный контроль, при этом позволяя кодирующему помощнику делать свое дело, тогда я бы рекомендовал детерминированный подход. И мы используем Codeex для этого примера. И поэтому поток начинается одинаково. Мы открываем проблему и упоминаем Codeex. Но затем он сразу же отклоняется от того, что мы видели от Cloud Code, потому что Cloud Code был тем, кто создал ветку функции для выполнения реализации, которая в конечном итоге приводит к запросу на слияние. Но здесь мы фактически делаем это в YAML для рабочего процесса. Итак, мы определяем процесс, а затем кодирующий помощник только приходит для внесения изменений в код, а затем после завершения изменений кода мы возвращаем контроль обратно нашему рабочему процессу GitHub Action для создания запроса на слияние на основе сводки, которую выводит Codeex, а затем также делаем комментарий к проблеме, указывающий на PR. И поэтому на этом этапе PR готов. И поэтому он более автономен в том смысле, что мы не одобряем создание запроса на слияние, но он гораздо более детерминирован, потому что кодирующий помощник ничего не делает в GitHub сам по себе. Он работает только с кодом. Итак, переходя к коду этого рабочего процесса, он выглядит довольно похоже на наш cloud fix. У нас сначала есть разрешения. Мы проверим репозиторий в нашей изолированной среде для запуска. А затем мы извлекаем наши инструкции из этого шаблона, этого документа markdown, а затем запускаем codeex fix. И поэтому это очень похоже на то, что выпустил Anthropic, где OpenAI имеет это действие Codeex, которое мы можем вызвать. Так что это почти никакой код для вызова самого помощника. Нам просто нужно передать API-ключ OpenAI. И я полагаю, вы также можете использовать свою подписку Codeex, но я просто хотел показать вам один пример использования подписки с Claude. А затем еще один пример использования API-ключа с Codeex. А затем у нас есть этот выходной файл. И это на самом деле очень важно, потому что, когда мы создаем запрос на слияние, поскольку сам кодирующий помощник этого не делает, нам нужен какой-то сводный отчет о том, что он сделал. И поэтому мы выводим его в этот файл. И тогда вы увидите здесь, что мы ссылаемся на это, когда готовим тело PR. Итак, теперь это то, чего мы не видели в cloudfix, потому что мы заботимся об этом детерминированно. Итак, мы готовим тело запроса на слияние с нашим собственным кодом, просто используя сводку, которую вывел Codeex, а затем мы создаем запрос на слияние, а затем мы также вручную комментируем проблему. Итак, мы используем наш токен GitHub, который, кстати, токен GitHub автоматически доступен как один из секретов, которые у нас есть в нашем репозитории. И поэтому, да, мы создаем комментарий к проблеме, который указывает на запрос на слияние, и тогда мы готовы к работе. Это буквально все. У нас есть только обработка сообщения о несанкционированном доступе, и на этом рабочий процесс заканчивается. Итак, немного больше, чем Cloud, потому что мы заботимся о большем количестве вещей здесь. Это дает нам больше контроля, если это важно для вас. А затем Cursor, безусловно, финальный босс для самого автономного агента. И дело не в том, что вам нужно использовать Cursor, когда вы хотите быть полностью автономным. Я просто выбрал одного кодирующего помощника для каждого примера. Но здесь мы создаем проблему GitHub. Мы упоминаем Cursor. И теперь у нас есть фиолетовые поля для всего здесь, потому что мы ничего не делаем в самом рабочем процессе. Мы просто отправляем запрос в Cursor, говоря ему создать ветку с помощью GitHub CLI, проанализировать код и исправить его. А затем, все еще в рамках Cursor, мы просим его использовать GitHub CLI для создания запроса на слияние и комментирования проблемы. И поэтому на этом этапе запрос на слияние готов. И Cursor сделал все. И действительно крутая часть этого рабочего процесса в том, что он одновременно самый простой и самый кастомный. И что я имею в виду под этим, прокручивая все, что мы уже охватили, это то, что мы сами устанавливаем CLI Cursor. А затем мы вызываем агент Cursor в безголовом режиме. Вы, возможно, делали это раньше локально на своем компьютере. Так что, если вы не используете IDE Cursor, вы можете просто сделать одноразовый запрос с флагом -p. И поэтому с Codeex и Cloud Code мы использовали официально поддерживаемое действие GitHub, мы не устанавливали CLI сами или не запускали его в безголовом режиме сами. Но здесь это просто прямая командная строка. Мы устанавливаем CLI, запускаем его, и мы просто предоставляем токен GitHub, а также API-ключ Cursor. А затем у нас есть обработка сообщения о несанкционированном доступе. Мы извлекаем запрос на исправление проблемы примерно так же. Это буквально все. Так просто иметь Cursor, который обрабатывает это полностью от начала до конца, потому что как часть этого запроса и того, что мы вводим сюда, мы говорим ему, вот детали проблемы, которую я хочу, чтобы вы создали ветку, проанализировали код, исправили его, сделали запрос на слияние и прокомментировали проблему, и кодирующие помощники сегодня определенно могут справиться с этим за один запрос. Спонсор сегодняшнего видео — Sonar и их платформа SonarQube, и это очень уместно для этого видео, поскольку я охватываю скорее введение в рабочие процессы кодирования ИИ. Для остального контента здесь у меня на самом деле нет возможности говорить о безопасности, но это очень важно. Вы всегда хотите запускать сканирование качества и безопасности кода, особенно для кода, сгенерированного ИИ. И у них есть сервер MCP, поэтому мы можем подключить SonarQube напрямую к нашим ИИ-помощникам по кодированию. Так что он может сам запускать сканирование безопасности. Буквально, я мог бы взять этот сервер MCP, встроить его в рабочие процессы GitHub, которые я только что показывал вам. Так что мы могли бы запускать сканирование безопасности перед созданием запроса на слияние. И я не буду показывать это здесь, потому что на самом деле трудно увидеть использование MCP в журналах GitHub Actions, но мы можем очень хорошо увидеть это в Cloud Desktop. Итак, у меня есть репозиторий, над которым мы работали в этом видео. Я подключил его к своему облачному экземпляру SonarQube. А затем я подключил сервер MCP к Cloud Desktop, просто следуя их документации. Так что мой запрос может быть таким же простым, как: "Привет, Claude, можешь ли ты проанализировать безопасность моего исследовательского агента Pydantic AI с помощью сервера SonarQube MCP?" Итак, я отправлю это, и это займет немало времени. Я вернусь, когда закончу. И вот оно. Мы получаем все наши проблемы, перечисленные. Он даже проводит дополнительное исследование для нас по конкретным проблемам, которые у нас есть. А затем он дает мне окончательный отчет, который является образовательным репозиторием. Вот почему у меня так много проблем. Но он даже находит один большой блокирующий фактор, на который он дает гораздо больше деталей. И такая вещь просто очень мощна для встраивания непосредственно в рабочий процесс кодирования ИИ. Итак, у меня будет ссылка в описании на SonarQube и их MCP. Я очень рекомендую ознакомиться с ними, если вы серьезно относитесь к качеству и безопасности кода. А затем для всех наших рабочих процессов обзора PR они довольно просты. На самом деле, намного проще, чем для исправления. Например, я просто перейду к cloud review. Итак, та же самая настройка с разрешениями. Проверить репозиторий. А затем мы загружаем инструкции, где мы просто загружаем запрос на обзор PR вместо исправления проблемы. Итак, та же самая вещь, где это, по сути, просто слэш-команда, которую мы принимаем в качестве запроса для отправки, которая также указывает, как извлекать наши глобальные правила. Итак, у нас есть глобальные правила, у нас есть команды, а затем мы запускаем Cloud Code точно так же. Это будет то же самое для Codeex и для Cursor, но на этот раз это просто другой набор инструкций, и мы работаем над запросом на слияние вместо проблемы. Так что именно поэтому я не углублялся в них, потому что это очень похоже. Если вы понимаете, как использовать Claude для исправления или Codeex для исправления, вы будете знать, как сделать то же самое для обзора. И еще одна очень важная вещь, которую я не хочу забыть вам сообщить, это то, как я выяснил, как все это построить. И я никогда не действую вслепую. Я всегда полагаюсь на документацию. Это то же самое здесь. Итак, у меня есть ссылка в описании на каждую из различных страниц документации для разных кодирующих помощников. Например, здесь Cloud Code и GitHub Actions. Они очень хорошо и четко излагают это в своих документах. А затем для SDK Codeex у них есть пример рабочего процесса. Это вот этот, над которым я работал. А затем для Cursor, поскольку я использовал CLI Cursor напрямую, я ссылаюсь на документацию CLI, и у них на самом деле есть пример здесь GitHub Action. Итак, буквально, прямая документация GitHub Action для каждого из кодирующих помощников, которых я использую. А затем я покопался и с другими, такими как Klein, у которого также есть документация по интеграции GitHub Action. И поэтому, действительно, независимо от того, какого кодирующего помощника вы хотите использовать, будет способ интегрировать его практически так же, как я показываю вам с этими тремя основными в этом видео. А затем способ настройки учетных данных для каждой из этих служб в вашем репозитории заключается в том, что вы просто переходите в настройки вашего репозитория, спускаетесь до секретов и переменных, нажимаете на действия, а затем настраиваете свой токен или API-ключ. Так что это довольно очевидно для Cursor и OpenAI. Вы просто заходите в панель управления. Но затем для токена ooth Cloud Code, как это сделать, я упомянул это кратко ранее, но просто чтобы показать вам команду визуально, это `claude setup token`. Так что вам не нужно использовать свой API-ключ Anthropic в GitHub Actions. Вы можете использовать свою подписку, которая намного более экономична. И я слышал, как многие люди говорили, что это невозможно, но я делаю это здесь, буквально. Так что очень, очень экономично. И у меня есть безопасность на месте, так что только я могу вызывать любого из моих кодирующих помощников в моем репозитории. Итак, позвольте мне дать вам полную демонстрацию этого. Вы можете увидеть, как все работает вживую. Итак, я перейду к проблемам здесь. Создам новую простую проблему. Я просто скажу, что readme слишком длинный. Я просто хочу очень простую демонстрацию, которая может пройти довольно быстро для каждого кодирующего помощника. Итак, я скажу, что readme слишком длинный. Нужно сделать его гораздо более лаконичным. Хорошо, круто. И да, я убедюсь, что все написано правильно. Создать проблему. Бум. Мы готовы к работе. Итак, теперь мы обычно можем передать это человеку для решения этой проблемы. Но сейчас я хочу дать моим кодирующим помощникам шанс. У меня есть моя команда разработчиков ИИ. Я хочу оркестрировать будущее ИИ-кодирования. И поэтому я перейду к комментариям здесь. Я скажу @cla-fix, решите эту проблему для меня, пожалуйста. И я мог бы быть гораздо более подробным в проблеме, моем комментарии, но опять же, просто быстрая демонстрация здесь. Итак, я отправлю это. А затем я могу сделать все это параллельно. Так что я также могу сделать codeex fix. Отправить комментарий здесь. А затем я сделаю @cursor fix. И поэтому все три этих рабочих процесса будут запущены одновременно. И поскольку каждый из них добавляет суффикс к ветке с их именем, таким как Claude, Cursor или Codeex, конфликтов не будет. Мы можем запускать их все одновременно. И поэтому я могу нажать на вкладку "Действия" здесь. А затем я перейду к статусу и отсортирую по тем, которые находятся в процессе. И вот оно. У нас есть желтый индикатор здесь, что Cursor исправляет Codeex и Cloud Code. Они все исправляют. И поэтому я вернусь, как только все станет зеленым. Хорошо, запросы на слияние готовы. Каждый из них занял всего пару минут. И поэтому я вернусь к репозиторию здесь. Перейду к нашим проблемам и посмотрим. У нас должен быть комментарий для каждого из наших кодирующих помощников. Вот оно. Cloud Code readme слишком длинный, проблема завершена, а затем у нас есть запрос на слияние Codeex и запрос на слияние Cursor. Очень, очень хорошо. Я нажму на эту кнопку здесь, чтобы создать запрос на слияние от Cloud Code. Итак, теперь у нас пять запросов на слияние: два, которые у меня были в начале этого видео, а затем по одному от каждого из наших кодирующих помощников. И очевидно, что иметь все это параллельно, вероятно, немного избыточно, но интересно посмотреть. И я просто хотел, как я сказал, показать вам несколько вариантов кодирующих помощников. А затем вы никогда не хотите сливать запрос на слияние без обзора. Итак, снова, я мог бы попросить человека сделать это, но я собираюсь попросить кодирующих помощников рецензировать друг друга. Итак, это наш от Codeex. Давайте попросим Cloud Code сделать это. Итак, @claude-review. Я мог бы добавить больше деталей, но я просто отправлю это и перейду к следующему. Итак, далее у нас есть от Cursor. И поэтому давайте попросим Codeex рецензировать это @codeex-review. Хорошо, выглядит очень хорошо. А затем, вы знаете, как это делается. Мы перейдем к последнему здесь, и мы попросим Cursor рецензировать работу от Cloud Code @cursor-review. Итак, у нас есть этот приятный маленький треугольник, где все кодирующие помощники рецензируют работу друг друга. Так здорово. Возвращаясь к рабочим процессам здесь. Если я обновлю, чтобы увидеть только те, которые находятся в процессе. У нас их два здесь, а затем один для Cursor появится через секунду. Вот оно. Хорошо, у нас все три запущены. Так что я вернусь снова, как только у нас будут зеленые галочки. И вот оно. Последние три обзора запросов на слияние теперь завершены. Мы можем просто открыть их очень быстро. И в целом, процесс обзора довольно прост. Все эти рабочие процессы довольно просты, потому что я просто хочу использовать это как отправную точку для вас. Так что вы можете взять его, вы можете настроить правила, вы можете настроить команды, действительно все, что вы хотите, чтобы ваши кодирующие помощники делали в ваших репозиториях. Вы можете делать гораздо больше, чем просто обрабатывать проблемы и запросы на слияние. И поэтому, вот один обзор. Действительно, действительно приятно и структурировано. Нашел всего пару мелких вещей. И это будет выглядеть одинаково для всех них, для Codeex, а затем также для Claude. Но мне просто нравится форматирование, которое у нас здесь есть. Наличие ИИ для обзора кода и возможность полностью настроить процесс обзора кода — это прекрасная вещь. Итак, это все, что я имею для вас по интеграции наших кодирующих помощников с нашими репозиториями. И я знаю, что это было скорее базовое введение, но я надеюсь, что это действительно поможет вам понять, почему GitHub — это будущее ИИ-кодирования. И, пожалуйста, не стесняйтесь использовать эти рабочие процессы для себя. Я дам ссылки на все них в описании. Вам действительно нужно только изменить разрешения, а затем вы можете изменить запросы, которые загружаются, все, что вы отправляете кодирующему помощнику. Вы можете настроить это практически для всего, что вы хотите делать в своих репозиториях GitHub. И поэтому также дайте мне знать, если вы хотите, чтобы я освещал больше контента на эту тему. И поэтому, если вы оценили это видео и с нетерпением ждете большего контента по ИИ-кодированию и ИИ-агентам, я был бы очень признателен за лайк и подписку. И с этим я увижу вас в следующем.