Transcription
Спасибо. Спасибо, Жасмин, за представление. Прежде чем мы перейдем к теме повышения продуктивности разработчиков с помощью ИИ сегодня, я думаю, было бы разумно оценить, где мы находимся сегодня с ИИ. Итак, если каждый сможет достать свои телефоны и отсканировать этот QR-код, это будет небольшой опрос, который мы проведем, чтобы увидеть, насколько мы продвинулись в продуктивности ИИ как группа прямо здесь сегодня. Возможно, вас попросят указать ваше имя. Не стесняйтесь пропустить эту часть. Э, в любом случае это будет анонимно. А затем, ответив на первый вопрос, убедитесь, что вы не закрываете экран. У нас всего три вопроса, которые мы зададим, и все они будут по той же ссылке. Хорошо. Раз, два, идем дальше. Я оставлю Жасмин на секунду тоже. Хорошо, вот так. Хорошо, первый вопрос. Какой уровень ИИ-ассистированного кодирования лучше всего вас описывает? И мы увидим здесь живое обновление. Вы можете сказать "никакой", если вы используете мало или совсем не используете ИИ, "новичок", если вы иногда используете чат, GPT или Claude. "Средний", если вы регулярно используете ИИ для своего ко-пилота, "продвинутый", если ИИ является вашим стандартом, и вы в основном просматриваете и итерируете код, который он производит. И "эксперт", если вы создаете полноценные рабочие процессы ИИ, агентов и интеграции инструментов. Отлично. Я вижу, как поступают ответы. Похоже, большинство из нас здесь — "средний" уровень, около 60%, что довольно хорошо. Только 2% — "никакой", что приятно слышать. И переходим к следующему вопросу. Какой процент вашего ежедневного кодирования генерируется ИИ, по вашей оценке сегодня? Я вижу 25%, 50%, 75%. Хорошо, этот показатель ниже, чем я ожидал, по сравнению с предыдущим, но около 50% из вас, похоже, имеют от нуля до 25% кода, сгенерированного с помощью ИИ. И последний вопрос, он довольно открытый. Какие инструменты повышения продуктивности разработчиков вы используете больше всего? Здесь может быть до пяти ответов. Просто введите любые инструменты, которые вы используете больше всего, и мы увидим, как начнет появляться облако слов. Вижу много ко-пилота. Чем больше слово, тем больше людей его написали. Я вижу ко-пилот, много чат, GPT, Claude, Cursor, GitHub, Cider, Astra. Кто-то только что сказал "код". Хорошо, это работает. Я дам еще пару. Не такое широкое разнообразие, как я думал. Похоже, большинство из нас используют ко-пилот, и это имеет смысл.
Итак, я хочу сравнить, где мы находимся в комнате сегодня, с последним опросом. Stack Overflow провел опрос об инструментах ИИ в процессе разработки. И они обнаружили, что примерно один из трех инженеров использует ИИ для кодирования менее одного раза в месяц, что намного выше, чем я ожидал. Это один из трех человек, которых вы можете видеть здесь, не используют код вообще, но я думаю, что, судя по тому, что мы видели, мы немного выше этого. Также может быть некоторая предвзятость, потому что это опрос Stack Overflow, и люди, которые используют Stack Overflow, могут использовать ИИ немного меньше, но это лучшие данные, которые у нас были. Теперь, что также действительно интересно, это то, что, хотя использование ИИ постоянно росло в течение последних 3 лет, настроения на самом деле снизились за последние 2025 год. В 2023, 2024 годах настроения были выше 70%. А в этом году, в 2025, мы спустились до 60%. Что интересно, потому что, как мы знаем, инструменты ИИ в 2025 году лучшие, чем когда-либо, верно? Так почему же? Я думаю, во многом это связано с заголовками вроде этого и множеством генеральных директоров, которые выступают с очень, очень смелыми заявлениями об ИИ, и, например, Цукерберг пошел на подкаст Джо Рогана и говорил о том, как ИИ скоро заменит инженеров среднего звена, возможно, к концу 2025 года, и из-за этого, я думаю, естественно, возникает ажиотаж с одной стороны, а затем возникает ответная реакция, когда люди начинают говорить: "нет, это не так, ИИ-кодирование немного переоценено, это не все, что планировалось". Так маятник качается в эту сторону. И я думаю, что именно здесь мы находимся прямо сейчас, когда многие люди немного опасаются использовать ИИ для кодирования. Но реальность, как и в большинстве вещей, обычно лежит где-то посередине.
Итак, повестка дня на сегодня: мы немного поговорим о текущем состоянии продуктивности разработчиков. Какие реалистичные выгоды вы можете ожидать получить? Затем мы немного поговорим о выборе вашего ИИ-ко-пилота. И, наконец, перейдем к двум рекомендованным мной инструментам: Cursor и Claude. А затем я поделюсь некоторыми уроками, которые я извлек от генерального директора Data Bricks на прошлой неделе, после чего в конце будет сессия вопросов и ответов. Хорошо, приступим. Продуктивность разработчиков. Прежде всего, это еще одно долгосрочное исследование, проведенное Стэнфордом более чем на 100 000 сотрудников, и они хотели выяснить, насколько реально повышается продуктивность в написанном коде. Итак, я не буду вдаваться в точную методологию, которую они использовали, но они не просто измеряли количество коммитов или строк кода, измененных. У них была группа экспертов, которая просматривала код и пыталась реально понять, какой уровень продуктивности был достигнут благодаря этому коду, а не просто количество или объем. И они обнаружили, что примерно на 30-40% больше кода генерируется с использованием ИИ. Однако они также поняли, что 15-25% этого кода приходится переделывать, потому что в нем есть ошибки или он в конечном итоге удаляется позже. Таким образом, они оценили, что чистый общий прирост продуктивности инженеров-программистов от ИИ составляет около 15-20%. Теперь я думаю, что это число может быть еще выше, если вы научитесь использовать эти инструменты, но я думаю, что как минимум это то, что вы можете ожидать получить от этих инструментов. Теперь перейдем к инструментам. Я думаю, есть три категории инструментов. Первая категория, я бы сказал, это универсальные дружелюбные к не-разработчикам инструменты, которыми может пользоваться кто угодно, и я думаю, что в этой категории мы действительно имеем 100-кратный рост продуктивности. Именно здесь я много времени уделяю преподаванию в Калифорнийском университете в Беркли. Я также руковожу некоммерческой организацией для детей, чтобы научить их использовать инструменты ИИ. Мы видим, как люди без опыта приходят на эти курсы, создают бизнес и начинают зарабатывать тысячи долларов на программном обеспечении, которое они написали, верно? Является ли это самым безумным программным обеспечением? Нет. Но оно выполняет свою работу и приносит им деньги. То же самое с детьми. К нам приходят 11-летние дети и создают приложения, которыми начинают пользоваться их друзья, и они получают реальных пользователей. Так что здесь действительно есть 100-кратный рост продуктивности, когда вещи, которые раньше были недоступны, теперь доступны, что также может быть связано с некоторым переоцененным ажиотажем вокруг ИИ, поскольку мы не видим такого же 100-кратного роста для разработчиков, но мы все еще видим рост. И я бы разделил наши инструменты для разработчиков на два сегмента. Один — это уровень IDE, где находятся инструменты, построенные на основе фундаментальных моделей LLM, такие как Copilot, который большинство из вас использует, Cursor, IntelliJ, CLion, и совсем недавно вышедший Google Anti-Gravity, так что мне пришлось обновить свой слайд. А с другой стороны, у нас также есть уровень инструментов, основанных на терминале, CLI. Обычно они создаются самими фундаментальными моделями — Claude, ChatGPT, Google Gemini — они создают свои собственные модели в этом формате CLI. И я собираюсь рассказать о многих вещах, которые, возможно, многие из вас уже знают, поскольку мы находимся на среднем уровне, но надеюсь, все вы сможете подняться на ступень выше, и к концу этого занятия освоите хотя бы один CLI-инструмент и один IDE-инструмент, если вы еще этого не сделали.
Переходя к выбору вашего ИИ-ко-пилота, как мы уже говорили, множество, множество инструментов. Большинство людей используют Visual Studio Code, согласно тому же опросу Stack Overflow, около 75%. Но что действительно интересно, так это то, что они углубились еще на один уровень и спросили тех, кто использует Visual Studio Code, с каким инструментом они хотят работать в будущем. И самые популярные ответы были Cloud Code, Cursor, IntelliJ, Codium, и Neovim. Но да, так что мы рассмотрим два инструмента сегодня: Cloud Code и Cursor. Не потому, что они были выбраны опросом, а потому, что я также считаю, что это, вероятно, одни из лучших инструментов на данный момент. Итак, мы проведем скоростной забег по 10 лучшим советам по Cursor, чтобы, если вы никогда раньше не пользовались Cursor, после этой сессии вы могли его скачать и стать профессионалом. Начнем с совета № 1: Tab. Я думаю, 2% людей здесь сказали, что они не используют кодирование вообще, и для этих людей я бы очень, очень рекомендовал начать с этой функции. Cursor создал свою собственную специализированную пользовательскую модель на основе этого, и она действительно, действительно хороша. Часто вы будете набирать 10-20 строк кода, просто нажимая Tab, не прилагая усилий. И он предлагает предложения на основе ваших последних изменений, вашего линтинга и принятых правок, которые вы вносите. Так что это действительно, действительно здорово. Если вы ненавидите ИИ, просто скачайте это, позвольте ему показать вам, что он собирается сгенерировать, и попробуйте оттуда. Второй — это агент Cursor. Я уверен, что многие из вас видели это и использовали это. Что действительно здорово в этом, так это то, что вы можете выбрать, какую модель вы хотите использовать с агентом Cursor. Так что вы можете попробовать Gemini, ChatGPT и т. д. И что мне действительно нравится в этом агенте, так это весь инструментарий, который он поставляется. Он может читать разные файлы. Он может искать в Интернете. Он может применять вещи к вашему терминалу и иметь MCP. Так что все эти инструменты — вот что делает его агента таким великим. И новая недавняя функция, которую они запустили, которая также действительно потрясающая, — это режим мультиагента, где теперь вы можете ввести один запрос, и он сгенерирует три, четыре, сколько угодно различных вариантов одного и того же ответа на запрос. И на самом деле я сделал это для нескольких самых популярных моделей, чтобы увидеть, что они сгенерируют. Итак, во-первых, у меня есть Composer. Некоторые из вас, возможно, не слышали о Composer раньше, Composer — это LLM, который Cursor создал сам. Хотя он, возможно, не так хорош по качеству кода, как некоторые другие модели высшего уровня, он действительно специализируется на скорости. И многие изменения, которые вы вносите в Cursor, — это простые изменения, для которых вам не нужен такой умный ИИ. И это действительно, действительно помогает. Итак, он сгенерировал этот вывод. Я попросил их всех сгенерировать целевую страницу для выпуска MacBook M5 Pro. Итак, Composer сделал это за 17 секунд. Для сравнения, Claude Sonnet занял около минуты, и вот что он сгенерировал. А затем, наконец, ChatGPT Codex занял около 2 минут, и вот что он сгенерировал. Теперь это небольшая выборка. Это один запрос. Так что это не полное исследование, а просто чтобы дать вам общее представление о том, как могут выглядеть эти запросы и сколько времени это займет. И если вы поставите их все рядом, вот как это выглядит. Вы можете выбрать то, что вам больше всего нравится. Мне лично, возможно, больше всего нравится Composer из всех. А затем просто для развлечения, поскольку вчера вышел Gemini 3, я протестировал и его, и вот что он сгенерировал за 34 секунды, что, возможно, является лучшим дизайном, но нам придется провести больше тестов, чтобы увидеть, насколько он хорош на самом деле.
Хорошо, совет № 4 — Shift Tab. По умолчанию ваш агент находится в режиме агента, но если вы нажмете Shift Tab, вы можете переключить его в режим запроса или планирования. И это тоже очень, очень полезно. Если вы пытаетесь просто понять свою кодовую базу и не вносить в нее никаких изменений, или, возможно, просто использовать ИИ как партнера по размышлениям, вы включаете режим запроса, начинаете общаться с ним. Вы можете даже использовать режим многоагентного чата. Так что у вас разные опыты, например, Gemini дает вам совет. ChatGPT дает вам совет. Вы видите, что говорят разные. А затем вы можете перейти в режим планирования, где, как только вы знаете, что хотите сделать, вы вводите это, и Cursor сгенерирует план для вас. И это будет файл README со всеми шагами, которые он предпримет. И он будет выполнять каждый шаг, тестировать его и продолжать двигаться вперед. Но прежде чем приступить к этому, он даст вам возможность просмотреть его план. И это действительно хорошо для этих очень сложных задач, которые вы выполняете. И еще одна вещь, которая мне действительно нравится во всем этом, — это когда вы интегрируете это с мультиагентом. Мне нравится, когда выходит новая модель, отслеживать эту модель с предыдущей, которую я использовал. Например, сейчас мне очень нравится Composer в сочетании с Claude. Но вышел Gemini, и я задаюсь вопросом, лучше ли он? Итак, я буду делать так, что все мои запросы будут генерироваться дважды. Один раз с моим обычным LLM, а один раз с Gemini, и я буду пробовать это в течение недели, посмотрю, что мне больше нравится, и переключусь оттуда. Так что я думаю, это действительно хороший способ тестировать каждый раз, когда выходят новые LLM, какой вам больше нравится. Круто. И для режима планирования вы можете увидеть, что он собирается сгенерировать. Он сгенерирует контрольный список, и вы увидите в реальном времени, как он проходит по нему, отмечая все, что было завершено. И снова, действительно хорошо для сложных функций. Совет № 5 — включите звук Cursor. Этот может быть недооценен. Многие люди не знают об этом, но самая большая проблема при производстве кода с помощью этих LLM — это время ожидания. Вы вводите запрос, вам приходится ждать 2 минуты, а потом вы забываете о нем. Вы возвращаетесь. На самом деле, это настолько большая проблема, что YC недавно профинансировал компанию под названием Chad Labs, у которой есть IDE с "мозговым гниением", и она позволяет вам играть в видеоигры и смотреть TikTok, пока вы ждете генерации кода. Эта компания собрала кучу денег на это. Так что вы можете сказать, что это действительно проблема. Но я бы не рекомендовал это как мою основную IDE. Просто включите звук Cursor вместо этого. Совет № 6 — пользовательские команды. Итак, еще одна замечательная вещь в Cursor — это повторяющиеся команды, которые вы часто используете, вы можете создавать пользовательские файлы README. Например, если вы хотите создать PR и у вас есть определенный формат, в котором вы всегда создаете свои PR, вы можете создать README, который это указывает. И тогда вместо того, чтобы каждый раз говорить Cursor одно и то же о том, как должен выглядеть ваш формат PR, вы просто вводите слеш, вводите команду, и Cursor имеет контекст об этом. Подобно командам, есть правила. Правила немного отличаются. Они не являются файлами markdown в Cursor. Они являются файлами MDC, которые немного отличаются. Что это позволяет вам сделать, так это дать описание каждого правила, а также дать ему тип правила. Так что вы можете выбрать, хотите ли вы, чтобы ваш тип правила применялся всегда. Если вы нажмете на это, каждое ваше действие будет применяться это правило. Так что это будет хорошо для таких вещей, как если вы просите свой код не генерировать комментарии. Вам не нравятся комментарии, генерируемые вашим LLM, вы введете это. Так что всегда он знает: "Эй, не генерируй мне никаких комментариев". Затем у нас есть интеллектуальное применение, когда сам агент решает, когда его следует применять. Так что на основе описания, которое вы даете правилу, агент прочитает его и скажет: "Эй, для этой задачи это хорошее правило или нет?". Иногда это работает, иногда не очень хорошо. Другое — применение к конкретным файлам. Так что вы можете поместить его в определенную папку. Когда определенные файлы затрагиваются, тогда это правило активируется. И, наконец, вы можете применить его вручную. И это, по сути, становится командами. Это почти то же самое. Если вы применяете правила вручную или создаете команды, вам придется ввести @ вместо слеша и сказать ему: "Эй, вот контекст, который я хочу, чтобы ты добавил к этому запросу". И еще одна вещь, которая действительно потрясающая в правилах, — это то, что у них есть правила на уровне проекта, правила на уровне пользователя и правила на уровне команды. Так что я настоятельно рекомендую поделиться ими со своими командами. Те, которые очень специфичны для вас, вы оставляете локально, но есть и другие, например, создание PR в том же формате. Отлично подходит для обмена с вашей командой, чтобы вы не создавали одни и те же правила снова и снова. И что также действительно здорово, так это формат agents.md, который, по сути, является README для агентов, который стал соглашением для многих из этих инструментов кодирования. Инструменты, такие как Codeex, Cursor, Gemini CLI, Copilot, многие из них принимают этот agents.md. И что это позволяет, так это то, что созданные вами правила будут работать со всеми этими различными агентами. Вместо того, чтобы у каждого из них был разный формат, вам придется копировать одно и то же правило в разные форматы и тому подобное. Печально, что Cloud Code еще не поддерживает это, но надеюсь, когда-нибудь скоро. Если кто-то из аудитории из Cloud, пожалуйста. А затем совет № 7 — это просто правила Cursor. Хорошие правила. Это похоже на инженерию запросов, но главное — это контекст, который вы ему даете, и просто инструктируете его, как вы хотели бы свою обычную документацию, давая ему все детали. Просто держите его коротким, менее 500 строк. Если что-то больше этого, разделите. Вы можете вкладывать правила. У вас есть одно, у вас может быть одно правило, которое ссылается на другое правило внутри него. Так что сделайте это. Дайте ему конкретные примеры и избегайте чего-либо расплывчатого. Некоторые примеры правил Cursor. Одно может быть вроде refresh.md, где у вас есть спецификация, что если ошибка сохраняется, вы даете ИИ спецификацию для поиска по всей кодовой базе и пытаетесь глубже изучить каждую область. И иногда это действительно помогает, когда вы застряли на ошибке. Вы можете сделать no_comments.md, где вы можете сказать: "Эй, не добавляй никаких лишних комментариев. Я не люблю комментарии". Или вы можете сделать PRD.md, где вы просто хотите сгенерировать PRD. У вас есть формат, в котором PRD генерируются в вашей компании. Вы помещаете это туда, и часто время, которое Cursor экономит, на самом деле приходится на вещи, которые даже не связаны с кодированием, как это.
Совет № 8, MCP. Я уверен, что вы все слышали о MCP. Они велики. Вы можете получить гораздо, гораздо больше функциональности, когда потратите время на их настройку. И я думаю, что именно здесь вы получаете много этого, как экспертный уровень, когда настраиваете эти MCP. Я настоятельно, настоятельно рекомендую потратить время на попытку настроить это. Единственное предостережение заключается в том, что есть максимум, у вас может быть 80 инструментов максимум в Cursor, даже тогда я бы не рекомендовал иметь 80 инструментов. Вы действительно начинаете видеть, как модели ухудшаются, когда вы даете им слишком много контекста, и им трудно понять, какой инструмент они хотят использовать. Так что не добавляйте слишком много, или если вы добавляете много, убедитесь, что вы их отключаете, когда они вам не нужны. Лучшие MCP, которые я бы рекомендовал, № 1 — это база данных документов. Я думаю, это самая большая вещь на данный момент. Это очень помогает. Есть так много пробелов в коде, который написан в документации, что ИИ не поймет, и только вы знаете, но как только вы подключите Confluence, Google Docs, что бы у вас ни было, где хранится ваша документация, это действительно, действительно большой прорыв. Второй — система контроля версий. Это, по сути, просто GitHub, что, очевидно, здорово иметь. Третий — любой инструмент управления проектами, который вы используете: Linear, Asana, Jira. Это помогает вам автоматически получать задачи, решать их или создавать задачи, экономит много времени. Еще один полезный инструмент — это любой тип базы данных MCP, и предпочтительно установить его в режиме только для чтения, чтобы вы случайно не стерли свою базу данных. Но такие вещи, как Snowflake, Superbase, если вам нужно что-то запросить, понять что-то из вашей базы данных очень быстро, это также очень полезно. И любые инструменты наблюдения, которые у вас есть, DataDog, Prometheus, что бы у вас ни было, когда вы пытаетесь отладить, доступ к этим журналам также очень помогает LLM. И еще одна вещь — управлять вашим контекстным окном. Я думаю, что часто, когда я вижу, как люди говорят, что этот ИИ работает плохо для меня, это потому, что они открывают один чат агента Cursor, начинают вводить в него, вводят немного, на следующий день они возвращаются и вводят то же самое в него, теперь у этого агента так много контекста, и он просто начинает ухудшаться. Так что всякий раз, когда вы переключаете задачи, убедитесь, что вы открываете нового агента, чтобы у него был полностью свежий контекст, потому что это действительно оказывает большое влияние. И да, я бы сказал, что инженерия запросов важна, но гораздо важнее, чем это, — это инженерия контекста, то есть какой контекст вы даете своему LLM, имеет гораздо большее значение, чем конкретный способ форматирования того, что вы говорите своему LLM.
Совет № 10, контрольные точки Cursor. Это довольно простой совет. У нас уже есть Git Control, но иногда у вас есть чат, который работает очень хорошо, затем вы даете ему неправильный запрос, и он полностью уходит в неправильном направлении. Просто полезно знать, что вы можете восстановить предыдущую точку в чате и продолжить оттуда. И я знаю, что сказал "топ-10 советов". Это просто потому, что "топ-10 советов" звучало лучше, чем "топ-14 советов", но на самом деле у меня 14 советов. Так что я дам вам еще четыре. Итак, еще одна вещь, которая мне нравится в Cursor, — это то, что он немедленно индексирует вашу кодовую базу. Когда вы скачиваете свою кодовую базу, по крайней мере 80% ее индексируется. А затем, когда вы добавляете новые файлы, он будет корректироваться. Когда вы удаляете файлы, он будет корректироваться. Иногда для действительно больших или сложных файлов он оставляет их в стороне ради производительности. Совет № 12, интеграция Cursor Slack потрясающая, или любая интеграция ИИ Slack потрясающая для этих действительно мелких вещей, где, возможно, вы делаете PR, кто-то комментирует его: "Эй, ты забыл изменить этот стиль форматирования" или они говорят: "Эй, можем ли мы обновить эту конфигурационную переменную?". Это делает его намного проще. Вы просто отмечаете Cursor, и вам не нужно заходить в свою кодовую базу, чтобы сделать это для таких простых изменений. Совет № 13 — браузер Cursor. Они тоже недавно запустили его, где вы можете фактически видеть свое приложение вживую рядом с вашим агентом, что отлично, потому что теперь у него есть доступ к логам консоли и сетевому трафику, и он может фактически тестировать ваши приложения за вас. А затем совет № 14, используйте с осторожностью. Есть режим YOLO, где автопринятие, и вы можете сказать ИИ: "Эй, принимай любые изменения, которые я делаю". Вероятно, вы захотите избегать этого, но некоторые случаи, где я видел, что это полезно, — это когда вы хотите писать тесты. Вы можете сказать ему: "Эй, напиши тесты", затем код, затем запусти тесты, посмотри, работает ли он, а затем итерируй, и вы можете получить кучу тестов, сгенерированных ИИ, просто циклически возвращаясь и тестируя ваше приложение. Хорошо, теперь, если мы прошли Cursor, и Cursor так хорош, зачем нам вообще нужен Cloud Code? Итак, я хочу поделиться реальным примером, который у меня был с Cloud против Cursor, и где эти два инструмента сияют в разных областях. Я не могу вдаваться в подробности того, что я делал, но я искал возможность реализовать функцию, и я дал один и тот же базовый запрос Cloud Code и Cursor. Что сделал Cursor, так это он просто выбрал одно решение, рассказал мне о нем, а затем выполнил его с этим неоптимальным дизайном. А затем я попробовал Cursor, с другой стороны, он искал в Интернете репозитории с открытым исходным кодом. Он представил мне три разных варианта с плюсами и минусами, действительно, действительно высококачественный анализ, и это сэкономило мне кучу времени. И я думаю, что именно здесь Cloud Code действительно сияет. По сравнению с Cursor, для небольших изменений Cloud Code на самом деле немного отстойный. Он будет чрезмерно инженерить вещи, исследовать их слишком глубоко. Но когда дело доходит до сложных функций и исследований, Cloud Code намного лучше. Он сжигает гораздо больше токенов, но я действительно думаю, что это того стоит. Так что, если у вас есть какая-то большая задача, трудный дизайн, который вы пытаетесь реализовать, я думаю, Cloud Code должен быть вашим другом, с которым вы общаетесь. А затем Cursor, с другой стороны, действительно хорош для получения быстрых результатов с использованием их модели Composer. Если вы хотите попробовать разные LLM, чтобы увидеть, если одна не работает, если другая может иметь ответ для вас. Cursor снова сияет здесь. И у вас есть все визуальные бонусы, которые идут вместе с ним. Хорошо. А затем раздел о Cloud Code. Большая часть этого похожа на то, что мы обсуждали для Cursor. Так что я буду держать этот раздел коротким. Я просто собираюсь Ой. Извините. Я просто собираюсь пройтись по четырем основным элементам, которые вам, вероятно, нужно знать для Cloud: навыки, под-агенты, команды и плагины. Навыки, похожие на правила, у нас были MDC для правил в Cursor, верно? И мы могли проверить, применяются ли они автоматически или нет. Так что навыки — это, по сути, те автоматически вызываемые правила, которые у нас есть в Cursor, где, если Cloud должен заметить что-то, когда возникает X, когда мы обсуждаем Y, тогда вы бы использовали навык. Под-агенты — это явные рабочие процессы. Так что, если вы хотите, чтобы какие-то конкретные задачи выполнялись, тогда вы будете использовать под-агента. И что действительно круто в под-агентах, в которые мы углубимся позже, — это то, что вы можете дать им конкретный доступ к различным MCP. И затем у нас есть команды, о которых мы только что говорили. То же самое в Cloud Code. И, наконец, плагины. Это их способ распространения пакетов. Так что вы можете объединить свои навыки, агентов, любые команды, которые у вас есть, а затем сделать это плагином, и другие люди из вашей команды или за ее пределами могут скачать его и использовать. Итак, начиная с навыков, опять же, похоже на правила, но навык, который у меня есть здесь, — это преобразование блога в нужный мне шаблон. У меня было бы правило здесь: если я генерирую блог, как он должен выглядеть, чтобы соответствовать формату моей компании? И он бы сделал это преобразование для меня. Второе — команды. Мы уже обсуждали это тоже, но команда может быть командой PR, где я говорю ему: "Эй, просто создай мне PR", чтобы мне не пришлось вводить три-четыре команды, которые требуются для его создания. А затем три, и это самая интересная часть, это под-агенты, которые, я думаю, являются одним из больших преимуществ Cloud. Итак, у нас есть наш основной агент Cloud в нашем терминальном чате, но затем у нас есть под-агенты, которые он может вызывать. Например, если у вас есть страница, у вас может быть под-агент PagerDuty, который имеет интеграции MCP со Slack и DataDog, и проверяет, какая страница была вызвана, идет и исследует журналы и пытается найти корневую проблему для вас. Или у вас может быть под-агент документации, где всякий раз, когда вы делаете какой-то PR, вы можете сказать ему: "Эй, обнови наши документы в соответствии с этими изменениями". Или вы можете иметь под-агента Карен, где вы можете попросить его пройти через Slack и Jira и посмотреть, закончил ли каждый свою задачу, а затем устранить или уведомить пользователей. Да. Так что под-агенты вы хотите использовать, когда у него есть очень специфическая цель, и вы хотите, чтобы у него был конкретный доступ к определенным MCP. И что действительно здорово в этих, так это то, что у них есть свое собственное контекстное окно. Так что это не загрязняет контекст вашего основного агента. У них есть свои собственные контекстные окна. И да, а затем, наконец, плагины. Просто краткий обзор плагинов. Опять же, вы можете объединить своих агентов, навыки и команды. И просто своего рода визуальное представление того, что вы можете иметь, и другие люди могут прийти и скачать его.
Хорошо, теперь мы прошли Cursor, мы прошли Cloud. Являются ли это двумя лучшими инструментами? Для меня лично, да. Но это определенно очень конкурентно. Это меняется почти каждую неделю, и в конечном итоге все зависит от личных предпочтений. Я думаю, что два других, которые я бы назвал очень близкими к ним, — это Klein и Codeex. Klein немного дешевле, чем Cursor, но я предпочитаю Cursor из-за модели Composer, которую он имеет сам, и индексации, которую он выполняет в своей кодовой базе, чего Klein не делает. Но я слышал, как многие люди говорят, что я получаю гораздо лучшие результаты, когда использую Klein, чем Cursor. Так что попробуйте оба самостоятельно. Посмотрите, что вам больше нравится. То же самое с Cloud Code против Codeex. Я слышал, как многие люди говорят, что я получаю лучшие результаты на Codeex, чем на Cloud Code. Лично я думаю, что Cloud Code немного лучше знает, когда он ошибается, и не уверенно говорит какой-то ответ, и я чувствую, что он немного глубже погружается в образовательный аспект, он лучше объяснит вам, что он делает, чем Codeex, но опять же, у меня нет статистики по этому поводу, это личный опыт, вам придется попробовать это самостоятельно и посмотреть, что вам больше нравится. А затем, наконец, Anti-Gravity от Gemini, который вышел вчера. Я бы очень рекомендовал и его. Этот действительно крутой, потому что это первый раз, когда мы видим, как фундаментальная модель создает IDE. Теперь у вас есть доступ к Gemini на фундаментальной модели с Google Anti-Gravity, но они также позволяют вам использовать ChatGPT, Claude и другие инструменты. Так что я думаю, что это может быть один из лучших из-за этой причины. Это своего рода первый в своем роде в этом плане. Теперь несколько бонусных категорий. Во-первых, я думаю, даже за пределами кодирования. Я работаю в индустрии примерно год, и это, я думаю, помогло мне больше, чем что-либо. Имея ИИ не только для документов, но и для объяснимости, так много раз просто не хватает документации в компании, и я просто использую Cloud Code, чтобы пройти через нее и общаться со мной, и объяснять мне кодовую базу, и это действительно, действительно помогает мне в областях, где иначе мне пришлось бы просить помощи у других. И один инструмент, который действительно потрясающий, — это Deep Wiki. Это ИИ-документы для любого репозитория. У них уже проиндексировано более 20 000 репозиториев в Интернете. На этой неделе я работал над проектом, у которого не было документации для его открытого исходного кода. Не ноль, у них была одна страница, но она была довольно ужасной, но этот Deep Wiki действительно, действительно помог мне в создании моего проекта с этими сгенерированными ИИ документами, и у него есть чат-бот рядом с ним, где вы можете задавать вопросы документации. Так что настоятельно рекомендую. Второе — ИИ-ревьюер кода. Честно говоря, я не углублялся ни в один из них. Я слышал, что Code Rabbit — лучший, но в целом, наличие ИИ-ревьюера кода экономит много времени, и он может помочь вам поймать некоторые мелкие синтаксические ошибки, ошибки стиля, или если у вас есть определенные форматы для определенных PR и определенные проверки, которые вам нужно сделать, это отлично подходит для этого. Еще одна вещь — инструменты с низким уровнем кода. Я думаю, что часть нашей ответственности как разработчиков — помогать нашим нетехническим друзьям на работе, верно? Так что представлять им, возможно, Cursor, но скорее инструменты вроде Lovable и Naden, потому что это действительно суперсила для них, и если вы можете просто представить им это и дать им маленький совет, они будут любить вас вечно из-за того, что они смогут создать благодаря этому. Так что я настоятельно рекомендую. Быстрый обзор того, что такое Naden. Naden — это, по сути, рабочий процесс, вы можете создавать ИИ-автоматизации и рабочие процессы на Naden. Что действительно круто в этом, так это то, что он очень низкоуровневый. У них есть интеграции практически с любым приложением, которое вы можете себе представить. Так что вы можете подключить его к своей электронной почте, и вы просто нажимаете на этот узел, и это выпадающий список, где вы выбираете разные переменные. Код действительно не нужен. Но если вы хотите создать что-то более сложное, у них есть модули кода JavaScript и Python, которые вы можете туда поместить, и вы можете фактически вводить код. Но опять же, для нетехнических бизнес-людей это помогает им довольно легко настраивать ИИ-агентов и оказывает большое влияние. А затем еще одна вещь, которую я хочу обсудить, — это оценка воздействия. Как вы узнаете, действительно ли ИИ оказывает продуктивное влияние на то, что вы делаете и что делает ваша компания? И я думаю, я видел, как многие люди пытались найти правильную метрику для этого, и я думаю, что вывод заключается в том, что ее действительно нет. Но что более важно, чем все остальное, — это просто найти разные метрики, которые вы можете отслеживать, чтобы ссылаться на них позже, когда вам понадобится. И часто у вас будет история, которую вы можете рассказать через свой качественный опыт, и эти метрики просто помогут вам подкрепить эту историю, когда придет время представить ее. Наконец, оценка затрат. Я не особо углублялся в это, частично потому, что многие из вас все равно будут тратить деньги компании, но также и потому, что я думаю, что большинство людей сейчас недоиспользуют ИИ, и имеет смысл переплачивать. Идите вперед, инвестируйте в это по максимуму. Переплачивайте первые 6 месяцев, посмотрите на результаты и выгоды, а затем оттуда корректируйте и сокращайте, если нужно. Но стоит упомянуть, что модель Kimmy особенно хороша для недорогих высококачественных результатов. Однако я должен сказать, что если вы используете модель Kimmy с Cursor, способ их вызова инструментов отличается. Так что вы не получите ее полную функциональность. Так что я бы не рекомендовал ее на другом LLM, кроме ее собственного CLI. И еще пара вещей, которые я хотел упомянуть из той исследовательской статьи Стэнфорда, о которой мы говорили ранее. Эти инструменты продуктивности будут отличаться в зависимости от того, над чем вы работаете, особенно над задачами с чистого листа с низкой сложностью, вы должны использовать ИИ почти каждый раз. Именно там достигается большинство приростов продуктивности. Но если вы работаете над задачами с уже существующим кодом и высокой сложностью, иногда вы можете захотеть отказаться от него. Это может быть не так полезно. Вы можете попробовать, но это действительно зависит от случая к случаю. А затем еще одна вещь — это также популярность языков. Python, Java, эти высокопопулярные языки работают намного лучше. Если у вас есть какие-то старые, менее популярные языки, будет трудно что-либо создать. А затем я хочу выйти за рамки написания кода. На прошлой неделе я выступал на мероприятии для группы генеральных директоров, и среди них был генеральный директор Data Bricks, Али Годзи, и он поделился историей, которая действительно запомнилась мне, и я хотел поделиться ею с вами. Он рассказал, что они создают коннекторы в Data Bricks, и обычно это занимает у них четыре месяца, извините, четыре квартала, чтобы запустить один из этих коннекторов. Но появился какой-то новый инструмент ИИ, я не знаю, какой именно, но он сказал, что появился этот новый инструмент ИИ, он пошел домой, попробовал его, и примерно за день он почти получил этот коннектор работающим, не на 100%, может быть, на 80%, но он сказал: "Хорошо, это здорово", взял инструмент, передал его своим командам, сказал: "Хорошо, ребята, давайте сократим время". Они пошли, исследовали инструменты, вернулись и сказали: "Да, это хорошо, мы можем сократить с четырех кварталов до трех кварталов", и он сказал: "Я не совсем понимаю, почему", он немного надавил на это, но они сказали: "Это просто так, потому что XYZ причина, мы не сможем этого сделать". Так что он сказал: "Хорошо, я сдался". Так что да, он не был уверен, но они сдались. А затем, извините, я продолжаю ударять по микрофону. Но затем у него был один немецкий сотрудник, о котором он говорил, который пришел и полностью переработал весь процесс. И благодаря нескольким вещам, которые он сделал, он смог сократить время на один коннектор с четырех кварталов до семи коннекторов за один квартал. Так что это 20, 21, 28-кратный рост продуктивности, что-то вроде того. Так каковы выводы и что он сказал? Главное — это то, что люди есть люди. Мы все люди в конце концов, даже лучшие из нас, инженеры, и мы сопротивляемся изменениям. Так что одна вещь, которая очень хороша, когда вы пытаетесь внести эти эволюции в ИИ, — это привнести свежий взгляд и заставить их переоценить предположения. Многие команды, мы можем не хотеть вносить изменения в наши собственные команды, потому что это вызовет у нас много работы, но когда кто-то другой приходит и делает это, им все равно, сколько работы это вам обойдется. И в итоге это приведет к большей продуктивности для вас. Номер два, он сказал, что есть скептики и сторонники. И он, и он вообще не критиковал скептиков. Он сказал, что они оба правы. Они оба приводят логичные причины, которые имеют смысл, почему вы должны или не должны что-то делать. Однако, при этом, он сказал: "Я понял, что почти каждый раз, когда речь идет о расширении границ в ИИ, найдите сторонника и поставьте его на руководящие должности". Почему я делюсь этим с вами, так это для тех немногих из вас, кто, возможно, не использует ИИ больше всего. Если генеральные директора говорят, что они поставят сторонников на руководящие должности, даже для вашей личной выгоды, вы можете захотеть рассмотреть, даже если вы не думаете, что это лучший вариант, изучить его немного, потому что это то, чего, вероятно, хочет ваше руководство. А затем три — они относятся к программному обеспечению как к реальному программному обеспечению. Он сказал, что стоимость кодирования сейчас ниже, чем когда-либо. И иногда именно другие задачи занимают много времени. И что произошло в этом случае на самом деле, они обнаружили, что около 80% времени, затрачиваемого на создание этих коннекторов, приходилось на работу PM. Это не была фактическая работа по программному обеспечению. И именно так им удалось сократить этот процесс, исключив множество пользовательских интервью, исключив написание PRD. И они просто рискнули. Они сказали: "Мы создадим это программное обеспечение. Если оно не сработает, мы просто создадим его снова, потому что стоимость создания этого намного ниже, чем раньше". Стоимость сейчас действительно заключается в генерации PRD. Так что давайте просто рискнем. Давайте попробуем, и мы будем итерировать и создавать его снова и отбрасывать, если понадобится. Так что да, это урок номер три. Сократите процесс, а не только код. И, наконец, пара советов. Он сказал, что в каждой ситуации теперь мы хотим пересмотреть все ранее сделанные предположения. Есть так много предположений, которые мы сделали о многих наших системах, которые просто больше не верны с ИИ сегодня, но мы просто не возвращаемся, чтобы пересмотреть их, где мы упускаем много приростов продуктивности. Так что это совет № 1. А затем совет № 2: каждая компания умирает от желания нанять того немецкого парня. Так что, если вы хотите получить повышение или продвинуться по карьерной лестнице, постарайтесь быть этим немецким парнем. Каждый бизнесмен его ищет. И, наконец, я хочу поговорить о том, что ИИ абсолютно несовершенен. У него могут быть и большие недостатки. Конечно, я не пытаюсь создать впечатление, что это все, что вы можете иметь, изменения, субоптимальный дизайн. Он очень уверенно галлюцинирует. Часто ваши собственные навыки могут начать ослабевать по мере того, как вы все больше и больше используете ИИ, что является еще одним негативным недостатком. Существуют угрозы безопасности, и иногда у вас также есть риски зависимости, когда многие люди пишут код, о котором они понятия не имеют, как он работает, а теперь, когда вам нужно его исправить, у вас возникают проблемы. Так что да, определенно есть компромиссы, как и во всем в жизни или в программном обеспечении. Но в целом выгода будет стоить компромисса. И выводы, о которых я хочу поговорить: во-первых, не просто смотрите на использование ИИ для ускорения вашего кодирования. Действительно посмотрите на те задачи, которые выходят за рамки простого кодирования, чтобы увидеть, что вы можете ускорить. Два, надеюсь, все вы, кто выйдет из этой сессии, попробуете IDE с поддержкой ИИ и инструмент CLI с поддержкой ИИ. И вы можете быть шокированы. Я думаю, что большая часть опасений против этих инструментов ИИ также исходит от того, что кто-то попробовал их год назад, они еще не были готовы, вы никогда не возвращались, чтобы попробовать их. Но теперь за 12 месяцев они добились огромного прогресса, что вы можете быть действительно шокированы, особенно с чем-то вроде Cloud Code. А затем четыре, добавьте несколько правил, добавьте несколько навыков, попробуйте их, найдите повторяющиеся задачи, посмотрите, как это работает для вашего рабочего процесса. И затем пять, продолжайте пересматривать любые ранее сделанные вами предположения в ваших рабочих процессах. И это все от меня. Теперь я готов ответить на ваши вопросы. Спасибо. Боже мой, у нас уже так много вопросов. Я хочу начать с благодарности вам за эту презентацию. Я запишу ее, загружу на наш образовательный сервис Netflix. Всем нашим разработчикам нужно это увидеть. Также напоминание, пожалуйста, заполните опрос в вашем приложении и дайте Сапфиру знать, если у вас есть какие-либо отзывы для него. Итак, первые вопросы. Когда вы говорили о Claude против Cursor, вы сравнили их по одному и тому же запросу, но была ли под ними одна и та же модель LLM или разные фундаментальные модели? Правильно. Под ними одна и та же модель LLM. Есть дополнительная тонкая настройка, которую они делают в Cloud Code, которая позволяет ему идти гораздо глубже, чем обычно, просто с Claude на Cursor, и вы увидите это по количеству токенов, которые он использует. Хороший вопрос. Итак, мой вопрос: поскольку вы работаете в Coinbase, я думаю, что это регулируемая отрасль, верно? Так в какой части вашей бизнес-функции вы используете Cloud Code или любой из этих инструментов для написания кода, верно? К сожалению, я не могу говорить о конкретных вещах Coinbase на этом мероприятии, но в целом, такие вещи, как написание PRD, любая документация, исследования, планирование, все эти вещи я обычно начинаю с Cloud Code. или Cursor. Я не знаю, точно ли я ответил на ваш вопрос. Я просто спрашивал с точки зрения кодирования. Так что это все, как из документации и тому подобного, верно? О да. О да. О, я могу поделиться этим. В Coinbase мы используем Cursor и Cloud Code. Хорошо. Да. Привет. Вы упомянули, что говорили об ИИ-нативных IDE, таких как Cursor и тому подобное. Насколько зрелы эти IDE в плане устаревших функций? Например, я много использую JetBrains Rider, и у них есть много функций рефакторинга, много приятных вещей для анализа вашего кода, и предоставляют ли эти IDE это тоже? Достаточно ли они зрелы, или мы просто полагаемся на возможности ИИ, чтобы делать все? Например, если я хочу рефакторить имя класса, например, есть ли у него детерминированная функция, которая идет и рефакторит все, или вы просто попросите агентов сделать это, что кажется пустой тратой энергии, я полагаю, просить ИИ-агентов переименовать, что довольно стандартно в индустрии. Да, имеет смысл. Честно говоря, я не видел инструментов рефакторинга в Cursor. Я не уверен, существуют ли они или нет, но IntelliJ также имеет свою собственную модель ИИ, которую вы можете использовать. И я думаю, что с рефакторингом ИИ действительно силен в этом, по крайней мере, в тех случаях, когда я его использовал. Но, как вы сказали, возможно, это пустая трата токенов, которые вы вкладываете в это для выполнения этих задач. Так что я не уверен. Мне придется проверить рефакторинг Cursor. Хорошо. Спасибо. Конечно. Я просто хочу добавить, что если вы используете IDE, такую как Rider, вы можете использовать Cloud Code внутри вашего терминала внутри Rider, что также делают наши разработчики Netflix. Отлично. Есть ли другие вопросы? Если это все, у меня также есть несколько QR-кодов здесь, если вы хотите связаться со мной в LinkedIn, но у меня также есть несколько маркетплейсов для плагинов Cloud и правил Cursor, которые вы можете посмотреть, если вы просто хотите увидеть, что используют другие люди, и что у них работает. Отлично. Спасибо всем. Спасибо.