Transcription
И все еще, как я говорю, в 2026 году, я все еще разговариваю с инженерами, которые говорят, что ИИ в наших самых сложных задачах не может справиться хорошо. >> Я так глубоко не согласен с тем, что нет ни одного штатного инженера, который проводит столько же строгих тестов, пробует разные алгоритмы и анализирует идеи вручную, чем тот, кто использует агента. Каждый должен посмотреть в зеркало и пересмотреть, как он тратит свое время. Есть много взаимодействий, которые у вас есть, или направлений, которые вы даете, или решений, которые вы принимаете, и я думаю, что многие из этих вещей для меня попадают под линию агента. Я думаю, что линия агента продолжает подниматься. >> Почему вы думаете, что эта концепция так важна для понимания? Как вы можете развеять мифы для людей, которые немного напуганы ею? >> Теперь, когда модели так хорошо пишут код, одна из лучших вещей, которые мы можем сделать, это создать действительно сложные оценки. И если вы создадите правильные тесты и критерии успеха для модели, тогда она может быть действительно креативной, и она может работать над этим в фоновом режиме и фактически пытаться улучшить множество вещей. >> Многие люди говорят: «Вау, если я зайду так далеко, что превращу свой собственный вкус, свои навыки или свой опыт в систему, я фактически просто создаю свою замену». >> Мы можем применять палитру Дэвида к большему количеству вещей. Я думаю, что планка качества, которую мы можем достичь, выше, потому что мы можем довести больше вещей до этой планки. Добро пожаловать обратно на «Как я ИИ». Я Кларавео, лидер продукта и одержимый ИИ, здесь с миссией помочь вам лучше создавать с помощью этих новых инструментов. Сегодня у меня Анкер Гойел, генеральный директор Brain Trust. И это технический выпуск. Так что, если вы старший или штатный инженер, или вице-президент по инжинирингу, или CTO, это тот, на который вам действительно стоит обратить внимание. И мы поговорим о том, как агенты кодирования могут помочь вам справиться с очень технической работой по архитектуре и инфраструктуре таким образом, который не мог сделать ни один другой инженер-человек раньше. Мы также развеем мифы об оценках для людей и просто покажем вам, как вы можете использовать их, чтобы сделать ваши ИИ-продукты лучше, не прикасаясь ни к чему. Давайте приступим. Этот выпуск представлен вам Guru, ИИ-слоем истины для знаний вашей компании. Вот проблема. Ваш ИИ так же хорош, как и информация, которую вы ему предоставляете. Большинство компаний получают уверенные, но неправильные ответы от ИИ, потому что их базовые знания устарели, неполны или просто неверны. Плохая информация не просто замедляет вас. Это стоит вам денег и подвергает вас риску. Guru решает эту проблему, добавляя слой проверки между знаниями вашей компании и инструментами ИИ. Вместо того, чтобы просто надеяться, что ваш ИИ справится правильно, Guru автоматически оценивает контент на точность, помечает устаревшую информацию и гарантирует, что ваша команда каждый раз получает достоверные ответы. Он работает с инструментами, которые вы уже используете, поэтому вам не нужно менять то, как вы работаете. Тысячи компаний доверяют Guru, чтобы их ИИ оставался точным и соответствовал требованиям. Готовы перестать играть в русскую рулетку со знаниями вашей компании? Посетите getguru.com, чтобы узнать больше. Добро пожаловать на «Как я ИИ». Я рад, что вы здесь. >> Я очень рад быть здесь. Спасибо, что пригласили. >> Итак, я вас рассмешу, но я недавно сделал выпуск о недавнем выпуске модели GPT 5.5, и я знаю, что вы и я используем Codex, и один из самых забавных комментариев в этом посте был: «Клэр, можешь ли ты сделать целый выпуск о техническом долге?» И мы разговаривали перед записью. Вы сказали: «Насколько техническая и насколько гиковская эта аудитория?» А я говорю: «Давайте!» Так что мы немного поговорим о том, как вы подходите к инжинирингу, а затем о том, как вы используете ИИ для таких вещей, как оптимизация медленных запросов. Итак, давайте начнем. Расскажите мне о вашем подходе к разработке программного обеспечения в эпоху ИИ. >> Знаете, я много работал над программным обеспечением для проведения оценок и наблюдения, и это сформировало мой собственный взгляд на разработку программного обеспечения. Теперь, когда модели так хорошо пишут код, одна из лучших вещей, которые мы можем сделать, — это создать действительно сложные оценки, и я не говорю об оценках ИИ. Я имею в виду такие вещи, как почему этот запрос так медленный, и если вы создадите правильные тесты и критерии успеха для модели, тогда она может быть очень креативной, и она может работать над этим в фоновом режиме и фактически пытаться улучшить множество вещей. Итак, одна из вещей, над которой я сейчас много работаю, — это ускорение запросов, которые люди выполняют в нашем продукте, и люди могут просто писать произвольные запросы, например, кто-то пытается найти иголку в стоге сена среди какого-то конкретного взаимодействия, которое произошло в их продукте, и они смотрят на миллиарды и миллиарды трассировок и хотят найти 5000 или около того, которые совпадают. И это за период в 90 дней или около того, много данных. И это один пример запроса. И, хорошо, есть все эти вещи, которые вы можете сделать в литературе по базам данных, такие как разные индексы, которые вы можете построить, и разные способы предварительной выборки данных и так далее. Но как вы пробуете все эти вещи и как вы запускаете все эксперименты, необходимые для выполнения чего-то подобного? Итак, что мы делаем, и над чем я лично много работал, — это пытаемся выяснить: вручную — это хорошо, но автоматически — еще лучше: каковы шаблоны запросов, которые люди запускают и которые медленные, а затем мы воспроизводим эти вещи и используем кодирующего агента, чтобы попробовать множество идей из литературы по базам данных. Например, скачать много данных локально, а затем, возможно, попробовать разные, в данном случае, я сейчас пробую разные форматы колоночных хранилищ. Мы используем индекс под капотом под названием Tantry, который имеет встроенное колоночное хранилище, но оно не очень хорошее. В целом вещь отличная, но их колоночное хранилище не очень хорошее. И поэтому сейчас мы исчерпывающе пробуем каждый формат колоночного хранилища с открытым исходным кодом, а затем исчерпывающе пробуем каждый движок выполнения колоночного хранилища и вычисляем матрицу этого, и это, знаете ли, это потрясающе. Я полностью согласен, как человек, который очень долго руководил инженерными организациями, когда вы пытаетесь внести изменения в инфраструктуру, платформу, основные компоненты вашего приложения, из-за высокой стоимости их внедрения и затем неизвестных неизвестных, которые довольно рискованны. Команды на самом деле довольно не склонны к риску, когда дело доходит до больших платформных сдвигов или изменений в их основной реализации. Это как вещь, которую вы отправили, это то, с чем вы застряли, безусловно, с инженерной стороны. И мне нравится в ИИ сейчас и в этих кодирующих агентах в частности, и в Codex в частности, это единственная настройка, Codex плюс эти модели GPT, которая позволила мне настроить очень похожий процесс, где желаемый результат — XYZ. Нам нужно программно тестировать довольно длинные структуры данных, чтобы выяснить, какие из этих потенциальных решений приблизят нас к желаемому результату. В вашем случае это скорость и задержка запросов к базе данных. В моем случае я занимался очень, вы это оцените, очень сложной миграцией данных >> хранилище, такое как хранимые структурированные и неструктурированные данные, сгенерированные ИИ. Все было в беспорядке с самого начала, а затем мне пришлось мигрировать это в схему, и это было как миграция схемы в схему, миллионы и миллионы и миллионы и миллионы строк и множество крайних случаев, и выполнение этого человеком занимает вечность. Вы знаете, вы можете написать скрипт, и вы можете использовать какие-то системы, но затем ваша человеческая способность управлять этими циклами и говорить «да, это правильно» или «нет, это неправильно» или «это дает нам указание двигаться влево» или «это дает нам указание двигаться вправо». И поэтому я чувствую, что эта комбинация очень точного результата и агента, достаточно умного, чтобы биться головой о действительно длинный хвост проблем с управляемым пониманием технической области, работает очень хорошо. И я не слышал этого со стороны хранилищ данных. Это действительно интересно. Но я просто думаю, что лидеры инжиниринга, я имел столько споров о том, что мы используем для нашего хранилища данных, как оптимизировать производительность, какие технологии следует внедрять в стек, а какие нет. И вы можете запускать эти очень, очень итеративные циклы, я полагаю, вы используете данные, похожие на производственные, или реальные репрезентативные запросы для их тестирования. Это так? >> Вы можете фактически использовать производственные данные, но для некоторых подмножеств вещей и с правильным инжинирингом вы можете просто работать с производственными данными. >> Да. >> И во многих отношениях это намного безопаснее, чем когда люди тестируют на производственных данных, потому что никто на это не смотрит. >> Да. И вот где у меня так много штатных инженеров очень, очень циничны относительно того, есть ли у ИИ место в их инструментах кодирования. Я все еще, как я говорю, в 2026 году, мы все еще разговариваем с инженерами, которые говорят, что ИИ в наших самых сложных задачах не может справиться хорошо. >> О, я, я, я так глубоко не согласен с этим. >> То же самое. Расскажите, почему вы не согласны. >> Ну, я думаю, что я работаю над базами данных почти два десятилетия. Есть не так много вещей, которые штатные, что бы там ни было, не склонные к риску, и так далее, которые вы могли бы применить, чем буквально создание базы данных. Если вы работаете над базой данных, мы недавно добавили эту модную индексную штуку в Brain Trust, которая использует фильтры Блума. И, кстати, мы обнаружили, что это будет практическим решением проблемы после недели непрерывных экспериментов с различными типами индексов. Фильтры Блума имеют плохую репутацию, но в данном случае они оказались очень эффективными. Так что, если вы создаете что-то подобное, обычно происходит то, что лучшие инженеры запускают несколько тестов, а затем вы отправляете их своим коллегам, и ваши коллеги разбирают их и говорят: «Вы не тестировали это, вы не тестировали то». И вы расставляете приоритеты для нескольких лучших тестов, а затем игнорируете остальные. Например, «О, я, я не тестировал это». Однако, если вы прочитаете код, вы увидите, что это не N квадрат, а логарифм, и поэтому этого не произойдет. И половину времени вы ошибаетесь. Теперь нет оправдания не проводить эти тесты. Так что теперь мы любим это. Мы не тратим время на то, чтобы сидеть и писать код для тестирования, но мы разговариваем с людьми. Мы смотрим на код. Мы смотрим на вещь. Мы говорим: «Хорошо, мы протестировали, насколько быстрее это делает запросы. Действительно ли мы хорошо протестировали, насколько медленнее это делает индексацию?» О нет, мы этого не сделали. И поэтому мы потратили некоторое время на это, и мы обнаружили, что мы ужасно справляемся с эффективной индексацией. И поэтому мы потратили много времени на это. И я, я не согласен с этим. Я могу, я могу понять аргумент, что модели не хороши в написании высококонкурентного кода или они не хороши в написании кода, чувствительного к производительности. Но я, нет ни одного штатного инженера, который проводит столько же строгих тестов, пробует разные алгоритмы и анализирует идеи вручную, чем тот, кто использует агента. И даже этот базовый уровень невероятен. >> Я согласен. И я думаю, что есть теоретическое качество, а есть практическое качество, верно? В теоретическом идеальном мире, в котором мы не спим, и каждый раз, когда мы садимся за ноутбук, мы пишем идеальный код, и в теоретическом мире, в котором все эти тесты проводятся, а не только те, что являются чушью. В этом теоретическом мире вы могли бы теоретически сказать, возможно, в каком-то непроверенном случае вы получаете лучшее качество, когда люди работают вручную. Но практическое применение заключается в том, что вы теряете контекст о том, что люди теряют контекст о проблеме в течение дней. У вас снижается концентрация внимания на сложных, но утомительных проблемах. И поэтому я думаю, что практическое качество снижается. И поэтому я говорю людям: практическое качество интеграции ИИ в ваш инженерный процесс при решении очень сложных технических проблем повышается просто из-за того, насколько интенсивно вы можете работать над проблемой и как долго и последовательно вы можете работать над проблемой. А затем, знаете ли, я собирался вернуться к тому, что сказал: вы можете браться за гораздо более интересные технические задачи с ИИ в качестве вашего, знаете ли, бокового помощника, чем раньше, опять же, практически, потому что ваша компания может поддержать стоимость этого. >> Если вы скажете: «Я хочу изолировать всех своих штатных инженеров, чтобы они решали наши проблемы с индексацией баз данных в течение следующего года, и мы действительно углубимся в детали, и мы протестируем эти шесть различных решений с открытым исходным кодом, и мы вернемся через год и скажем вам, нашли ли мы решение». >> Бизнес скажет: «Нет, вы знаете, вы, вы, вы генеральный директор». Например, «Нет, нет, спасибо». Но если вы скажете: «Эй, у нас будет эта штука в фоновом режиме, и мы будем ее проверять. Мы будем добиваться быстрого прогресса». Конечно. И мы можем выпускать другие вещи, пока мы это делаем. Я думаю, это очень легкое «да». >> Абсолютно. Да. Я имею в виду, я думаю, что девиз, который у нас есть сейчас, — это просто нет оправдания отсутствию строгости. Например, и нет оправдания отсутствию производительности, если кто-то жалуется на что-то. Если кто-то жалуется на мелкую царапину в пользовательском интерфейсе, знаете ли, что бы это ни было, просто нет, у нас нет бэклога. Нет оправдания просто не улучшать эти вещи. >> Да. И для тех, кто ищет, у нас нет бэклога вдохновения, мы только что брали интервью у Брайана из Intercom, который говорит, что их цель — бэклог ноль. Ничего в бэклоге, чтобы все можно было выпустить. Хорошо. Итак, мы решаем очень технические проблемы. Я думаю, это отличный подход. Как вы занимаетесь инжинирингом с помощью ИИ? Потому что мне нравится, что вы все еще, знаете ли, пишете код. Вы тратите на это время. Есть ли какие-нибудь советы или хитрости по управлению вашим парком агентов, которые, по вашему мнению, уникальны? >> Я думаю, что каждый должен посмотреть в зеркало и пересмотреть, как он тратит свое время. Есть много взаимодействий, которые у вас есть, или направлений, которые вы даете, или решений, которые вы принимаете. И я думаю, что многие из этих вещей для меня попадают под линию агента. И для меня линия агента — это как если бы я или кто-либо другой был на совещании или что-то еще, если бы мы эквивалентно взяли информацию, которую мы обсуждаем, и просто дали ее агенту, решил бы он ту же проблему? И я думаю, что линия агента продолжает подниматься, и также я думаю, что лучшие люди продвигают линию агента внутри своей компании, будучи умными в том, какие навыки они пишут и какие интеграции они строят и так далее. Так что, как только вы это сделаете, у вас, вероятно, будет гораздо больше времени, чем вы думали. Я не провожу никаких встреч после 12. Это последняя встреча дня для меня. И это означает, что каждый день я могу в рамках структуры Пола Грэма «график создателя против менеджера» входить в уровень концентрации, необходимый для графика создателя. И поэтому я лично пишу много кода и трачу много времени на написание кода. И я, я не тратил столько времени на написание кода так давно. И мне это очень нравится. Так что это номер один — выделите время. Мой рабочий процесс очень прост прямо сейчас. У нас еще нет отличной настройки фоновых агентов. Я думаю, что мы исследуем различные вещи и пытаемся туда добраться. Но у меня обычно пять или шесть фоновых агентов, работающих на моем компьютере. Каждый из них — сеанс T-U. Прямо сейчас я работаю над четырьмя вещами. Так что каждый из них — сеанс T-M. Они называются Brain Trust One через Brain Trust 4. И, знаете ли, у каждого из них есть какой-то UI и какие-то службы. Проблемы, такие как конфликты портов. Я не могу изолировать все так, как мне хотелось бы. И я думаю, что существует множество решений для тривиального программного обеспечения, которые делают это. Пока еще не так много решений для сложного программного обеспечения. И я в восторге. Я имею в виду, все, с кем я разговариваю, строят что-то свое. Я только что встретил стартап, которому два месяца, и они построили свой собственный внутренний инструмент для выполнения фоновых PR-запросов агентов, что я не осуждаю их за это, я не знаю, что бы они еще делали, но это своего рода безумие. А затем у меня также есть удаленные. Вот один, где я работаю над улучшением производительности нашего колоночного хранилища, и это работает не на реальных данных, но близко к реальным данным, и это работает удаленно, и это работает с гораздо большим масштабом, и я имею в виду, если бы я запустил это на своем компьютере, он бы, вероятно, вышел из строя из-за того, сколько вычислений он использует. Но я могу протестировать, какая реальная задержка между EC2 и S3, если я пытаюсь выполнить 4000 одновременных чтений. Достаточно ли этого? Недостаточно ли этого для этой рабочей нагрузки? Могу ли я правильно чередовать вещи? И я запускаю этот эксперимент уже несколько дней, пытаясь выяснить, что лучше всего. Сейчас я разговариваю с ним о том, каким должен быть жизненный цикл индексации, потому что я думаю, что мы выяснили, как ускорить запросы. >> Некоторые люди, которые слушают это, скажут: «О боже, это так технично. У меня нет таких проблем. Позвольте мне отступить для людей и рассказать вам, что я думаю, что вижу здесь, а именно: во-первых, вы используете Codex, верно? >> Да. >> Codex для сложных проблем, люди. Я говорю вам, просто >> Я думаю, что это единственная модель, которая будет регулярно с вами не соглашаться. И я думаю, что если вы работаете над сложными проблемами, это очень важно. >> А для вас, что я также слышу, это то, что вы используете фоновые агенты. Вы можете, по сути, иметь личный предел параллелизма, скажем, четыре. >> Конечно. Что примерно то же самое, что я могу сделать. Так что я думаю, люди спрашивают меня все время, как вы справляетесь со всем этим контекстом? Я говорю, я не делаю больше, чем, думаю, могу сделать в любой момент времени. И я также, у меня более тривиальные проблемы, чем у вас. Так что я думаю, вы правы в том, что нынешние коммерческие фоновые агенты, как я бы их назвал, которые вы можете купить готовыми, отлично работают для веб-приложений, стандартных веб-приложений. Я очень доволен ими. Если вы не используете один из них в качестве инженерной организации, возможно, это классический SaaS, очень, очень, очень рекомендую. Но я все больше и больше слышу от команд две вещи, которые вы упомянули. Я все больше и больше слышу, что люди просто создают своих собственных фоновых агентов. Так что это происходит. Это происходит в командах, очень, очень больших и очень, очень маленьких. Я думаю, примитивы существуют для начала экспериментов с этим. И поэтому я не думаю, что нам будет так удивительно слышать о людях, создающих своих собственных внутренних кодирующих фоновых агентов, даже если основная инфраструктура — это что-то от крупных поставщиков моделей. Я думаю, второе, что я много слышу, и мы слышали это от команды Stripe, — это инвестиции в облачные среды разработки и удаленные вычисления, опять же, потому что если бы вы запускали некоторые из этих вещей, особенно те, что связаны с большими данными, на своем компьютере, это начинает звучать как взлетающий самолет. Это не годится. И последнее, что я услышал от вас, это порты. Я шучу со всеми. Я говорю, рабочие деревья повсюду. Порты с 3000 по 3009 составляли, я просто, все. И я должен упомянуть Криса Тейта из Verscell, который выпустил вещь под названием Portless, которая просто делает управление несколькими локальными портами на вашей локальной машине немного приятнее. Так что для простых вещей я бы поискал это. Мы дадим ссылку в заметках к шоу на GitHub. Общие проблемы, с которыми, я думаю, сталкиваются люди при одновременном выполнении инженерных процессов на своих машинах, а затем мета-вещь, которая просто заключается в том, чтобы выделить время для кодирования. >> Вам это нужно, всем. Я тоже не провожу встреч после часа дня, иногда я провожу подкасты ранним днем для людей, но весь день я просто в своем реальном состоянии, это толстовка, плохая осанка. >> Я думаю, что вы, я уверен, тоже это чувствуете, но когда я писал большую часть своего кода вручную, я входил в это своего рода эйфорическое состояние потока, где я, знаете ли, полностью концентрировался на проблеме. А потом, когда я начал много работать с агентами, я потерял это на некоторое время. Но теперь, когда я пишу код, знаете ли, Lane 8 вчера выпустил новый альбом, вам стоит его послушать. Наденьте свою толстовку и наушники. Я снова в этом состоянии. Просто другой рабочий процесс. >> Да. И я дам людям своего рода, знаете ли, ИИ-маму интернета, которой я стараюсь быть, которая заключается в том, что я чувствую, что многие люди идут двумя лагерями: они получают больше удовольствия, чем когда-либо прежде, и они возвращаются в состояние потока того, что заставило их заняться разработкой программного обеспечения, строительством, технологиями или чем-то еще, или они подходят к тревоге, выгоранию, срыву из-за того, что они чувствуют эту тревогу продуктивности. И они не, я думаю, я думаю, что я вижу, что люди чувствуют, что если они на совещании и они не запускают агентов, они делают что-то неправильно, или если они разговаривают с кем-то и они не запускают агентов, они делают это, и я просто говорю: мне нравится идея разбивать ваше время с ИИ немного больше. >> Да, я думаю, это просто фокусирует вас на более продуктивных частях этого, и это также более приятный способ делать вещи. Да, у меня был этап, который, я думаю, я прошел. Знаете ли, моя жена Елена. Где мы ужинаем вместе, обычно почти каждый вечер. И поэтому у меня был этап, когда мой ноутбук не был за столом, но был открыт и на диване. И я думаю, что я уже прошел этот этап. Теперь ноутбук закрыт, и я думаю, это важная вещь. >> Я согласен. Когда я впервые использовал OpenClaw, я установил его на старый MacBook, и он оставался открытым на нашем кухонном острове, где все наши розетки, и он нависал над нами за ужином и за завтраком. И если его перемещали, я говорил: «Где Полли? Она жива? Она открыта? Она закрыта?» Так что да, закрывайте ноутбук, люди. Закрывайте ноутбук. Этот выпуск представлен вам Persona. Вы учитесь создавать с помощью ИИ, но есть важный вопрос, который вам нужно задать. Кто на самом деле использует ваш продукт? Это законный пользователь, бот или мошенник? Brex, Figma, Etsy и Twilio доверяют Persona, чтобы ответить на этот вопрос. С платформой проверки личности Persona вы можете создавать фирменные впечатления, автоматизировать предотвращение мошенничества и знать, кто является человеком в Интернете. Это позволяет легко предоставить хорошим пользователям опыт, который заставляет их чувствовать себя желанными, и остановить злоумышленников от причинения ущерба. А для тех из вас, кто занимается разработкой в области ИИ-агентов, Persona помогает вам проверять личности людей, компаний и разработчиков, стоящих за агентами. Именно так компании, такие как Lithic и Skyfire, расширяют границы коммерции с помощью агентов. Узнайте больше на withpersona.com. Хорошо, Итак, мы рассмотрели первую половину этого эпизода, которая, я думаю, очень интересна для технических специалистов. Как заставить долгосрочные или просто очень тщательные агенты работать над техническими проблемами, чтобы получить реальные тесты производительности при изменении вещей. Мне это нравится. Второе — это ваш основной рабочий процесс, как вы занимаетесь кодированием, как вы выделяете время, так и технически, каков ваш рабочий процесс. Давайте поговорим об оценках, потому что я чувствую, что это то, что очень пугает многих людей, и очевидно, вы создаете продукт, который поддерживает это, но отступив, почему вы думаете, что эта концепция так важна для понимания и как вы можете просто развеять мифы для людей, которые немного напуганы ею? >> Машинное обучение конкретно смещает задачу программирования с «как» на «что». И это правда, забудьте об LLM, знаете ли, это правда, скажем, когда вы были в средней школе, вы занимались статистической регрессией, вы не определяете, вы вычисляете, какими должны быть наклон и пересечение по оси Y, вы не определяете это, но вы даете ему все точки, которые являются, знаете ли, «что», а не «как», что является наклоном и пересечением по оси Y. И я думаю, что, знаете ли, классные инновации вокруг трансформеров и задачи предсказания следующего токена, которые позволяют, знаете ли, удалять токены и делать все эти классные вещи. Все дело в том, чтобы сказать: «Хорошо, вот вычислительная подложка, и вот «что», то есть результат. Это предсказание следующего токена. Можете ли вы пойти и использовать много GPU и выяснить, как этого достичь?» И я думаю, что если вы возьмете это как вдохновение для всего, что вы делаете с ИИ, тогда вы сможете быть более продуктивными. И я думаю, что это применимо к традиционному программированию, как мы только что говорили. Я не диктую точно реализацию или даже набор алгоритмов, которые мы используем для решения проблем. Я просто пытаюсь очень кратко определить, в чем проблема, почему это проблема и как оценить решения этой проблемы. Это также применимо к созданию программного обеспечения для ИИ, и это методология оценки для вас, чтобы сказать, вот как выглядит успех. На мой взгляд, оценки — это фактически современная версия PRD. Так что, PRD, вы бы сказали: «Эй, в плюсах, вот как выглядит успех». Оценки также часто пишутся в плюсах, но вы дополняете это примерами. Так что, знаете ли, лучшие PRD имеют хорошие примеры, такие как, возможно, кто-то сделал демо или написал историю пользователя или что-то в этом роде. Это то же самое. Разница с оценками в том, что вы кодируете эти пользовательские истории таким образом, чтобы их можно было в некоторой степени количественно оценить, а затем вы, а затем вы позволяете модели или чему-то еще выяснить, как, а вы действительно сосредоточены на «что». >> Приведите пример, как вы используете это в разработке продукта, чтобы сделать это немного более ощутимым для людей. >> Да, давайте начнем с чего-то, что, я думаю, довольно просто, а затем мы перейдем к менее простым вещам по мере продвижения. Итак, это наш пользовательский интерфейс. И я работаю над очень простой задачей: я пытаюсь создать промпт, который будет частью агента, который хорошо отвечает на вопросы о документации Brain Trust. Итак, мы посмотрели на несколько вопросов, которые люди задают в наших документах, и просто поместили их в набор данных. Вы можете загрузить CSV-файл, это не имеет значения. Просто составьте список вопросов или вы можете сгенерировать их автоматически. Что угодно, просто начните с чего-нибудь и написали очень простой промпт. Мы будем использовать GPT 5.4 mini, и я подключил сервер MCP. Так что я подключил сервер Brain Trust MCP. Мы также экспериментировали с Context 7, который индексирует документы для вас. Вы также можете отключить MCP и просто посмотреть, что модель уже знает о вашем продукте. Они становятся довольно хорошими в знании каждого продукта сейчас. И здесь я просто запустил его, и вы можете увидеть некоторые ответы. Я буду честен, я не очень хочу читать все это вручную. И поэтому я обычно начинаю с того, что говорю: «Эй, можешь ли ты придумать хорошую функцию оценки для этих результатов?» Мне важно иметь краткие фрагменты кода, использовать только один язык и, скажем, избегать тире. >> Всегда. >> Да, конечно. И теперь в этом случае GPT 5.4 перед этим пойдет и фактически посмотрит на все это для меня, и он посмотрит на некоторые результаты, и он перезапустит что-то, и он сделает свое дело, и он придумает новую функцию оценки. Одна из вещей, которые, кстати, довольно круты в этом рабочем процессе в целом, и я ожидаю увидеть это в большем количестве продуктов со временем, это то, что вы заметите, что у меня есть это в эквиваленте «безумного режима» кодирующего агента, который иногда опасно запускать на вашей машине, но этот агент работает внутри этой песочницы и использует данные и некоторые промпты и так далее. Так что риск позволить ему просто попробовать что-то очень низкий. И поэтому я думаю, я в восторге просто от того, что вижу агентов в большем количестве сред, кроме моего локального компьютера с bash и чего-то очень опасного, что могло бы испортить мою жизнь, если что-то пойдет не так. Я в восторге просто от того, что у меня больше агентов, которые работают в таких средах и делают все, что хотят. Я даже не знаю, что он делает прямо сейчас, но мы узнаем через несколько минут. >> Я очень взволнован этим. И просто для людей, которые не смотрят или которым нужен еще один набор контекста, по сути, что вы сделали, это вы взяли эти вопросы, которые люди задают на вашем сайте документации или в поиске или в любом чат-боте о том, как работает продукт. Вы создали небольшой промпт для ответов на эти вопросы. А затем прямо сейчас вы создаете, вы заставляете ИИ создавать оценщика, который говорит вам, насколько хорошо эти вопросы отвечаются на основе очень расплывчатого определения того, что вы хотите, чтобы он делал. А затем этот балл применяется, этот механизм оценки применяется ко всем этим, чтобы вы могли фактически ранжировать его? >> Да. Да. Да. Я думаю, что он немного выходит из-под контроля. Так что я переключусь на этот, который немного лучше. >> Мы делаем это в прямом эфире, мы любим прямую демонстрацию. >> Я знаю. И давайте используем Claude и попробуем. Так что этот немного чище, и он фактически написал промпт. Давайте используем более умную модель. Он не выбрал самую умную модель. Он написал промпт, который принимает входные и выходные данные, а затем оценивает их по этим критериям. >> Писать эти критерии вручную — это боль. Так что очень приятно просто позволить модели сделать это за вас. Да. >> И что мы можем сделать, это запустить его, и он количественно оценит, насколько хорошо модель справляется по этим критериям, а затем мы можем посмотреть на это по одному или, что я на самом деле делаю в последнее время, — смотрю на это в совокупности. И поэтому оценки начнут поступать сюда. >> Какова альтернатива, которую люди делают, что вы считаете менее эффективным? Одна из них — просто не делать этого. Я знаю, много людей. >> Да. Я имею в виду, я думаю, что многие люди, и я сам попадаю в эту ловушку, несмотря на работу над этим продуктом, так что нет никакого осуждения за это, но я думаю, что многие люди просто пробуют вещи на одном или двух примерах и обобщают это. И, честно говоря, я не думаю, что это плохая идея. Мне нравятся проверки настроения. Но, что происходит, так это то, что если вы делаете это, вы в конечном итоге играете в своего рода игру «ударь крота». Так что вы можете сделать это очень хорошо для одной или двух вещей, а затем вы выпускаете это, а затем это не хорошо для чего-то еще. И мы, у нас есть дизайнер по имени Дэвид. И Дэвид очень крутой. Он хорошо одевается. Он интересуется последней музыкой. Он любит музыку раньше других. Он сказал мне, что когда он был ребенком, он играл в футбол, и у всех были черные туфли, а он хотел оранжевые, а на следующий год все хотели оранжевые туфли. Так что он такой человек, верно? >> Да. И у нас происходит много ИИ-штучек. Так что для Дэвида, у которого есть ultimate, который является ultimate законодателем вкуса Brain Trust, непрактично смотреть на все вручную. И на самом деле я запускаю тонны оценок, чтобы количественно улучшить вещи, а затем, когда я чувствую, что оценки хороши, и мой собственный менее сложный вкус думает, что результаты хороши, я иду к Дэвиду и прошу его проверить настроение. И я, вероятно, делаю это примерно раз в несколько дней. И тогда Дэвид дает мне проверку настроения, и примерно половину времени он просто полностью уничтожает все, что я сказал. Например, «Эй, вы думаете, что это хорошо, но на самом деле это не очень хорошо». И тогда я возвращаюсь и пытаюсь зафиксировать то, что сказал Дэвид, и говорю: «Эй, Дэвид на самом деле думает, что нормально показывать оба языка, если вы знаете, бла-бла-бла-бла-бла». И тогда я пытаюсь как бы зафиксировать Дэвида, а затем улучшить оценщиков, а затем попытаться количественно оценить Дэвида. А затем в следующий раз, когда я пойду к нему, я не повторю ту же ошибку, но я все равно получу его проверку настроения. Ну, и я просто должен упомянуть мета-вещь здесь в этой истории Дэвида, которая мне очень нравится, которая заключается в том, что многие люди говорят: «Вау, если я зайду так далеко, что превращу свой собственный вкус, свои навыки или свой опыт в систему, будь то система, такая как оценка Дэвида, судья Дэвида в цикле, или что-то еще, я фактически просто создаю свою замену». И я предполагаю, потому что я это делаю, и похоже, вы тоже. вы цените Дэвида больше в этой системе. >> О да, да, да. Мы можем применять палитру Дэвида к большему количеству вещей, например, к планке качества, которую мы можем достичь, выше, потому что мы можем довести больше вещей до этой планки. >> Мне нравится. Хорошо, так что это был мощный эпизод. Один из моих любимых. Мы много говорили о решении очень технических проблем с помощью ИИ. Мы немного развеяли мифы об оценках для людей и показали, как в безопасном пространстве вы можете фактически позволить ИИ думать, что это одна из мета-тем этого — в безопасном пространстве вы можете позволить ИИ работать с большой автономией, и вы, вы знаете, бросите в него много данных, и вы получите более высокое качество результатов, гораздо больше, чем если бы вы вручную исправляли вещи или даже вручную оценивали их. Я проведу быструю молниеносную сессию, а затем мы вернем вас, я имею в виду, почти полдень, так что время кодировать. >> Время кодировать. Время кодировать. >> Один, у меня есть вопрос. Когда вы говорите, что нет оправдания, нет оправдания ошибкам. Нет оправдания мелким дизайнерским недочетам. Нет оправдания этому. Как вы думаете, как вы практически, возможно, у меня есть два вопроса, на которые вы можете ответить. Это будут наши две молниеносные сессии. Как вы практически управляете скоростью для клиентов, то есть, никогда ли клиенты не говорят: «Подождите, что это? Подождите, что это?» Слишком много функций просто потребляется как клиент. А затем два, как вы технически управляете пропускной способностью в систему? >> Создание продукта и написание кода теперь выглядит как резьба, а не строительство. Так что очень быстро создать что-то с слишком большим количеством функций, слишком большим количеством кнопок и слишком большим количеством кода, и вам нужно потратить много времени на удаление вещей. И поэтому мы фактически, я бы сказал, в 90% случаев, когда кто-то жалуется на что-то, мы удаляем вещь, которая вызывала путаницу, и просто делаем систему лучше, потому что мы теперь понимаем точку зрения человека, который жаловался, и мы можем создать продукт, который даже не нуждается в сложности, которая привела их к путанице в первую очередь. Я приведу пример. Если вы загружаете трассировку и представляете, что нажимаете Command F, вы можете в своем мозгу подумать, что это просто поиск того, что на странице, но то, что на странице, может быть сотнями мегабайт текста, и это виртуализировано, и это по разным диапазонам, и также есть таблица. Итак, у нас была очень мощная реализация поиска, которая искала по диапазонам и ранжировала все, и, знаете ли, бла-бла-бла, все эти классные вещи. А затем многие люди жаловались, и они просто говорили: «Почему это, я просто нажал Command F. Я просто хотел, чтобы показать вещь», и мы действительно упростили это со временем. Так что я думаю, я думаю, мы стараемся вырезать, а затем с точки зрения технического управления этим, мы тратим гораздо больше времени на CI, чем раньше. И поэтому я думаю, что много усилий платформы сместилось так, что если мы действительно хороши в CI, то мы можем двигаться быстрее, и если мы чувствуем, что нас ограничивают, вместо того, чтобы выпускать кучу дерьмовых вещей, мы говорим: «Хорошо, давайте сделаем паузу и улучшим CI, чтобы мы заработали способность двигаться быстрее». >> Снова для вице-президента по инжинирингу на заднем плане инвестируйте в CI. Я говорил всем, они спрашивают: «Как мне ускорить мою инженерную скорость с помощью ИИ?» Я сказал: «Исправьте свой CI». >> Да. Да. >> Каждый инженер теперь строит платформу, и на платформе агенты выполняют работу, которую инженеры делали вручную, верно? И я думаю, что это применимо к оценкам. Например, если вы инженерная команда и вы создаете ИИ-продукт, ваша главная задача — создать петлю обратной связи. Это означает, что у вас есть конвейер, который позволяет вам вызывать из эфира реальные данные и превращать их в оценки. И как инженерная команда, это ваша главная задача. Это не промпт-инжиниринг. Это не выбор фреймворка агента. Это не переписывание вашей базы данных, что угодно. Это создание этого конвейера. И то же самое верно для CI, это та же идея, но примененная к разработке программного обеспечения. Ну, и я дам еще один совет, который заключается в том, что вы думаете, что эти люди, занимающиеся оценками, всегда говорят: «О да, для моего ИИ-продукта мне это нужно». Я видел снова, я думаю, команда Intercom провела много оценок своего внутреннего использования кода Claude, чтобы выяснить, где инженеры сталкиваются с проблемами, где люди сдаются, где агенты запрашивают разрешения, которые должны быть эскалированы. И я думаю, что такой анализ в вашей команде очень, очень важен и в конечном итоге приведет вас к этим лучшим результатам. Хорошо, последний вопрос. Вы кажетесь очень рассудительным человеком. Так что я предполагаю, что получу очень разумный ответ, но я спрашиваю всех. Когда одна из ваших четырех вкладок не делает того, что вы хотите, когда оценки проваливают тест Дэвида, что у вас есть в кармане в качестве стратегии промптинга, на которую вы полагаетесь? Вы кричите? Вы подкупаете? >> Закрыть сеанс. А затем я улучшаю оценки и снова начинаю с нуля. Да. Да. >> Это человек, который придерживается темы. >> Да. Я имею в виду, я приведу вам пример. У нас есть этот сценарий использования с открытым исходным кодом, извините, модель, сценарий использования, где мы запускаем модели с открытым исходным кодом, и мы обрабатываем миллионы токенов в секунду. Это очень, очень масштабно. Так что каждый цент имеет значение, и каждая оптимизация имеет значение. Мы пытаемся сейчас перейти от модели А к модели Б, и я снова, я человек, который создает программное обеспечение для написания оценок. Я написал скрипт оценки с помощью vibe, и он застрял, а затем я прочитал код, и это около 3000 строк полного мусора, и у него были все эти функции оценки и вся эта чушь, и он запутался, и поэтому я в субботу я написал вручную, без автопилота, без автозаполнения, я просто, отчасти для улучшения моего собственного понимания проблемы, я написал оценку вручную, и к концу воскресенья проблема была решена. >> Да. >> Так что вы закрываете сеанс, вы делаете это сами. >> Да. Только для оценки. Только для оценки. >> Отлично. Это было так здорово. Где мы можем найти вас и как мы можем помочь? >> Если вы заинтересованы в оценках или вы пытаетесь решить проблемы с ИИ-наблюдаемостью в вашей компании, пожалуйста, ознакомьтесь с BrainTrust. Мы находимся на brainust.dev, brain onx, или я ankrg yl. Я очень рад пообщаться. Мы также нанимаем. Если вам нравится работать над этими проблемами, и вам нравится, возможно, расширять границы строгости и так далее, и вам показалось интересным это, мы будем рады с вами поработать. >> Ну, спасибо большое за то, что присоединились. Это было здорово. >> Было очень весело. >> Большое спасибо за просмотр. Если вам понравилось это шоу, пожалуйста, поставьте лайк и подпишитесь здесь на YouTube или, что еще лучше, оставьте нам комментарий со своими мыслями. Вы также можете найти этот подкаст на Apple Podcasts, Spotify или вашем любимом подкаст-приложении. Пожалуйста, рассмотрите возможность оставить нам оценку и отзыв, которые помогут другим найти шоу. Вы можете увидеть все наши выпуски и узнать больше о шоу на howiipod.com. До скорой встречи.