Transcription
У нас сейчас будет еще несколько сессий до обеда. И первая из них, э-э, я думаю, имеет одно из самых заманчивых описаний. Э-э, стек Пола, я прокрутил вниз, и там написано: "Мы расскажем, почему мы приняли решение прекратить писать код". Я остановлюсь здесь. Думаю, это звучит отлично. Давайте все просто перестанем писать код. Мне нравится эта идея. Э-э, для тех из вас, кто был здесь раньше, когда было очень, очень многолюдно, у нас есть еще стулья, которые мы принесем к обеду. Так что, э-э, когда позже станет многолюдно, э-э, будет много мест, где можно будет посидеть. Не волнуйтесь. Э-э, но я передам слово прямо сейчас, потому что, э-э, Пол здесь, чтобы поговорить о том, почему он прекратил писать код. [фыркает] Спасибо, Пол. [аплодисменты] [аплодисменты] Для тех, кто смотрит прямую трансляцию, в комнате абсолютно полно народу. Это не так, не слушайте, что я говорю. Я шучу. Я прикалываюсь. Хорошо. Итак, меня зовут Пол Стэк. Э-э, я здесь, чтобы поговорить о том, что если люди проектируют систему, то ИИ пишет код. [фыркает] Я хочу, я хочу, чтобы вы дали мне 25 минут. Это все. И я покажу вам, почему код больше не имеет значения. Код на самом деле не является главным. И как раз перед тем, как я вышел, я присоединился к сцене, я запустил процесс, который является нашим процессом того, как мы на самом деле создаем системы в нашей компании. И я покажу вам результат в конце. Так что мы не пишем ни строчки кода. Хорошо? Ни одной строчки кода я не написал с конца января, я не знаю, может быть, с конца января. Так мы работаем. Так работаю я. Я не говорю вам, что так вы должны работать. Поверьте мне, это очень освобождает, когда вам больше не нужно заботиться о коде. Но я обещаю вам, это очень интересное направление и очень интересный путь. Я покажу вам наш процесс подробно, и вы сможете взять то, что вам полезно. Все, что я вам покажу, является открытым исходным кодом. Вы можете с этим поиграться. Вы можете посмотреть на это. Вы можете увидеть, какая там сумасшедшая идея. Но к концу я хочу, чтобы вы подумали о типах вещей, которые вы можете делать. Хорошо. Различие здесь между написанием кода и созданием машины, которая пишет код. Хорошо. В эпоху ИИ это очень интересная вещь. Мы слышим, что это называется программными фабриками, темными программными фабриками, всеми этими разными вещами. Все сводится к очень похожему делу и очень похожему процессу. Итак, сегодня мы поговорим о том, почему мы перестали писать код. Хорошо, что изменилось, когда мы это сделали, как мы разработали руководящие принципы, что означает наш шаблон "архитектура прежде всего", как "swamp" я расскажу вам немного позже об этом сумасшедшем названии и как ИИ возвращает вам работу, ради которой мы на самом деле пришли в индустрию. [фыркает] Итак, узким местом больше не является мышление в программном обеспечении. Хорошо. Раньше нам приходилось думать о том, как мы воплощали идею, как мы доносили эту идею до пользователей, как мы тестировали эту гипотезу, и временные затраты на это требовали огромных инвестиций, и нам приходилось вкладывать много предварительных размышлений и процессов. Хорошо, в компании, где я раньше работал, она называлась System Initiative. Буквально на прошлой неделе мы запустили совершенно новую компанию на основе этого, и она называется Elder Swamp Club. В System Initiative мы потратили шесть лет на создание продукта. Хорошо, мы пытались революционизировать инфраструктуру как код и способы ее использования. Это была самая красивая, и я действительно имею в виду, самая красивая архитектурно спроектированная кодовая база на Rust, которую вы когда-либо видели. Хорошо, это была невероятно хорошо спроектированная распределенная система, которая запускала множество микросервисов, которые общались друг с другом через шины событий и делали много всего. В конце января мы выбросили каждую строчку ее. Каждую строчку. И это не потому, что код был плохим. Это потому, что продукт, который нам нужно было переосмыслить для эпохи агентов. Продукт не будет резонировать, когда мы будем двигаться вперед с ИИ. Теперь мы, к сожалению, расстались с командой в то время, и пятеро из нас остались. Пятеро из всей компании остались. И 25 января мы начали с зеркальной доски, без единой строчки кода, написанной во всей системе. Мы сказали: "Так, давайте перепроектируем что-то с нуля и подумаем, что мы на самом деле сделали". Этот слайд, я впервые представил этот доклад два месяца назад, и я сказал: "Два месяца, абсолютно в восторге от того, что у нас есть". Четыре месяца, я поражен тем, что мы построили. Хорошо? И я искренне это имею в виду. Не потому, что я это построил, а потому, что я на самом деле построил продукт, с которым я всегда хотел работать как операционный специалист. Да, я операционный специалист, разработчик. Я писал код в течение долгого времени. И поэтому у меня очень большой интерес к тому, что мы на самом деле пытаемся построить здесь. Я работал в HashiCorp, создавая Terraform. Я работал в Palumi, создавая Palumi. Я некоторое время работал в сфере инструментов для разработчиков. Так что я невероятно предвзят. Невероятно предвзят. Поэтому для меня очень важно построить что-то, что меня действительно волнует. Итак, вопрос в том, если я не пишу код, что я делаю вместо этого? На самом деле, это даже лучше. Хорошо, я разлюбил код, может быть, два года назад. И причина, по которой я разлюбил код, заключается в том, что я был на звонке в Zoom с пятью другими людьми, и они говорили о соглашениях об именовании очередей NATS, и я просто хотел сойти с ума. Хорошо. Самая неинтересная вещь в мире для меня лично. Люди, с которыми я был на звонке, любили это. Они были так заинтригованы этим. Они действительно хотели, чтобы это было идеально. Мне было все равно. Хорошо. Я просто хочу кое-что отметить. Я из Северной Ирландии. Если я ругаюсь, это просто происходит. Это просто я даже не осознаю, это просто вырывается. Так что, прошу прощения заранее. Хорошо. Итак, для меня сейчас, то, что я на самом деле делаю, это, даже несмотря на то, что я владею продуктом, потому что я как бы фактически отвечаю за него, но я на самом деле владею архитектурой, которая идет с продуктом. Меня волнуют проектные решения, ограничения, инварианты, вещи, которые делают эту систему связной для пользователя во времени. Инженеры получают стабильно хороший результат, когда они выражают то, что хотят с точки зрения архитектуры. Я написал пост в блоге об этом, может быть, три недели назад, под названием "Вайбы не масштабируются". Хорошо, не масштабируются. Краткое содержание блога: они не масштабируются. Хорошо, если вы пишете код на "вайбах", и нет идеи о том, что вы пытаетесь сделать, и вы даете одну строку подсказки, вы чего-то достигнете. Будет ли это самый безопасный, самый полезный инструмент со временем? Скорее всего, нет. Вам придется вложить серьезное время, и вы, вероятно, потратите много токенов, чтобы сделать это. [фыркает] Поэтому мы стараемся устанавливать конкретные, недвусмысленные ограничения, что означает, что мы запретили написанный вручную код. Абсолютно запретили. Мы не можем, никто из нас, как инженеров или людей, работающих в компании, не может отправить пул-реквест, написанный нами. Он будет удален, убран, даже не закрыт. Он будет буквально просто удален как пул-реквест. Это не рекомендация. Это не предпочтение. Это буквально то, как мы работаем. Агенты пишут каждую строчку кода. Хорошо? Вы можете зайти в наш репозиторий. Даже несмотря на то, что агенты пишут код, я обещаю вам, это не ужасно. Я бы сказал, что это здорово. Это не так. Я имею в виду, будут вещи, на которые вы посмотрите и скажете: "Мне это не нравится. Мне не нравится, как это расположено". Это вкус. Хорошо? Это, знаете ли, наименее важная часть этого. Соглашения об именовании. Сколько раз мы спорили в пул-реквестах как инженеры-программисты о соглашениях об именовании и о том, сколько строк должен иметь класс, прежде чем он будет рефакторен? Я однажды слышал нелепый, абсолютно нелепый разговор, где кто-то сказал, что если класс имеет более 100 строк, он должен быть выделен в свой собственный микросервис. Я говорю: "Да ладно, это глупо. Это абсолютно безумно". Хорошо. Итак, для нас гораздо важнее то, что мы даем LLM, нашим агентам, очень строгие операционные и проектные руководящие принципы. Хорошо, это то, над чем мы работаем изо дня в день. Мы работаем над дизайном системы. Мы работаем над ограничениями, в рамках которых должен работать агент. Мы работаем со всеми частями, для которых агент должен формировать очень строгие защитные барьеры. Это шаблоны, границы, архитектурные ограничения, знаете ли, инварианты, которые мы должны соблюдать, вещи, которые потерпели неудачу в прошлом, где вам нужно передать эти данные обратно, чтобы агент не совершил ту же ошибку снова, потому что вы знаете, что агенты плохи. Они будут совершать ошибки. На самом деле, они скажут вам, что они не совершили ошибку, но они абсолютно совершили ошибки. Итак, это не документация для нас. Это фактически исполняемые ограничения. И это то, что действительно, действительно важно. Хорошо. Кроме того, поскольку мы не пишем код, мы не принимаем чужой код. Мы являемся инструментом с открытым исходным кодом. Мы поговорим об этом немного позже. Я искренне верю, что нормы открытого исходного кода сейчас меняются в мире ИИ. Так много проектов перегружены инструментами на основе ИИ, кодом на основе ИИ, который поступает в систему, и они просто не хотят его поддерживать. Так много людей создали инструменты вокруг этого, чтобы остановить это. Митчелл Хашимото создал инструмент под названием "vouch", где вы фактически должны поручиться и сказать, что вы не агент, и что вы на самом деле, знаете ли, правильный человек, который отправляет код. Мы не принимаем никаких пул-реквестов ни в какой форме. И это не потому, что я не доверяю вашему коду. Я абсолютно не доверяю. Но то, что я пытаюсь сделать, это сохранить целостность нашей цепочки поставок. Хорошо. У меня есть конечные пользователи бинарного файла. Последнее, что я хочу сделать, это попытаться открыть поверхность атаки, где кто-то, кто неизбежно умнее меня, сможет внедрить код в систему. И вы видите так много таких проблем, происходящих по всему интернету сегодня. Хорошо, Trivy был абсолютно уничтожен пару месяцев назад. Хорошо, мы видели атаку "mini shy hol" на прошлой неделе, где 364 npm-пакета фактически находятся под угрозой в системе. Так что, знаете ли, мы очень сильно полагаемся на то, что ИИ будет генерировать очень правдоподобный, хорошо отформатированный, протестированный код в масштабе, и если нам придется создавать и смотреть на этот код, мы никогда не сможем отличить, что является атакой на цепочку поставок, а что на самом деле является изменением в самом коде. Так что мы просто запретили это. Хорошо. И, конечно, мы столкнулись с большим сопротивлением со стороны людей. Они говорят: "О, знаете ли, это не кажется очень хорошим. Я абсолютно готов принять вас в качестве движущей силы нашего продукта. Предоставьте мне проблемы. Предоставьте мне запросы на функции. Предоставьте мне проектные спецификации, которые вы считаете более интересными. Предоставьте мне идеи, где код не очень хорош, и система фактически поможет продвинуть его вперед". Итак, у нас есть полный поток от идеи до слияния кода, и наш поток выглядит примерно так. Хорошо, у нас есть начало, и вы обрабатываете проблему. Хорошо, мы на самом деле написали, как ни странно, мы находимся в мире ИИ. Мы написали навык. Хорошо, все пишут навыки. Наш навык основан на CLI. Хорошо, наш навык, как наш навык, просто защитные барьеры, запускающие правильные CLI-инструменты для этого. Но фактически, что здесь происходит, это то, что мы обрабатываем проблему или запрос на функцию. Затем она классифицируется. Затем она попадает в цикл планирования, генерации, обзора, планирования, генерации, обзора, планирования, генерации, обзора. И это враждебный обзор. Хорошо. Так что здорово, что план, знаете ли, агент скажет: "Это лучший план для того, что вы делаете". Затем я написал, я написал очень ворчливый враждебный обзор, который говорит: "Вы не доверяете никакому коду в мире. Вы должны доказать, что он безопасен. Вы должны доказать, что в нем нет атак внедрения. Вы должны доказать, что он архитектурно завершен в соответствии с руководящими принципами". И эти два агента фактически вступают в этот цикл, чтобы выяснить, когда это станет правильным делом. Мы доходим до пяти. Хорошо. Мы разрешим только пять циклов, прежде чем он вмешается и скажет: "Эй, мы не можем договориться об этом. Вы должны быть арбитром того, что происходит". [фыркает] В этот момент мне приходится вмешиваться. Человек в цикле сейчас, в этот момент. План генерируется. План безопасен на основе враждебного. Человек должен сказать, что это правильная функция. Это правильное исправление ошибки. Вот причины, почему. Затем мы начинаем реализацию. После реализации мы воссоздаем ее. Если это ошибка, мы пытаемся ее проверить. Если это функция, то она попадает в пул-реквест, открытый. Пул-реквест открыт, проходит через другой набор обзоров. Если он не прошел, то он возвращается к реализации и так далее. Затем мы уведомляем или, прошу прощения, выпускаем его, а затем уведомляем пользователей, которые его запросили, и мы закончили. Хорошо, это не куча скриптов оболочки, потому что их было бы ужасно поддерживать. Это фактически конечный автомат внутри навыка в CLA. Невероятно просто, но на самом деле невероятно мощно, потому что я могу расширять конечный автомат в любом виде. Для нас вся точка входа в систему — это наш claw.md. Да, мы пользователи claw-кода. Хорошо, agents.mmd вы можете подставить и сделать то же самое. Для нас это claw-код. Хорошо, это исполняемый контракт. Это буквально центр гравитации в нашей всей системе. И поэтому каждый сеанс claw-кода или CI будет читать этот claw-код по умолчанию. Теперь наш cloud-код немного отличается. Мы не встраиваем все слова, как бы. Мы не очень хороши со словами. Мы инженеры-программисты. У нас есть такие вещи. Хорошо, TypeScript. Он должен быть строгим. Никаких "any", потому что "any" — это дьявол. Он должен быть именованными экспортами, без значений по умолчанию. Он должен иметь AGPL-авторское право вверху каждого файла. Никаких обещаний "выстрелил и забыл". Не теряйте память людей. Правильно? Затем архитектура. Все должно иметь журналы и конечные точки JSON. Все должно импортироваться из модов. Вы никогда не должны раскрывать внутренние пути, потому что это деталь реализации. Это те типы ограничений, которые нас волнуют. Хорошо, это те типы вещей, которые очень, очень важны. А затем внизу нашего claw-кода всегда есть строка, которая гласит: "Эй, если вы столкнулись с неочевидной проблемой во время сеанса, которая может помешать будущим пользователям, будущим сеансам claude, будущим сеансам агентов, запишите ее и предложите обновление для вашего claw.MD, прежде чем мы продолжим". Итак, когда мы переходим к полной стратегии тестирования. У нас есть модульные тесты, интеграционные тесты, контрактные тесты, свойства тесты, архитектурные тесты, и это конец бинарного файла. Как только бинарный файл построен, мы берем этот построенный бинарный файл и отправляем его в другой репозиторий. Мы полностью выводим его из контекста всего остального и запускаем его как пользователь. Мы фактически запускаем старые UAT-тесты. Запустите этот скрипт. Вот намерение того, что он собирается сделать. Выполните эту команду. Вот что он произведет. Никогда не кодируйте слова вручную. Это было бы безумие. А затем у нас есть еще один набор тестов, которые находятся сверху. Враждебные тесты. Хорошо, эти тесты пытаются внедрить, пытаются убить процесс посередине, пытаются убить данные, пытаются удалить их, пытаются сделать все, что в конечном итоге сделает пользователь. Не по ошибке. Они просто делают это. И это просто то, что происходит. Пользователь — ваш лучший пользователь, ваш лучший QA всей вашей системы. Мы стараемся обрабатывать ошибки, которые поступают, и возвращаем их в качестве враждебных. Затем берет на себя управление наш CI. CI для нас фактически имеет пять уровней слияния. Хорошо, у нас есть обзор кода, потому что нам нужен обзор кода. Это просто так работает. Но затем у нас есть враждебный обзор. Предположите, что все сломано. Попытайтесь доказать, что это сломано. Затем у нас есть обзор пользовательского опыта. Проверьте CLI. Убедитесь, что он не регрессирует вывод. Убедитесь, что команды имеют правильную структуру. Мы стараемся идти по принципу "существительное-глагол". Так что мы стараемся сохранить эту, знаете ли, вещь, создать вещь, получить вещь и так далее. Так что мы стараемся обеспечить эту согласованность, и мы должны закодировать это как этап обзора. Затем, конечно, нам нужен обзор безопасности CI, потому что всевозможные хитрые люди будут пытаться внедрить что-то в мой конвейер CI. Так что я хочу поймать это до того, как оно даже начнется. И затем последнее, что удивительно, учитывая, где мы находимся и все, что сказал Гай, это то, что для нас проверки навыков невероятно важны. Хорошо, не только сам навык, но и контент, формат, макет, триггеры. Это жесткий барьер для нас. Наша система невероятно настроена на управление агентом. Поэтому опыт агента должен быть очень хорошим. Так что мы буквально блокируем любые регрессии в контенте или опыте по мере продвижения. Когда все проходит, он сливается сам. Я не шучу. Хорошо. Причина, по которой я не шучу, заключается в том, что если я покажу вам этот пул-реквест, слитый незадолго до того, как я вышел на сцену. И вы можете видеть, что пул-реквест был открыт моим агентом. Он прошел первый обзор. Затем этот прошел. Затем он проходит большой блок и обзор, типа "не могу этого сделать". Агент затем выяснил, что ему пришлось внести некоторые изменения прямо здесь. Продолжает идти. Это все контекст, который невероятно важен. Вот новое изменение, и агент фактически смог воспроизвести себя, выяснить, что все в порядке. Эти предложения все в порядке, а затем он автоматизируется и запускается. Хорошо, мы не делаем ничего необычного. Мы просто доверяем процессу, который мы постоянно совершенствуем. Итак, для нас барьер — это наш UAT. Просто потому, что часть этого слита, не означает, что это автоматически доходит до конечного пользователя. У нас есть весь этот уровень тестов, которые проходят, и мы ловим регрессии каждый день, прежде чем они дойдут до конечных пользователей. Абсолютно каждый день, и это блокирует наш конвейер, и никто другой не может опубликовать релиз, пока это не будет исправлено. Теперь самое важное здесь — в нашем UAT-репозитории есть строка, которая гласит: "Тесты — источник истины. Не меняйте тесты. Всегда выясняйте, является ли это регрессией в бинарном файле". И то, что мы получили за последние 30 дней, это 295 открытых проблем. И это проблемы, а не просто ошибки, но и запросы на функции и так далее. Я выпустил 27 из них. Я закрыл 81 как дубликаты или просто то, что мы не будем делать. Медианное время обработки составляет, это не рабочие часы. Это elapsed часы в день — 4,6 часа. И от обработки до выпуска, включая все эти уровни, — 1,6 часа. Хорошо. В компании, где я работаю, пять человек. У каждого из нас есть Claw Code Max Pro, который стоит 200 долларов. А затем мы тратим около 1500-2000 долларов в месяц на весь процесс обзора CI. Мы можем выпускать программное обеспечение во много раз быстрее за 3000 долларов в месяц, чем раньше. Это действительно не так. Но то, что мы на самом деле смогли сделать, это научить систему отлаживать себя. Хорошо. Так что Swamp фактически знает, когда он сталкивается с ошибкой. Он проверит систему контроля версий кода в той версии, где у него ошибка. Он попытается воспроизвести ошибку, а затем откроет проблему от вашего имени. Он даже проверит, была ли проблема исправлена в более поздней версии, прежде чем она произойдет. Так что мы пытаемся включить этот защитный барьер в то, что мы делаем. И мы получаем такой вот очень плотный цикл с ошибками, что означает, что ошибки, которые мы получаем от агента, невероятно хорошо сформированы и имеют много отличного контекста, который идет с ними. [фыркает] Итак, для нас мы не просто автоматизируем код. Мы на самом деле строим всю систему, которая поддерживает работу системы и поддерживает ее. И то, что нас волнует здесь, это то, что нам больше не нужен фактор автобуса. Мы все работаем в командах, где один человек является главным архитектором, к которому нужно обратиться по поводу части системы, которая не менялась каждые шесть месяцев или каждый год. Хорошо. Мы делаем это в инфраструктуре как коде. Мы делаем это на платформе. Мы делаем это в реальном программном обеспечении все время. Хорошо. Мы пытаемся устранить этот фактор автобуса, потому что мы пытаемся сделать агента осведомленным о системе. Агент каждый раз находится в свежем контексте. В прошлом, я даже не знаю, сколько, может быть, два месяца, я не запускал /cle в своем контекстном окне. Хорошо. Потому что каждый отчет — это совершенно новое рабочее дерево claw, которое делает его очень сфокусированным, очень конкретным, и это означает, что он фактически заботится только о контексте в этой области. Итак, как вы можете начать? Хорошо, потому что в этом вся суть, почему мы на конференции, подобной этой. Хорошо, самый маленький возможный способ сделать это, и я говорю об этом со многими людьми. Хорошо, превратите свои соглашения в ограничения. Хорошо, сядьте и подумайте об ограничениях, которые сейчас, если вы поместите агента на часть программного обеспечения в вашем контроле версий, которое он не знает, он не сможет получить из самого контроля версий. Это первое, что вы абсолютно можете сделать. И эти ограничения действительно важны. Закодируйте ту единственную вещь, которую знает только один человек в организации, в организации IT-программного обеспечения. Хорошо, потому что такой человек определенно есть в каждой организации, 100%. [фыркает] Хорошо, запустите этот цикл один раз от начала до конца, выясните, где он ломается, и это следующее ограничение, которое вам придется пройти. Вы всегда должны начинать очень маленькими шагами и просто настраивать. Вы просто не можете направить агента на весь ваш репозиторий исходного кода и просто представить, что все будет хорошо. Это не будет хорошо. Это абсолютно не будет. Но если вы сделаете это правильно и таким маленьким контролируемым способом, то ИИ вернет вам работу, ради которой вы пришли в индустрию, решая проблемы пользователей, создавая системы для конечных пользователей, имея архитектуру и проектирование систем. Я писал в блоге на прошлой неделе, что намерение — это новая архитектура. Оба предыдущих выступления в этой комнате, ребята, а затем выступление Даны были отличным отражением того, куда движутся люди в этом отношении, и мне понравилось видеть оба, потому что контекст — это новый код, а Дана начала говорить о том, что намерение — это то, как вы управляете системой в дальнейшем. Вы можете видеть, что многие из нас начинают приходить к тому же соглашению, тому же консенсусу о том, что на самом деле происходит здесь. Итак, как я уже говорил, я запустил триаж образа swamp перед началом этого доклада. Хорошо, я начал с команды вверху, которая гласит: "триаж проблемы номер 518". Он загрузил навык. Он выполнил пару команд. Это фактические команды swamp. Это наши команды CLI, которые устанавливают защитные барьеры для системы. Затем он извлекает детали проблемы, начинает понимать кодовую базу. Он начинает читать операционные файлы. Он начинает читать весь контекст, который ему на самом деле нужен. Затем он возвращает мне список сводных данных. Вот что я нашел. Вот что происходит. И затем, благодаря этому, он может классифицировать ее и фактически сказать: "Эй, это ошибка. У меня есть все необходимое для написания плана". Затем он строит очень структурированный план. И поскольку это очень структурированный план, он фактически способен дать мне очень подробный вывод того, что представляет собой план, плюс любые враждебные предупреждения, которые там происходят. Хорошо, это не, честно говоря, когда я говорю, что это не супер умный. Это просто создание руководящих принципов и защитных барьеров. Это на самом деле то, о чем я говорю здесь. Где мой экран пропал? Да, вот он. [прочищает горло] Итак, здесь очень важно, что мы находимся в ситуации создания этой установки, этой структуры, этой другой части, которая вам нужна, чтобы построить эту фабрику, эту систему, которая позволяет вашей системе двигаться вперед. Хорошо. И затем, как мы построили в Swamp Club. Итак, swamp-club.com. Вы можете зайти и посмотреть, как мы это построили, потому что, как я уже сказал, все здесь является открытым исходным кодом. Весь триаж проблем, все эти части, все эти фабрики также являются открытым исходным кодом. Так что для нас мы любим иметь возможность показать это. Это как наша гордость и радость в данный момент, потому что мы так хорошо проводим время, создавая программное обеспечение, которое мы создаем. Вы можете найти меня в интернете по адресу stack72. Я написал бесчисленное количество блогов за последние четыре недели о том, как мы это построили, и это на stack72.dev. И я считаю, что у меня есть время для вопросов. >> [аплодисменты] >> Спасибо. >> Есть ли у нас вопросы? Э-э, вот там очень удобный. Э-э, Лу, если вы подождете микрофон, спасибо. >> Привет, это был отличный доклад. Большое спасибо. Э-э, в чем теперь ваше узкое место? Это как бы, потому что вы запускаете это на Claude Max или [фыркает] вы не запускали это на своих ноутбуках. Э-э, это узкое место? Вы бы хотели иметь возможность разместить это в облаке или типа того? >> Прекрасный вопрос. В чем наше узкое место? Узкое место — это решение, что строить. Хорошо, я не запускаю автономных агентов, которые сидят и обрабатывают каждую входящую проблему. Это было бы безумие. Причина, по которой это было бы безумие, заключается в том, что кто-то что-то внедрит. Так что всегда есть человек, который смотрит на это. Стоит ли это обрабатывать? Это то, что нас волнует? Это наше, наше мышление на самом деле, знаете ли, решение, что строить, потому что когда я могу строить так быстро, я могу запустить 10 агентов одновременно. Но если это неправильные функции для пользователей, я просто создам эту монолитную систему, которая на самом деле не имеет смысла и не имеет никакого драйва и никакой согласованности в дальнейшем. Это наше узкое место. Наше узкое место — это теперь продумывание того, что важно для наших пользователей. >> Отлично. Еще есть? >> Я был, вы сказали, что с вашим >> Подождите микрофон. [фыркает] >> Это, вероятно, полезно. Э-э, вы сказали, что с вашим, э-э, системой, жизненный цикл обзора, знаете ли, что он автоматизирован до тех пор, пока иногда что-то не будет помечено, где агенты не могут договориться, и поэтому тогда вмешивается человек. Что, когда человек вмешивается в этот момент, как он собирает достаточно контекста, чтобы иметь возможность решить, в каком направлении идти, потому что, знаете ли, агенты перерабатывали так много знаний, что где вы, я имею в виду, вероятно, есть разные способы, в зависимости от контекста, но, знаете ли, как вы начинаете как бы выяснять, как я набираю знания? >> Прекрасный вопрос. Хорошо, так мы, вопрос в том, как мы, как люди, выступаем арбитрами, когда агенты на самом деле не могут договориться. Итак, для нас это как каждый раз, когда мы запускаем эту команду, этот план, этот враждебный обзор, он захватывается как структурированный вывод в нашей собственной системе, в Swamp. Так что мы можем фактически использовать Swamp для запроса и сказать: "Эй, дайте мне четыре вещи, о которых он не может договориться. Расскажите мне, о чем он может договориться, потому что это просто данные, верно? Это буквально просто данные, где мы можем фактически задавать вопросы, и мы можем, потому что это, и это так легко понять разницу, а затем мы можем принять решение. И если в конце этого мы не можем понять это, мы говорим: "Убейте эту сессию, начните новую", потому что мы потеряли всего 10 минут, и нет проблем. Мы не, мы не тратим тысячи долларов. Я имею в виду, это буквально очень короткий период времени, и мы можем это сделать. Так что мы можем запустить столько, сколько нам действительно нужно. >> Э-э, не могли бы вы немного подробнее рассказать о вашей модели открытого исходного кода и особенно о коммерческой модели? Я большой поклонник. Я полностью согласен, что мы переизобретаем, как работает открытый исходный код, и мне нравится ваш подход. Но какова ваша коммерческая модель? >> Хорошо, мы занимаемся продажей лицензий на программное обеспечение. Хорошо, это буквально это, это как модель "красного горячего". Хорошо. И причина в том, что люди теперь больше заботятся о цепочке поставок и больше заботятся о поддерживаемости и драйве. Так что, если кто-то хочет взять наше программное обеспечение, форкнуть его, собрать его, делать с ним все, что угодно, пожалуйста. Это AGPLV3, верно? Это так работает. Вы не можете создать конкурирующую компанию, потому что это в наших условиях обслуживания. Но в то же время, мы активно работаем со многими людьми, которые хотят эту лицензию, которые хотят эту заботу, эту поддерживаемость программного обеспечения. Они не хотят поддерживать это сами. Это наша модель лицензирования. >> Еще один быстрый. >> У нас есть время? Хорошо. >> Спасибо. >> Большое спасибо за этот доклад. Я думаю, что вопрос, который у меня есть, я уверен, что у вас сейчас все еще пять человек в команде, верно? Э-э, применим ли этот подход в большом масштабе, когда у вас есть сотни микросервисов и проблемы с масштабированием и экспертными знаниями, которые >> Какой замечательный вопрос. Масштабируется ли этот подход к другим людям? Дана очень хорошо сказала в последнем докладе. Когда у вас есть защитные барьеры, когда у вас есть эта система, каждый в организации фактически уполномочен поступать правильно. Мы не считаем, что нам нужно масштабировать компанию до сотен инженеров, чтобы сделать это, верно? Что нам нужно, это то, что мы на самом деле заботимся о людях, у которых есть архитектурное видение и продуктовая юзабилити, и они заботятся о продвижении системы вперед. Как только они там, как только они знают, что мы пытаемся построить и сделать, тогда несколько агентов могут работать одновременно. У меня сейчас пять агентов работают на моем ноутбуке. Вы понимаете, что я имею в виду? И так оно и будет. Я искренне верю, что в будущем программного обеспечения таким образом, младшие специалисты становятся действительно важными, действительно важными. Хорошо? Потому что сейчас, когда младшие специалисты приходят в инженерные организации, они делают низкоуровневую работу. Они работают над небольшими частями кода, потому что вы не можете дать им систему. Вы не можете, младшие специалисты теперь могут изучать архитектурные ограничения системы. Им не нужно заботиться о синтаксисе кода. Конечно, они могут его читать. Конечно, это очень важно для них, но они фактически учатся с более высокой скоростью о ограничениях и системном мышлении, чем когда-либо прежде. Так что для нас важно убедиться, что мы сохраняем эту основную группу людей, которые фактически вовлечены в обеспечение того, чтобы отзывы пользователей были действительно хорошими. Я создал, я слышу эти вопросы все время. Я предварительно создал кучу проблем. Это все вопросы, которые у меня были раньше, которые выглядят как вещи, типа "вы судите шесть лет работы, вы все выбросили, и вы довольны четырьмя месяцами". Это медовый месяц? Абсолютно, 100%. Буду ли я таким же через четыре месяца? Я, вероятно, перепроектировал бы систему четыре раза под капотом. Это просто так работает мир. Может быть, я даже сделаю переписывание в стиле кнопки на Rust. Я не буду этого делать. Но да, и, знаете ли, мы многому учимся. Любой, у кого есть дополнительные вопросы, найдите меня. Я буду здесь весь остаток дня. Большое спасибо. Наслаждайтесь остальной частью конференции. Было приятно. [аплодисменты] [музыка] >> [музыка]