Transcription
Что бы вы сказали к концу этого подкаста, что каждый узнает от вас? >> Главное, о чем я хочу сегодня поговорить, это о том, как мы можем быть режиссерами наших кодирующих агентов. Все сейчас слышат, как большие языковые модели могут поддерживать до 1 миллиона токенов в своем контексте. Это как пять книг о Гарри Поттере. У больших языковых моделей есть так называемая "зона глупости". С Opus сейчас это обычно около 250 000 токенов, и я чувствую, что он попадает в зону глупости. >> Это определенно дает людям ложное чувство безопасности, когда они думают, что у них есть миллион. С кодирующими агентами вы тратите больше времени на планирование, чем на фактическое создание. >> Без проверок верификации, возможно, это 65 или 70, но теперь вы можете получить что-то, что составляет 92 с первого прохода. >> Если вы скажете ему никогда не удалять базу данных, он все равно сделает это. Если вы не позволите ему удалить папку, он все равно может написать скрипт для этого. >> Недавно у нас кое-что случилось. Агент пытался быть проактивным и увидел что-то в своем списке задач, но неправильно истолковал это и в итоге отправил электронное письмо всему нашему списку с кодом скидки, который не должен был быть отправлен. Если у вас есть установка, что все, что агент может прочитать или к чему может прикоснуться, вы должны предполагать, что он это сделает, даже если вы никогда не просили его об этом, это предположение спасет вас от удаления вашей базы данных. >> Хорошо, Коул, спасибо большое, что пришли сегодня. Я очень рад погрузиться. >> Я рад быть здесь. Да, спасибо, что пригласили меня на свой подкаст, Нейт. Я с нетерпением жду этого. >> Абсолютно. Да, мы давно не разговаривали, поэтому я с нетерпением жду, чтобы узнать, чем вы занимались, и услышать, так сказать, соус, который вы сегодня всем преподнесете. Итак, очень быстро, что бы вы сказали к концу этого подкаста, что каждый узнает от вас? >> Да. Итак, главное, о чем я хочу сегодня поговорить, это о том, как мы можем действительно быть режиссерами наших кодирующих агентов, и в частности облачного кода, потому что именно им большинство людей пользуются сейчас. Это то, чем пользуюсь я. Но на самом деле, это создание системы, где у вас есть ваш способ работы с облачным кодом, который сам развивается со временем. И мы поговорим не только об использовании его для кодирования. На самом деле, я использую свой облачный код как свой второй мозг. Мне нравится так его называть. Я знаю, Нейт называет его AIOS. У каждого свой термин, но на самом деле это использование облачного кода как инструмента, чтобы сделать ваш бизнес AI-нативным. Мы разберем все это и просто несколько высокоуровневых стратегий, которые, честно говоря, вы можете начать применять уже сегодня. >> Мне это нравится. Да, я очень рад погрузиться, потому что, знаете, у меня нет формального образования в области разработки программного обеспечения, и я думаю, что могу предположить, что большинство моих слушателей тоже не имеют его, но, очевидно, поскольку продукты называются Cloud Code, я думаю, что многие люди, которым я об этом говорю, которые не очень глубоко разбираются в области ИИ, очевидно, думают, что это инструмент для кодеров, и вам нужно понимать код, чтобы им пользоваться. Так что, мне нравится такая постановка вопроса. И очень быстро, прежде чем мы начнем, вы и я знаем друг друга довольно давно. Мне кажется, когда я уволился с работы и начал заниматься этой сферой, вы были одним из основных каналов, за которыми я следил и до сих пор слежу, чтобы быть в курсе и узнавать, как правильно работать с ИИ. И мы как бы видели, как друг друга растем и, знаете, общаемся. Так что я очень рад погрузиться, но я хотел убедиться, что у вас есть возможность быстро дать всем краткое представление, если они еще не видели ваш канал, о том, чем вы занимаетесь, и >> да, чем вы занимаетесь. Да, звучит хорошо. Знаете, прежде чем я дам представление, я хотел бы поделиться кое-чем о том, о чем вы говорите. Например, когда мы впервые встретились, забавно, потому что я на самом деле помню, у меня было около 50 000 подписчиков, когда Нейт впервые связался со мной, а у него было около 10 000, а теперь все немного по-другому. У меня около 200 000. У вас сейчас почти 800 000, верно? Это довольно безумно. Было очень приятно наблюдать за вашим ростом, как быстро вы росли. Но да, мы оба были тогда небольшими каналами. Так что да, это было давно. Дикое путешествие. Да, в любом случае, что касается того, чем я на самом деле занимаюсь, то, как сказал Нейт, я имею опыт в области разработки программного обеспечения. Так что я был инженером всю свою жизнь. С восьми лет, на самом деле, я начал с языка под названием Scratch. Он разработан MIT. Так что я просто создавал видеоигры в детстве, вроде Super Mario Bros. и Pokemon, такие клишированные вещи. Но это то, что привело меня в мир кодирования. И я пронес это через старшую школу, колледж, получил степень бакалавра в области компьютерных наук, а затем у меня была просто работа инженера-программиста в компании из списка Fortune 500, и это было здорово, но я всегда хотел быть предпринимателем. И когда генеративный ИИ начал набирать обороты в конце 2022 года с выходом ChatGPT, знаете, и он покорил мир, тогда я понял, что вот куда я хочу вложить все силы, потому что есть действительно большая возможность для инженеров-программистов, в частности, создавать агентивные приложения. И поэтому я начал много этим заниматься, например, для своей компании и для друзей с их стартапами, практически посвящая этому весь день и всю ночь в течение очень долгого времени, более года. И дошло до того, что, хотя я знаю, год может показаться недолгим, но в сфере ИИ год — это долго. Так что дошло до того, что, хорошо, у меня есть кое-что, чему можно научить людей. Поэтому я и начал свой YouTube-канал. >> Изначально это было очень, очень технично, я писал строчка за строчкой. Я даже не использовал ИИ-помощников по кодированию тогда, просто показывал, как создавать ИИ-агентов с помощью, знаете ли, LangChain и LangGraph в то время. И теперь это развилось во многое другое, например, я много фокусируюсь на ИИ-помощниках по кодированию, поэтому мы сегодня об этом говорим. И да, я уволился с основной работы примерно через три месяца после начала своего YouTube-канала, что, думаю, примерно то же самое и у вас, Нейт. Да. Потому что это безумие, как быстро, когда вы делаете это правильно и обучаете людей ценным вещам, как быстро канал может взорваться. И поэтому сейчас я занимаюсь своим ИИ-сообществом, похожим на Нейта, где у меня есть контент курсов, еженедельные семинары, которые я провожу. Я также проводил некоторое обучение на уровне предприятия. Так что прихожу в команду и провожу 4-часовую сессию, помогая им внедрить полную систему использования ИИ-помощников по кодированию, чтобы они действительно могли иметь это как стандарт для команды, знаете ли, отойти от "вайб-кодинга" к действительно структурированному подходу и помочь им фактически интегрировать это в их существующие процессы и технологический стек и тому подобное. Так что это было довольно здорово. И поэтому, на самом деле, это и все, чему я учу в сообществе, я переношу многое из этого сюда, к тому, о чем мы будем сегодня говорить. >> 100%. Быстро, ребята, короткий перерыв, чтобы рассказать вам о сегодняшнем спонсоре, ClickUp. ClickUp — это программное обеспечение, которое заменяет все программное обеспечение, что, мне кажется, довольно смешно, но очень правдиво. Если вы следите за мной давно, вы знаете, что я использую ClickUp очень, очень давно. Все, что я делаю с моей командой, живет в ClickUp. Все наше общение, все наше управление проектами, все наши чаты, и все, что я делал с моими клиентами, когда я управлял агентством изо дня в день, мы также приглашали их в ClickUp. Так что он заменил нам Slack и наши инструменты управления проектами. Так что, если вы уже используете ClickUp, вы должны попробовать эту новую функцию под названием Brain 2. Но если вы еще не используете ClickUp, то Brain 2 — это потрясающая причина попробовать ClickUp. Это своего рода суперкомпьютер, который может делать массу классных вещей. И я расскажу об этом через секунду. У них есть супер-агенты здесь. Но вы можете переключаться между различными чат-моделями, которые вы, вероятно, уже используете и любите. Прямо здесь вы можете видеть, что я сам использовал Brain, чтобы просмотреть все, что происходит в наших проектах, а затем создать для меня ежемесячную презентацию для команды. Так что это может выглядеть так, как я прошу Brain создать инвестиционную презентацию для нашего стартапа texttospeech под названием Glido. И я сказал ему использовать только пробные данные, но убедиться, что она профессиональная и увлекательная. И вот так у нас есть презентация, которую я могу открыть на полный экран прямо здесь. У нас есть платформа голосового ИИ, которая делает каждый бренд звучащим по-человечески. И когда я начинаю перемещаться здесь, вы можете видеть, что у нас также есть анимация. Так что это не просто статичная, знаете ли, слайд-презентация. Мы можем пройти через нее и почувствовать анимацию. И подумайте о том, что это был всего лишь одно предложение. Если бы мы действительно начали вводить в это больше и больше данных, это было бы очень, очень солидно. И это всего лишь один из многих вариантов использования Brain 2. Так что это не просто чат-бот. Как я сказал, он может делать вещи, и вы можете создавать своих собственных супер-агентов здесь. И что мне действительно нравится в супер-агентах, так это то, что они являются 24/7 агентами. Вы можете пометить их в ClickUp. Вы знаете, вы можете отправить им сообщение, и они проснутся и ответят вам, и они смогут искать все. Вот почему, на мой взгляд, гораздо круче, что ClickUp делает это по сравнению с чем-то вроде закидывания агента OpenClaw или Hermes в ClickUp, потому что эти агенты уже имеют полный контекст и могут искать все. Так что прямо сейчас, поскольку вы смотрите это видео, вы можете получить это супер-крутое предложение, которое сейчас на экране, используя ссылку в описании. А теперь вернемся к видео. Да. Ну, я просто рад, что мы оба рискнули, потому что, знаете ли, это нелегкое решение, но ваш мозг просто понимает это. И поэтому было здорово видеть, знаете ли, последовательность и то, чем вы занимались. Но я думаю, что если вы вспомните, я не знаю, 5-10 лет назад, когда люди получали свои, знаете ли, степени по CS и тому подобное, это была такая безопасная ставка в то время, знаете ли, и я не думаю, что многие люди >> предсказывали, насколько быстро это изменится, как, знаете ли, эта графика того, к чему применяется ИИ, и сейчас это просто большинство — кодирование и разработка программного обеспечения, и, очевидно, все догонит. Но здорово, что вы смогли, знаете ли, сделать этот поворот и быть впереди кривой, и вот мы здесь. Так что возможность вести этот разговор, один из нас с совершенно нетехническим образованием, а другой с техническим образованием, будет действительно крутой. Так что да, давайте просто начнем. >> Да, звучит хорошо. Круто. Итак, что касается того, что я подготовил на сегодня, вы увидите, что я пришел из технического фона, но на самом деле все сводится к тому, что я буду использовать эти концепции для использования облачного кода для гораздо большего, чем просто кодирование, как я намекнул в начале. И поэтому я думаю, что для меня я действительно люблю опираться на свой технический опыт, потому что многие из способов, которыми вы будете использовать ИИ-помощника по кодированию для своих операций, своего AIOS, своего второго мозга, как бы вы это ни называли, вы будете заимствовать из принципов разработки программного обеспечения, осознаете вы это или нет. Так что часто, когда вы учитесь эффективно использовать эти инструменты и просто изучаете лучшие практики с YouTube Нейта, блога Anthropics или Boris Journey или кого-либо еще, они привносят принципы разработки программного обеспечения и много принципов управления продуктами, а также. И поэтому, да, некоторые из примеров, которые у меня есть здесь, которые мы рассмотрим, они немного технические. Но это действительно просто для иллюстрации того, как я начал использовать этот инструмент, а затем, конечно, я обобщу вещи, а также дам несколько конкретных примеров. >> Итак, если вы хотите, Нейт, я могу просто перейти к первой части, которую мы здесь имеем. Хорошо, да. Итак, у меня есть краткий обзор, я имею в виду, мы довольно быстро пройдемся по этому, потому что я хочу, чтобы это было довольно непринужденно, и я знаю, что вы тоже, Нейт, но просто несколько разных столпов того, как мы можем перейти от простого использования облачного кода к тому, что многие называют "вайб-кодингом", знаете ли, промптингом и надеждой, где вы дергаете за рычаг, как игровой автомат, до точки, где мы действительно им управляем и имеем систему для надежных и повторяемых результатов. И это действительно может быть проще, чем вы думаете, верно? Большая часть того, что люди делают, чего действительно не следует делать, это то, что вы вводите запрос и не делаете много планирования заранее или проверки после. Это две вещи, о которых я действительно хочу поговорить здесь. И это применимо к написанию любого кода или любого приложения. Это применимо к развитию вашей системы, когда вы создаете навыки и интеграции для облачного кода, или даже просто используете его для автоматизации вещей в вашем бизнесе. И поэтому, да, подход заключается в том, что вы всегда хотите планировать с учетом контекста, создавать то, что вы хотите сделать, а затем иметь подход к проверке, насколько высокоуровневым я могу это сохранить. И другая, так сказать, золотая крупица здесь заключается в том, что каждый раз, когда вы проходите этот цикл с облачным кодом, любой агентский рабочий процесс или вещь, которую вы создаете, всегда будет возможность в конце развить вашу систему. И мы поговорим о том, что это значит немного позже, но на самом деле это сводится к тому, что будет что-то в вашем способе работы с облачным кодом, что вы можете улучшить, чтобы в следующий раз это было лучше. >> И я намеренно говорю высокоуровнево, потому что я перейду к некоторым примерам. Но многие люди не думают об этом, верно? Они как бы доходят до точки, когда говорят: "Хорошо, мое приложение работает. Этот веб-сайт выглядит хорошо, или он теперь может автоматизировать создание счетов, что угодно". И они говорят: "Хорошо, мы закончили". В следующий раз, когда я захочу создать счет, я просто снова пройду тот же процесс. Но на самом деле будут возникать проблемы, которые вы можете спроектировать так, чтобы они возникали реже, верно? Это системная эволюция, как я люблю это называть. >> Так вы заставляете его учиться, как вы бы учили сотрудника, верно? >> Абсолютно. >> Да. Например, мой второй мозг, я буквально называю его своим соучредителем, верно? Так что я хочу, чтобы он лучше учился мне со временем и тому, как я люблю работать, как я хочу, чтобы он работал. >> Мм. Да. И я думаю, что эта четырехступенчатая структура или как бы вы ее ни называли, она, да, когда вы смотрите на нее так, это может показаться технической вещью из области разработки программного обеспечения, но если вы просто свяжете это с тем, как вы бы, скажем, построили домик на дереве, вы бы сначала спланировали это. Вы бы нарисовали это. Вы бы поняли, сколько дерева вам нужно и где, вы бы взяли правильное снаряжение, а затем, когда вы его построили, вы бы не просто посадили на него своих детей. Вы бы проверили это. Вы бы убедились, что это не упадет. Так что, >> это просто отличный способ подумать об этом. И особенно если вы подумаете о некоторых ловушках, которые есть у этих моделей, например, о том, что они просто "да-человек". >> Если вы скажете: "Эй, знаете, я хочу сделать это. Это выглядит хорошо?" И они просто скажут: "Да, выглядит", не просмотрев план. А затем >> на стороне проверки, >> знаете ли, иногда они говорят вам, что что-то сделано, но это не так. Так что иметь свой собственный метод делать это тоже >> очень важно. >> Кстати, ребята, я знаю, что мы погружаемся в тонны информации в этом эпизоде. Поэтому я разбил все это на бесплатное руководство по ресурсам, к которому вы можете получить доступ совершенно бесплатно, присоединившись к бесплатному сообществу школы. Ссылка на это находится в описании. Также, если вы хотите посмотреть некоторые ключевые моменты из этого эпизода и всех будущих подкастов на моем канале, то перейдите и посмотрите YouTube-канал AI Automation Society, где мы будем публиковать некоторые лучшие моменты подкаста. Я дам ссылку на этот YouTube-канал в описании этого видео. В любом случае, спасибо, ребята. Вернемся к подкасту. >> Да, проверка действительно сводится к тому, чтобы доказать мне, что это действительно сделано и работает, >> верно? Верно. И поэтому, для любой кодирующей задачи это такие вещи, как модульные тесты и линтинг, и вот тут становится немного техничнее, но на самом деле вы можете применить это к чему угодно. Например, я, это пример, который я сейчас раскрою. Я использую облачный код для генерации всей этой диаграммы. Я >> Я так и думал. Да. >> Да. Да. Да. У меня есть навык. Это мой навык диаграммы Excalidraw. Я освещал его на своем YouTube-канале. Я использую его для создания всего этого. И я собирался обсудить этот пример немного больше прямо здесь, когда мы действительно углубимся в проверку работы. Но я думаю, что это просто такой хороший пример, не связанный с кодированием, это просто создание диаграммы. Но что касается проверки, я на самом деле заставляю его брать диаграмму Excalidraw и рендерить PNG. Так что есть интеграция, которую я построил в навык для облачного кода. Так что он может рендерить ее как изображение. И, как многие из вас знают, облачный код теперь невероятно хорошо понимает изображения. За последний год он стал настолько хорош в >> даже просмотре, знаете ли, как бы я ни увеличивал масштаб здесь, есть довольно много контекста, но он может выделить мельчайшую часть текста на большом изображении, как это. И поэтому я заставляю его смотреть на это >> а затем выяснять, есть ли какие-либо проблемы с отступами или пробелами, как если бы были какие-либо наложения, и поверьте мне, было, ему пришлось итерировать несколько раз, чтобы создать что-то такое большое. Но суть в том, что он способен итерировать сам. Так что нас не особо волнуют первоначальные ошибки, которые он допускает. Пока он делает это сам, нас волнует только последнее, что он передает нам, когда говорит, что закончил. Так что, если у нас есть этот шаг, когда он говорит, что закончил, то, значит, он действительно закончил, или, по крайней мере, близок к этому. Я имею в виду, он все еще, вероятно, не будет идеальным, но вы поняли. Да. >> Да, 100%. Я делал что-то похожее с моим конвейером видеомонтажа с графикой движения, которую он добавляет, и иногда вещи выходили за пределы. Но, как вы сказали, идея в том, что он почти никогда не будет на 100% с первого раза, но без проверок верификации, возможно, это 65 или 70, но теперь вы можете получить что-то, что составляет 92 с первого раза. >> Верно, именно так. Да. Да. Это хорошо. Так что, я имею в виду, проверка, валидация, как бы вы это ни называли, это одна из самых важных вещей, на которых я сейчас сосредоточен для любого приложения или автоматизации, которую я создаю. Я хочу, чтобы у кодирующего агента был какой-то механизм для проверки своей работы, для кода, чтобы проверять свою работу. И для некоторых вещей, вроде дизайна веб-сайтов, это на самом деле довольно просто. Есть много инструментов, возможно, вы слышали о Playwright или Agent Browser от Verscell, чтобы он действительно просто запускал сайт, он может выполнить команду для запуска веб-сайта, а затем он может посетить его так же, как пользователь, делая снимки экрана по пути, чтобы доказать вам что-то, или даже просто просматривать пользовательский интерфейс. Это довольно просто для других видов вещей, которые вы будете строить. Это может быть довольно сложно, чтобы агент действительно эффективно проверял свою работу. Один действительно простой пример, довольно глупый пример. Я в свободное время, я всегда любил видеоигры в детстве, я имею в виду, как я говорил о Scratch. Я имею в виду, я строил вроде Pokemon и Mario Bros и тому подобное. И поэтому я на самом деле немного занимаюсь, пытаясь, я ненавижу это признавать, но "вайб-кодинг" видеоигр, верно? Это просто хобби. Я не пытаюсь сделать что-то слишком сумасшедшее, и это больше похоже на то, чтобы оно работало в фоновом режиме для развлечения. Но одна из вещей, о которых мне пришлось подумать, это как построить механизм для кодирующего агента, чтобы он мог на самом деле играть в видеоигру. Это немного сложнее, потому что они не могут, кодирующие агенты, им нужно время, чтобы подумать, верно? Так что, если у вас есть игра, которая работает со скоростью 60 кадров в секунду, она не сможет реагировать на вещи так, как это сделал бы человек. Так что думая о системе, где она может, по сути, замедлить частоту кадров. Я знаю, что это немного глупый пример, но это просто одна из самых больших вещей, которые вам нужно спроектировать для всего: как агент на самом деле проверит это, как это сделал бы пользователь, потому что просто глядя на код, который он создает, или на навык, который он строит для вас, этого недостаточно, чтобы он просто сделал этот своего рода обзор, высокоуровневый обзор, который хорош, но вам нужно дождаться, пока он действительно использует приложение или что бы вы ни делали, как вы бы это сделали. >> Да, абсолютно. И быстро, для тех, кто, возможно, не слышал термин "хаpness" раньше, каково ваше краткое определение этого? >> Да, нет, это хорошо. Я знаю, что это становится техническим, >> верно? Да. Так что, обычно, когда люди говорят о "хаpness", они говорят о чем-то больше, чем то, о чем я собирался немного поговорить в конце. Так что, когда я говорю о валидации, это больше похоже на, я имею в виду, это своего рода, мне нужно подумать о том, как на самом деле объяснить, что такое "хаpness" на самом деле. Это обертка вокруг большой языковой модели, инструментов и контекста, к которым у нее есть доступ. Так что она знает, над чем работает и как работать эффективно. Так что, если мы думаем о "хаpness" для ИИ-кодирования, облачный код на самом деле является "хаpness", верно? Когда вы скачиваете облачный код и запускаете его, он загружает системный промпт поверх Claude как большой языковой модели. Он дает ей инструменты, чтобы она могла выполнять команды и создавать файлы на вашем компьютере. Это то, что действительно делает ее "хаpness". И когда я приводил пример "хаpness" для тестирования, это больше похоже на предоставление ей системы, где она говорит: "Хорошо, вот команды, которые я могу выполнить, чтобы запустить игру, а затем замедлить частоту кадров, чтобы я мог взаимодействовать с ней кадр за кадром и действительно останавливаться, анализировать и думать, прежде чем предпринять следующее действие". Так что вы можете думать об этом как о, так что, возможно, я просто перейду вперед. Вы можете думать о "хаpness" как о том, что просто оборачивает модель. И затем есть также этот компонент "хаpness", который вы можете создать сами. Я называю это ИИ-слоем. И поэтому для облачного кода это как ваш claw.mmd и ваши навыки, и ваши хуки, и любые серверы MCP, которые вы подключаете для связи с другими платформами, такими как ваша CRM или ваше программное обеспечение для управления задачами, верно? Это построение поверх "хаpness". Так что это своего рода большая языковая модель — это рассуждение. Это мозг в центре, а затем вы выбираете инструмент, такой как облачный код или CodeX, или что-либо еще, а затем вы можете как бы построить контекст и интеграции поверх. >> Абсолютно, мне нравится. Да, хорошо сказано. Я думаю, что что-то забавное, что любой слушатель должен попробовать прямо сейчас, это если вы зайдете к ИИ-модели и попросите ее объяснить ИИ-хаpness или агентский хаpness. Я готов поспорить, что она приведет всю автомобильную аналогию, где двигатель — это ИИ-модель, а автомобиль — это хаpness. Так что дайте мне знать, если вы запустите это и увидите, что это так. >> Звучит хорошо. Я имею в виду, мы могли бы протестировать это прямо сейчас. >> Нет, мы не будем. Нам не нужно делать это прямо сейчас. Но да, это ваше домашнее задание на сегодня. >> Да. >> Да. Да. Круто. >> Да. >> Да. >> Итак, я имею в виду, мы много говорили о валидации. Планирование — это другая вещь, на которой я действительно хочу остановиться, потому что большинство людей не делают этого достаточно. >> И это требует терпения. И это одна из тех дисциплин разработки программного обеспечения, которую я люблю применять, даже когда разговариваю с кем-то, кто не пишет код или кто не является техническим специалистом: вы должны потратить, я имею в виду, с кодирующими агентами вы тратите больше времени на планирование, чем на фактическое создание, потому что вы действительно вкладываете много усилий заранее в план, а затем используете это для делегирования как можно большей части кодирования, или для многих из нас, всего кодирования, ИИ-помощнику по кодированию. И поэтому его успех действительно зависит от того, насколько хорош ваш план. Обычно у вас есть своего рода, многие люди любят использовать Markdown, верно? Я много использую Markdown. Так что у меня будет один документ Markdown, который описывает, знаете ли, цель. Что мы здесь строим? Как выглядит успех? И, конечно, вместе с этим идет стратегия валидации, которую мы уже обсуждали. Так как он узнает, что работа сделана и работает хорошо? И затем, не вдаваясь в технические детали, особенно для любого рода кодирующих задач, у вас будут точки интеграции, верно? Например, если вы строите поверх существующей автоматизации или приложения или веб-сайта, что угодно, какие части кодовой базы мы действительно должны затронуть? И поэтому, если вы более технически подкованы, вы можете как бы оценить, убедиться, что он правильно понимает: "Хорошо, какие файлы мы действительно будем создавать и редактировать здесь?" Не то чтобы вам это было нужно. И затем, когда у вас есть этот план, вот как выглядит мой рабочий процесс. И это для всего. Так что вы загружаете контекст, любые документы, которые нужны вашему агенту, связанные с текущей задачей. А затем я обычно заставляю его проводить некоторое исследование, обычно используя для этого под-агентов. Так что, если я создаю новое приложение, возможно, я заставлю одного под-агента исследовать, какой хороший технологический стек для этого. Какой хороший подход, если есть люди, которые создавали похожие приложения, верно? Так что, особенно если вы не очень технически подкованы, это может быть очень полезно для него, чтобы просто собрать много информации, а затем предложить вам план. И вот тогда вы создаете план с кодирующим агентом. Это также то место, где обычно вы хотите, чтобы кодирующий агент задавал вам много вопросов. Например, я знаю, Нейт, вы только что выпустили видео сегодня о навыке Мэтта Пок "Grill Me", которое очень хорошее. Вам нужно убедиться, что кодирующий агент не предполагает кучу вещей о том, что вы хотите, чтобы он сделал, например, рабочий процесс, который вы хотите построить, навык, который вы хотите построить, что угодно. И поэтому, когда он задает вам много вопросов, уточняет эти вещи, это хорошо. Так что вы можете быть уверены, что когда у вас будет окончательный план, вот что мы собираемся сделать сейчас, что и вы, и кодирующий агент согласны с тем, что будет сделано, и как вы будете это проверять. >> Абсолютно. Да, мне нравится. Когда вы это делаете, вы обычно используете режим планирования в облачном коде, или вы планируете, но не в режиме планирования? >> Да, обычно я не использую режим планирования. Хорошо. Он хорош, но режим планирования переводит облачный код в немного другое поведение, которое я предпочитаю контролировать сам. Так что мой навык планирования — это инструкции о том, как я хочу, чтобы он задавал мне вопросы, и просто в целом, как я хочу заниматься исследованиями и организацией вещей в план. >> Да. >> И поэтому, как я хочу определить разделы. Если вы этого не сделаете, то вы просто используете режим планирования облачного кода. Он построит что-то вроде этого. Но я просто люблю иметь этот более высокий уровень контроля. Я думаю, что это тема, которую вы часто получаете из моего контента в целом: я люблю иметь контроль и настраиваемость, потому что в конце концов именно так вы получаете лучшие результаты. Это своего рода кривая обучения, чтобы добраться до этой точки. Например, я не использую OpenClaw или Hermes. У меня есть свой собственный второй мозг, который буквально построен непосредственно поверх облачного кода. И я большой сторонник этого, даже несмотря на то, что эти другие инструменты с открытым исходным кодом очень мощные, потому что вы запускаете что-то, чего не понимаете, и вам труднее по-настоящему принять это как свое, и это не фундаментальный компонент, на котором вы можете построить свою собственную систему. Так что вы скорее принимаете чужую систему. И эти инструменты проделали действительно хорошую работу, облегчив расширение и действительно создание своего собственного. Но в конце концов, построение чего-то с нуля всегда даст вам наибольший контроль, даже если это может быть довольно пугающим. Да, я понимаю. Да, это интересно. Я имею в виду, это действительно имеет смысл. Я всегда люблю, знаете ли, это то, что я часто говорю, что очень простая теория — это просто быть искренне любопытным, чтобы понять, что происходит, особенно когда я не понимаю, что означают эти строки кода Python, которые он только что написал. И вся идея "темного кода". >> И я, как вы думаете об этой идее, потому что вы много говорите о "вайб-кодинге" и о понимании вещей на их основе? >> Да. >> Как они на самом деле чувствуют себя в безопасности? >> Да, это очень хороший вопрос. Так что >> довольно загруженный тоже. >> Нет, это хорошо. Я приветствую это. Так что я отвечу двумя способами. Сначала я скажу, что, возможно, не всем нравится это слышать, но если вы используете ИИ-помощника по кодированию для написания кода, потому что вы создаете свой второй мозг, вы создаете автоматизацию, что бы это ни было, я бы рекомендовал хотя бы попытаться дойти до точки, где вы можете понять код, и на самом деле сначала это может быть так же просто, как просто попросить облачный код или любого другого кодирующего агента объяснить, что он только что написал, потому что код может выглядеть довольно пугающе, но когда вы преодолеете этот начальный барьер, он читается как английский, и, возможно, это просто я, будучи чрезвычайно невежественным, потому что я жил и дышал этим с восьми лет, но это начинается так, как только вы понимаете основные примитивы, вроде "это класс", "это цикл while", "это оператор if", он начинает читаться как английский, вы думаете: "Хорошо, я понимаю, когда эта часть кода будет выполнена". Просто постоянно спрашивайте своего кодирующего агента. И поэтому, я имею в виду, в облачном коде есть функция "слэш", кстати, так что вы всегда можете просто иметь побочный разговор, где вы говорите: "Эй, помоги мне понять, что здесь происходит". И тогда это не разбавит ваш основной контекст и просто не будет продолжать подбрасывать контекст в облачный код. Вы можете вести этот отдельный разговор для своего собственного понимания, а затем вернуться к основной задаче, не влияя на нее. Так что я бы рекомендовал это. И затем, знаете ли, если кто-то действительно не склонен учиться кодировать, это просто не ваша цель. Вы хотите использовать облачный код для автоматизации вещей и не иметь необходимости проектировать приложения. Я полностью понимаю это. На самом деле все сводится к вашей стратегии валидации, которая будет определять, насколько уверенным вы можете быть в том, что создано. Так что, если вы тратите много времени на это, поэтому я говорю, что всякий раз, когда вы строите что-то с облачным кодом, способ, которым вы не "вайб-кодите", это то, что вы заключаете делегирование кодирования между планированием и процессом валидации, в котором вы активно участвуете. Верно? Единственная причина, по которой я когда-либо скажу: "Хорошо, Клод, займись этим", это потому, что я убедился, что создал действительно подробную спецификацию и определил, как вы сообщите мне, что закончили, и как вы можете быть уверены, что это действительно так. >> Мне нравится. Очень хорошо сказано. Добавить нечего. >> Круто. Хорошо. Да. >> И что касается создания этого плана с кодирующим агентом, самое важное — это управлять контекстом, на что ваш кодирующий агент действительно будет обращать внимание в начале любой сессии планирования. Так что здесь внимание дефицитно. И существует большое заблуждение сейчас у многих людей, где они думают, что на самом деле не имеет значения, сколько вы бросаете кодирующему агенту, потому что все сейчас слышат, как большие языковые модели могут поддерживать до 1 миллиона токенов в своем контексте, когда они говорят: "О, это как пять книг о Гарри Поттере". Я забыл точную, но люди всегда приводят какую-то аналогию, которая делает это довольно очевидным, где это 1 миллион токенов — это безумное количество информации, и это действительно так, но есть два огромных оговорки. Первая — это то, что этот контекст закончится гораздо быстрее, чем вы думаете, потому что если он читает кучу навыков, которые вы для него настроили, или кучу кода, это может быть десятки сотен тысяч токенов очень быстро, а затем другая вещь — у больших языковых моделей есть так называемая "зона глупости". И поэтому у вас есть начальная часть разговора до первых, скажем, 100 или 200 000 токенов, где большая языковая модель чувствует себя очень остро, или, по крайней мере, чувствует себя на пике своих возможностей. Как только разговор превышает эти первые 100-200 000 токенов, очевидно, это зависит от модели, когда вы достигаете зоны глупости, вы доходите до точки, где она просто чувствует себя перегруженной информацией и начинает пропускать вещи и делать ошибки, которые кажутся вам такими очевидными, или вроде того, где вы думаете: "Если бы у меня был свежий контекст здесь, я бы никогда не допустил такой ошибки". Она пишет действительно плохую строку кода или не использует навык, который, как вы думали, она должна была знать. Верно? Такой тип вещей, если это происходит в середине более крупного рабочего процесса. >> И поэтому я говорю, что внимание дефицитно. Не поддавайтесь ложному представлению о том, что вам не нужно заботиться о том, сколько вы ей даете. Если вы пытаетесь заставить ее обрабатывать более крупный рабочий процесс, вы все равно должны быть очень осторожны с тем, что вы даете ей заранее, по сравнению с тем, что вы позволяете ей обнаружить, когда ей это действительно нужно. И это одна из самых важных вещей с навыками в Claude: вы даете ей процедуры и лучшие практики, но она решает, хорошо, теперь мне нужно полагаться на этот процесс или эту информацию. Так что вы не просто вываливаете кучу вещей заранее. Многие люди так делают. Даже с серверами MCP в прошлом, они подключали свои, скажем, 20 серверов MCP к облачному коду, и каждый из них заполнял контекст примерно 20 000 токенов информации заранее, потому что у него есть все вызовы инструментов или инструменты, которые поставляются с сервером MCP. И поэтому их большая языковая модель всегда действовала очень глупо. И поэтому они говорят: "Я использую последнюю версию Opus. Почему я получаю ужасные результаты?" И на самом деле это сводится к тому, сколько контекста заполнено сразу. Да. О боже. Это сводит меня с ума. Это действительно сводит меня с ума, когда вы слышите, как люди обвиняют модель, когда на самом деле это проблема навыков. И мы видим это, когда вы смотрите на эти исследования и опросы о внедрении в бизнес, где на самом деле эти люди либо еще не почувствовали ROI, потому что они не знают достаточно о том, как им действительно пользоваться, верно? А также люди, утверждающие, что у них есть навыки, но они просто не делают этого. И внедрение — это еще одна проблема. Но, очевидно, я не занимаюсь тяжелым кодированием, созданием программного обеспечения и приложений. Но, знаете ли, мы делаем довольно крутые вещи, и я видел, как некоторые люди делают действительно потрясающие вещи, и это просто >> да, >> есть много вещей, знаете ли, если вы немного подумаете о вашей диаграмме, у вас есть модель в центре, у вас есть хаpness агента вокруг этого, а затем, очевидно, огромный слой — это то, что вы туда поместили, а также то, как вы управляете своими вещами. И я думаю, что 1 миллион контекстных окон, особенно для, скажем, Opus 4.8 на данный момент. Очевидно, это здорово, но это определенно дает ложное чувство безопасности людям, которые теперь думают, что у них есть миллион, но когда, и я знаю, что это может устареть через месяц или два, но давайте скажем, что сейчас, когда вы находитесь в облачном коде, >> когда вы обычно >> делаете свой компакт или сессию, передачу и очистку, и когда вы выходите из нее? Да. Итак, с Opus сейчас это обычно около 250 000 токенов, и я чувствую, что он попадает в зону глупости. >> Это мой точный номер тоже. >> О, правда? Хорошо. Да. Да. Хорошо. Так что, и это, кстати, очень субъективно. Я не собираюсь ставить миллион долларов на то, что Борис Черни или кто-то еще скажет: "Да, это тоже 250 000". >> Четверть миллиона — это просто чисто, верно? >> Да. Это просто звучит хорошо, и это довольно точно. Я бы сказал, что Opus 4.7 был около 200 000, а затем Sonnet 4.6 — это, честно говоря, вероятно, только около 100 125 000. По мере того, как вы переходите к этим меньшим моделям, зона глупости становится довольно небольшим объемом контекста по сравнению с тем, что она теоретически может обрабатывать. Вы просто никогда не хотите доходить до этой точки. Так что с зоной глупости я также слышал о том, что модель очень хорошо запоминает вещи, которые находятся в начале и в самом конце, а в середине она теряет. Так где это вписывается в разговор о зоне глупости? >> Да. Так что, по сути, эта проблема просто усиливается, чем больше вы попадаете в зону глупости. Да. И, да, что касается, я имею в виду, нам не нужно вдаваться в технические детали того, как работает механизм внимания для LLM, но да, вы можете думать, я имею в виду, аналогия, которую я всегда использую, это проблема "иголки в стоге сена". Да, >> как если бы у вас была эта маленькая часть информации, которую вы хотите, чтобы агент запомнил посреди огромного разговора, это как искать иголку в стоге сена. Вы не можете ожидать, что модель просто из-за того, как спроектированы большие языковые модели. Вы не можете ожидать, что она всегда сможет вычленить эту маленькую часть информации. >> 100%. Да. >> Да. Я бы хотел, чтобы могла. Было бы приятно, если бы не было такой вещи, как зона глупости. Это сделало бы гораздо удобнее для нас передавать ей огромные задачи и позволять ей просто работать. Но большая часть причин, по которым нам приходится создавать хаpness, и многие вещи, на которых я сейчас сосредоточен на своем канале и в целом, что я строю, это создание хаpness, которые строят рабочий процесс, который может связывать несколько сессий кодирующих агентов вместе. И поэтому, по сути, это как одна модель выполняет планирование, а затем мой оркестратор автоматически берет этот документ передачи, план, а затем передает его другому агенту для реализации. И когда реализация завершена, он создаст отчет об исполнении, а затем передаст его следующему агенту для проверки и проведения обзора кода. И это может показаться, что это много инженерии, и это так, но это очень необходимо сейчас, потому что если вы пытаетесь выполнять какую-либо реальную работу для программного обеспечения производственного уровня или создавать автоматизацию, которая имеет решающее значение для вашего бизнеса, вы не можете просто бросить все это на одну сессию облачного кода, если вы не можете уверенно построить это в этой зоне, прежде чем попасть в зону глупости. И в большинстве случаев вы просто не можете этого сделать, или, по крайней мере, вы не можете действительно доверять тому, что это будет так, потому что вы никогда не знаете, сколько раз вам придется итерировать что-то. И >> поэтому я действительно, я думаю, можно сказать, оптимистичен сейчас в отношении инженерии хаpness, которая заключается в создании рабочего процесса, который оркестрирует множество сессий кодирующих агентов для обработки более крупной задачи. И действительно простой пример такого хаpness — это цикл Ральфа. Он стал супер вирусным в начале этого года. Так что, я думаю, даже если вы не так много слышали об инженерии хаpness, вы, вероятно, по крайней мере слышали о цикле Ральфа. И это действительно основа такого рода хаpness, верно? Цикл Ральфа — это объединение нескольких сессий кодирующих агентов. Я бы хотел, чтобы у меня сейчас была одна из моих диаграмм для этого. Я просто объясню это устно, но, знаете ли, у вас есть первая сессия облачного кода, которая читает вашу более крупную спецификацию для более крупной автоматизации, которую вы хотите построить, а затем она определит список задач, первая фаза — это это, вторая фаза — это это, а затем у нее будет много кодирующих агентов, обрабатывающих одну фазу.
за раз, но это будет как бы делать все автоматически в цикле. Вот почему это называется петлей Ральфа, потому что, скажем, агент один выполняет фазу один, а затем пишет свой маленький отчет, как бы передавая его второму агенту, который продолжит работу. И главная причина, по которой петля Ральфа имеет значение, заключается в том, что вы не можете позволить одному агенту справиться с этой большой задачей, не попав в "тупую зону", и, знаете, на полпути к фазе два, верно? Вам нужно разбивать вещи. >> Да. Итак, кажется, с высоты птичьего полета идея или, своего рода, образ мышления заключается в том, что у вас есть сборочная линия, и у вас есть агент, который что-то делает. Каждый агент как бы делает одно дело очень хорошо и передает свой ввод следующему агенту таким образом, чтобы >> агент имел достаточно контекста, чтобы понять, что было сделано, что осталось сделать и какова его текущая задача. >> Да, именно так. Да, сборочная линия — это очень хорошая аналогия, и, я имею в виду, это применимо к гораздо большему, чем просто написание кода. Например, один пример, который приходит на ум, когда я думаю о том, как я много говорю о кодировании как о примере для многих вещей, но я работаю со многими компаниями, которые находятся как бы на стороне B2B. И когда вы работаете в B2B, вы много занимаетесь составлением предложений, например, смет, верно? Например, у вас есть строительная компания или, например, я работал с компаниями в полиграфической отрасли, где у них есть запрос типа: "Хорошо, сделайте мне, например, 100 000 листовок или что-то в этом роде", и для этих компаний одна из самых больших возможностей для использования ИИ — это использовать что-то вроде Claude, чтобы помочь им принять запрос и автоматически создать смету, например, предложение о том, сколько будет стоить эта работа, >> потому что это действительно, действительно трудоемкая работа, больше, чем вы думаете. Когда я разговаривал с этими компаниями, это безумие, сколько работы в это вложено, потому что им приходится принимать запрос, и им нужно понять, сколько труда уходит на, знаете ли, детали, очевидно, в зависимости от отрасли, а затем им приходится исследовать последние цены на вещи и убеждаться, что они получают их от правильного поставщика. В это вложено так много, и поэтому такая вещь, это действительно хороший пример, ничего общего с созданием кода, все еще используя что-то вроде кода Claude. Вы можете использовать агентов по кодированию для этого, чтобы пройти через этот большой рабочий процесс, например, просматривая их инвентарь, просматривая цены, сравнивая поставщиков, >> все на основе того, что потребуется для выполнения этой задачи, например, этого ремонта, этих 100 000 листовок, для любого запроса от другой компании, а затем создавая эту смету и понимая, как работает компания, например, какой наценки они хотят сверху, исходя из труда и стоимости деталей или чего-либо еще. В это вложено много. И поэтому такая вещь, где вы создаете рабочий процесс, где у вас есть один агент, который будет исследовать инвентарь, один агент, который будет смотреть на цены и сравнивать цены на детали, а затем один агент, который будет составлять PDF-файл, а затем, возможно, еще один, который сделает его красивым. Я имею в виду, я немного растягиваю пример, но вы понимаете идею, что вы на самом деле не имеете только одного агента, который справляется со всем этим для чего-то такого большого. И вы собираетесь много планировать, верно? Вы собираетесь планировать, у вас будет проверка в конце, какие расчеты я могу сделать в конце, чтобы убедиться, что, например, эта работа имеет желаемую прибыль, например. >> Да. Да. И я думаю, я вспоминаю одну из наших самых больших неудач, когда я еще занимался повседневной работой в агентстве, это был именно этот случай, когда приходилось просматривать тонны и тонны примеров, прошлых предложений, прошлых работ клиентов, прошлых предложений, и приходилось генерировать эти предложения с таким количеством различных факторов, которые в них входят. И это была одна из наших самых больших неудач, потому что я лично недооценил эту сборку. И мы начали, не осознавая, сколько на самом деле необходимо для получения точного предложения. Так что это был отличный урок для меня, чтобы узнать не только о важности задавать достаточно вопросов и планировать, но и >> о том, как вы разделяете работу. И я думаю, очевидно, Коул упомянул, что он говорил о многих таких примерах, связанных с кодированием, но я на самом деле не занимаюсь кодированием. Я имею в виду, в конце концов, эти автоматизации — это код. Так что да, это кодирование. Да. Но >> я не занимаюсь >> программным обеспечением. Я не создаю продукты, но каждая из этих теорий, о которых мы говорили, и эти умы и структуры напрямую применимы к работе со знаниями, как я люблю это называть, того, что я делаю изо дня в день, и того, что, вероятно, большинству из вас нужно делать. Это дает вам невероятное преимущество сразу же в коде Claude. И я думаю, что >> когда вы думаете о своей работе или думаете о некоторых своих обязанностях, это не просто одна обязанность. Это так. Вы можете разбить это на столько мелких подзадач, как Коул только что сказал: один агент занимается исследованиями, один агент занимается генерацией PDF, все эти маленькие цепочки подзадач, которые сходятся вместе, чтобы фактически выполнить общую обязанность, которая может состоять из 10 маленьких задач, которые связаны вместе. Поэтому, когда вы можете фактически разбить процесс, просто записав его или, знаете ли, нарисовав его на листе бумаги, >> это делает вещи намного яснее, >> верно? Да. Да. И одна вещь, которую я хочу сказать здесь, это то, что многие люди хотят упростить это до использования только под-агентов. Так, для этого большого рабочего процесса, что, если я просто заставлю свой основной код Claude раздать кучу задач под-агентам? Это может работать для некоторых вещей. Мне нравится использовать под-агентов, особенно когда я изначально планирую любую автоматизацию или приложение, но трудно заставить их хорошо общаться друг с другом. Как мы много говорили о передаче работы здесь. Часто один агент, когда он делает следующий шаг в рабочем процессе, должен понимать работу, проделанную предыдущим, будь то работа, фактически написание кода, или это просто исследование, или это извлечение информации из вашей CRM, например, у него должен быть этот документ о передаче, и очень трудно сделать это хорошо с под-агентами. Claude попробовал свои силы в чем-то с командами агентов, так что они, это как бы шаг выше под-агентов, где они действительно могут общаться друг с другом, но это очень необработанно. Это очень хорошая идея, но она очень необработанная и очень дорогая, как бы, много токенов. >> Да. >> И так, да, и это именно то, над чем я работаю. Есть проект с открытым исходным кодом, над которым я работаю, под названием Archon, и он действительно решает проблему, как мы можем более, слово, которое я использую, детерминированно, как мы можем построить модель ИИ, построить код Claude в систему, вместо того, чтобы код Claude пытался оркестрировать все, потому что тогда становится трудно для связи, и все становится очень много токенов, верно? Так что, как я люблю это выражать, мы хотим выбирать, когда модель ИИ работает в рабочем процессе, вместо того, чтобы она управляла всем этим. >> Мм. Да. Да. Как сделать такую автономную недетерминированную систему максимально детерминированной? >> В основном. Да. Да. Максимально детерминированной. Я бы хотел сказать, сделать ее детерминированной, но это никогда не произойдет. К сожалению, это фундаментально невозможно. >> Да. >> Мне нравится. Да. Полностью согласен с вами. >> Круто. Да. Ну, я имею в виду, на самом деле мы обсудили большинство других вещей, которые у меня есть на диаграмме. Мы говорили о проверке, убедившись, что она может проверять свою работу, и, да, я имею в виду, что главное здесь — нам действительно не важно, что она делает на первом проходе. Если мы построим систему, где она сможет итерировать, это все, что нам действительно важно, если это не займет миллиарды токенов, чтобы добраться до финальной стадии. Но когда я использую код Claude для чего-то, я никогда не оптимизирую скорость. Я имею в виду, по крайней мере, я не хочу, чтобы это было нереалистично медленно, но любую задачу, которую я ставлю перед ней, мне неважно, если это что-то, над чем мне придется работать полчаса или полтора часа. Я отправлю этот запрос, а затем перейду к другой сессии Claude для всего остального, что мне нужно сделать, или я сделаю что-то, как бы это ни звучало, без агента на некоторое время, если мне нужно записать видео. Ну, я имею в виду, возможно, я использую агента в видео, но вы поняли. Но в любом случае, суть в том, что мне неважно, сколько времени это займет, потому что меня волнуют только наилучшие возможные результаты. >> И поэтому, да, вот почему я трачу много времени на разработку систем для агентов по кодированию, чтобы они могли проверять свою работу, будь то автоматизация браузера для веб-сайта или глупый пример, который я привел ранее, способ для нее как бы играть в видеоигру, как человек. И это очень увлекательная проблема для меня сейчас. Это просто этот уровень проверки в конце для агента по кодированию, который также распространяется на такие вещи, как безопасность. И поэтому это не так интересно обсуждать сейчас, но безопасность довольно важна для меня. Это то, на чем программисты vibe получают очень сильные ожоги. Я имею в виду, вы слышите эти ужасные истории, по крайней мере, раз в месяц >> о том, как их супербаза, приватный или секретный ключ утекает в их JavaScript-файлы и тому подобное, потому что они просто полностью программируют vibe. Я имею в виду, это самый простой пример, но да, такая часть проверки также очень важна. >> Да. И по этому поводу безопасности и >> что может пойти не так, когда вы думаете о своего рода уровне разрешений, который вы ставите вокруг своих агентов. Я вижу много ложного чувства безопасности, когда люди думают, что их запросы — это достаточно хороший уровень разрешений, когда на самом деле этот уровень разрешений должен быть >> ограниченными ключами или вы действительно не можете ничего трогать, потому что я думаю, я говорил со своей командой, и >> мы пришли к такому выводу, что >> если у вас есть образ мышления, что >> все, что агент может читать или трогать, он будет делать, даже если вы никогда не просите его об этом. Это предположение спасет вас от удаления вашей базы данных. >> Да. И это забавно, что вы приводите этот пример конкретно, потому что я как раз собирался сказать, что если вы скажете ему никогда не удалять базу данных, он все равно сделает это. >> Мм. >> Например, история, которая стала вирусной, примерно месяц или два назад, о ком-то очень высокопоставленном в Meta, у кого была база данных. Я до сих пор не уверен, что это правда. Мне кажется, они могли бы быть, я не знаю, потому что люди получают так много внимания, когда у них есть такие глупые истории. Но в любом случае, >> теории заговора с Коулом, >> верно? Да. Но это определенно возможно, и я знаю некоторые истории о том, что это действительно произошло, просто в меньшем масштабе. >> Это кажется таким странным, или звучит так глупо, что их реальная производственная база данных была стерта. Но я имею в виду, даже если ваша тестовая база данных будет стерта, это все равно может быть неприятно, если это сильно замедлит вас. И поэтому, да, это очень важно. Вы никогда не должны предполагать, что только потому, что вы сказали агенту не делать что-то, он никогда этого не сделает. Я имею в виду, это то же самое, если вы говорите ребенку не делать что-то, он может просто не слушать. Я имею в виду, даже взрослые. >> На самом деле недавно с нами произошло что-то, что, возможно, стало причиной нашего разговора об этом. >> Хорошо. >> У нас был такой инцидент, когда у агента были благие намерения. Он пытался быть проактивным, и он фактически увидел что-то в своем списке задач, но неправильно истолковал это >> и в итоге отправил электронное письмо всему нашему списку >> со скидочным кодом, и это не должно было быть отправлено. Так что нам пришлось изменить код, обновить страницу, мы отправили извинения по электронной почте. Так что, если вы находитесь в списке рассылки и получили это, вот что произошло. Но это просто, знаете ли, я не злился на человека, который был как бы ответственен за агента. Это была просто отличная возможность для нас подумать: хорошо, почему это произошло? >> И, знаете ли, она написала исследование. Мы отправили его всей команде, и все сказали: хорошо, это очень, очень хорошее напоминание о том, насколько осторожными нужно быть. Потому что, знаете ли, если вы подключаетесь к серверу MCP и не ограничиваете разрешения, у него есть все, знаете ли. Да. Да. Это хорошо. Да. Основной способ, которым я ограничиваю действия моего агента по кодированию, — это с помощью хуков. >> Так, например, хуки Claude — это очень хороший способ, потому что, по сути, хук в Claude — это небольшой фрагмент кода, который вы можете запускать, когда происходит определенное событие в инструменте. Так, когда вы начинаете сессию, когда вы заканчиваете сессию, прямо перед тем, как Claude использует инструмент, вы можете запустить какой-то код, который выполняет проверку безопасности. Я имею в виду, есть много других вещей, но мне нравится использовать хуки для безопасности. И поэтому, что вы можете сделать в Claude, это каждый раз, когда он собирается вызвать инструмент, например, он хочет записать в файл или сделать какой-то запрос в веб, вы можете проверить эту команду, чтобы убедиться, что она не пытается копаться в папке, которую вы не хотите, чтобы она трогала, или запускать какую-то команду, которую вы не хотите, чтобы она запускала. И есть много разных способов проверить это, в которые мы не должны вдаваться сейчас. Но это один из моих любимых способов убедиться, что он не читает мои переменные среды или не запускает команду удаления для базы данных. >> И очень трудно убедиться, что вы покрываете все лазейки, потому что есть много вещей, которые агенты по кодированию могут сделать, чтобы обойти эти проверки. >> Да. >> Чтобы обойти эти проверки, тоже. У многих людей есть ложное чувство безопасности вокруг этого. Так что у вас есть этот первый ложный смысл безопасности, когда это как бы: ну, я сказал ему никогда не удалять мою базу данных. А затем у вас есть второй уровень, когда это как бы: я блокирую все команды SQL на удаление. Но затем есть третий уровень, который вы должны убедиться, что вы проектируете, например, для агента по кодированию. Если вы не позволяете ему вызывать команду удаления, например, команду удаления для удаления папки, он все равно может написать скрипт для этого. Так что ему просто нужно сделать двухшаговый процесс: написать скрипт, а затем запустить скрипт, и тогда он все еще сможет удалить файл или папку на вашем компьютере. Так что это, я имею в виду, они менее склонны делать это. Так что вы все равно продвигаетесь, если у вас есть хотя бы этот второй ложный смысл безопасности, но вы должны быть очень осторожны. Вы должны, это на самом деле сложная проблема для решения. >> Да, чувак. ИИИ — это страшно. >> Да. >> Но я хотел бы увидеть, и, возможно, у вас уже есть, но я хотел бы увидеть мастер-класс по хукам от Коула, потому что я на самом деле только что записал один. >> И я не так уж часто использую хуки, честно говоря. Я действительно не использую. Я думаю, мой основной хук — это просто уведомление звуком, когда он закончил или когда он нуждается во мне. Но да, я определенно недоиспользовал хуки. И я не уверен, связано ли это с тем, что они в основном ценны, когда вы занимаетесь тяжелым кодированием, но >> я предполагаю, что есть много вещей, которые я мог бы делать в своей повседневной работе, где хуки были бы действительно хороши, и мне определенно нужно немного больше изучить, как я могу их использовать. Но в любом случае, >> да. Да. Я определенно должен сделать мастер-класс по хукам, потому что я использую их многими способами. >> Да, поскольку мы на этой теме, один из действительно интересных способов использования хуков — это то, что вы можете использовать их для автоматического предложения, например, вы можете заставить Claude автоматически предлагать способы улучшения вашего ИИ-слоя, улучшения ваших правил, улучшения ваших навыков. И многие инструменты, такие как Hermes и OpenClaw, делают это. Я не думаю, что они явно используют хуки, но, например, OpenClaw каждые 10-20 ходов, я думаю, это настраивается, он как бы сжимает ваш разговор и сохраняет его как память, верно? Так что у вас есть весь, как бы, ежедневный журнал с файлом memory.md. Все это происходит из того, что, по сути, является хуком Claude. Так, с тем, как я использую Claude со своим вторым мозгом, >> каждый раз, когда у меня происходит сжатие памяти, которое я стараюсь избегать, я не хочу заходить так далеко в разговор, или я заканчиваю сессию, он автоматически создает сводку разговора, помещает ее в ежедневный журнал, а затем у меня есть процесс каждый день. Это, по сути, как бы, Claude мечтает, что он будет смотреть на ежедневный журнал, а затем извлекать любые действительно важные вещи для хранения и как бы продвигать их в мой основной файл памяти. Например, вот решения, которые я принял недавно, или вещи, над которыми я активно работаю, и где я нахожусь с ними. >> Так что, по сути, хуки управляют всем этим. Этот терминал, который, это уже второй раз, когда он появляется. >> Это на самом деле хук, который только что сработал. Так что я просто тестирую другие вещи. Я забыл его отключить, что, к сожалению, но на самом деле теперь это хорошая иллюстрация. У меня был хук, который сработал, пока я говорю о нем. Я просто тестирую что-то другое прямо сейчас. >> Да. Просто еще один способ сделать эти недетерминированные вещи максимально детерминированными. Итак, что у нас дальше после этого раздела проверки работы? >> Да. Да. Так что, на самом деле, это последнее. Так что мы уже говорили о "харнесе", но последнее и, честно говоря, вероятно, самое важное — это эволюция системы, о которой я говорил немного раньше. И на самом деле образ мышления здесь заключается в том, что, вот что делает вас действительно направляющим Claude, а не просто пользователем его, построение системы — это самое важное. Поэтому всякий раз, когда возникает проблема, вместо того, чтобы просто исправить проблему и двигаться дальше, это возможность для вас с помощью агента по кодированию, с помощью Claude, выяснить, что мы можем улучшить, чтобы это не повторилось. Возможно, есть новое правило, которое мы можем добавить в наш claw.md, или есть новый документ, который мы можем дать ему во время нашего планирования, или, возможно, есть обновление нашего навыка, которое мы могли бы сделать. И я намеренно говорю обобщенно, потому что есть миллион разных способов улучшить нашу систему. И поэтому это своего рода пример, который вы привели, Нейт, когда у вас было электронное письмо, которое было отправлено, или, по крайней мере, оно было отправлено гораздо большему количеству людей, чем должно было. И поэтому вы написали отчет о том, что произошло. Что мы можем сделать лучше. И поэтому это своего рода то же самое, но как бы для агента, чтобы в будущем у него было это правило, чтобы он больше не делал этого. Например, возможно, он не выполнил всю необходимую вам проверку. Так что теперь вы просто убедитесь, что это часть правила, где это как бы: убедитесь, что вы не забываете эту проверку, как бы, в качестве глупого примера, но таким образом каждая ошибка становится постоянным улучшением. Поэтому, как только у вас появится такая система, вы фактически почти приветствуете ошибки. Я хочу, чтобы что-то пошло не так, потому что тогда я могу убедиться, что это никогда не повторится >> верно? Я почти чувствую себя немного нервным, когда все идет слишком хорошо, потому что тогда это как бы: о черт, у меня нет способа улучшить своего агента прямо сейчас. Так что это может стать приятным. >> Да. Абсолютно. >> Да. Просто становиться лучше со временем. У меня есть интересный вопрос для вас. Так что >> я полностью согласен. Каждый раз, когда у вас происходит сбой, вы должны рассматривать это как данные и возможность улучшить систему. >> Теперь, что насчет того, до того, как вы получите эти сбои? Как вы думаете, как вы можете, насколько это возможно, найти эти крайние случаи или предсказать, какие крайние случаи могут произойти, и попытаться построить защитные механизмы до >> части тестирования? Ну, это никогда не может быть идеально, поэтому я так сильно на это полагаюсь. Но в целом, когда вы ищете крайние случаи, я имею в виду, Claude на самом деле довольно хорош в этом. >> Он не охватит почти все крайние случаи, но даже просто спросить его, как это может пойти не так, — это вопрос, который иногда люди, честно говоря, боятся даже задать, но это очень хороший вопрос, когда вы закончили реализацию. И это часть моего навыка обзора кода, который я встроил, где это как бы: спросите себя, что может пойти не так здесь, а затем попытайтесь создать сценарий, где вы действительно тестируете это. Например, если я создаю автоматизацию, где, по моему мнению, может быть крайний случай, когда она не обрабатывает этот тип ввода правильно, я, как часть обзора кода моего агента, заставлю его создать это, как бы, он вызовет приложение с этим вводом, как вебхук или что-то еще, и попытается сломать его и посмотреть, что произойдет. И тогда, если он сломается, ну, это, очевидно, вернется к части нашей проверки, где >> он затем устранит эту проблему, а затем снова проведет тесты, верно? Итерируйте, как вы находите проблему, исправляете ее, а затем также повторно тестируете, не забывайте повторно тестировать, потому что, возможно, ваш исправление на самом деле не решает проблему. >> Мм. Да. Ну, я думаю, знаете ли, что-то, что я понял после ответа на комментарии YouTube, Q&A в сообществе, общения с вами и просто наблюдения за тем, что происходит, когда люди изучают такие инструменты, это то, что вы действительно, знаете ли, простейшим способом описать это, вы просто должны относиться к нему как к своему лучшему другу, который является самым умным человеком в мире. Имея в виду, вы относитесь к нему как к наставнику. Он не будет смеяться над вами, если вы спросите его что-то глупое. Вам просто нужно быть любопытным, и вам нужно задавать >> задавать вопросы, которые вы задаете себе. И я думаю, когда вы преодолеете эту идею, что он может научить вас чему угодно, и он может, по большей части, особенно если вы спросите его правильно, он может помочь вам решить большинство ваших проблем, когда у вас есть, знаете ли, это чувство беспокойства, потому что, возможно, вы не понимаете, что он сделал. Так что это огромный сдвиг в мышлении для всех, с кем я говорил, кто пытается начать и не понимает этого. Если они, знаете ли, возможно, они отправят мне текстовое сообщение с вопросом или зададут вопрос. Это просто как бы, ответ часто может быть: "Вы уже спрашивали Claude code об этом?" >> Я знаю. Да. Мне жаль это говорить, но да, это часто доходит до этого. >> Да. Где это как бы: нет, вы должны были просто обычно, как я могу быть более полезным, это сказать им, что именно спросить, например, дать ему эту ссылку, дать ему то, а затем вот как бы я спросил. Но да, часто это сводится к этому. И я имею в виду, вы не можете просто спрашивать Claude обо всем из-за, как бы, психического трюка, который вы упомянули ранее. Иногда, если вы спрашиваете его мнение, спрашивать большую языковую модель о ее мнении — это очень скользкий путь. >> Да. >> Но, но то, что мы можем спросить его, это понять, как что-то работает. Вот когда он может сделать действительно хорошую работу. Так что, возвращаясь к примеру ранее, если вы не технический специалист, но хотите попытаться понять автоматизации и вещи, которые он создает для вас, это действительно хорошая вещь, которую стоит спросить, потому что там нет никакого психического трюка, верно? Он не просто пытается угодить вам. Он просто помогает вам понять. Способ угодить вам — объяснить вещь, верно? >> Итак, это действительно хороший случай, просто пытаться понять что-либо. И тогда, как мы только что говорили здесь о проверке, пытаться найти крайние случаи. Если есть что-то, где есть фактические эмпирические данные, где есть способ проверить, что эта автоматизация не обрабатывает этот ввод хорошо. Я имею в виду, там нет места для психического трюка. Это как бы, он либо работает, либо нет, и на самом деле нет никакой серой зоны или мнения. >> Так что, если вы думаете, что может быть крайний случай, или он думает, что может быть, он может протестировать его, и тогда это черное или белое. >> Верно. >> Так что я хочу услышать, что вы думаете об этом, потому что вы кратко упомянули агентские команды ранее, и >> я на самом деле нахожу, что использую их довольно много для одного конкретного случая использования, и я хочу услышать, что вы думаете об этом. Так что на самом деле время, когда я обращаюсь к командам агентов, это когда >> я пытаюсь помочь, знаете ли, я пытаюсь что-то решить, но я не хочу просто спрашивать мнение Claude code, как вы только что сказали. >> Да. >> И поэтому я часто делаю так, что я запускаю своего рода панель дебатов или своего рода комнату для совещаний. >> Приятно. >> И я говорю, знаете ли, один из вас — генеральный директор, один — новичок, один — студент колледжа, и просто куча разных персон, иногда даже семь. И я просто заставлю их всех провести независимое исследование, сформировать свое собственное мнение, а затем я заставлю их дебатировать. >> И тогда я просто смогу прочитать дебаты, и я смогу иногда сказать: "Продолжайте дебаты, пока вы все не придете к какому-то консенсусу". >> Но я делаю это довольно часто. И это не значит, что я делаю все, что выдает команда агентов. >> Но иногда это просто очень здорово для меня прочитать все эти мнения. Но я хочу увидеть, вам это нравится? Вы думаете, это серьезный недостаток? Какие у вас мысли по этому поводу? >> Мне это действительно нравится. Я никогда этого не делал. >> Вы никогда этого не делали? Вам определенно стоит попробовать. Сегодня вечером я буквально должен попробовать это. Это очень весело. >> Да. Мне очень нравится эта идея, потому что я экспериментировал с чем-то похожим. Я называю это "враждебной разработкой", где, по сути, после того, как Claude code закончит сборку чего-то, у меня будет отдельная сессия Claude code, где я заставляю ее играть роль адвоката дьявола. Я хочу, чтобы вы были злы на другую сессию Claude code, чтобы действительно убедиться, что она не просто радуется, когда есть некоторые проблемы, которые нужно выявить. >> И это работает очень хорошо. Так что в целом, противопоставление больших языковых моделей друг другу — это хорошая идея. >> Я хотел бы попробовать это раньше. Так что, да, я попробую. Я думаю, что это действительно хорошее применение для команд агентов, потому что в этот момент вы не полагаетесь на то, что они получат идеальный ответ. Они очень много токенов, и связь никогда не бывает идеальной. Поэтому я не очень рекомендую команды агентов, когда вы пытаетесь заниматься глубокой разработкой или строить какие-либо сложные автоматизации. Но когда это больше похоже на исследования и просто формирование консенсуса, я думаю, что это будет очень хорошо для этого. Я попробую. >> Круто. Да. Дайте мне знать, если попробуете и что думаете. Но я никогда >> не говорил об этом и не снимал видео, потому что я знаю, что люди будут делать это, а затем скажут: "Вы только что убили мой 5-часовой лимит". >> Верно. Да. К сожалению. >> Так что, >> сколько вашего лимита это использует, когда вы обычно это делаете? >> Я имею в виду, на плане за 200 долларов в месяц от 4% до 10%, иногда. Знаете ли, >> это не так уж плохо. >> Это не так уж плохо. Но, знаете ли, если вы скажете что-то вроде >> не останавливайтесь, пока все не согласятся, и они просто продолжают идти, тогда вы можете столкнуться с некоторыми проблемами. Но >> чтобы закончить здесь, я должен спросить, >> я только что снял видео о моих любимых функциях в Claude Code. И я предварял все это видео и, по сути, сказал, что это не список лучших функций или, знаете ли, самых используемых или самых полезных. Это, по сути, то, как я использую Claude Code изо дня в день, те, которые мне больше всего нравятся. И у меня был нумерованный список из 12 вверху. Но я хотел бы услышать от вас, чтобы поставить вас в неловкое положение. Если бы у вас был топ-3, основанный на том, что я предполагаю, что мы используем очень по-разному. >> Что бы вы сказали, что являются вашими тремя любимыми? >> Да. Так что, хуки — это определенно, может быть, не мой самый любимый, но, вероятно, тот, который большинство людей не поставили бы в свой топ-3. >> И это из-за того, что я делаю с ним для безопасности, а затем вся интеграция со вторым мозгом. Так что он способен, по сути, извлекать сводки и запоминать вещи со временем. >> Нам определенно нужно видео о хуках от Коула. Да, честно говоря, я должен сделать это на следующей неделе. >> Да, нам определенно нужно. >> Да. Хорошо. Да, спасибо, Нейт. Да, так что, да, хуки. Хуки — это определенно номер один. >> Хорошо. >> А затем, потому что я упомянул некоторые вещи здесь, я имею в виду, на самом деле, когда я, есть как бы два разных типа функций Claude Code. У вас есть компоненты ИИ-слоя, такие как правила, навыки, хуки, а затем у вас есть просто общие возможности "харнеса", такие как команды агентов и / кстати, и диспетчер, динамические рабочие процессы, такие вещи, верно? Это либо то, что вы используете, либо то, что вы строите поверх. >> Под-агенты были бы, вероятно, номером два, >> просто потому, что, как я сказал, есть опасности использования под-агентов, но просто использование их для развертывания и исследования множества различных вещей. Я использую это для этого все время, и особенно когда я работаю над более сложными кодовыми базами или строю более крупные автоматизации, я использую под-агентов, чтобы, по сути, извлекать контекст из определенных частей моей системы, верно? Например, вы отвечаете за получение обоснования здесь, как мы будем работать с фронтендом в этом приложении? Как мы будем работать с бэкендом? >> А затем, честно говоря, вероятно, мой номер один. Так что, я думаю, хуки были бы два, а под-агенты — три. Вероятно, мой номер один — это навыки. Хотя это очень, очень клише, >> Да. Это должно быть навыки. >> Это просто лучшее. Да. >> Да. Например, навыки. Навыки диктуют все. У меня есть навык создания этой диаграммы. У меня есть навык написания сценариев для моих YouTube-видео. У меня есть навык создания PowerPoint. >> У меня есть навык >> >> Я имею в виду, вы буквально можете сделать >> так универсально. Да. >> Да. Это просто любой повторно используемый запрос, вы просто делаете его как навык. >> Мм. И Claude хорошо развивает то, как вы можете параметризовать вещи, например, у них есть, например, навыки с областью действия пути, и вы можете установить, вызывается ли он только вами, или агент также может решить это сделать. >> А затем, говоря о проверке, возвращаясь сюда, имея этот навык автоматизации браузера, чтобы он знал, как использовать CLI. >> Это совершенно другая вещь — это комбинация навыка плюс CLI, которая просто очень, очень мощная, потому что, по сути, любую платформу или инструмент, который вы хотите, чтобы ваш агент по кодированию мог использовать, это либо будет сервер MCP, и они все еще хороши, но, честно говоря, что я считаю еще лучше, более эффективным по токенам, это наличие CLI, чтобы у него был доступ к вашей CRM или GitHub или чему-либо еще через CLI, а затем навык говорит ему, как использовать этот CLI, а затем более конкретно, как вы хотите, чтобы он использовал это, как вы хотите, чтобы этот CLI был интегрирован в ваш рабочий процесс. Так что эта комбинация, я опираюсь на нее для всего, мой инструмент Archon, о котором я говорил ранее, это CLI, который поставляется с навыком. Так что, если вы хотите эти более детерминированные рабочие процессы, где вы выбираете, когда у нас есть LLM, когда мы просто запускаем код, тогда вы строите это как рабочий процесс, а затем теперь Archon со своим навыком и своим CLI становится инструментом, который мой второй мозг может вызвать, когда он хочет отправить один из этих рабочих процессов для обработки проблемы GitHub или запуска этой автоматизации, что бы это ни было. Очень круто. Мне нравится. Да. Мне нравится список. >> Мои топ-3 >> это навыки были номером один. >> Хорошо. >> Номер два, у меня была строка состояния. >> О, приятно. >> Мне просто нравится качество жизни, знаете ли, просто видеть модель, усилия, окно. Мне это нравится. А затем мой номер три — это рутины. >> Мне нравятся облачные рутины. Я просто думаю, что это так круто, что, >> знаете ли, я знаю, что у нас есть SDK и все такое, но просто приятно иметь возможность запланировать что-то, что >> это просто мой Claude code. И >> да, я думаю, что это были мои три лучших, и они, вероятно, будут меняться. Но да, я ценю, что вы поделились своими. Было интересно услышать. Я рад, что хуки попали в список, так что я определенно буду следить за этим видео. >> Звучит хорошо. Да. Хорошо. Что вы используете для рутин? >> Ну, у меня сейчас идет один, это торговый бот. >> Изначально я использовал его с агентом OpenClaw, но я переключил его на рутины, чтобы посмотреть, как >> как он будет там. Но затем другие вещи, просто, на самом деле, он там работает хуже. Да, он там работает хуже, но я не знаю, если это, я имею в виду, рынок и все остальное тоже, но >> я думаю, что OpenClaw просто из коробки имел лучшие возможности памяти для такого рода вещей. >> Да, имеет смысл. >> Но затем, знаете ли, просто ваши другие стандартные вещи, такие как проверка команды и предоставление мне обновлений в течение недели, и отчеты в конце недели, просто очень, очень простые вещи, но >> приятно добавить рутины туда. Так что да, я очень ценю, что вы провели нас через все это сегодня. Есть ли что-нибудь еще, что вы хотите оставить всем? >> Это хороший вопрос. Да, я бы сказал, что независимо от того, насколько вы техничны, на самом деле все сводится к тому, что вы можете думать о себе как о продакт-менеджере для Claude Code. Так что вам не обязательно описывать, как что-то построить, но важно, чтобы вы формировали видение, верно? Что мы собираемся построить? И тогда многие люди называют это инжинирингом намерений сейчас. Просто еще одно модное слово, по сути, вы хотите дать, как бы, "почему", почему мы строим эту вещь, потому что это действительно формирует "как" довольно хорошо. Так что это большая часть вашего процесса планирования, >> которая далеко вас заведет, и, как бы, это кажется немного глупым, потому что вы действительно начинаете входить в своего рода персонификацию Claude Code, когда вы говорите ему, почему вы делаете вещи, но на самом деле это имеет значение. Вам приходится как бы преодолевать себя и говорить: это немного неловко относиться к нему как к человеку, но на самом деле именно так вы получаете лучшие результаты. >> Так что просто сделайте это. Это на самом деле очень помогает в хороших планах и хороших спецификациях, прежде чем вы начнете что-либо строить с Claude или автоматизировать. >> Отличный совет. Отличный совет. Я на самом деле вчера прочитал в >> документации Claude о том, как правильно составлять запросы 4.8, что там говорилось, что нужно дать ему контекст, почему вы что-то делаете, и он, вероятно, сделает лучшую работу. >> Это потрясающе. Коул, где люди могут найти вас, если они хотят смотреть больше ваших материалов или связаться с вами? >> Да, так что YouTube-канал — это основное место, где я публикую весь свой контент. Так что вы можете просто поискать мое имя, Коул Медин. Это написано не так, как вы думаете. Это M E D I N. Звучит как Медин. Все говорят неправильно. Но да, это мой YouTube-канал. А затем я также много публикую в LinkedIn. >> То же имя, очевидно. >> Вот. О да, я думаю, что в течение первых нескольких месяцев, когда я знал вас, я думал, что это Коул Мин, и я говорил, я говорил Медин все время, но приятно. >> Всем приятно знать, что все прояснилось. Это Коул Медин. >> Правильно. Да, это шведская фамилия. И, да, Нейт, есть люди, которые говорили это намного хуже, чем вы. Например, кто-то назвал меня Мелден в прямом эфире на сцене на шахматном турнире в старшей школе. Это было хуже. >> О, чувак. Да, я не знаю. Многие люди галлюцинировали букву L. Я заметил. Я не знаю почему. >> О, правда? >> Да. Многие люди писали мне это как Мелдон или Медлин. >> О, вау. Хорошо. Потому что я, на самом деле, один раз для меня. >> Я получал это часто по какой-то причине. Но >> вау. >> В любом случае, да, спасибо большое, что присоединились, Коул. Я был здесь не только для того, чтобы пообщаться с вами, но и многому научился. Так что большое вам спасибо, как всегда. Приятно с вами поговорить, и надеюсь, мы сможем сделать это снова скоро. >> Да, звучит хорошо. Я ценю это. И вам спасибо, Нейт. Это было потрясающе. >> Абсолютно. Я люблю с вами болтать. >> Потрясающе. Вот так. Хорошо. Берегите себя, Коул. >> Да. >> Хорошего вам дня. >> Большое спасибо за просмотр сегодняшнего эпизода. Надеюсь, вам понравилось. Не забудьте, что я разбил все это на бесплатное руководство по ресурсам, к которому вы можете получить доступ совершенно бесплатно, используя ссылку в описании, чтобы присоединиться к нашему бесплатному школьному сообществу. Увидимся там. Большое спасибо.