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. Он проанализирует проблему, а затем начнет копаться в кодовой базе, проводя анализ первопричин, а затем реализуя исправление, и даже сделает так, что я смогу нажать кнопку прямо здесь, чтобы создать запрос на слияние для исправления, которое он сделал. Это так круто. И это очень похоже на наших других помощников по кодированию. Я могу сделать @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, чтобы он мог делать такие вещи, как комментировать нашу проблему. А затем я передаю свой токен аутентификации Claude 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 Action, но мы можем увидеть это очень красиво в Cloud Desktop. Так что у меня есть мой репозиторий, над которым мы работали в этом видео. У меня он подключен к моему облачному экземпляру SonarQube. А затем у меня есть сервер MCP, подключенный к Cloud Desktop, просто следуя их документации. Так что мой запрос может быть таким же простым, как: "Привет, Claude, можешь ли ты проанализировать безопасность моего агента исследований Pydantic AI с помощью сервера SonarQube MCP?" Так что я отправлю это, и это займет немало времени. Я вернусь, как только закончу. И вот оно. Мы получаем все наши проблемы, перечисленные. Он даже проводит дополнительное исследование для нас по конкретным проблемам, которые у нас есть. А затем он дает мне окончательный отчет, который является образовательным репозиторием. Вот почему у меня так много проблем. Но он даже находит один большой блокирующий фактор, на который он дает гораздо больше деталей. И такая вещь просто очень мощна для встраивания непосредственно в рабочий процесс кодирования с помощью ИИ. Так что у меня будет ссылка в описании на SonarQube и их MCP. Я очень рекомендую ознакомиться с ними, если вы серьезно относитесь к качеству кода и безопасности. А затем для всех наших рабочих процессов обзора PR они довольно просты. На самом деле, намного проще, чем для исправления. Как я просто перейду к облачному обзору. Так что та же самая настройка с разрешениями. Проверить репозиторий. А затем мы загружаем инструкции, где мы просто загружаем запрос на обзор 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. Вы просто заходите в панель управления. Но затем для токена аутентификации Claude 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. И поэтому также дайте мне знать, если вы хотите, чтобы я освещал больше контента по этому поводу. И поэтому, если вы оценили это видео и с нетерпением ждете большего контента по кодированию с помощью ИИ и агентам ИИ, я был бы очень признателен за лайк и подписку. И с этим я увижу вас в следующем.