Transcription
Все одержимы моделью, и я думаю, им следует больше интересоваться "обвязкой", тем, как получить максимум от "обвязки", давая ей правильные запросы, давая ей правильные навыки для работы и улучшая среду, в которой работает модель. Как я уже говорил про Fable, модель полезна, но я думаю, что "обвязка" требует не меньше работы, и у вас гораздо больше контроля над "обвязкой", чем над моделью. Люди сосредоточены не на том. Они смотрят на большую блестящую новую вещь, когда на самом деле просто сосредоточьтесь на том, что работает уже 30-40 лет, знаете ли, и это действительно работает. Люди постоянно спрашивают меня, как оптимизировать расходы на токены? Имейте кодовую базу, в которую легче вносить изменения, >> верно, Мэтт? Так в чем же будет основное различие между людьми, которые используют ИИ, чтобы невероятно продвинуться вперед, и большинством людей, которые получают от него лишь небольшой толчок? Итак, в своей книге "Философия проектирования программного обеспечения" Джон Астерут говорит о разнице между тактическим и стратегическим программированием. Я нахожу это различие очень полезным, когда думаю об ИИ, потому что тактическое программирование — это все, что касается повседневной работы на местах, фактического написания кода, фактического копания в синтаксисе, выяснения ошибок по мере их возникновения и фактического создания кода, создания коммитов. Стратегическое программирование — это победа в войне, а не в битве. Это долгосрочное мышление. Это генерал, сидящий наверху. Как должна выглядеть кодовая база, какие um стратегии я могу использовать для повышения нашей скорости? И для меня стратегическое программирование всегда было самым интересным, самым захватывающим. Так я думал, даже когда был младшим специалистом. Как мы можем увеличить нашу скорость? Как мы можем сделать больше с меньшими затратами? И ИИ, по сути, поглотил тактическое программирование. Его больше нет, верно? Все исчезло. Так что ИИ просто лучше справляется с тактическим программированием, чем вы, потому что он может делать это дешевле, верно? И поэтому вам нужно быть отличным в стратегическом программировании, чтобы получить максимум от этого бесконечного флота тактических программистов, к которым у вас теперь есть доступ. >> Значит ли это, что нужно знать, как оркестрировать этих агентов, плюс некоторые основы проектирования программного обеспечения, архитектуру кодовой базы, как бы вы разбили это на такие конкретные навыки, которые люди могут изучить? >> Да, отличный вопрос. Стратегическое программирование действительно не изменилось в ИИ, верно? ИИ — это просто um, все, что мы делаем, это вместо того, чтобы делегировать младшим или средним программистам, мы делегируем ИИ. Так что вещи, которые вам нужны для хорошего делегирования, остаются прежними. Вам нужно заранее спроектировать сложные части. Вам нужно убедиться, что эти задачи действительно, действительно хорошо определены. Вам нужно подумать об интерфейсах между всеми модулями в вашей кодовой базе. Знаете, вам нужно подумать о тестировании и хороших тестах. Вам нужно, по сути, спроектировать кодовую базу, в которой легко работать, и иметь достаточно документации, чтобы указать ИИ на правильные места, где он будет вносить эти изменения и делать это эффективно. >> Я думаю, все в данный момент согласны с тем, что прогресс ИИ очень быстр, если не ускоряется. Так что, я думаю, многие люди также упускают часть повышения своей квалификации, верно? Потому что, да, вы можете платить за подписки, вы знаете, вы можете получить новейшие инструменты, но в конечном итоге это может сделать любой, но все равно будут люди, которые используют эти инструменты для массового роста своего бизнеса, знаете ли, для выпуска большего количества и лучшего программного обеспечения, чем когда-либо прежде, и будут люди, которые, как бы, попробуют немного и, знаете ли, возможно, используют бесплатную версию или более дешевую модель. Так как бы вы посоветовали людям начать учить себя, чтобы стать лучше? >> Да. Um люди постоянно спрашивают меня, как бы, потому что, знаете ли, я продаю курсы для разработчиков, верно? Так что я, знаете ли, вы можете принять мой совет с щепоткой соли, но лично я считаю, что мои навыки являются множителем для ИИ, верно? Если я могу контролировать кодовую базу и думать о том, как бы, как следует строить вещи, и просто говорить ИИ, как это делать, тогда ИИ просто имеет гораздо более богатый контекст для работы. И я думаю об этом, я имею в виду, я вижу это повсюду, и люди, um, как CTO и люди, с которыми я разговариваю на конференциях, говорят мне это постоянно, что ИИ делает старших разработчиков в 10 раз лучше. И это как бы не имеет смысла нанимать так много младших специалистов, потому что младшие специалисты получают небольшой толчок от ИИ, но старшие специалисты получают от него просто смехотворно огромный толчок, и они могут сделать с ним гораздо больше. Так что ваши навыки — это потолок того, что может сделать ИИ. И если ваши навыки низкие, то ИИ не сможет пройти дальше этого, знаете ли. Так что стать хорошим в ИИ — это действительно стать хорошим в своей области, стать хорошим в том, что um ИИ будет делать для вас. Так что лучший учитель может использовать ИИ, чтобы учить людей лучше, чем um случайный человек, знаете ли. Так что я думаю, что навыки сейчас важнее, чем раньше, потому что опять же, у вас просто есть этот множитель, доступный вам, и вы можете делегировать больше. Так что вы недавно выпустили новый навык "учить", верно? Можете ли вы рассказать нам больше об этом? Если вы когда-либо пытались извлекать данные поиска из Интернета в масштабе, вы знаете, что это кошмар. Вы пишете скрейпер, он работает неделю, но затем меняется макет. Затем вы сталкиваетесь с капчами, ваши прокси блокируются, везде ограничения скорости, и внезапно вы обнаруживаете, что поддерживаете инфраструктуру скрейпинга вместо создания фактического проекта. Вот где вступает в игру SER API. Он предоставляет вам чистые структурированные результаты поиска из Google, Bing, Yahoo и других источников через один вызов API. Вы отправляете запрос, и получаете чистый JSON-объект с именно теми данными, которые вам нужны. Никакого решения капч, никаких вращающихся прокси, никакого сломанного HTML. Они обо всем этом заботятся. И для работы с ИИ это огромный плюс. Скажем, вы создаете агента, которому нужна информация в реальном времени. Просто используйте их API поиска Google. Или, возможно, вы обучаете модель ИИ, которой нужен набор данных. Их API Google Images предоставляет вам предварительно классифицированные заголовки, URL-адреса и миниатюры, готовые к использованию. Множество производственных агентов уже используют SER API в качестве одного из своих основных инструментов, и вы можете начать с 250 бесплатных кредитов. Кредитная карта не требуется. Просто отсканируйте QR-код на экране или нажмите на первую ссылку под видео. Ах, и огромное спасибо Surf API за спонсорство этого видео. >> Да, я много знаю об обучении. Я был учителем 10 лет, на самом деле. Так что я преподавал um пение и вокал, когда я был um прямо из университета. Затем я стал разработчиком, а теперь я обучаю разработчиков. Я занимаюсь этим последние четыре года. Так что я много знаю об обучении, и я подумал, хорошо, что если я возьму некоторые из принципов обучения, которые я знаю, такие как зона ближайшего развития, такая как разница между знаниями, навыками и мудростью, и закодирую это в навык и, по сути, использую это для создания курса на лету по любой теме, и это то, что я сделал, и это чрезвычайно эффективно. Я на самом деле учусь, я учу себя кубику Рубика с помощью этого. Я могу решить кубик Рубика сейчас по памяти благодаря этому навыку. И я использовал это для всяких вещей. Так что вчера я um копался в том, как может выглядеть запрос к навыку "учить" о том, как стать старшим разработчиком. И он, по сути, прошел большой путь, изучая кучу надежных ресурсов, собирая большую um учебную программу, и просто выдал что-то потрясающее. И так >> абсолютно, давайте попробуем. >> Да. Да, я думаю, людям понравится это увидеть. >> Определенно. Хорошо, так um Дэвид, чему ты хочешь научиться? >> Давай как системный дизайн. >> Знаете что, я um я um я у меня есть идея, что многие люди приходят ко мне. Я um я преподаю курсы для инженеров, на самом деле, людей, которые уже знают, как быть инженером. >> Меня интригует, может ли этот навык научить вас, по сути, основам инженерии, понимаете? Чтобы заполнить пробелы, которые у вас могут быть, если вы "вайб-кодер", понимаете? Так что я собираюсь притвориться, что я "вайб-кодер". Я собираюсь вызвать навык "учить". Я нахожусь в пустом каталоге, и я просто позволю ему работать. Так что я буду диктовать что-то, и посмотрим, как пойдет. Я "вайб-кодер", и я хочу заполнить пробелы в своих знаниях, чтобы я мог выпускать лучшее программное обеспечение. Я знаю очень, очень простые команды CLI, и я знаю достаточно, чтобы читать код и использовать терминал, но это все. Что, по вашему мнению, мне следует изучить, чтобы um развивать свои навыки дальше? >> Итак, я собираюсь поставить это >> простой запрос, простой английский. Любой может задать вам это. >> Точно. И это просто очень, очень простой запрос. И я не столько говорю о предмете, который я пытаюсь изучить. Я говорю о своей миссии, о том, чего я хочу добиться от этого, о причине, по которой я прихожу на эту сессию с учителем сегодня. И вы можете думать об этом как о совместной работе. По сути, я разговариваю с учителем, а агент — мой учитель. и он должен знать, как лучше всего меня учить. >> И хорошо, что вы упомянули об этом и создали навык недавно, потому что буквально вчера я думал об этом, верно? Особенно когда вышел Fable. Я подумал, как я могу повысить свою квалификацию, чтобы получить от него максимум, потому что, как бы, я знаю, что я не там, где могу быть. Знаете, есть люди намного лучше меня, намного более квалифицированные, чем я. Так что, как бы, это отличное время, что у вас есть этот навык сейчас. >> Хорошо. Ну, это um, так что он, по сути, говорит: "Хорошо, я проверил рабочее пространство. Это чистый лист. Навык "учить" нужно запускать в рабочем пространстве, потому что он сохраняет кучу информации в этом рабочем пространстве. Хорошо? >> И для "вайб-кодера", который может читать код и использовать базовый терминал, самый большой пробел — это почти никогда не больше синтаксиса. Это то, что вокруг кода, что позволяет вам выпускать без страха. Это 100% правда. Так что git, чтение ошибок, отладка, как на самом деле выпускается программное обеспечение, тестирование, абсолютно git — это то, с чего мы начинаем. Хорошо? >> Но сначала миссия. Я не хочу угадывать. Три быстрых вопроса. Первое, что делает навык, — это, по сути, согласовывается с тем, что вы хотите сделать. Я думаю об обучении и учении не как о получении информации в голову, а как об ориентации в мире, помещении вас в новое место в мире. И это своего рода немного абстрактно и немного, знаете ли, почти духовно, но на самом деле это не так. По сути, вам нужно изучить эти навыки, чтобы сделать что-то в мире, и это ваша миссия, верно? Так что это как бы, что вы строите, что означает "выпускать лучшее программное обеспечение" для вас прямо сейчас, над каким конкретным проектом вы работаете? >> Итак, давайте представим, что я отвечу на это. Давайте представим, что я был бы um, я тренер по вокалу, который хочет научиться лучше кодировать, понимаете, это на самом деле то, кем я был тогда. Так что я преподаватель вокала и преподаватель пения. Я хочу создать приложение для планирования, чтобы помочь мне планировать занятия со студентами, помогать мне вести записи о студентах, лучше их обучать и, знаете ли, создавать что-то, с чем они могут практиковаться. Это тот тип приложения, на который я смотрю. Так что, вероятно, полнофункциональное веб-приложение с базой данных, с какой-то аутентификацией, но это намного превосходит мои возможности прямо сейчас. Кстати, я использую Whisper Flow для диктовки. Это очень хорошо. >> Да. Так что это тоже будет игра, насколько быстро вы можете выводить свои токены из своего мозга и возвращать их обратно в свой мозг. >> Абсолютно. Да, я имею в виду, как бы, диктовка — это, если мы сделаем небольшой отступление о диктовке, любой, кто не использует диктовку, просто намного быстрее, верно? Для меня это очень быстро, потому что я довольно бегло говорю. Так что я могу довольно эффективно переводить свой мозг в слова. >> Но это навык, знаете ли, это навык в конце концов, и люди могут um научиться лучше и быстрее вербализовывать ложь. >> Точно. И это навык, который на самом деле переоценен, если вы um, если вы разработчик. Это действительно, действительно так. Как бы, я обнаружил, что способность общаться и способность говорить была чем-то, что было просто смехотворно переоценено в мире разработки, и поэтому это оказалось um, это создало mission.md здесь. Так что он, по сути, говорит: "Хорошо, кто этот человек? Что он хочет построить? Почему это важно? Как выглядит успех? Способность выпустить это приложение, не сломать его, запустить его и доверять, что оно работает для реальных студентов. Это теперь будет ориентировать все, что делает этот навык и что он будет делать дальше. Так что вы можете видеть, что он выполняет некоторые um поиски здесь. Так что он ищет надежные ресурсы. Как um полнофункциональное веб-приложение um фронтенд, бэкенд, бла-бла-бла-бла-бла. Позвольте мне настроить ваши ресурсы, запись обучения, справочный лист и ваш первый урок. Так что он начнет выдавать некоторый материал, который запускается локально. И это идея этого, я думаю, что есть навыки как "без состояния", которые не требуют никакого состояния на локальной системе или какой-либо um памяти о том, что было сделано раньше. А есть "с состоянием". Так что навыки, которые полагаются на информацию, работающую локально. И этот навык "учить" — это навык "с состоянием", потому что если вы думаете о работе с отличным учителем, учитель помнит, что вы делали раньше. Учитель знает, куда вам нужно um идти дальше. Знает, в чем ваша миссия, все такое. И поэтому он сохраняет кучу состояний локально, чтобы помнить все. И он, прежде всего, создал справочник. Так что у нас есть справочный лист. Теперь он создаст первый урок. И они создаются как HTML. Это означает, что мы можем открыть их в браузере и иметь um действительно богатый материал для просмотра, потому что изучение вещей в терминале — это просто жестоко. >> Да. Так вы используете um cl code с Fable, верно? >> Я использую claw code с opus 4.8 со средним усилием. Так что я не использую Fable. Пока еще не совсем. Я не решил, хочу ли я вообще заниматься Fable. Um >> действительно >> Я, ну, я имею в виду, да, я не особо верю во весь этот um, вчера ли это было, когда он был выпущен. Это просто огромное количество шума. Люди говорят, что они сделали это с одного раза, то сделали с одного раза. И да, это кажется шагом вперед. Это кажется немного лучше. Но затем вам приходится сопоставлять это со стоимостью токенов и доступностью, задержкой. Um Я предпочитаю не пробовать новую модель, когда она выходит, и подождать около месяца, чтобы увидеть, как все сложится. Вот что я сделал с um Opus 4.5, который был um последний раз, когда у меня было огромное um новое ощущение от модели, и это сработало нормально. Знаете, вы не um вы не теряете так много, просто подождав немного, чтобы увидеть, как все сложится. >> Хорошо, так это файл, который он создал. >> Это урок один. Получите кнопку "отменить" для ваших проектов. Так что мы можем видеть, что он использует более богатый um, как бы, на самом деле видеть это в HTML намного богаче и >> приятнее, чем делать это в терминале. Это сохраняется локально, так что вы всегда можете вернуться и обратиться к этому, и он дает вам реальные вещи, которые вы можете делать в терминале, дает вам настоящие упражнения, которые вы можете выполнить. Так что вы создаете папку, переходите в нее, начинаете ее инициализировать, создаете файл, проверяете статус, добавляете его в staging, сохраняете снимок, и поскольку он, конечно, работает на моей системе, он знает мою настройку. Он, вероятно, уже проверил, установлен ли у меня git, и тому подобное. Так что это, знаете ли, идеально >> персонализированное образование, знаете ли. >> Точно. Полностью персонализированное. Так какая команда сохраняет снимок ваших измененных изменений? Дэвид, думаешь, ты ответишь мне на этот вопрос? um команда git сохранить снимок ваших измененных изменений get commit >> get commit бам так снова он использует методы, хорошо известные в образовании для увеличения um силы запоминания, верно? Так что викторины — это такая неловкая вещь, как бы, я ненавижу викторины, но викторины просто необоснованно эффективны для um увеличения силы, с которой что-то хранится um какая команда показывает, что изменилось прямо сейчас, Дэвид? >> good status Get status. Да. Ох, черт. Я нажал не то. um, что делает git add с изменением? >> Stages changes. >> Стадирует изменения. Коммит лучше всего представить как >> безопасную точку. >> Безопасную точку. Вы сломали файл, но еще не закоммитили. Чтобы восстановить его, вы запускаете >> um get restore. >> Да, я думаю, это git restore, не так ли? Да, вот он. Очень хорошо. >> Хорошо. И тогда он отправляет вас читать первоисточник, если вы хотите. Так um progit book um и затем приглашает вас задать своему учителю последующие вопросы и создать следующий урок. И идея этого в том, что вы, я думаю о знаниях как о графе, верно? Это как большой лес, по которому вы исследуете. И то, что это делает, это создает линейный путь через этот граф. Он, по сути, говорит: "Хорошо, вы это узнали. Теперь, я знаю, что вы это узнали. Это в вашей записи обучения. Мы видим, что он сохраняет список записей обучения в правом верхнем углу, это ваша миссия и ваша отправная точка. Так что он зафиксировал вашу миссию, решение начать с зоны ближайшего развития Git, текущие оценки, вы поняли. Так что это здорово. Я чертовски люблю это. И это то, что я бы рекомендовал любому, кто начинает с um, особенно с разработки, потому что это как бы, я имею в виду, я разработчик. Я знаю, что такое образование для разработчиков. И поэтому я как бы вложил это в этот навык "учить". И я думаю, что я всегда думал, что кодирование довольно легко изучить. Как бы, у меня не было особых проблем, когда я учился сам. И я думаю, что это отличный способ сделать это. >> Так это уже доступно на GitHub где-нибудь? Где люди могут это найти? >> GitHub Matt Pokco skills. И если вы зайдете туда, вы просто запустите эту um CLI команду npx skills latest add map skills. Вы можете выбрать навык "учить", и он просто сохранится в вашей локальной настройке. Так что, используете ли вы claw code, используете ли вы codeex, он будет работать, и вы сможете просто вызвать teach внутри нового рабочего пространства. >> Итак, у вас есть, возможно, самый, по крайней мере, один из самых известных и популярных репозиториев навыков. Что отличает хороший навык агента от плохого? >> Это такой глубокий вопрос. Это такой глубокий вопрос, потому что это зависит от того, чего вы хотите. Um вы можете думать о том, что есть два типа навыков. Есть навыки, которые являются процедурами, навыки, которые вы намерены um запускать сами, а затем есть навыки, которые больше похожи на способности. Это способности, как бы, вещи, которые вы намерены um вызвать сам модель. И поэтому хороший способность, например, может быть um ваши стандарты кодирования, скажем. Так что, скажем, ваш агент как бы делает свое дело, работает, и ему нужно проверить, как бы, как написан ваш код React. Так что он собирается написать код React, вы um вызываете способность um отличные стандарты кодирования React, скажем, а затем читает его и понимает: "Хорошо, я не должен использовать use effect, я должен использовать что-то другое". Процедура — это скорее что-то um, вот как я предпочитаю, чтобы мои навыки были написаны, это что-то, что вы вызываете сами, чтобы модель вела себя определенным образом. Это что-то, что я люблю, это мой навык "grill me", это один из моих самых популярных навыков. Что он, по сути, делает, это превращает модель в противника-интервьюера. Так что это под продуктивностью, под grill me. Это невероятно коротко, и вы можете видеть, что это буквально всего четыре предложения, я думаю, этот навык, может быть, пять предложений, и он необоснованно эффективен, потому что он просто превращает агента в противника-интервьюера, задающего вам вопросы, интервьюирующего вас и предлагающего идеи, которые вы могли бы не рассматривать, пока не достигнете общего понимания. Я использовал это для кодирования, прежде всего, просто как замену режиму планирования. Так что, прежде чем вы фактически приступите к реализации кода, вы говорите: "Хорошо, вот моя идея. Um, возьми у меня интервью. Давайте достигнем общего понимания. Давайте проясним любые странности или любые неожиданные вещи, прежде чем мы приступим к работе настолько, насколько это возможно. И это просто необоснованно эффективно. И это процедура. Это не способность. >> Я предпочитаю, чтобы мои навыки были процедурами. Я люблю быть тем, кто контролирует. Я люблю говорить: "Хорошо, мы сделаем grill me", а затем мы скажем: "Давайте напишем документ с требованиями к продукту". Так что мы используем два PRD, например. Затем давайте возьмем этот PRD и превратим его в отдельные задачи, чтобы мы могли их проработать. Это просто лично то, как я люблю это делать. Но другие навыки, такие как "суперсилы" от Opera, который, вероятно, является самым популярным репозиторием навыков, идут противоположным путем и предпочитают, чтобы модель была более контролируемой. Но я всегда предпочитал, чтобы я лично контролировал, потому что я знаю свои навыки, я знаю свои способности. Я не хочу делегировать свое мышление модели. >> Да. Я имею в виду, я думаю, это одна из. Видите ли, я играю с этой идеей списка. Это как список способностей, знаете ли, знаний. По сути, что-то, что, если бы вы могли взять среднего, знаете ли, 100-кратного разработчика, который использует ИИ, по сравнению с, знаете ли, 1-кратным разработчиком, что бы это было? Список различий, верно? Вы можете сказать, как бы, некоторые из них — это просто сырой интеллект, знаете ли, бла-бла-бла, но большинство из них, вероятно, обучаемы, большинство из них — это некоторые навыки, некоторые знания, что-то вроде этого. Так что я одержим этой идеей, и я думаю, что одна из них — это как бы знать, когда нужно, чтобы ИИ задавал вам вопросы, знаете ли, как бы, этот стиль навыка "grill me", потому что лично я обнаружил, что самая большая разница вместо того, чтобы говорить "сделай это приложение с одного раза", я описываю свое видение этого приложения и говорю, как бы, перечислите 10 самых важных решений, верно? Решения по проектированию программного обеспечения, архитектурные решения, продуктовые решения, которые будут формировать этот проект, и возьмите у меня интервью, пока вы не поймете 98% этого. Верно? Так что, как бы, это одна из вещей, которые я бы включил в список. Что, что, по вашему мнению, есть в списке? >> Ну, можем ли мы um, могу ли я оспорить идею, что это возможно? Правильно ли я возьму этот вопрос по-другому? Потому что >> навыки действительно трудно писать, особенно потому, что каждый навык, который вы пишете, утекает описание, это описание здесь, в контекстное окно. Верно? >> Да. >> И вы можете отключить это. Так что есть некоторые навыки здесь, я думаю, в моем "инженерном масштабировании", я думаю, который имеет um disable model invocation true. Так что этот навык может быть вызван только пользователем, и это означает, что его описание не утекает в контекст. Каждая способность, скажем, у нас есть список. Скажем, у нас есть 100 различных навыков. Вы будете утекать 100 описаний в контекстное окно. Верно? >> Хорошо. Может быть, позвольте мне перефразировать. Я не имел в виду для ИИ. Я имел в виду, что список — это человек, верно? Как бы, если бы вам пришлось сказать, как бы, я знаю, что это сложно, как бы, это, возможно, редукционистски, взять человека, который как бы, действительно очень продуктивен, знаете ли, может быть, как бы, некоторые из лучших людей в OpenAI, которые как бы, стоят сотни обычных разработчиков, что бы это было? Список их способностей, навыков, знаний, которые сравнивают их с обычным разработчиком? >> Да, понял. Ну, это, я имею в виду, вы как бы движетесь в моем направлении, я думаю, что это то, что я предпочитаю скрывать большинство этих описаний от самого ИИ и сохранять все эти знания внутри человека, верно, внутри разработчика. И поэтому я предпочитаю, чтобы мои навыки использовались так: вы, по сути, водитель. Знаете, вы берете руль. И поэтому я думаю, что это такое захватывающее время быть старшим разработчиком и um, как бы, делиться и um, как бы, процедуризировать, возможно, um свою работу на многоразовые части, верно? Как бы, в um кодовой базе у вас есть функция, которая повторяется три раза. Вы берете эту функцию и выносите ее в общую функцию, которая затем um, вы уменьшаете дублирование, по сути, и мы можем сделать это сейчас с нашими собственными процедурами, с тем, как мы строим программное обеспечение, мы можем взять эти um, хорошо, я um, знаете ли, составил этот план um 100 раз, я знаю, как составлять хорошие планы, я могу превратить это в навык, распространить его среди своей команды, и каждый сможет планировать одинаково, внося вклад в тот же навык, делая всех в команде лучше. Так что вы повышаете планку, действительно, того, что могут делать инженеры. Это такое захватывающее время. И что бы я сказал, так это то, что навыки, как бы, есть um, я немного запутаю нашу терминологию. Я думаю, что есть три вещи, которые вам нужно хорошо делать в чем угодно, это то, что вам нужны знания. Вам нужно фундаментальное um, как бы, что это такое, как бы, понимание этого в вашей голове. Вам нужны навыки. Вам нужно уметь делать это много раз, чтобы um, знаете ли, в мышечной памяти. А затем вам нужна мудрость. Вам нужно знать, когда это делать. Вам нужно знать, как это вписывается в реальный мир. И мудрость почти невозможно получить без того, чтобы фактически сделать это в точном контексте, где вам это нужно сделать. Так что, если вы хотите быть кем-то вроде человека в Anthropic, конечно, вы можете получить знания, вы можете получить навыки, но тогда как вы получите мудрость, верно? Как бы, вам, вероятно, нужно пойти в Anthropic, чтобы получить мудрость, чтобы фактически понять, как это сделать, знаете ли? Но я думаю, что это как бы, способность объединить первые два, знания и навыки, в что-то многоразовое — это такой увлекательный um результат этого странного века, в котором мы живем. >> Итак, в настоящее время мы говорили о навыках. Какова ваша настройка агентной инженерии? Какие инструменты вы используете? Какие модели? Сколько агентов? >> Да. Um, моя настройка такая um, я использую claw code, по сути, для планирования и для um некоторой реализации локально. Так что я использую Opus 4.8 с um средним усилием, это то, на чем я остановился, и это работает нормально. Я делаю большую часть своей um разработки и большую часть своей работы сейчас um AFK, то есть без меня за клавиатурой, и я делаю это с помощью инструмента, который я построил, um, инструмента под названием sand castle, и sand castle, по сути, является способом запускать агентов в песочницах. >> Хорошо. >> Так что вы можете um, внутри, как бы, если вы не запускаете агента в песочнице, то он будет делать странные вещи. Так что он может, знаете ли, случайно удалить ваш домашний каталог или um, знаете ли, эксфильтровать ваши um переменные среды на um плохие сайты и так далее. С помощью Sand Castle вы, по сути, можете подключать такие вещи, как Docker или Podman, и запускать агентов, запускать um, вот как это выглядит, запускать clawed code um внутри какой-то песочницы, что чрезвычайно круто, чрезвычайно эффективно, и это означает, что вы можете параллельно запускать кучу агентов одновременно либо на своей собственной машине, либо вы можете использовать, например, песочницы Versel, чтобы просто поднять удаленный агент и затем вернуть коммиты в ваше локальное рабочее пространство. Я делал это, и я фактически комбинировал это с GitHub actions. Так что мы можем видеть, например, здесь, внутри вкладки actions моего sand castle, вот этот um, это было действие обзора агента, которое произошло некоторое время назад, которое проверяет ветку. Это запускается на um PR. Он um запускает агент обзора, который является просто локальным запросом. Мы можем видеть все um вещи, которые сделал агент. Он проверяет различные вещи, бла-бла-бла-бла-бла um, проверку типов, очистку, а затем отвечает: "Круто, все выглядит хорошо". Так что в основном я делаю это, запуская um агентов с помощью sand castle на GitHub actions и, по сути, просто говоря им делать вещи, и это было чрезвычайно необоснованно эффективно, потому что вы просто можете параллелизировать столько, сколько хотите. вы не беспокоитесь об ограничении ресурсов на своей локальной машине, и да, это просто очень, очень быстро, просто запустить агента и заставить его что-то сделать. >> Так в плане моделей, это 5.5 экстра высокие, это другой код, что вы предпочитаете? >> Это, я думаю, um, опять же, просто claw code um opus 4.8 um medium. Я думаю, я не особо менял это, честно говоря. Я в основном не беспокоюсь о моделях так сильно. Я в основном просто использую um, как бы, я думаю, да, это мой, как бы, горячий взгляд, я полагаю, который заключается в том, что >> все одержимы моделью. Все одержимы двигателем гоночного автомобиля Формулы-1, тогда как на самом деле двигатель — это лишь часть всей системы. Верно? У вас есть все шасси. У вас есть um, как оно um, как оно движется по воздуху. Все одержимы um моделью, и я думаю, им следует больше интересоваться "обвязкой", тем, что вы можете сделать, чтобы получить максимум от "обвязки". Um, давая ей правильные запросы, давая ей правильные навыки для работы и улучшая среду, в которой работает модель, улучшая кодовую базу и все такое. Так что да, как я уже говорил про Fable, как бы, модель полезна, но я думаю, что "обвязка" требует не меньше работы, и у вас гораздо больше контроля над "обвязкой", чем над моделью. >> Это правда. Я бы, возможно, немного оспорил вас на этом, потому что я не вижу, почему вы не можете делать и то, и другое, потому что, очевидно, я um, я согласен, что вам нужны правильные навыки, вам нужна правильная настройка, все это имеет значение, но затем, если вы замените лучший двигатель, все это мгновенно станет лучше. Нет. >> Да, это совершенно так. Um, но я думаю, что вам нужно думать о них как о 50/50, верно? Так что вместо um, модель составляет как бы 90%, а um, 10% оптимизации "обвязки", как бы, все так сосредоточены на модели, люди не так um, заинтригованы, так что, давайте вернемся на шаг назад, есть известная идея в ML, это "горький урок", вы слышали о "горьком уроке"? >> да >> да, "горький урок" — это идея о том, что um, что бы вы ни делали в исследованиях машинного обучения, вычислительные мощности, сырые вычислительные мощности всегда победят вас, потому что вычислительные мощности увеличиваются с такой высокой скоростью, что вы можете просто полагаться на то, что лежащая в основе вещь станет лучше, и это um, победит любые оптимизации, которые вы на нее наложите. И есть um, своего рода идея здесь, что, возможно, я попадаю в "горький урок", что вместо того, чтобы um, как бы, оптимизировать свою настройку, оптимизировать свою "обвязку", мне следует просто дождаться, пока модели станут лучше, дождаться, пока двигатель станет лучше, и тогда моя машина будет быстрее. Я не знаю. Я все еще думаю, что есть много чего можно получить, просто оптимизируя "обвязку" и сосредоточившись на создании um, как бы, хороших кодовых баз, в которых агент может работать хорошо, вместо того, чтобы ограничивать агента еще до того, как он начнет. Я бы сказал, вероятно, я, я согласен, что вам не следует ждать. Как бы, это была очень глупая идея. Люди просто ждут AGI или ничего не делают. Очевидно, я полностью согласен с вами. Я бы сказал, что я где-то посередине. Я бы сказал, как бы, я активно пытаюсь улучшить свою настройку каждый день, пытаясь, знаете ли, быстрее использовать этих агентов. Выяснить, хорошо, следует ли мне использовать Cmax здесь? Следует ли мне использовать, следует ли мне разместить это на VPS? Следует ли мне использовать Tailscale здесь? пытаясь, как бы, активно улучшать все, кроме модели, но также пытаясь использовать лучшую возможную модель, потому что фундаментально, как вы сказали, вы можете попасть в это. Я бы сказал, может быть, если это 50/50 сейчас, для простоты этого аргумента, что если бы um, модель действительно стала намного лучше, верно? Как бы, давайте предположим, следующее поколение, верно? Как бы, Opus 6, Fable 6, GPD 6, что угодно, 7, как бы, вы не думаете, что эти модели потребуют меньше управления и um, меньше помощи, по мере того как они становятся более компетентными, или нет? >> Я не пророк, верно? Это то, что я говорю на каждый из этих вопросов. Я пытаюсь сделать лучшее с тем, что у меня есть сейчас, и я не имею um, у меня нет понимания, чтобы знать, станут ли эти вещи лучше. Я не хочу делать прогнозы о будущем. Я думаю, что если я постараюсь сохранить свое um рабочее пространство и свою "обвязку" агента как можно более независимыми, если я постараюсь применять хорошие фундаментальные принципы программного обеспечения к тому, что я делаю, если я буду делать вещи, которые всегда работали, то это, вероятно, будет продолжать работать и в будущем. Понимаете? >> Так что, если я попытаюсь чрезмерно оптимизировать вокруг модели, если я слишком сосредоточусь на модели, я потеряю фокус на um, фундаментальных принципах. Это, это, это моя точка зрения. >> Да. Так что, по сути, вы сосредоточены на, как бы, хорошо, что было правдой в течение последних 10, 20, 30 лет, знаете ли, действительно лучшие принципы отличного программного обеспечения, и это, вероятно, сохранится и с новой моделью, а не люди, идущие от модели в первую очередь и, как бы, хорошо, эта модель, возможно, требует более коротких запросов, эта модель, знаете ли, плохо справляется с этой частью, позвольте мне исправить эту часть, как бы, строя um, правильно, прочный фундамент, а не, как бы, начиная с модели, может быть >> точно, люди сосредоточены не на том. Они смотрят на большую блестящую новую вещь, когда на самом деле просто сосредоточьтесь на том, что работает уже 30-40 лет, знаете ли, и это действительно работает, знаете ли, если у вас есть кодовая база, в которую легко вносить изменения. Как бы, люди, как бы, люди постоянно спрашивают меня, как вы оптимизируете расходы на токены, верно? Как вы оптимизируете расходы на токены? Имейте кодовую базу, в которую легче вносить изменения? Потому что тогда вы можете использовать более глупую модель. Если архитектура вашей кодовой базы лучше, то вы можете получить более дешевую модель для выполнения той же работы, потому что ваши um, ограждения лучше, ее легче исследовать, ей нужно тратить меньше токенов, ударяясь головой о стену. Если вы ограничиваете свою модель с первого дня, то вам понадобится умная модель, чтобы получить от нее максимум. Um, но да, так что я думаю, что мышление от модели в первую очередь — это неправильный путь. >> Да. Так что, по сути, я бы сказал, что полная противоположность вам — это квинтэссенция "вайб-кодера", который как бы, переключает инструменты каждую неделю, верно? Как бы, выходит новое обновление replit, переходит на replit agent, переключается на lovable, переключается на это и то, постоянно переключается и никогда не изучает никаких принципов программирования, ничего о разработке программного обеспечения, ничего. Вы, как бы, ваш подход — это, по сути, разница в подходе. Это не то, что вы не верите в ИИ, очевидно, верно? Сейчас вы активно пытаетесь быть на переднем крае ИИ и обучать людей, как им пользоваться. Это больше о разнице в подходе. Это как бы, "слушайте, ребята, изучите основы. Изучите, как работает код, как выглядит хорошее программное обеспечение, и это будет ценно, независимо от того, что. Независимо от того, опережает ли OpenAI, опережает ли Anthropic, опережает ли Gemini". По сравнению с полной противоположностью, которую, к сожалению, я думаю, большинство людей, новичков в ИИ, принимают, это как бы, прыгать на последнюю тенденцию и как бы, переключать все, как только, знаете ли, выходит какое-то новое обновление или инструмент. >> Полностью. И я думаю, знаете ли, вы можете это сделать, и это захватывающе. Um, но вы на самом деле не повышаете свои навыки таким образом. И это ваши навыки. Я твердо верю, что это потолок того, что может сделать ИИ. Вам следует сосредоточиться на себе. Знаете ли, повышайте свою квалификацию для этого нового мира вместо того, чтобы думать um, верно? Как мне делегировать свое мышление? Как мне больше делегировать? Знаете ли, вам следует больше углубляться в свою область и делегировать только тактические вещи. Сохраняйте стратегическое мышление. Продолжайте думать о, знаете ли, следующих um месяцах и неделях, дорожной карте того, куда вы движетесь в своем коде, вместо того, чтобы просто um пытаться делегировать это um, люди одержимы идеей, что, знаете ли, вы можете просто делегировать все ИИ, и вы не можете, вы действительно не можете, и я не вижу, я имею в виду, опять же, я не пророк, знаете ли, я просто смотрю на то, что у нас есть сейчас, и это не >> да, да, я тот человек в реальном мире, который движет этим. Мне нужно принимать продуктовые решения. Я знаю, куда я иду. И я думаю, что я как разработчик должен контролировать, и мне нужны навыки, чтобы иметь возможность это делать. >> Я согласен. Одно замечание, которым я поделюсь о Fable, произошло вчера, что немного пугает и определенно не соответствует практикам безопасности, заключается в том, что я настраивал новый um, как бы, новый агент для um, как бы, Twitter, и, по сути, um, API Twitter был глючным. Консоль разработчика не загружала некоторые кнопки, и я попробовал в другом браузере. Это все равно не работало. Я отключил все расширения. Это все равно не работало. Так что я дал ему несколько солидных минут, чтобы попытаться отладить это, и потерпел неудачу. Я имею в виду, я не это не было главной задачей, которую мне нужно было выполнить, поэтому я не старался изо всех сил, но я дал это Cursor, работающему на Fable. Он использовал встроенный браузер внутри Cursor. Знаете, мне пришлось войти, очевидно, в консоль, но помимо этого он начал кликать. Он создал API-ключи, скопировал их. Опять же, я не рекомендую это для производственных приложений. Это просто простая вещь для меня. А затем он выяснил, когда он тестировал, что эти API-ключи находились в другом um, приложении в консоли, и они на самом деле не использовали кредиты, которые я зарядил. Затем он снова переместил приложение, используя встроенный браузер внутри Cursor, и, как бы, для меня я действительно почувствовал, что я здесь делаю? Как бы, очевидно, я описал, что мы строим, почему мы это строим, некоторые из um, как бы, мое видение "grill me" в начале, но затем я почувствовал, что, хорошо, я просто вошел в консоль, и я просто зарядил несколько долларов, но как бы, все остальное делал ИИ, верно? Так что, как бы, я почувствовал, что моя ценность в этом проекте была намного ниже, чем с предыдущими моделями. Так каковы ваши мысли по этому поводу? Я имею в виду, если вы думаете о выводе ИИ, верно, что он um, что он делал в конце там, um, ему нужно, как бы, как ИИ знает в конце, что он сделал хорошую работу, верно? Что такое теория здесь, что вы можете полностью исчезнуть из проекта. Нет, вы все еще нужны, верно? Как бы, все, что мы делаем здесь, это то, что мы дали ИИ набор инструментов, и мы um, мы дали ему ограниченную задачу, и он выполняет эту задачу, верно? Вы знаете, мы дали ему цель и сказали, знаете ли, сделайте бла-бла-бла-бла-бла. Я не думаю, что это особенно волшебно, знаете ли, это то, что um, агенты могут делать сейчас, вы просто даете им инструменты, и они идут и делают это. Но чтобы решить, правильно ли это, um, um, протестировать безопасность в конце этого, это то, для чего вы нужны, верно? Вы, Дэвид, нужны для этого, чтобы знать, сделал ли он хорошую работу. И поэтому, да, мы можем делегировать больше, но я не думаю, что это причина начинать думать um, знаете ли, или иметь "психоз ИИ" или что-либо еще. Это просто, да, это разумная вещь, которую ИИ может делать с использованием компьютера. >> Я также видел, как многие люди сообщали, как бы, они, знаете ли, возможно, искали оптимизации или делали какую-то функцию, а затем снова я говорю о Fable, потому что он только что вышел. Это актуально, верно? Так что это у меня на уме. Но многие люди сообщали, что он нашел um, более глубокие ошибки, которые они вообще не замечали. В то время как другие модели полностью упускали их. И это, я бы снова, я бы немного оспорил вас, что это признак того, что ИИ может делать больше. Я не говорю, что мы должны быть полностью исключены из цикла, но как бы, если ИИ um, перепроектирует фронтенд, и он находит проблему в одном из um, бэкенд API конечных точек, как бы, серьезную проблему безопасности, я бы утверждал, что это как бы, ИИ более вовлечен. Это не 50/50 в этот момент. >> Да. Так вы говорите, что um, чем лучше, тем лучше um, чем лучше двигатель, тем большую ценность вы можете принести бизнесу, просто имея двигатель, и эти эффекты являются эмерджентными. Вы не знаете, что вы получите, увеличив мощность >> его. Он все еще будет знать видение, верно? Он все еще будет знать, что вы здесь делаете. Как бы, это образовательный репозиторий для моих студентов в моем платном сообществе, или это что-то просто для моей команды. Им будет пользоваться примерно пять человек. Цель этого — XY Z. Он все еще будет знать основную идею, инициативу, которая исходит от вас. Но в плане действий и того, что происходит, мой аргумент будет заключаться в том, что по мере того, как модели становятся мощнее, все больше и больше этого будет делаться ИИ. Но не только это, ИИ будет замечать, что нужно сделать, например, пример с um, знаете ли, глубокими ошибками, которые пользователь даже не отлаживал. >> Полностью. Но я думаю, что мы думаем, что модель — единственный способ достичь этого, верно? Что вы могли бы сделать, это в вашем репозитории, вы могли бы запустить um cron job, который запускается каждый день, скажем, и делает обзор безопасности, и каждый день он проверяет новую часть репозитория, верно? И вы могли бы использовать относительно простую модель для этого, и вы, вероятно, получите неплохие результаты. Я имею в виду эту идею о том, что есть глубокие ошибки, которые um, знаете ли, или глубокие um, вещи безопасности внутри вашего приложения, которые um, модель может обнаружить, а другие нет, знаете ли, как бы, конечно, это звучит привлекательно, но вы, вероятно, также можете обнаружить эти ошибки с помощью более дешевых моделей, если вы просто искали в правильных местах, знаете ли, и вы дали ему правильный запрос, скажем, для лучшего слова, или правильную "обвязку". Так что я не думаю, что есть что-то особенное в модели, которая делает эти вещи, или, знаете ли, и я думаю, что это опять же 50/50. Если бы у вас была "обвязка", которая как бы, искала именно эти вещи, то вы бы их нашли, и я думаю, что мы отстаем в наших практиках и ожидаем, что модель просто заполнит пробелы. >> Вы абсолютно можете просто запустить Opus и заставить его делать эти вещи. Знаете ли, люди говорили об этом, когда вышел Opus 4.5, вау, все эти вещи безопасности, которые Opus, это просто, конечно, он их нашел, и вы можете просто получить это с "обвязкой" и просто заставить его делать это снова и снова. Мне нравится >> Да, я понимаю. Я понимаю, как бы, вы, по сути, боретесь с волной хайпа, знаете ли, вы пытаетесь, как бы, внедрить какой-то смысл, какую-то мудрость в это. Скажем, ребята, хорошо, модели становятся лучше. Да. Но в то же время, давайте не будем терять очевидные, знаете ли, оптимизации, очевидные вещи, которые всегда, всегда были правдой. Может быть, как бы, если бы у вас была лучшая "обвязка", вы могли бы поддержать ее даже в предыдущем поколении модели. Или, может быть, вам не пришлось бы тратить 2000 долларов на API-токены, может быть, только 200, знаете ли, подобные вещи. Так что да, я полностью согласен с вами. Вы пытаетесь быть как >> одна вещь, одна вещь, просто чтобы закончить там, которая заключается в том, что >> что это, что это за вещь, которую вы узнали из Fable, глядя на свой код и замечая проблему безопасности? Что вы на самом деле узнали? Конечно, вы узнали, что Fable хорош, определенно, но вы также узнали
что есть проблемы с безопасностью в вашем коде, верно? И вам, вероятно, понадобится что-то, что будет работать и проверять на наличие новых проблем с безопасностью в будущем. Нам нужно встроить циклы в наши, э-э, циклы, ради всего святого, э-э, в наши, я имею в виду, мы можем поговорить и об этом, если у меня есть какие-то мнения на этот счет. Э-э, вам нужно создавать эти, э-э, системы, которые просто проверяют ваш, как вам нужно, что я пытаюсь сказать? >> Вам нужно выяснить, почему это произошло, почему это вообще дошло до такого состояния. Знаете, это как если кто-то постоянно крадет ваш велосипед, может быть, купите замок. >> Да, именно. Может быть, нам нужно, э-э, разрабатывать системы, которые самосовершенствуются со временем, верно? И это то, что мы делаем как инженеры-программисты уже давно. Мы пишем наборы тестов, чтобы мы могли тестировать свой собственный код. Мы проводим человеческие обзоры, чтобы убедиться, что все выглядит так, как должно. Мы рефакторим, чтобы в будущем лучше менять код. И, конечно, модель обнаружила, что нам нужно делать это немного больше. Так что давайте делать это немного больше. Но нам не нужно использовать эту модную модель, чтобы получить эти сведения. Видите ли, это одна из вещей, которую я бы включил в список: то, что действительно отличает людей, которые собираются двигаться супербыстро с ИИ и создавать лучшую и более качественную программу, от людей, которые этого не делают. Как и большинство людей в такой ситуации, они просто сказали бы: "О, да, Fable — это здорово. Исправь ошибку. Она исправляет ошибку". Но вот люди, я не знаю, это как 10-кратный разработчик, это почти как 10-кратный строитель ИИ, понимаете, потому что все становятся больше строителями, будь то дизайнерский фон, разработческий фон. Это как если бы этот человек посмотрел на основные проблемы. Это как, как это вообще произошло? Как у меня была эта ошибка так долго, что я ее не заметил и не попытался исправить основную проблему? Понимаете, будь то новый навык, новая система, лучший процесс постановки, что угодно, что, я думаю, я бы включил в список ваших человеческих возможностей или вещей, которые у вас должны быть, чтобы получить максимум от ИИ. Полностью согласен. >> Хорошо. Итак, вы упомянули циклы. Это было супервирусно в Твиттере. Может быть, до сих пор, но, знаете, неделю назад. Э-э, я думаю, это началось с Питера Стэнбергера, если я не ошибаюсь. Но, по сути, люди одержимы агентскими циклами. Э-э, половина из этого, я бы сказал, это исследовательские лаборатории, продающие больше токенов. Вы знаете, по сути, вы должны запускать циклы, чтобы платить нам больше бесконечных токенов. Прекратите задавать запросы своим агентам. Выясните, какие циклы он может запускать вечно, постоянно. Половина этого может быть полезной. Каково ваше мнение? >> Итак, мы, по сути, говорим здесь о разнице между работой "человек в цикле" и работой "AFK". Верно? Работа "человек в цикле" — это когда вы находитесь там с агентом, разговариваете друг с другом и, э-э, выясняете что-то. Так что очень полезно для планирования, очень полезно для некоторых более сложных реализаций, э-э, очень полезно для нечеткой работы, знаете, вещей, которые вам просто нужно, э-э, выяснить локально с агентом. А затем мы говорим о AFK-вещах. Так что AFK — вдали от клавиатуры, вы отправляете агента, и он идет и делает что-то. Теперь я думаю, что, я имею в виду, в тот момент, когда я открыл для себя AFK, это был момент, когда я действительно погрузился в ИИ-кодирование, и момент, когда я действительно смог значительно увеличить свой объем работы, потому что тогда, вместо того, чтобы мне приходилось сидеть в цикле, обрабатывать все запросы разрешений, обрабатывать все, знаете, все, о чем агент должен меня спросить. В тот момент, когда я могу просто устранить себя из уравнения, я парализовал себя. Внезапно появляется два меня, знаете, или три, четыре, пять меня, способных создавать гораздо больше кода, который я затем просматриваю. Эта идея, что циклы — это единственный способ сделать это, — это безумие, знаете, как мы, по сути, говорим об истории этого, она восходит к Джеффри Хантли. Э-э, где это? Г. Хантли Ральф, э-э, восходит к Ральфу. Вы помните Ральфа? >> Да. >> Я говорил о Ральфе в январе, кажется. Э-э, оригинальная статья датируется 14 июля прошлого года. И, по сути, это цикл. Так что это идея, где у вас есть цикл while, который говорит: "Хорошо, передай этот запрос Claude Code", и затем, э-э, в конечном итоге вы закончите. Теперь это, по сути, просто повторное выполнение Claude Code снова и снова. Такова идея цикла Ральфа, о котором я говорил некоторое время. И я понял, что мне на самом деле не нужно запускать это как цикл, верно? Единственное, что мне нужно из этого, — это чтобы AFK-агент взял на себя конкретную задачу и выполнил эту задачу. >> То, как я в основном думаю об этих вещах, это очереди, хорошо, очереди, а не циклы. Очередь — это, по сути, бэклог задач, которые мне нужно выполнить. Я смотрю на проблемы Sand Castle прямо сейчас. Это отчеты об ошибках, касающиеся, э-э, Sand Castle, запросы на функции, подобные вещи. Мне нужно определить объем задачи. Допустим, это, например. Итак, я немного разобрался здесь. Это, э-э, своего рода исследовано. Хорошо, это тривиально? Это возможно? Это, э-э, было сделано AFK, верно? Так что этот пункт был снят с очереди. Он был исследован, возвращен в очередь. Мне, возможно, придется пойти и реализовать это. Э-э, похоже, да, это выглядит довольно хорошо. Я действительно добавлю метку "агент реализовал" и пойду и реализую это в своей настройке GitHub Actions Sand Castle, о которой я говорил ранее. >> Теперь это не цикл, на самом деле, это как бы просто, э-э, это очередь, которая в конечном итоге разрешается. Это будет снято с очереди, когда будет, э-э, э-э, когда запрос на слияние будет объединен. И это, по сути, вся разработка. У вас просто есть очередь задач, которые вам нужно выполнить. Менеджеры проектов добавляют больше вещей в очередь. Вы выполняете задачи в очереди. Вот так мы всегда это делали. И есть несколько узлов, снимающих задачи с очереди, несколько разработчиков. И поэтому идея, что существует один цикл, который просто идет и выполняет все задачи, на самом деле не соответствует тому, как, как правило, работают команды разработчиков, когда все это как бы внутри GitHub Actions, как это. Э-э, любой разработчик может добавить одну из этих меток, может что-то запустить и просто начать работу. Так что, да, я думаю, идея цикла полезна, но это не вся картина. И я думаю, что идея очереди, из которой вы снимаете задачи, лучше. Но в основном это просто бессмыслица, на самом деле. Как когда люди говорят, что вам нужен цикл, задающий вопросы вашему агенту, >> мы на самом деле говорим об AFK-агентах. >> Да. Я полагаю, когда вы говорили, я не знаю почему, но образ, который пришел мне в голову, — это как средневековый король, управляющий королевством с какими-то министрами или чем-то в этом роде. И, по сути, предполагая, что король знает лучше, имеет больше всего контекста, а не король, который просто случайно унаследовал империю, верно? Так что, если вы отправили министра в какой-то регион, далекий регион, и вы никогда не слышали от него, никогда не давали ему приказов, он бы работал по циклу, и это могло бы пойти не так или пойти правильно, в зависимости от того, насколько сложны проблемы в этом регионе, насколько умный министр, что угодно. Но в конечном итоге, как король в этом средневековом королевстве, вы хотите использовать подход очереди. Вы хотите, чтобы люди приходили к вам и говорили: "У нас проблема, надвигается вторжение", знаете, или "в этом регионе голод", и у вас есть эта очередь проблем, и вы все еще главный, так что это было бы эквивалентом человека здесь с, знаете, кучей агентов, кучей ИИ, вы все равно расставляли бы приоритеты: "Хорошо, у нас есть эти 50 отчетов об ошибках, только три из них критичны, давайте сначала исправим их. Хорошо, у нас есть эти ресурсы, эта сделка с брендом, эта компания хочет работать с нами, проверьте их репутацию сначала. Это хороший способ думать об этом? >> Полностью. И то, что мы делаем здесь, это как бы вы все еще можете встроить тонны автоматизации. Допустим, у меня была бы какая-то телеметрия, настроенная для песочницы, для песочницы, или какой-то инструмент наблюдения, такой как Sentry или что-то в этом роде. Я мог бы получить отчет об ошибке из живого приложения, немедленно создать проблему из него, пометить эту проблему как "исследовать проблему". Может быть, агент мог бы вернуть структурированные данные из исследования, говоря: "Можем ли мы исправить это немедленно, или это требует участия человека в цикле?" Он идет и реализует это. Он идет и проверяет это. А затем, возможно, у него будет небольшая метка: "Можем ли мы автоматически объединить это, или это, наконец, э-э, уведомит пользователя, чтобы он сделал это?" Я вижу эти системы как необходимость иметь контрольные точки "человек в цикле", и вам нужно отодвигать их все дальше и дальше, верно, все дальше и дальше к финальному результату, насколько это возможно. Так что вы, по сути, получите эти, э-э, вместо того, чтобы видеть отчет об ошибке, вы увидите отчет об ошибке, вы увидите, э-э, исследование кодовой базы, вы увидите исправление и увидите, э-э, можем ли мы это проверить? >> Да. Точно так же, это то, что вы получаете как человек, вместо того, чтобы видеть отчет об ошибке, и это намного богаче, и это означает, что это один клик мышью, а не целая сессия отладки. >> Так что это, я имею в виду >> так что тогда вопрос здесь >> где Да. Да. Так что вопрос в этой ситуации становится, потому что это не цикл, он работает только тогда, когда приходит ошибка, нет смысла в том, чтобы он работал бесконечно, просто платя OpenAI или Anthropic бесконечно, но мой вопрос был, знаете, опять же, по мере того, как ИИ становится мощнее, где, потому что вы упомянули, что вы отодвигаете себя все дальше и дальше к последнему шагу, это отправка в продакшн, какие, когда это пересекает порог, где, как эти типы вещей, будь то небольшое изменение пользовательского интерфейса, знаете, пользователь запрашивает новую цветовую схему, что угодно, это может быть одобрено автоматически, верно? А затем, может быть, мы пойдем дальше и дальше. Так как это выглядит? Вы понимаете, к чему я клоню? >> О, как вы удаляете контрольные точки "человек в цикле", вот что >> Да. Как вы решаете, по сути, где это, это достаточно тривиально, чтобы вы даже не смотрели на это, верно? Как, может быть, все агенты, которые у вас есть, которые, опять же, вы настроили средства защиты, у них есть ваши навыки, вы используете хорошую модель, и все агенты говорят: "Хорошо, это небольшая ошибка, это был просто смещенный элемент пользовательского интерфейса. Нет никакого, знаете, вредоносного намерения со стороны пользователя. Пользователь не пытается взломать приложение. Мы просто объединим это в продакшн немедленно". Это, предположительно, расширит, как бы, объем вещей, которые могут быть объединены в продакшн немедленно. Так как бы вы об этом думали? >> Ну, я бы сказал, что вы получаете от обзора, верно? >> Конечно. Вы получаете, хорошо, как вы получаете возможность контролировать вещи, контролировать опасные вещи от попадания в продакшн. Так что предотвращайте, э-э, безопасность, плохие вещи, происходящие, вы Да. >> предотвращаете, знаете, э-э, скажем, утечку исходного кода Claude Code миру, знаете, вы предотвращаете эти плохие вещи. Э-э, но вы также получаете, э-э, понимание вашей собственной системы, э-э, сантехники, верно? Так что вы наблюдаете, как вещь делает свою работу, и оцениваете, хорошо ли она справилась. И так, второе, вы не хотите терять, потому что, опять же, мы говорим о средствах защиты, верно? Вы хотите улучшать свои средства защиты со временем, и вы хотите некоторую наблюдаемость в них. Теперь вы можете удалить некоторые контрольные точки "человек в цикле". Так что вы можете сказать: "Хорошо, этот, э-э, этот PR — это просто внутренний рефакторинг. Он просто перемещает некоторый код. Он на самом деле не меняет никакого поведения". И вы можете иметь ИИ, который как бы говорит: "Хорошо, вам действительно не нужно это проверять". Но тогда кто проверяет ИИ, который это делает, верно? Как вы даете обратную связь этому со временем? Вам, вероятно, нужно проверять некоторые из PR, которые агент считает подходящими для проверки, чтобы проверить, действительно ли они подходят для проверки. А затем вы улучшаете это со временем. И поэтому нам нужно подумать об этом. Мы не просто проверяем код. Мы также проверяем систему, которая производит код, и это важно и полезно, но я согласен, что цель — удалить контрольные точки "человек в цикле", где это возможно, определенно. Так что, может быть, лучший способ, вместо того, чтобы, хорошо, скажем, в среднем за день для этого приложения ИИ автономно исправляет 20 вещей и отправляет их в продакшн немедленно, потому что они были очень маленькими, в конце дня, вместо того, чтобы вы просматривали все это, потому что это было бы скучно и медленно, может быть, вы получите пользовательский, знаете, HTML-файл с навыками и скажете: "Хорошо, это общие шаблоны в исправленных ошибках, верно?" Так что, вместо того, чтобы вам приходилось проходить через все коммиты GitHub, PR, что угодно, что на самом деле не оптимизировано для этой агентской эры. Я имею в виду, опять же, GitHub был создан давно. Это было бы пользовательское программное обеспечение, пользовательский HTML-файл, что угодно, что, знаете, знает вас, ваш стиль обучения, ваши распространенные ошибки. У него есть история прошлых ошибок, знаете, что угодно. И это было бы более оптимизировано для того, чтобы помочь вам улучшить себя и систему. >> Полностью. Я имею в виду, одна действительно классная, как бы, то, о чем мы здесь говорим, это сделать обзор бесшовным и убрать, э-э, убрать человеческие усилия из обзора. Одна вещь, которую я видел, которую люди делают, которая сумасшедшая, это то, что при любом изменении на стороне клиента, ИИ записывает видео, как он проходит по коду и, э-э, то, что изменилось. Затем он вызывает API преобразования текста в речь и накладывает некоторую речь. Так что это как бы ИИ разговаривает с вами, пока он проходит по коду, и у вас просто есть видео в PR, где вещь работает, как бы, такая насыщенность — это то, что мы должны встраивать во все, что мы делаем, и пытаться оптимизировать для человеческого обзора и ускорить человеческий обзор, потому что все как бы жалуются, знаете, как, о, чувак, у нас так много кода для обзора, но, вероятно, вы могли бы использовать ИИ, чтобы помочь вам просмотреть код, верно? Как, э-э, во всех интересных способах, которые, я думаю, мы только начинаем осваивать. Абсолютно. Итак, многие люди хотят что-то построить с помощью ИИ, верно? Будь то, вы можете начать с некоторых личных инструментов, чего-то для вашей команды, но многие люди хотят построить, э-э, бизнес, будь то стартап ИИ, будь то какой-то другой бизнес. Как бы вы об этом думали? Как, знаете, многие люди, есть, есть группа людей, которые говорят: "О, да, SaaS", знаете, подписки, они будут более ценными, чем когда-либо, потому что вы будете добавлять больше мест для агентов. Есть группа людей, которые говорят: "SaaS мертв". Как вы думаете о построении бизнеса, построении программного обеспечения в эпоху ИИ? >> Ну, я, я не думаю, что многое изменилось в этом, честно говоря. Э-э, как и снова, я не оракул. Я не особо слежу за рынками. Мне не особо, э-э, важно, умрет ли SaaS или преуспеет. Э-э, если вы строите бизнес, вам нужно делать фундаментальные вещи. Вам нужно пойти и поговорить с клиентами. Вам нужно выяснить, что им нужно. А затем вам нужно создавать прототипы, которые выглядят так, как им нужно, и решают их реальную проблему. Я не думаю, что что-то изменилось, и я думаю, что вы можете научиться делать это и быть лучше в этом, но я не думаю, что ИИ дает вам какое-либо особое преимущество, потому что вам нужно выйти в реальный мир, вести беседы и выяснять, что на самом деле нужно людям. Так что я думаю, что все классические книги по дизайну продуктов по-прежнему будут актуальны здесь. Просто у вас есть огромный перевес, когда дело доходит до фактической реализации, и процедуры, о которых они говорят, вы можете начать делегировать их ИИ. Так что в основном это просто о наличии правильной идеи и создании правильной вещи. И это то, с чем ИИ не может помочь. Если вы не разговариваете с реальными людьми и не выясняете, чего они хотят, как только вы выясните, чего хотят люди, э-э, вы готовы к работе. >> Да, я думаю, что это на самом деле то, в чем ИИ известен своей плохой работой, это как бы оригинальные идеи "из коробки". И, да, как бы, это, вероятно, будет одним из основных советов, которые я бы дал людям: вам нужно выбирать функции, которые добавляются, верно? Если вы видите кого-то, кто как бы делегирует все это, это как бы, что дальше, что большое мы должны добавить? Это как бы, нет, вы должны быть во главе продукта. Вы можете, да, очевидно, вам не нужно, как бы, изучать точный синтаксис или что-то в этом роде, вам не нужно читать каждый файл, но как бы, вы не можете просить ИИ построить ваше приложение. Вам нужно иметь видение. Вам нужно знать, почему вы его строите и какую проблему оно решает. >> Абсолютно. Вам следует спрашивать ИИ, что вы можете удалить из своего приложения. По сути, вам следует спрашивать, как мне сделать это проще? Как мне улучшить пользовательский опыт? Как мне на самом деле сосредоточиться на том, чего хотят люди, вместо того, чтобы в конечном итоге, знаете, э-э, одно из тех ужасных, э-э, приложений, финансируемых венчурным капиталом, которые мы все видели, где есть тысяча функций, и вы не можете найти то, что хотите сделать. Так что снова, это просто основы дизайна продукта. >> Мы упомянули, что старшие разработчики получают 10-кратное улучшение и, знаете, ускорение. Как вы, потому что по моему опыту это правда, но только если они действительно использовали инструменты ИИ. Есть группа разработчиков, которые все еще отказываются в это верить или, знаете, ИИ не так хорош. Они пробовали это год назад, два года назад, они были, знаете, разочарованы, но, очевидно, инструменты, средства защиты, модели намного лучше. Но мой контраргумент или, может быть, это не контраргумент: что насчет просто найма настоящих, если бы вы нанимали молодых людей, которые являются истинными верующими в ИИ, которые знают эти инструменты вдоль и поперек. Они используют их все время. Они знают, какая модель лучшая, какой навык лучший, какой, знаете, агент лучший в каждой ситуации. И, очевидно, им нужны некоторые технические основы. Но как бы вы примирили это напряжение: эти старшие разработчики имеют 10, 15, 20 лет опыта и получают 10-кратное увеличение, а эти — настоящие верующие в ИИ, которые, возможно, не имеют столько опыта, сколько старшие, но как бы лучше работают с ИИ? Ну, найм отличных младших специалистов всегда был целью любой компании, по сути, потому что если вы найдете отличного младшего специалиста, то любой, кто увлечен, сделает лучшую работу, чем кто-то более опытный, по сути, энтузиазм побеждает опыт в чистом объеме работы, и потому что они развиваются намного быстрее и учатся намного быстрее. И поэтому люди, которые действительно, э-э, взволнованы этой новой эрой и много знают об этом, если вы просто сочетаете это с небольшим количеством основ программирования, потому что то, о чем мы говорим, я думаю, есть разница между DX — опытом разработчика и AX, верно? Опыт агента. И поэтому опыт агента — это опыт, который агент имеет при работе с кодовой базой. И все, что вы можете сделать, будь то, э-э, э-э, лучшие навыки, э-э, увеличение мощности модели, конечно, э-э, улучшение средств защиты и улучшение кодовой базы, также, э-э, это потрясающе, часто люди забывают об улучшении кодовой базы на самом деле для лучшего AX, знаете, улучшении, э-э, они забывают обо всех краях, которые вы можете получить с хорошими основами программирования. И вот где старший будет полезен, потому что старший знает, как создать хороший DX, верно? Они знают, как, если они хорошие старшие, они знают, как создать кодовую базу, которая может хорошо работать с людьми. И существует огромное совпадение между хорошим DX и хорошим AX, но они просто подходят к проблеме, как младший, который отлично разбирается в ИИ, просто подходит к проблеме с другой точки зрения, чем, э-э, старший. Э-э, каким был ваш первоначальный вопрос? Как их нанимают или как вы, или как вы нанимаете из обоих? >> Конечно. Но не то, как вы нанимаете, а скорее, кто, возможно, получит больше альфы, знаете, кто будет более ценным? Это как старший, у которого много такого опыта, знаете, правильный способ мышления о программном обеспечении, но, возможно, не такой истинный верующий в ИИ, по сравнению с кем-то, кто полностью принимает ИИ в максимальной степени и знает, как использовать его в полной мере. >> Я думаю, если у вас есть экспериментальный склад ума, и вы увлечены ИИ, то вы получите от этого массу пользы, независимо от того, являетесь ли вы младшим или старшим. И я думаю, опять же, если вас интригует средство защиты, прежде всего, и вас интригует улучшение AX везде, где это возможно, тогда вы будете процветать и любить это. Теперь, очевидно, есть много, э-э, веских причин, по которым люди не хотят садиться на поезд ИИ. Вы знаете, они могут, э-э, просто быть немного, знаете, нервничать из-за этических вопросов. Вы знаете, как Anthropic крадет у всех, э-э, романы и просто как бы впихивает их в Claude. Э-э, но как бы, это здесь, и это то, как выглядит работа сейчас. Вы знаете, если вы просто тактический программист, просто занимающийся своей работой, вы уволены, верно? Это вне игры. Вы не можете быть кодовым обезьяной больше. Вам нужно мыслить стратегически. И поэтому старшие могут абсолютно использовать это по максимуму. Но младшие тоже могут этому научиться. >> Хорошо. Мой заключительный вопрос будет практическим для людей, которые смотрят. Если бы вы могли взять среднего энтузиаста ИИ и дать ему один или два практических шага, которые нужно сделать сегодня, чтобы улучшить свою настройку, улучшить свои средства защиты, узнать что-то, что бы это было за один или два шага? >> Первое, что я бы сделал, это удалил бы каждый навык, каждый плагин, каждый сервер MCP. Я бы вернулся. Я бы удалил ваш claw.md, удалил бы ваши agents.mmd, вернулся бы к абсолютно ничему, а затем наблюдал бы за агентом. Посмотрите, что он делает. По моему опыту, все раздувают свое контекстное окно слишком большим количеством вещей, слишком большим количеством инструкций. Вернитесь к чистому листу и посмотрите, что делает агент. Как только вы увидите, что делает агент в этом базовом, э-э, своего рода режиме, затем накладывайте вещи поверх него и убедитесь, что эти вещи являются процедурами, процедурными навыками, а не навыками способностей. Накладывайте вещи, которые вы сами решаете. И мой репозиторий навыков — это отличное место для начала. Если вы действительно чего-то не хватает, если вам действительно не хватает, скажем, мозгового штурма из суперсил, тогда верните это. Если вам этого не хватает, если вам этого не хватает, и убедитесь, что вы устанавливаете их таким образом, чтобы вы могли настраивать их, вы можете играть с ними и экспериментировать, знаете. Э-э, если вы замечаете проблемы, тогда попытайтесь найти решения для их устранения и постарайтесь как можно больше делегировать реализацию AFK-агенту. Э-э, AFK — это просто невероятный способ работы. Это требует немного настройки, но как только она настроена, она просто сходит с ума. >> Хорошо, Ви? Спасибо за ваше время. Где люди могут найти вас? >> Э-э, найдите меня в Твиттере, найдите меня на aihero.dev, и у меня есть информационный бюллетень, где я публикую обо всем этом. Так что aihero.dev, особенно если вы хотите узнать о моих навыках и обновлениях к ним, перейдите на aihero.dev/skills. >> Хорошо, я все это прикреплю ниже. Еще раз спасибо за ваше время, Мэтт, и хорошего дня. А теперь где Дэвид?