Transcription
Хорошо, хорошо. Я, Том? Должен ли я сказать, что мы вернулись? Мы вернулись, мы вернулись. Хорошо, народ, как я говорил, директор, автор бестселлеров Google Cloud AI, да. Спикер по опыту разработчиков ИИ. Пользовательский опыт. Ади Асмани. Вы очень добры. Спасибо, что пришли. Привет, народ. Приятно быть здесь. Я рассказывал вам, что смотрел репортаж Bloomberg об ИИ, и вы там были, и я сказал своей жене: "Я знаю этого парня", а она: "Нет, не знаешь". Я: "Знаю", а она мне не поверила.
Она вам не поверила? Нет. Наверное, так и лучше, да. Но Ади, Ади, я знаю тебя давно. Ты пишешь, снимаешь видео и выступаешь с тех самых дней jQuery. О боже, занимаясь. Веб, да. Многое связано с производительностью веба, а теперь много агентов и навыков ИИ. Да, да. Много агентов. И сегодня мы говорили о том, что вы вышли и рассказали, что у вас есть репозиторий навыков, который несколько раз попадал на главную страницу Hacker News. Я стараюсь не слишком часто заглядывать в Hacker News в наши дни. Никогда не знаешь, будет ли это хорошо или плохо. Ну, расскажите нам об этом. Хорошо, сегодня я хотел поговорить с вами об агентских навыках. И знаете, многие здесь, вероятно, знают, что это такое, но очень быстро, я, я Адди, я работаю над кучей агентских вещей в Google. Так что, например, комплект для разработки агентов, платформа агентов, и мы работаем над рядом проектов, связанных с навыками в Google. Так что мы думаем о навыках уже некоторое время. Если вы не совсем уверены, что такое навыки, это, по сути, стандартизированный способ дать ИИ-агентам новые возможности и экспертизу. И они были очень горячей темой в последние пару месяцев, особенно когда вы помните те времена, когда люди делились своими секретными конфигурациями оболочки, и там было много файлов, и они говорили: "Эй, это мои фокусы". Да, мои файлы dot. Это мои файлы dot, которые очень хорошо работают для меня, мои. Волшебные трюки. Это мои, это моя сумка трюков. И вы бы сказали: "Я хочу эту сумку трюков". Но потом вы думаете: "Ну, моя сумка трюков может отличаться от твоей". И поэтому я думаю о навыках очень похожим образом. Знаете, иногда вы хотите вдохновиться чужими. Иногда нормально просто взять, знаете, скопировать их сумку трюков. И поэтому я думаю, что здесь будет кое-что, что люди смогут просто скопировать и взять себе. А иногда будут вещи, которые будут вдохновлять. Теперь, на случай, если навыки — это не то, на что вы потратили много времени, я подумал, что было бы интересно просто дать людям очень быстрое введение. И поэтому я, я закодировал этот очень быстрый, очень глупый настольный компьютер Windows в браузере. И я подумал, что я вставлю туда Клиппи, потому что я не видел Клиппи. Я не видел Клиппи так много на сборке. Нам не разрешено упоминать Клиппи. Это очень. Это очень хорошо. Да, это очень хорошо. На самом деле есть костюм Клиппи. Есть, который можно носить, но если вы его носите, вам не разрешается говорить. Реальная история. Правда. Ага, таковы правила. Вы не упомянули его. Я упомянул. Так что, так что мы в порядке. Мы совершенно. В порядке, нас арестовали. Хорошо, я вас подставил. Это странно, потому что у нас здесь внизу док macOS, а над ним окна. Мне нравится. Это. Привносит лучшее из всего, это просто это просто ужасно. Это как худшее из всего, худшее из всех миров. Хорошо, так что если вы не совсем уверены, что такое навыки, по сути, есть стандартизированный способ упаковки экспертизы и контекста, который, знаете ли, ваш агент может не иметь. Он может упаковывать рабочие процессы. Ваши инструкции для вашего агента, и знаете ли, структура их такова. У вас есть имя, у вас есть описание. Здесь может быть гораздо больше контента, но, по сути, имя и описание — это основные части, которые будут у каждого файла навыка. И они повторяемы. Обычно у вас не будет навыка для чего-то одноразового, потому что одноразовая вещь будет больше похожа на подсказку. Но навык — это то, что вы или ваша команда можете использовать на повторной основе, и это может быть полезно для нескольких разных проектов. Теперь навыки загружаются по требованию. Так что, знаете ли, у вас есть задача, которая поступает к вашему агенту, он сопоставляет ее с навыком, загружает его шаги, а затем пытается следовать им. Ему не обязательно знать больше, чем имя и описание. Итак, агентские навыки, как вы упомянули, это проект, который я создал некоторое время назад, и для предыстории, я немного замедлился с открытым исходным кодом на несколько лет. Вы и я давно занимаемся открытым исходным кодом, очень давно, очень давно. Как вы знаете, вы создаете проект с открытым исходным кодом, это похоже на рождение ребенка. Вам приходится его поддерживать. И поэтому вы должны быть явными, когда хотите выпустить проект с открытым исходным кодом в мир, и это занимает время. Так что я подумал: "Хорошо, я выпущу одну из этих вещей". Я видел, что Гэри Тан выпустил G stack. Верно, верно. И я подумал: "Ну, если Гэри Тан занимается G stack, и люди учатся на нем, ничто не мешает мне выпустить свою точку зрения на агентские навыки в мир". И поэтому я начал этот проект, и он получил некоторое развитие, и я подумал: "Было бы интересно, возможно, провести людей через него". Моя точка зрения на агентские навыки, я бы сказал, немного отличается от других. Я основываю свои агентские навыки на жизненном цикле разработки программного обеспечения. Я думаю, что они, я, я очень сильно опираюсь на агентную инженерию, ИИ-ассистированную инженерию, эту сторону вещей, где вы стараетесь быть очень дисциплинированным в отношении того, знаете ли, я буду явно указывать, что я хочу построить. Я буду проверять, что построено. Я буду иметь в виду качество. И поэтому для моих агентских навыков у меня есть много шагов, которые соответствуют SDLC. Так что определяйте, планируйте, стройте, проверяйте, просматривайте и выпускайте. И для каждой из этих различных фаз SDLC есть ряд различных навыков, которые находятся в этом проекте, которые соответствуют здесь. Так что для определения у нас есть навыки, которые могут опрашивать вас, чтобы получить ясность вокруг идеи, если у вас есть очень расплывчатая идея. Так что, возможно, у вас была идея в душе, и вы думаете: "Ну, я вроде знаю, какой будет результат, но я на самом деле не знаю, как будет выглядеть пользовательский интерфейс, или я не знаю, какие будут детали". У вас есть навык, который может помочь уточнить ее до чего-то более конкретного. Вы можете заниматься разработкой на основе спецификаций. У нас есть навыки планирования для преобразования вещей в задачи. У нас есть навыки построения, которые могут помочь вам уточнить это до места, где у вас будет очень хороший фронтенд UI, ваш API и дизайн интерфейса будут в хорошем состоянии, и эти навыки для ряда других фаз для проверки. Это очень важно. Знаете, я думаю, что вы и я много работали в браузере со временем, верно? Я до сих пор строю, я, я раньше работал над Chrome. Я до сих пор строю много, знаете ли, проектов, которые будут отображаться в браузере. И поэтому автоматическое тестирование в браузере с помощью агента в наши дни — это то, что меня волнует. Так что у меня есть навык, который будет это делать. Автоматическая отладка также является частью этого рабочего процесса. У меня есть цикл обзора кода, который включает в себя такие вещи, как упрощение кода, безопасность, а затем у меня есть навыки выпуска, которые помогут вам со всем, от вашего CI до вашего рабочего процесса Git, вашей документации, выпуска и запуска. Теперь, здесь много фаз. Я на самом деле покажу вам, как они работают, но есть, по сути, шаблон, который я использую для всех моих навыков. Есть обзор, который я захватываю, например, когда эти вещи должны использоваться. У меня есть обоснования, например, почему это должно использоваться и почему это не должно использоваться. Так что у агента есть небольшой механизм защиты, который он может, который он может учитывать, а затем и красные флаги, чтобы агент знал, если вещи действительно выходят из-под контроля, а затем и проверка. Так как мы узнаем, что мы действительно сделали шаги правильно и хорошо? Теперь все это просто сопоставляется с командами. Так что вы можете явно использовать команду слэш в Copilot в любом из ваших агентских инструментов кодирования и запускать любую из этих фаз. Теперь вам не обязательно использовать, конечно, мои агентские навыки, как я уже говорил, они очень похожи на вашу сумку волшебных трюков или файлы dot. Если есть что-то, что вам полезно, скопируйте это, украдите это, знаете ли, помогите, знаете ли, сделайте вас продуктивным. Если вы обнаружите, что мой способ делать вещи полезен, знаете ли, вы можете зайти и использовать его целиком. Но я хочу показать вам немного этого в действии. Так что у меня есть готовый проект, где я установил навыки. У нас есть некоторые файлы агентов, у нас есть подсказки, которые просто сопоставляют все эти навыки. Вот что происходит, когда вы просто устанавливаете его в проект. А затем у нас есть некоторые из самих навыков, и я здесь, в боковой панели Copilot. Я выбрал Gemini 3.5 Flash. Я работаю в Google, я работаю над Gemini, поэтому я буду использовать Gemini 3.5 Flash здесь. Это отличная модель для агентского кодирования и для агентских задач. Я считаю, что, знаете ли, VS Code также имеет представление об агентах в наши дни, верно? Так что все эти команды, знаете ли, вы можете просто набрать слэш, вы увидите, что здесь появляются дополнительные команды для использования агентских навыков, и вы можете использовать любую из них. Так что, например, такие вещи, как уточнение, такие вещи, как упрощение кода и так далее. Но чтобы мы могли видеть, что на самом деле строится, я буду придерживаться этого представления. И мы можем начать, возможно, даже с быстрого взгляда на наши навыки. И я просто покажу вам разработку на основе тестов. Я говорил о том, что, возможно, дам вам некоторое представление о том, что содержат эти файлы. Теперь вы увидите много контента здесь. Я стараюсь быть очень добросовестным в отношении того, что попадает в контекстные окна. Так что, опять же, если вы чувствуете, что здесь слишком много для ваших нужд, вы всегда можете сократить это. Вы всегда можете оптимизировать это дальше. Но я стараюсь быть очень явным. Так что для разработки на основе тестов я захватываю цикл TDD. У меня есть очень явное представление о том, что означает иметь падающий тест. Что означает иметь проходящий тест. Как следует думать о рефакторинге. Какие другие шаблоны, по моему личному мнению, работают очень хорошо? Многие из этих шаблонов были вдохновлены тем, как мы строим программное обеспечение в масштабе в Google. И поэтому я подумал, что было бы интересно закодировать их в эти навыки. Так что вы увидите здесь такие вещи, как пирамида тестов, руководства по принятию решений. Здесь закодировано ряд лучших практик. Ниже вы также увидите, что я захватываю такие вещи, как антипаттерны тестирования, вещи, которых следует явно избегать, как подходить к тестированию в браузере. Так что это связующее звено, которое затем может вернуть нас к таким вещам, как тестирование в браузере, отладка в браузере. Я говорю ему, что проверять. Я говорю ему, как думать о границах безопасности, когда дело доходит до тестирования. Вы можете быть настолько явными или открытыми, насколько хотите с этими вещами. Я стараюсь быть явным, просто потому что я думаю, что есть ценность в том, чтобы быть намеренным в том, как вы подходите к этим вещам. Теперь, что, по моему мнению, было бы интересно, я всю свою жизнь пытался оптимизировать свою продуктивность. Я думаю, что я, вероятно, много раз терпел неудачу. И поэтому отслеживание привычек — это то, на что я смотрю время от времени, верно? Я думаю, многие люди пытаются улучшить свои привычки и свои системы. Так что я подумал, было бы интересно попробовать построить трекер привычек. И, возможно, знаете ли, если вы посмотрите на график вклада GitHub каждого, возможно, у нас будет трекер привычек, который использует этот визуальный элемент. Например, насколько хорошо вы следуете своим привычкам с течением времени. Итак, мы начнем с того, что я просто запущу команду уточнения. И причина, по которой я это делаю, заключается в том, что у меня есть сырая идея. Так что я хочу построить трекер привычек, верно? Так что мы скажем что-то вроде трекера привычек, вдохновленного GitHub. И я на самом деле не хочу бэкенд базы данных. Может быть, давайте просто сделаем так, чтобы все работало в браузере, так что храните все в браузере? Это относительно расплывчато. Это довольно расплывчато, довольно высокоуровнево. Вы скажете "график вклада" или вы это опустите? Я просто. Я просто оставлю это вдохновленным GitHub. Я мог бы сказать "график вклада", но это явное указание. Это верно. Так что мы просто запустим уточнение сейчас. И он анализирует параметры нашей подсказки, анализирует основные компоненты запроса. Он запускает навык. Вы видите, что он читает этот навык на месте. Теперь первое, что здесь появилось, это то, что он задает мне уточняющие вопросы. Так кто является основным целевым пользователем? Отличный вопрос. Он не знает, предназначено ли это только для меня, или я строю это для команды, или я строю это для своей семьи или своих друзей, или что. Так что аудитория будет, скажем так, комнатой инженеров-программистов на Build прямо сейчас или на YouTube, потому что люди будут смотреть это позже. Просто кто угодно. Просто кто угодно, каковы ограничения и ожидания для хранения только в браузере? Отличный вопрос. Вы можете использовать index DB, local storage, session storage, множество различных вариантов. Я оставлю это очень простым. Меня устраивает local storage для этого, помимо стандартной сетки вклада, так что здесь он смог сам это понять. Какие аналогии GitHub вы хотите исследовать? Например, фиксация привычки, ветвление вариаций, pull requests? Я не хочу углубляться в эти аналогии, поэтому я думаю, давайте оставим это. Давайте оставим это простым с сеткой вклада. Интересно, что он склоняется к этому. Как будто он хочет сделать все о GitHub. И это одна из тех вещей, если вы посмотрите, как определен этот навык, он на самом деле содержит язык, вокруг которого пытается начать сходиться в направлении, идея, которую вы имеете, склоняясь к тому, что "хорошо, я вроде понимаю, что вы имеете в виду. Давайте продолжим идти по этому пути". Так что же такое успех для MVP? Потому что очень часто, если вы определяете просто высокоуровневую подсказку, она не знает, пытаетесь ли вы создать что-то для стартапа или для бокового проекта на выходных, или что. Так что я думаю, что требования к производительности хороши. Как и все это кажется хорошим. Мне не обязательно, чтобы это было офлайн-первым с сервисными работниками прямо сейчас. Так что загрузка быстрая, чистый UI, вот и все. Быстрая загрузка и чистый UI, отзывчивость. Хорошо, так что у нас есть все эти ответы. Это не заняло у нас много времени, чтобы начать получать ясность вокруг этого, верно? Мне еще не пришлось писать большой спецификацию самостоятельно. И поэтому он пытается прочитать остальную часть моего проекта прямо сейчас, пытаясь увидеть, есть ли там какой-либо другой контекст. Это свежий проект, так что ему не нужно много. И вот результат, верно? У него есть постановка проблемы. У него есть заявления о том, как мы различаем направления, думаем о стресс-тестах, и он дает нам несколько направлений, по которым мы можем пойти. Так что направление А — это конфигуратор профиля разработчика. Так что очень минималистичная высокоточная копия профиля GitHub позволяет нам отслеживать привычки так же, как и репозитории GitHub. Здесь гораздо больше деталей. Направление B — это скорее терминал привычек, управляемый клавиатурой. Я больше 2D. Так что горячий. Прямо сейчас, да, 2D так горячи. Направление C — экспортер Markdown SVG, так что бэкенд-инструмент для простого текста, ваша конфигурация привычек и данные сетки. Так что это больше данных. Это больше похоже на то, что вы действительно хотите ввести необработанные данные и управлять ими, что не совсем соответствует моему настроению. Я думаю, что первое, вероятно, ближе всего к тому, что я имел в виду. Так что я пойду с направлением А. И вы также можете видеть, что у него есть другие предположения и возражения. Так что он спрашивает меня, какое направление резонирует больше всего. Я просто скажу направление. А. Он рекомендовал что-нибудь, я не видел под прилавком? Так что мы можем прокрутить назад. Как только вы выберете AB или CI, он произведет 1. Он не рекомендовал 1. Вы можете фактически изменить файлы своих навыков, чтобы сказать: "Ну, я хочу, чтобы вы дали свою собственную точку зрения на это". В этом случае я пытаюсь, знаете ли. Потому что я замечаю, что модели любят рекомендовать, и они почти всегда, когда дают вам выбор, говорят: "Ну, вот что я делаю", да. И тогда я говорю: "Ну, если это то, что вы делаете, то это то, что я хочу делать". Ну, и иногда я спрашиваю модель: "Дай мне 3 варианта и скажи, что, по-твоему, мне следует делать", на всякий случай. Да. Но тогда я чувствую, что я не. Я всегда делаю то, что хочет модель, понимаете, что я имею в виду? Я говорю: "Ну, если вы думаете, что это лучше, то это, вероятно, лучше", что неверно, у меня. Так много сказать о когнитивном долге и когнитивной капитуляции. Это верно, ваша следующая статья о. Итак, что у нас здесь? Так что приложение называется Streak, у нас есть постановка проблемы, у нас есть направление здесь. У нас есть некоторые предположения для проверки, такие как каков процент удержания? Какова будет частота вокруг привычек? Какова будет юзабилити мобильных устройств, поскольку инженеры настраивают рабочие места на настольных компьютерах, но часто завершают привычки на мобильных устройствах. Достаточно ли local storage? Ну, вероятно, local storage хорошо поддерживается везде на данный момент. Так что я думаю, что почти все эти идеи круты. Так что у нас определен объем MVP. И он также говорит, чего он не делает. Так что он не делает облачную синхронизацию, он не будет делать расширенные социальные функции. И у него есть некоторые открытые вопросы для нас, если мы хотим прояснить их. И он также спрашивает нас, хотим ли мы просто сохранить это? Так что я скажу да, сохранить. Итак, мы взяли очень высокоуровневую идею и уточнили ее. Теперь следующий этап — это фактическое превращение этой высокоуровневой идеи. Так что мы получили ее в лучшее место. Давайте превратим это в более подробную спецификацию. Теперь для некоторых людей вы можете сказать: "Ну, это кажется несколькими шагами". Вам не обязательно следовать моему способу делать вещи. Если вы хотите просто сделать один шаг для создания своей спецификации, вы можете это сделать. Мне просто нравится конкретика. Так что вы хотите планировать. Вы хотите план, спецификацию, а затем реализацию. Я сам парень, который планирует и реализует. Просто пропустите это. Это совершенно нормально. У каждого свой рабочий процесс. Здесь вы можете увидеть файл, который он сгенерировал, и это будет отправной точкой для следующего шага. Так что следующий шаг — спецификация. Так что у нас есть идея. Мы можем пойти и просто набрать слэш спецификация, и он прочитает вывод из последней фазы, он начнет генерировать что-то гораздо более конкретное. Так что он принимает эти предположения, определяет критерии успеха, набрасывает стек технологий гораздо более подробно, а затем у него есть эти открытые вопросы немного более подробно. Это действительно быстро. Да, это довольно быстро. Опять же, используйте Gemini 3.5 Flash или любую модель, которая доступна на момент просмотра этого на YouTube. Да, потому что он движется. ИИ движется быстро. Через 4 часа все будет. По-другому. Все будет по-другому. Так что у нас есть некоторые открытые вопросы. Методы генерации сетки. Следует ли нам использовать стандартные сетки вклада GitHub? Мы предпочитаем рендерить сетки как модульные динамические SVG-группы или макеты элементов CSS Grid. Я буду. Я знаю CSS Grid, я использую SVG, но я не эксперт, так что я просто для одного. Я скажу: "Выберите то, что вы считаете лучшим", а затем, при первом посещении, шаблон. Какие стандартные привычки следует установить для новых посетителей? Это хороший вопрос. Мы плохие привычки или мы отслеживаем плохие. Мы отслеживаем хорошие привычки. Хорошие привычки. Хорошие привычки. Упражнения, гидратация, чтение. Чтение медитации. Люди медитируют? Прокрутка? Делать прокрутку? Делать прокрутку. Хорошо, медитация. Медитация, вероятно. Лучше, чем медитировать после того, как вы прокрутили. Хорошо, у вас есть желаемое место для этого файла? Я просто позволю ему сделать то, что вы считаете лучшим. Круто. Что мне нравится в этом, так это весь этот пользовательский интерфейс. Все эти вопросы находятся прямо в боковой панели Copilot. Мне не нужно использовать какое-то другое приложение для этого. Какой бы ни была ваша агентская поверхность пользовательского интерфейса, вы можете получить похожий опыт. Так что теперь он создал для нас спецификацию. Я сохраню это, и на следующем этапе вы можете пойти и посмотреть спецификацию. Кстати, она здесь. Это будет гораздо более подробная версия того исходного файла, который у нас был. Но вы увидите, что у нас есть критерии успеха. У нас есть метрики для производительности, такие как largest content full paint. У нас есть определенный стек технологий. Это будет очень упрощенно. Так что ванильный JavaScript. Я не говорил, что хочу что-то на React. Меня это устраивает. Он никогда не спрашивал вас о стеке технологий, не так ли? Да. Он не спрашивал меня о стеке технологий, и это еще одна вещь, которую вы можете закодировать в своих навыках. Так что это предположение, которое вы просто позволяете. Это предположение, которое меня устраивает. Вы можете предположить, что оно определено тестами и playwright для нашего сквозного тестирования, что меня устраивает, наше хранилище, а затем структура проекта и стиль кода. И если здесь есть что-то, что вам не нравится, вы всегда можете вернуться и либо вручную настроить это, либо поработать со своим агентом. Так что вы настраиваете это дальше. Так что у вас есть спецификация. Теперь следующее, что вы можете захотеть сделать, это фактически начать разбивать это на отдельные части. Теперь это полезно, если вы работаете над большим проектом. Если вы работаете над чем-то маленьким, вы, вероятно, захотите перейти прямо к реализации. Я все равно покажу вам этот план в действии. Так что у нас есть шаг планирования. И что мы можем сделать с планом, это я могу пойти и запустить план. Я просто покажу вам, как это работает. И что это может сделать, это помочь разбить. То, что мы часто говорим в разработке программного обеспечения, это если у вас есть большая проблема, разбейте ее на мелкие части, верно? И план помогает вам с этим. Он разбивает вашу большую спецификацию на гранулированные части, которые затем могут быть реализованы. И это очень хорошо, если вы работаете с TDD, потому что у вас есть, знаете ли, очень отдельные части, которые могут быть протестированы, проверены по мере перехода к другим частям. У людей есть много разных способов делать TDD. Так что я не буду предполагать, что мой способ — это правильный способ или что-то в этом роде. Так что он идет и набрасывает основные части проекта прямо сейчас, потому что это нормально. Он может настроить наш шаблон перед тем, как мы фактически начнем реализовывать остальное. Я просто продолжу это, и вы увидите, что он спрашивает, прежде чем начать фазу один, я должен инициализировать наш структурированный список дел, чтобы обеспечить полную прозрачность, и он сделает это сейчас. Так что здесь у вас будет файл package.json, который, как мы видим, был создан. План реализации установлен и сохранен в плане. Так что у нас есть список задач. Здесь вы видите фазы и задачи. Так что у нас есть фаза один, задача один, которая имеет критерии приемки. И это похоже на создание чистой логики, TypeScript интерфейсов, ваших типов, ваших функций для вычисления стриков, ваших общих вкладов за последние, скажем, 365 дней, частей local storage, по сути, вещей, которые не обязательно касаются вашего пользовательского интерфейса. И у нас есть здесь некоторые критерии приемки. Так что у нас есть список вещей, которые должны быть истинными, а также проверка. Так что набор тестов должен иметь возможность работать на этой части логики, чтобы двигаться дальше. Он также предлагает, какие файлы, вероятно, будут затронуты в рамках этого, чтобы действительно сузить их. Если вы занимались vibe coding или агентной инженерией в течение некоторого времени, вы знаете, что один из способов, которым мы пытаемся ограничить радиус поражения, — это сказать: "Ну, я просто нацелюсь на эти конкретные файлы", потому что, особенно если вы работаете над существующим проектом, вы не хотите, чтобы он начал перезаписывать или касаться файлов, которые, возможно, не имеют отношения к текущей задаче, верно? Так что у нас есть несколько различных фаз и задач здесь. Некоторые из других фаз будут включать наше хранилище данных. Так что этот слой для local storage, он будет включать визуализацию наших привычек в виде графика вклада в стиле GitHub, а также остальную часть нашего пользовательского интерфейса. Так что у нас есть наш план здесь. Что вы можете сделать, опять же, это поддерживает очень гранулированный подход или отсутствие необходимости думать об этом в таких деталях. Так что, если бы я хотел, я мог бы сделать что-то вроде слэш-билдинг задачи один и просто заставить его выполнить первую задачу из этого списка. Так что давайте посмотрим, что он сделает. Он создал четыре задачи в рамках этого. Он оценивает это. Он читает наш навык разработки на основе тестов прямо сейчас. Вы видите, что он устанавливает эти первые вещи. Я также просто сделаю. Да, если вы всегда разрешаете. Вы можете сделать это в самом низу и включить обход утверждений, если хотите. Я узнаю что-то новое. Где я? Где? Ой, подождите, подождите, подождите. Я вижу, о чем вы говорите. Прямо там, да. И тогда он перестанет спрашивать, обходите ли вы утверждения? Вы рекомендуете обходить утверждения? Я обхожу утверждения во всех своих личных проектах. Так что теперь вы строите по одной фазе за раз. Вы вообще так работаете или вы больше? Я думаю, это действительно зависит от того, что вы строите. Так что, если я строю личный боковой проект и просто хочу построить что-то, может быть, у него одна цель, вероятно, я пропущу построение таким образом и просто позволю ему построить все. Если я строю что-то относительно сложное, меня устраивает делать это по фазе за раз. Это может показаться медленнее, но тот факт, что вы проходите через все эти шаги, и вы знаете, хорошо, этот фрагмент протестирован, когда мы строим пользовательский интерфейс, я знаю, что ничего другого не сломано. Я теперь сделал слой данных. Ничего другого не сломано. Это дает вам гораздо больше уверенности, когда вы работаете. Это просто другой способ подхода. Это такой компромисс, потому что тогда вы знаете, что цикл обратной связи, например, снова, вы — проблема. Вы замедляете агента. Это сложно. Я сам с этим борюсь. Да, да, абсолютно. И я бы сказал, что вам нужно принять решение в конце дня о том, сколько времени вы хотите инвестировать и куда в жизненном цикле разработки программного обеспечения вы хотите его инвестировать. Хотите ли вы потратить много времени на свою спецификацию? Просто позвольте вашему агенту построить много кода, а затем потратить время на его проверку, определение ваших тестов на этом этапе, выяснение того, как я оцениваю качество, как это? Это может быть нормально. Или вы хотите подойти к этому с учетом TDD? Хотите ли вы иметь явную стратегию того, как вы будете проверять качество, чтобы по мере того, как вы проходите, это уже решает эти проблемы? И я не думаю, что есть правильный или неправильный способ. Это просто разные способы работы, понимаете, что я имею в виду? Так что то, что вы можете видеть с этой первой фазой, заключается в том, что реализация является тестовой. У нас есть наш первый целевой падающий красный тест, чтобы сказать нам, что "хорошо, у нас есть тест, он падает, мы реализуем минимальную чистую логику в Streaks. Мы красные-зеленые здесь, да. И, как я уже сказал, вам не обязательно делать это с отдельными задачами. Мы можем продолжать запускать сборку, чтобы пройти остальное, а затем перейти к другим фазам. Так что вы можете видеть, что благодаря совету Берка об обходе утверждений, мы просто продолжаем. И я человек, о котором люди часто говорят: "Как инженер понимает, что генерируется, если он не читает весь код?" Да, очень часто, когда ваш агент генерирует что-то, что вы делаете? Вы переключаетесь на другую агентскую задачу? Например, очень часто я, я думаю, я обнаружил, что делаю это. И поэтому я начал немного замедляться. И в наши дни я стараюсь читать траекторию немного больше, например, что это сказало? Что это думало? Почему это думало то, что оно думало? И есть ли там какой-нибудь проблеск информации, который я могу извлечь, который просто дает мне знать. О, хорошо, вот как я ожидал. Это то, что вы имеете в виду. Понимаете, да? Так что это интересно, потому что я, я не знаю, что делают все остальные, но я, я наблюдаю, как работает агент. Теперь я не читаю все, что он делает. Я в основном просто смотрю на него, когда должен делать что-то другое. Но я просто, я буквально наблюдаю, как агенты вращаются. Но мне интересно, вы, вы смотрите на код? Отличный вопрос. Я стараюсь, я вообще, если это не личный проект, есть много личных проектов, которые в конечном итоге оказываются одноразовыми вещами. О, у меня есть, у меня есть потребность на час. Я просто построю что-то, что будет выброшено. И в таких ситуациях меня вполне устраивает сказать, что если я не понимаю код, агент исправит что-то для меня. Однако, если это будет что-то, что я буду поддерживать по крайней мере несколько недель или несколько месяцев, я обычно возвращаюсь и по крайней мере понимаю архитектуру. И я стараюсь прочитать некоторые основные файлы, чтобы, если я обнаружу, что агент не смог исправить что-то или он отклонился от темы, я смог вернуться и внести исправления сам. Знаете, очень часто. Так что я продолжу работать над сборкой, и мы можем продолжать болтать. Так что он будет продолжать выполнять свои фазы TDD. По мере реализации каждого фрагмента он будет переходить от красного к зеленому, реализовывать фазу и выполнять все. Это так интересно. Я даже не знал о тестировании "красный-зеленый", пока не вышел Spec Kit. Это был мой первый. Это был первый раз, когда я увидел это. Это идея написания падающих тестов, а затем их выполнения, и это было около 45 лет. Это как-то грустно. Вы не знаете, что это такое. Вы совсем не смотрите на 45. Я нет, да. 445 было вчера. С днем рождения. Большое спасибо. Так что мы будем продолжать делать это. Я также хотел бы поделиться комментарием по этому поводу. Я думаю, что очень часто во всей диаспоре агентной инженерии индустрия рисует очень широкие мазки о лучших практиках. Например, если вы, если вы в Твиттере, если вы в любой социальной сети, очень часто лучшие практики для соло-основателя или небольшой команды стартапа будут разделяться. И лучшие практики для такой команды, которая, возможно, еще не имеет пользователей, возможно, они работают над вечнозеленой кодовой базой. Они очень отличаются от людей, которые работают над чем-то, либо устаревшим коричневым полем с командой. И поэтому я думаю, что важно просто понимать, что, знаете ли, есть ситуации, когда нормально просто отдаться вибрациям и позволить агенту разобраться. И если что-то пойдет не так, мы просто позволим агенту исправить это. В других ситуациях, когда понимание того, что происходит за кулисами, по-прежнему довольно важно. Да, на 100% согласен. Я на самом деле, так что очень интересно в этом то, что я думаю, что я и большинство людей ищут, это просто скажи мне, что установить, чтобы все работало правильно? Это агентские навыки? Это суперсилы? Это G stack? Например, что это? И ответ заключается в том, что это может быть что-то из любого из них, но ваша работа меньше связана с написанием кода сейчас, а больше с построением этих рабочих процессов, которые действительно работают. И это не всегда одно и то же, даже для разных проектов в одной организации. Так что абсолютно, это очень, я не знаю, как это назвать. Это не разработка программного обеспечения. Это не автоматизация. Это, как бы вы вообще это описали? Например, мы все работаем в McKinsey сейчас. Я, я, я не знаю. Я, я признаю, что агентная инженерия, мы, мы, мы теперь работаем в спектре, верно? И будут времена, когда мы будем заниматься vibe coding, будут времена, когда мы будем заниматься агентной инженерией. И чем больше усердия вы должны применять к процессу, тем ближе вы подходите к агентной инженерии. И я думаю, что в больших компаниях, малых компаниях, в любое время, когда вы работаете над чем-то существующим и имеющим существующих пользователей, вы обязаны им заботиться о качестве, заботиться о том, чтобы не ломать вещи таким образом, как иногда агенты тонко делают. Да, на 100% согласен. Если вы строите трекер привычек, это одно. Если вы выпускаете VS Code, вам нужно быть довольно дотошным. Да, в отношении того, чтобы не сломать это. Да. Так что у нас осталось около 10 минут. Так что я собираюсь немного пропустить вперед и просто очень быстро показать вам некоторые из этих других фаз. Так что пакет агентских навыков также включает шаг проверки. Теперь, что делает Verify, это то, что он может просто проверить, что реализация, как она была сделана до сих пор, будь то полная или частичная реализация чего-то, что уже можно использовать, может работать в браузере и фактически делать то, что нужно. Так что он собирается проверить, что он действительно может что-то запустить. Но давайте посмотрим, достаточно ли его построено, чтобы он мог это сделать. Так что он сейчас запускает свой npm run build. Он собирается запустить свой npm run dev, и мы увидим, работает ли это на самом деле. Так что у нас есть. У нас есть что-то, похожее на профиль GitHub, где. Откуда вы взяли эту картинку? Я понятия не имею, кто это, магия LLM. Кто-то, если этот человек смотрит. Кто-то. Кто-то в мире. Привет, кто бы это ни был, это может быть и не разработчик. Это может быть человек, который просто любит печь печенье где-нибудь в мире. Он просто оказался на GitHub. Да, он просто оказался на GitHub. Но знаете ли, он открыл этот браузер прямо в VS Code. Он может выполнять свои проверки за кулисами, чтобы увидеть: "Хорошо, что-то действительно сломано? Если я взаимодействую с пользовательским интерфейсом, что-то действительно начинает ломаться?" И я думаю, что это очень интересно, например, если вы фактически перейдете к подсказкам и перейдете к нашему навыку проверки, он в конечном итоге попробует тестирование в браузере с навыком dev tool. Существует множество способов автоматического тестирования в браузере в наши дни, будь то Puppeteer, Playwright, Versal, агент браузера, есть много различных вариантов. Я не собираюсь говорить, что есть правильный, но выберите то, что имеет смысл для вас. Я просто думаю, что в наши дни есть много отличных инструментов для того, чтобы просто убедиться, что ваша вещь работает. Решаете ли вы кодировать все свои пользовательские пути и тестировать их очень, очень целостно, зависит от вас в конечном итоге. Веб-разработчики, как обычно, имеют это лучше, чем кто-либо другой. Верно? Например, с нативными приложениями гораздо сложнее. Теперь для моих навыков фаза обзора становится действительно важной, и у людей много мнений о обзоре. Я склонен находить, и это то, что я обнаружил, разговаривая с инженерами в Google, у нас все еще есть культура, где мы склонны к тому, чтобы инженеры вручную просматривали код. Даже даже с этим, даже с попыткой привнести ИИ в наш процесс обзора кода, имея, знаете ли, агент, выполняющий локальный первый проход или многократный проход, действительно, действительно ценно. Теперь есть люди, которые доводят это до конца до враждебного обзора кода с очень глубокими, знаете ли, шаблонами. Есть люди, у которых будут другие модели, знаете ли, например, "Эй, я собираюсь, может быть, я буду использовать Gemini для реализации, а Opus или codecs, соответственно". Так что у вас здесь много гибкости. Опять же, нет правильного или неправильного способа. Люди часто решают эти вещи на основе вибраций. Но вы увидите, что у нас есть ряд различных видов проверок обзора, которые были сделаны здесь. Так что работает хорошо, что технически считается корректностью? Так что все модульные тесты, которые были реализованы до сих пор, по-видимому, проходят. У нас нет проблем с безопасностью. Кажется, знаете ли, мы работаем с ванильным JavaScript. Мы, конечно, хотим избежать проблем с XSS или межсайтового, знаете ли, межсайтового скриптинга, чего-либо подобного. Читаемость и архитектура кажутся в хорошем состоянии. Производительность кажется в хорошем состоянии. Это простое, знаете ли, приложение, и оно также применяет рекомендации. Так что навигация с клавиатуры для этой сетки вклада имеет смысл, верно? Например, это не то, о чем я думал. И вы можете обнаружить, что в зависимости от сложности того, над чем вы работаете, вы можете сделать это гораздо более сложным. Другая часть обзора кода, которая, по моему мнению, полезна в наши дни, — это упрощение кода. И очень часто мы делаем так, что агент реализует что-то, мы проверяем, может быть, вы читаете код, может быть, вы проверяете, что он, по крайней мере, работает в браузере. Или, знаете ли, если вы строите нативное приложение, "Эй, оно по крайней мере работает", но вы не обязательно возвращаетесь и спрашиваете себя: "Эй, может ли это быть проще?" И одна из замечательных вещей в TDD или наличии тестов или качественных ворот заключается в том, что вы теперь можете сделать этот цикл упрощения кода и иметь что-то, что может проверить, что остальная часть вашей логики по-прежнему работает. Да. Верно, очень интересно. Так что у меня вопрос по безопасности, насколько вы доверяете недетерминированному? Потому что для меня это то, где, где дорога встречается с реальностью, верно? Со всем остальным вы можете справиться. С безопасностью нельзя. Насколько вы доверяете этому обзору, что вы не отправляете ключ, вы не отправляете какие-то SQL-инъекции, что-то, что может привести вас в большие неприятности в будущем? О да, я думаю, что есть много хороших бесплатных и коммерческих предложений, которые идут еще глубже в безопасность, чем эти навыки. И поэтому есть много вещей, которые, например, мы видели, любой, кто занимается байт-кодингом и инженерной инженерией в течение некоторого времени, сталкивался с этими проблемами, верно? Очень часто люди используют API-ключи ужасными способами, верно? Они быстро собирают что-то и не понимают, что, о, подождите, на самом деле есть тонны утечек данных или способ реализации Office оставляет вас уязвимым для всех видов проблем. Или кто-то может просто бесконечно бомбить ваш API, потому что он не заблокирован. Точно. И если вы, если вы старший инженер, если вы опытный, вы знаете, на что обращать внимание. Если вы промежуточный, если вы не так техничны, если вы подходите к этому без такого большого опыта, или, возможно, вы опытный инженер, и вы просто ленивы. Потому что иногда мы ленивы. Полезно кодировать эти вещи в навыки просто как проверку здравого смысла для себя. О, на самом деле Список конкретно. Да. Так что я считаю, что я не могу придумать все крайние случаи, но модели на самом деле очень, очень хороши в этом. Например, если вы когда-либо просите модель просмотреть кодовую базу, она почти всегда найдет что-то, что вам нужно изменить ваш ввод, верно? Они действительно, действительно тщательны и хороши в этом. Так что да, опять же, я не знаю, я чувствую, что нам нужны, возможно, лучшие продукты или что бы то ни было, но все это для меня агенты код должен пройти через какой-то детерминированный гейт, который говорит: "Да, одобрение безопасности достигнуто", потому что я не доверяю, я в ужасе от того, чтобы выпустить что-либо в прямом эфире на Twitter и сказать: "Вот что я построил", а затем кто-то скажет: "О, а вот ваш ключ к Джимми". И я думаю, что именно здесь заключается большая ценность в понимании того, что означает хорошо? Что означает сделано? Верно? И если вы заботитесь о безопасности, вы заботитесь о качестве, вы заботитесь о производительности, вы заботитесь о доступности, вы заботитесь о чем-либо из этого, это хорошее напоминание, чтобы попытаться закодировать это в то, как вы подходите к качественным воротам в своих проектах. Да, навыки — это просто один из способов кодирования этого в то, как вы думаете обо всем этом. Но я думаю, что просто наличие инструментов, чтобы убедиться, что вы не объединяете код, который противоречит этим лучшим практикам, — это всегда хорошая идея. Да, я чувствую, что нам нужно больше таких детерминированных ворот. Я просто не знаю, что это такое, например, сейчас. Markdown — решение всего. Это как, ну, у нас есть недетерминизм. Как мы собираемся исправить это с большим недетерминизмом с текстовыми файлами? С текстовыми файлами. Так что у нас осталось около 6 минут. Я хотел бы провести некоторую Q&A, потому что вы можете продолжить. Да, да. Так что я закончу через минуту. Так что есть много отличных команд, лабораторий, которые думали об упрощении кода. И очень часто я люблю делать так, чтобы в любое время, когда они открывают свой код или пишут пост в блоге о своей работе, я изучаю. Например, есть ли что-то, чему я могу научиться из того, что они делают, что я могу затем включить в свои навыки или как я работаю? Вы можете сделать это и для упрощения кода. Даже для этого простого приложения он уже нашел около 3-4 возможностей для упрощения кода. Так что это здорово. У нас есть шаг выпуска здесь также. Просто для экономии времени я просто пропущу вперед и покажу вам один, который я построил раньше. Это похоже на то, что называется Streak. У него есть график в стиле графика вклада GitHub, знаете ли, в самом низу. И он просто показывает нам с течением времени, следуете ли вы некоторым из этих лучших практик. Так что для меня, я лишаюсь экрана на какую-то часть утра? Я, знаете ли, планирую свои рабочие цели? Я размышляю? Так что вы можете, знаете ли, это не сложное приложение, но вы можете открыть, знаете ли, инструменты разработчика вашего браузера, перейти в панель приложений, local storage, и мы можем увидеть, что все наши данные здесь. У нас есть все наши записи для каждой из этих вещей. Все локально. Все это будет работать в автономном режиме, но это делает трюк. Теперь мы можем провести Q&A, вы можете провести Q&A. Так что давайте потратим несколько минут. У нас есть Том? Как мы это делаем? У нас есть микрофон или мы будем проводить Q&A? О, прямо там. Да. Так что, если вы хотите, мы продолжим строить здесь. Если вы хотите задать вопросы, сейчас ваш шанс. А пока мы можем продолжать обсуждать навыки, если хотите. Это зависит от вас. Отлично. Если у народа есть вопросы, я с радостью отвечу. Иначе я с удовольствием продолжу показывать вам вещи. Хорошо, у нас есть один. Это Энтони. Привет, да, вопрос к вам. Как бы вы разделили работу между моделью типа Flash и про-моделью? Вы бы планировали во Flash, а затем реализовывали в Pro? Как бы вы разделили работу? Вы слышали это? Да, интересный вопрос. Так как вы разделяете между моделями? Например, планируете ли вы во Flash, а затем реализуете в
Про? Например, вы мультимодельны среди семейства Gemini? Как насчет вашего личного ухода? Да, я, это именно мой рабочий процесс. Я склонен, и особенно если вы пытаетесь оптимизировать затраты, это отличный способ действовать. Вы можете использовать модель с более низкой стоимостью часто для этапа планирования, особенно если вы пытаетесь, например, оптимизировать токены, использовать модель с более низкой стоимостью для этапа планирования, использовать гораздо более способную модель для вашей реализации. И будь то, знаете ли, одна из моделей Gemini Pro или Opus или кодеки, любой из этих вариантов может быть хорош для ваших нужд. Но я обнаружил, что эта гибкость хорошо работает, и Copilot, и многие другие инструменты также позволяют вам просто легко переключаться между различными моделями для этих нужд и этих разных этапов, что здорово. Интересно, у меня есть к вам вопрос. Где MCP вписывается в этот рабочий процесс? Это отличный вопрос. У меня слишком много твердых мнений о MCP в эти дни. Я думаю, что давайте. Сделаем это. У нас на самом деле есть немного дополнительного времени, так что мы можем немного поговорить. Верно, я, я лично думаю, что вещи, вещи движутся так быстро, верно? И раньше мы говорили о разнице, знаете ли, эй, MCP был действительно хорош для, знаете ли, связи, верно, между данными и агентами и так далее. И я думаю, что люди обнаружили, что очень часто есть случаи, когда вы действительно хотите CLI вместо MCP. И мы начали видеть, как рабочие процессы немного эволюционируют, потому что, возможно, вам не нужно иметь так много инструментов, возможно, простое использование CLI будет более эффективным способом достижения ваших целей. Так что я лично чувствую, что мы все еще находимся на этой стадии эволюции, когда мы видим, например, хорошо, где MCP будет лучшим решением по сравнению с тем, чтобы люди напрямую использовали CLI для вещей? Это своего рода спорная область, я чувствую, потому что я в какой-то момент сказал, что ваш сервер MCP должен быть навыком и ACLI, я отчасти все еще придерживаюсь этого, просто потому, что они так хороши в использовании CLI. Единственное возражение, которое у меня есть к этому, я болтал с Ризом, который, я думаю, сейчас работает в Open Code, об этом в X, и он отметил, что аутентификация — это реальная проблема, и что MCP делает это действительно, действительно хорошо. И с CLI действительно трудно контролировать разрешения для вашего агента, так что я согласен с этим. Но в целом я почти полностью использую навыки. Единственные MCP, которые я использую, это, конечно, Work IQ, верно? Потому что если вы находитесь в экосистеме Microsoft, это как бы лучшая вещь на свете. И затем Context 7, я всегда говорю. Об этом, это здорово. Это. Удивительно, если вы все не используете сервер MCP Context 7, это единственное, что вы должны установить сегодня, и просто скажите своему агенту всегда читать документацию перед тем, как что-либо делать, и он будет использовать Context 7 для чтения документации. О, блестяще. Я чувствую, мне это нравится, знаете ли, даже в Google Cloud, я знаю, что во многих других местах люди начали выпускать и поддерживать больше наборов навыков просто потому, что вы можете. Вы можете так далеко продвинуться в эти дни, убедившись, что независимо от того, какая дата отсечения у данных вашего агента, у вас есть актуальная документация, актуальные инструкции о том, куда идти, где что найти, точно так же, как должен выглядеть рабочий процесс разработчика. Так что я большой поклонник навыков, люди еще не знают об этом. Да, они потрясающие. И я, одна из вещей, другое преимущество, о котором вы говорили в начале, это то, что они загружаются постепенно, верно. Так что одна из вещей, с которой мы все сейчас боремся, это то, что контекстное окно — это проблема. И, честно говоря, я чувствую, что нам нужно лучшее решение, чем контекстное окно в целом в какой-то момент в будущем. Это своего рода очень рудиментарный примитив для взаимодействия с LLM. Но проблема в том, что контекстное окно заполняется очень быстро, и MCP, он должен указывать все инструменты. Так что, если вы не знали, навыки загружаются постепенно. Так что модель получает, например, название навыка и краткое описание. И затем из этого она загрузит навык. И затем навык может указывать на другие файлы, и затем она загрузит эти файлы. И поэтому это очень, очень экономично для использования токенов, что сейчас важнее. Это становится все важнее с каждым днем, поскольку мы переходим от мира, где вы используете столько ИИ, сколько хотите, к этому — вот сколько у вас токенов. Используйте их с умом. Абсолютно. Хорошо. Ну, Адди, большое вам спасибо за то, что были здесь. Я многому научился. Я с нетерпением ждал этого просто ради бесплатного обучения по вашему репозиторию навыков, так что я получил от этого пользу. Спасибо, что были здесь. Спасибо, что пригласили. Ценю это. Это здорово. Хорошо. Большое вам спасибо. Итак, мы скоро вернемся с нашим следующим гостем, и, думаю, возможно, люди смогут пообщаться с вами, если захотят. Конечно. Хорошо. Спасибо, ребята. Вот. Идем.