Transcription
Наш следующий спикер здесь, чтобы поговорить о инженерии "сбруи". Как создавать программное обеспечение, когда люди управляют, а агенты выполняют. Присоединяйтесь ко мне, приветствуя на сцене сотрудника технического отдела OpenAI, Райана Леопо. Доброе утро, Лондон. Я очень рад быть здесь сегодня. Я Райан Лапо, и последние девять месяцев я имел честь создавать программное обеспечение исключительно с помощью агентов. Я миллиардер токенов, и я считаю, что для того, чтобы мы достигли нашего будущего с ИИИ, мы хотим, чтобы каждый был миллиардером токенов, чтобы использовать модели для выполнения всей работы. И это означает, что нужно принять идею о том, что модели способны быть полноценными инженерами-программистами. И я испытал это на себе, запретив своей команде даже прикасаться к своим редакторам, чтобы работать через модели, чтобы выполнить работу. И сегодня я немного расскажу вам о том, что означает принять это и операционализировать ваш образ работы, кодовые пространства, в которых вы живете, и процессы в ваших командах, чтобы агенты выполняли всю работу. Я считаю, что говорю с единомышленниками, когда говорю, что способ создания программного обеспечения изменился. За последние шесть месяцев мы видели, как кодирующие агенты захватили мир, и возможности постоянно развивались с супербыстрой скоростью, чтобы эти модели и "сбруи", в которых они живут, могли выполнять более сложные действия, выполнять более сложную работу с более высокой надежностью на более длительных временных горизонтах. И мы пришли к тому, что реализация больше не является дефицитным ресурсом в том, что означает выполнять работу инженера-программиста. Код бесплатен. У нас есть изобилие кода для решения проблем, с которыми мы сталкиваемся в повседневной жизни, когда управляем нашими командами, создаем программное обеспечение и решаем проблемы пользователей. Наем людей за клавиатурами в составе наших команд ограничен только мощностью GPU и бюджетами на токены. И каждый инженер сегодня в этой комнате имеет доступ к мощности пяти, пятидесяти или пяти тысяч инженеров 24 часа в сутки, 7 дней в неделю, каждый день года. Единственное, что нужно сделать, это наша роль — выяснить, как продуктивно развернуть эти ресурсы в нашем коде и в наших командах, чтобы использовать эту новую мощность. И в этом мире наборы навыков смещаются в сторону системного мышления, системного проектирования и делегирования, чтобы использовать это изобилие мощности для производства кода для решения проблем. И этому есть три причины. Все это произошло в конце 2025 года. Для меня волшебным моментом стал GPT 5.2, который, когда вышел, смог выполнить всю работу инженера-программиста. Модели на данный момент настолько хороши, что они изоморфны нам с вами с точки зрения способности производить высококачественный код, решающий реальные проблемы пользователей в реальных кодовых базах. Код бесплатен. И я знаю, что это, возможно, пугающая вещь, которую нужно услышать, потому что код несет бремя обслуживания, но его бесплатно производить, бесплатно рефакторить, и это больше не то, на чем стоит зацикливаться. Мы думаем о коде как о бремени, потому что это синхронный отток внимания у инженеров в нашей команде. Но модели невероятно терпеливы. Они бесконечно параллельны. Таким образом, возможность производить, поддерживать, рефакторить и удалять код больше не является принудительной функцией для определения того, как распределять ресурсы в ваших инженерных командах. Так что своего рода "таблетка ИИИ" здесь — это вера в то, что модели способны производить каждую строку кода, которая нам когда-либо может понадобиться, выяснять, когда их удалять, выяснять, когда их рефакторить или делать их более надежными. И ваша роль как инженеров-программистов — выяснить, как разблокировать вашу команду агентов и людей, управляющих этими агентами, чтобы они могли управлять ими в течение длительного периода работы, чтобы выполнить всю работу. Идея здесь в том, что каждый из вас — старший инженер. У вас столько членов команды, сколько вы можете одновременно управлять и иметь токены для поддержки, и вам нужно смотреть на день, неделю, шесть месяцев в будущее, чтобы выяснить, какие структуры вам нужно создать, чтобы продуктивно использовать эту бесконечную мощность для производства кода. Дефицитными ресурсами в этом мире, которые мы видим сегодня, являются три вещи: человеческое время, человеческое и модельное внимание, а также контекстное окно модели. И в мире, где человеческое время и внимание дефицитны, роль заключается в том, чтобы думать о том, куда уходит это время, находить способы его продуктивной автоматизации и перемещать это синхронное человеческое время в более высокопроизводительные действия. В мире, где человеческое время дефицитно и человеческое время требуется для производства кода, у нас есть ранжирование. Вещи либо P0, либо P2. Эти P3 никогда не будут сделаны. Однако в мире, где код бесплатен и бесконечно изобилен, все эти P3 запускаются немедленно, возможно, в 4 раза параллельно. Мы выбираем тот, который решает проблему, и он идет. Мне посчастливилось создавать множество агентов внутри OpenAI для повышения производительности моих коллег. И когда код бесплатен, все эти внутренние инструменты могут иметь хорошую локализацию и интернационализацию с первого дня. Я могу создавать инструменты, которые мои коллеги в Лондоне, Дублине, Париже, Брюсселе, Цюрихе и Мюнхене смогут использовать на своих родных языках, не торгуясь с мощностями других моих команд, чтобы создавать высококачественные инструменты. Мы должны работать с предположением, что лучшие части инженерии программного обеспечения, которые мы все знаем, живем и дышим, доступны в любом продукте, который мы когда-либо могли бы построить, все время. Людям больше не нужно беспокоиться об реализации. Важно не код, а запрос и защитные механизмы, которые привели вас туда. Вот почему оставление следов, документации, ADR, документации, ориентированной на персоны, о том, как выглядит хорошая работа. Все исторические журналы тикетов и обзоров кода. Это процесс, который привел вас и ваши команды к коду и продуктам, которые у вас есть сегодня. И это то, что нужно сделать, чтобы ваши агенты тоже туда добрались. Ваша работа — создавать системы, программное обеспечение и структуры, которые позволяют вашей команде быть успешной. И для этого нам нужно сделать их понятными для тех агентов, которые управляют реализацией. Это означает структурирование их таким образом, который является родным для агентов. Написание их таким образом, который уважает дефицитный контекст, который является этим другим дефицитным ресурсом здесь, и поиск способов сделать токены, необходимые для выполнения работы, легко предсказуемыми. Это означает, что вещи должны быть максимально одинаковыми, чтобы мы могли ограничить внимание, которое модель должна активировать, чтобы выполнить работу. Масштабный рефакторинг в этом мире бесплатен. Так что делать вещи одинаковыми — это то, что вы все можете сделать. Никогда больше не будет миграции, которая будет открыта в течение шести месяцев, потому что вы не можете получить последние части кодовой базы для выполнения, потому что вы можете просто запустить 15 агентов для выполнения этой работы до конца. Вот что значит миграция, верно? Мы можем закончить их сейчас. Ну же. Это хорошо. Это хорошо. Хлопайте. Здесь есть своего рода метаэпистемологический вопрос о том, что значит хорошо работать, и хорошо работать как инженер-программист — это сложно. Это требует от нас многолетней работы в индустрии, чтобы полностью осознать, что значит писать высококачественный, поддерживаемый, надежный код, на котором наши коллеги по команде смогут строить, который принесет пользу кодовой базе для одного патча. Вероятно, это требует 500 мелких решений по пути, касающихся недоопределенных нефункциональных требований, которые входят в производство хорошего кода. Агенты, модели во время своего обучения видели триллионы строк кода, которые принимают каждый возможный выбор этих нефункциональных требований, которые вы можете себе представить. Итак, наша работа — специфицировать эти нефункциональные требования, записывать их таким образом, чтобы агенты могли видеть, что это значит хорошо работать, что приведет к объединенному патчу. И если агенты этого не делают, наша работа — находить способы уточнить и ограничить их вывод таким образом, чтобы код, который они пишут, был приемлемым. Вы можете просто сказать: "Не производите хлам". Не принимайте хлам. Вы не получите хлам в своей кодовой базе. Но для этого требуется краткосрочная потеря скорости, чтобы вернуться или дважды щелкнуть по задаче, чтобы выяснить, с чем борются агенты в вашей среде. Установите защитные механизмы, чтобы они перестали совершать эти ошибки, а затем найдите способы отступить и потратить свое время на более высокопроизводительные действия, как только вы устраните некоторые блокирующие факторы в краткосрочной перспективе. Когда я думаю о расширении прав и возможностей моей команды таким образом, каждый является экспертом в том, что он приносит. У меня есть разнообразная полностековая команда, которая является экспертом в архитектуре фронтенда, масштабируемости бэкенда, продуктивном мышлении. И каждый из этих различных персонажей дополняет набор навыков моей команды, привнося различное понимание, различный набор решений для этих нефункциональных требований. Фактически, когда товарищи по команде записывают это, каждый инженер, управляющий агентами, получает лучшее от каждого человека в моей команде. Мне не нужно блокироваться на низкосигнальном обзоре кода, чтобы понять, что значит написать хороший план QA. Чтобы один инженер в моей команде задокументировал это в долгосрочной перспективе, означает, что каждая траектория агента получит хороший план QA. И мы можем делать это один раз на высоком уровне, на котором мы можем строить. Итак, как мы можем заставить агентов хорошо работать? Какие инструменты и методы у нас есть, чтобы фактически внедрять запросы в наших агентов и постоянно напоминать им о том, что значит принимать эти конкретные решения, которые мы ожидаем в отношении этих нефункциональных требований. И есть много способов, которыми мы можем это сделать. Мы можем писать хорошие файлы agents.mmd. Однако с автокомпрессией кода, которая продолжает улучшаться, GPT 5.4 и CEX фантастически справляются с автокомпрессией кода. Я, по сути, больше никогда не должен писать /new. У меня есть несколько фотографий в моем Твиттере, где я прикрепляю свой ноутбук к задней части своей машины, чтобы продолжать выполнять вывод во время поездок на работу и обратно. И в этом мире вам придется строить с учетом того, что контекст со временем будет выгружаться. Нам нужно постоянно обновлять контекст, пока агент выполняет задачу. И способы, которыми мы можем это сделать, — это иметь агентов-рецензентов, которые смотрят на код по ходу работы через призму того, что значит быть успешным. Верно? У нас есть агенты по безопасности и надежности в нашей кодовой базе, которые постоянно работают как часть каждого пуша и CI, которые смотрят на эти документы и предложенный патч и делают простые вещи, такие как: есть ли тайм-ауты и повторные попытки в этом сетевом коде? Имеет ли введенный код безопасный интерфейс, которым невозможно злоупотреблять? Я уверен, что каждый здесь когда-либо получал уведомление из-за сетевого кода, который вышел из строя в продакшене, вызвав сбой, который мог бы быть устранен повторной попыткой и тайм-аутом. И я знаю, что я виновен в том, что установил эту повторную попытку и тайм-аут, объединил исправление ошибки и в остальном проигнорировал это. Я не являюсь надежным рецензентом или автором кода в отношении этого нефункционального требования. Однако, потратив время на написание некоторых документов, написание линтера, который является уникальным для моей кодовой базы, который будет смотреть на каждый раз, когда я вызываю fetch, чтобы убедиться, что вокруг него обернута повторная попытка и тайм-аут, означает, что я надежно решил эту проблему, и я могу сделать это, потому что я опираюсь на эту аксиому, что код бесплатен, что агенты способны хорошо работать, что я могу полностью мигрировать кодовую базу для надежного решения этой проблемы раз и навсегда. И чтобы работать таким образом, нам нужно отступить и посмотреть на долгосрочные классы сбоев, которые агенты и люди в кодовой базе совершают снова и снова. Выяснить, почему мы тратим на это время. Разработать решение для систематического устранения этого класса неправильного поведения, а затем продолжать наблюдать, уточнять и принимать дополнительные решения по этим нефункциональным требованиям. Один действительно классный трюк, который я использую здесь, заключается в том, что вы можете писать тесты о исходном коде, а также, которые отделены от линтеров. Верно? Если мы знаем, что контекст ограничен, мы можем написать тест, который ограничивает тот факт, что файлы не длиннее 350 строк. Мы адаптируем нашу кодовую базу к "сбруе", к моделям, чтобы выполнить немного инженерии, чтобы быть контекстно-эффективными и выжать больше пользы из возможностей модели, которые у нас есть сегодня. Другие вещи, о которых мы можем подумать, — это предоставление хороших сообщений об ошибках, которые дают фактические шаги по устранению для модели и людей, чтобы понять, как действовать дальше. Недостаточно сказать, что у нас сбой линтера, потому что мы ожидаем в цикле, или что у нас есть неизвестное в этой глубокой части кодовой базы, и почему модель пишет функцию под названием is record. Что нам нужно сделать, это предоставить запрос через сбой линтера или теста, который говорит: "Нет, нет, нет, у вас не должно быть неизвестного здесь вообще, потому что мы парсим, а не валидируем на краю, и вы, конечно, имеете здесь тип, который был получен из зота, несущей инфраструктуры для нашего ИИ-будущего, вы можете просто запрашивать вещи, о которых я говорил здесь сегодня, это запрос, вы можете сделать это, не касаясь весов модели вообще. Забавная дигрессия здесь: кажется, что каждое достижение, которое мы имели в сложности того, как мы пишем код для взаимодействия с этими моделями, происходит как из увеличения возможностей моделей, так и из все более нишевых способов внедрения запросов в эти модели. Запросы, я уверен, вы знаете, это запросы, силы запросов, правила файлов, запросы, навыки, запросы, эти сообщения об ошибках линтера, о которых я говорю, запросы, агенты-рецензенты, которые вставляют комментарии в PR, которые мы требуем от агента для рассмотрения, прежде чем он сможет предложить его для слияния, запросы, вы найдете множество способов вставить запросы в ваш код, и один из способов, которым вы можете это сделать, — это встраивать SDK агентов в ваши тесты, которые будут проверять кодовую базу на приемлемость, используя запросы, которые встроены в код. И если я обнаруживаю, что трачу много времени на написание запросов, мы можем фактически использовать агента и для этого. Я направил codecs на все поваренные книги запросов, которые у нас есть в руководстве разработчика OpenAI, и попросил синтезировать из них навык о том, как писать запросы. Это означает, что когда я нахожу необходимость писать запросы, чтобы улучшить производительность моего агента локально в коде, я использую навык для написания запросов, которые я написал с агентом, смотрящим на запросы, чтобы написать запросы. Вся польза, которую вы кодируете в своем репозитории, своей команде и агентах таким образом, отлично складывается. Чтобы немного вернуться к идее о том, что один продуктивно мыслящий инженер в моей команде смог дать нам большой толчок. Они знают, что значит написать хороший план QA. Однако, чтобы написать хороший план QA, вы должны задокументировать все функции, которые у вас есть, критические пользовательские пути и то, как пользователи взаимодействуют с вашими приложениями, веб-приложениями, API и сервисами. Как только вы запишете это о том, как написать хороший план QA, с ожиданием, что вся работа, ориентированная на пользователя, имеет план QA, теперь агент-рецензент сможет утверждать ожидания относительно того, что значит доказать, что вы эффективно написали функцию. План QA указывает, какие носители должны быть прикреплены к PR, чтобы люди и агенты знали, что вы хорошо поработали, что имеет следствие в том, что я больше доверяю результату, меньше нуждаюсь в наблюдении за агентом. и еще больше исключаю себя из цикла, чтобы делегировать все больше и больше работы агентам. И все это просто гарантирует, что у агентов есть инструменты, токены и контекст для выполнения всей работы, чтобы исключить себя из необходимости как синхронного драйвера. Модели жаждут токенов. Мы можем операционализировать нашу кодовую базу, чтобы дать им токены для продвижения вперед, используя субагентов и все эти другие методы для уточнения вывода агента. Я рад сообщить вам всем сегодня, что вы можете просто создавать вещи. Не стесняйтесь исключать себя из цикла, заставляя агентов выполнять всю работу, потому что они могут. Спасибо. >> Очень рад представить нашего гостя. У нас сегодня Райан Леапо. Он только что выступил с основной речью. Очень интересный спикер. Человек — полный вперед, гипер-инженер в OpenAI. Итак, немного предыстории. У нас был эпизод Laten Space с ним. Мы выпустили его на днях. Он написал отличную статью под названием "Инженерия сбруи", и мы подумали: "Вау, это чистое золото". Мы пригласили его на подкаст. Он миллиардер токенов, тратит более миллиарда выходных токенов в день. Это примерно более 1000 долларов. Так что, знаете, человек действительно живет этим. Мы хотим сохранить это захватывающим. Задавайте хорошие вопросы, задавайте интересные вещи, задавайте вещи, которым люди могут научиться. Но, знаете, давайте поприветствуем Райана на сцене. >> Привет всем, как дела? Рад быть здесь. Лондон был фантастическим, и я рад рассказать о том, что мы делаем и как мы работаем здесь. >> Думаю, тебе нужно подойти. Эта камера просто здесь. Так что >> Меня ослепил QR-код. Так что >> Хорошо. Итак, предыстория. У нас есть около часа. Отсканируйте этот QR-код. Вы должны получить Slido. Slido позволит вам задавать вопросы. Если вы видите что-то интересное, вы можете поставить ему лайк, и мы постараемся пройти через них. К сожалению, первое я не могу полностью сделать, но давайте просто начнем. Райан, можешь показать нам свою реальную рабочую установку без ноутбука? >> >> Да. Вот. Пляжный маргарита линейный, верно? >> О, вау. Я скажу, посмотрите подкаст, который мы выпустили. Мы проходим через некоторую работу, но если вы хотите поговорить об этом, я думаю, без того, чтобы на самом деле показывать нам, каков ваш рабочий процесс? Какова ваша установка? Как вы подходите к задаче? >> Конечно. Итак, мы с моей командой начинаем с тикетов, верно? У нас есть куски работы, которые мы хотим сделать, функции, которые мы хотим добавить в наши приложения, работу по обеспечению надежности, которую мы хотим сделать. Мы передаем этот тикет агенту вместе с несколькими навыками, которые позволяют ему манипулировать нашим приложением. Мы хотим, чтобы точка входа в процесс разработки была codecs, а не средой, которую мы вокруг нее построили. Так что мы делаем вещи "снаружи внутрь", верно? Как codecs — это точка входа, так же, как и вы. И мы даем ему инструменты, мы даем ему инструкции, как готовить. Так что вместо того, чтобы создавать оболочку, в которую запускаются наше приложение и CEX, у нас есть навык, который учит Codex, как запускать приложение, который учит Codex, как запускать этот локальный стек наблюдения, чтобы дать ему логирование и телеметрию. Мы даем ему навык, который позволяет ему загружать Chrome DevTools и подключаться к приложению с помощью локального CLI, который будет подключаться через какой-то демон, который у нас есть. Так что весь способ, которым мы настроили репозиторий и все локальные инструменты разработки, предназначен для того, чтобы codecs вызывал их первым. Это означает, что у нас есть своего рода куча маленьких мини-"сбруй" внутри кодовой базы, которые позволяют нам легко вставлять дополнительные защитные механизмы. Знаете, большой пакет пользовательских правил ESLint, которые подключаются к каждому пакету PNPM в рабочей области. У нас есть еще одна своего рода локальная среда разработки, которая позволяет нам добавлять своего рода более высокоуровневые целостные тесты, которые утверждают структуру самого кода, а не синтаксис или поведение кода. Такие вещи, как конфиденциальность пакетов, зависимости между различными слоями нашего стека. Эти виды вещей. Убедиться, что, знаете ли, в нескольких файлах схемы zod дедуплицируются, что существует единая каноническая реализация наших общих вспомогательных функций. Эти виды вещей, потому что, знаете ли, мы видели, как агенты работают, иногда оптимизируя локальную согласованность пакета, а не используя наши общие утилиты и подобные вещи. Так что, наблюдая за этим поведением, мы создали кучу маленьких псевдо-линтеров для проверки исходного кода, которые выявляют такое плохое поведение, чтобы люди не отвлекались, обращая на это внимание в обзорах, и тому подобное. Но установка оптимизирована для того, чтобы агент выполнял работу, а люди не должны отслеживать высокий оборот в кодовой базе. Мы централизуем нашу пользу вокруг пяти-десяти навыков. Мы не идем слишком широко по навыкам, предпочитая улучшать существующие навыки, потому что, по крайней мере, я нахожу, что инфраструктура внутри репозитория, все локальные инструменты разработчика меняются очень часто, и у меня действительно нет возможности отслеживать это. Так что мы скрываем всю эту сложность под навыками, которые должен вызывать человек, и позволяем агенту просто разобраться. Одна интересная вещь здесь заключается в том, что когда мы перешли от прямого использования протокола Chrome DevTools к этому "демонскому" механизму, я не знал об этом в течение трех недель. Это было совершенно нормально, потому что Codex мог сделать это, знаете ли, с документацией и вещами, которые у нас были. >> И часть этого вы можете получить больше деталей в вашей статье. Так что некоторая предыстория, вы написали отличную статью под названием "Инженерия сбруи". Там есть целый раздел о том, как вы думали о навыках, тысячи навыков против упрощения их до нескольких. Но хорошо, продолжая, как вы останавливаете себя от чрезмерной инженерии "сбруй"? И немного похожий последующий вопрос: вы часто строите небольшие инструменты для себя, если вообще когда-либо? Вы строите пользовательские инструменты? >> Да. Так что я думаю, что это своего рода указание в направлении "горького урока", верно? Это как я могу гарантировать, что работа, которую я делаю, не будет полностью устаревшей из-за увеличения возможностей модели, и то, как я думал об этом, — это выполнение минимального объема управления контекстом, чтобы собрать требования для агента, чтобы он выполнил приемлемую работу в течение всего его рабочего процесса, а контекст — это то, что, я думаю, никогда не устареет, верно? Модели должны быть проинструктированы о требованиях задачи, какие защитные механизмы следует соблюдать, эти виды вещей. Так что хорошая "сбруя" действительно операционализирована вокруг предоставления модели текста в нужное время, чтобы она могла посмотреть на проделанную работу и информацию о том, что такое хорошая работа, и, знаете ли, фундаментально модели обучены следовать инструкциям. Все, что должна делать "сбруя", — это предоставлять инструкции модели в нужное время. Так что мы хотим минимизировать это тоже, верно? Вы не хотите загружать все эти инструкции заранее, потому что тогда вы как бы перегружаете агента, но все эти требования к тому, что такое хорошая работа, должны соблюдаться на протяжении всего PR, верно? Так что поиск способов либо отложить, либо предоставить эти инструкции "точно в срок" — это своего рода то, что должна делать хорошая "сбруя", верно? Если вы знаете, что вы хотите, чтобы ваши компоненты React были разложены так, чтобы они создавали хорошие снимки для отдельных, более без состояний частей, верно? Вам не нужно загружать это заранее. Вместо этого вы должны позволить агенту готовить и экспериментировать с пользовательским интерфейсом, который вы хотите создать, а затем во время линта или теста сказать: "Хорошо, вы проделали работу. Чтобы закончить ее, вы должны разбить это так, чтобы ваши компоненты были маленькими и максимально без состояний, и имели локальные зависимости от хуков вместо проп-драйлинга или чего-либо еще, что вы хотите, чтобы код выглядел так". И тогда агент скажет: "О, это новая инструкция для меня. Позвольте мне взять патч как есть, изменить его, чтобы убедиться, что он соответствует инструкциям". И затем он загружается на GitHub. И эта вещь не будет устаревшей из-за увеличения возможностей модели. Это действительно просто о том, чтобы получить этот правильный текст, этот правильный контекст для агента в нужное время. >> Можем ли мы поговорить о примере хорошей "сбруи"? Итак, многие люди спрашивают о модели codecs, "сбруе" codecs. Как это сравнивается с другими "сбруями"? Итак, облачный код, открытый код. Как вы принимаете эти решения во внимание? Вы не работаете напрямую над codecs, но если есть вещи, о которых вы можете говорить о "сбруе" codecs, что вы видите, когда вы проектируете ее? >> Да. Так что одна вещь, которая, я думаю, очень мощная, — это идея о том, что лаборатории не просто пост-тренируют модели, а пост-тренируют модели в контексте "сбруи", в которой они в основном развернуты, верно? Инструмент apply patch или специфические семантики кодирования для вызова инструмента bash находятся в цикле для процесса пост-тренировки для "сбруй" из лабораторий, что означает, что есть польза от прямой зависимости от этих своего рода "первоклассных" "сбруй". По крайней мере, я так считаю. И, как таковой, возможность направлять их через такие вещи, как SDK, или напрямую манипулировать сервером приложений Codex, означает, что вы получаете возможность использовать всю эту пользу в пост-тренировке. Вместо этого сосредоточьтесь на частях, которые вас волнуют, то есть на том, как выглядит правильный код. Я, в некотором смысле, высоко уверен, что такие вещи, как clog code и codecs, будут продолжать улучшаться. Это ответственность команд, работающих над этими кодирующими агентами. Так что в моей роли, где я действительно не хочу фокусироваться на "сбруе" кодирования вообще, я ищу способы подключиться к ним таким образом, который, как бы, направляет агента. Это означает, что моя работа может, как бы, подняться до рассмотрения различий в поведении модели между релизами, а не глубокого понимания основ "сбруи". Вместо этого я могу думать о том, что значит, знаете ли, управлять желаемым поведением на основе наблюдаемого поведения, а не внутренних механизмов вещи. Это идеальное продолжение следующего вопроса, который заключается в том, есть ли у вас какие-либо рекомендации по платформе для совместной работы? Итак, когда вы находитесь в жизненном цикле разработки программного обеспечения, есть ли какая-либо платформа, которую вы используете для агентов, инженеров, разработчиков, чтобы все вместе работали над чем-либо? Какие-либо советы, какие-либо инструменты? >> Да. Так что в этом мире в основном это были файлы markdown в репозитории и GitHub, которые были основным своего рода центром и спицами. Если вы думаете о совместной работе над документом, как вы открываете Google Docs, пишете что-то, просите обратную связь, люди комментируют, вы применяете предложения, эти виды вещей. Это своего рода чистая комната, только для этого рабочего артефакта, который вы производите. PR, как бы, имеет аналогичную цель. Так что мы относимся к этому как к большой доменной области вещания с центром и спицами, где все агенты и люди сотрудничают вместе. И поскольку мы оптимизируем пропускную способность, мы не блокируем какой-либо вклад в это, как бы, люди могут либо рецензировать, либо нет. Агенты могут либо рецензировать, либо нет. Агент реализации может подтвердить, отложить или отклонить любую обратную связь, которую он получает. Позволяя каждому участнику производства диффов принимать свои собственные суждения о том, что значит доставлять, получать, отвечать на обратную связь. И это имеет приятное свойство, как бы, не запирать модель в коробке во многих местах. Мы хотим, чтобы они использовали свое хорошее рассуждение, своего рода. Так что быть супер предписывающим относительно того, что каждый бит обратной связи должен быть рассмотрен, может иметь этот, как бы, катастрофический режим сбоя вашего кодирующего агента, которого избивают все рецензенты, когда на самом деле мы хотим склоняться к принятию кода, а не к совершенству, а не к утоплению в мелочах и подобных вещах. >> Как людям начать использовать кодирующие агенты? Люди, которые использовали много вручную написанного кода, как им начать переход? Что им следует передать? Как им преодолеть этот барьер: "Хорошо, я все еще проверяю каждый PR, я копирую и вставляю из codecs". Как среднему инженеру начать использовать эти инструменты? >> Я думаю, есть два способа подойти к этой проблеме. Один — начать использовать кодирующие агенты, чтобы повысить вашу уверенность в коде как таковом, как он написан сегодня. Верно? Я думаю, мы все согласимся, что больше тестов, вероятно, хорошо, верно? Утверждать, что наши программы хорошо специфицированы и ведут себя правильно, когда наши пользователи взаимодействуют с ними, — это хорошо. И агенты очень хорошо смотрят на существующий код с некоторым контекстом о том, как он должен использоваться, и пишут тесты, которые утверждают это поведение. Так что, используя это для повышения вашей уверенности в качестве кода, вы также повысите способность агентов успешно навигировать по нему, что означает, что вам не придется так сильно беспокоиться о проведении супердетального обзора вывода агента. Другой способ подумать об этом — посмотреть, на что вы тратите свое время. Это, знаете ли, уставиться в редактор, писать код? Это ожидание запуска тестов? Это ожидание обратной связи от человеческого обзора? Медленный ли CI, и вы ждете этого? Может быть, у вас куча нестабильных тестов, и вы используете агентов для постепенной автоматизации частей, где вы тратите свое время, потому что, в конечном счете, высокопроизводительные части нашей работы — это определение работы, которую необходимо выполнить, приоритизация и планирование этой работы, а затем эффективное расширение прав и возможностей людей в нашей команде для выполнения этой работы. И чем больше мы можем делегировать и перейти к своего рода этой роли последовательности и оркестровки, даже если вы просто думаете об управлении своими командами, чем более параллельными и чем более глубокими индивидуальными выполнениями этих делегирований мы можем добиться, верно? Если я создам примитивы, которые облегчают, например, запуск способов реагирования на события в моей очереди Kafka, верно? Мне не нужно вникать в детали с каждым инженером, убеждаясь, что они правильно реализуют потребителя, верно? И эти же своего рода строительные блоки хорошо применяются к агентам и отлично складываются. >> Забавный вопрос. Как вы работаете с агентами в машине? >> Я не использовал новый голосовой режим, который недавно был запущен в CarPlay. Еще не готов к этому. Но обычно я запускаю задачу прямо перед тем, как покинуть офис, подключаю свой ноутбук к телефону, пристегиваю его на заднее сиденье и позволяю ему готовиться в течение 30 минут, которые уходят у меня на дорогу домой. В большинстве случаев с навыками, которые мы вызываем, мы говорим агенту: "Вы работаете над задачей, продолжайте, пока тесты не станут зелеными". Знаете, мне не нужно тянуться туда и нажимать "да", продолжать. И я, по сути, могу более полно насытить свой день потреблением токенов. Мечта здесь в том, что у меня действительно будет 50 агентов, работающих 24/7, и мне не придется с ними взаимодействовать. И способ сделать это — хорошо определить работу, найти способы ее автоматического планирования и исключить себя из необходимости нажимать кнопку. Каждый раз, когда мне приходится вводить "продолжить" агенту, это своего рода сбой "сбруи" в предоставлении достаточного контекста о том, что значит продолжать до завершения. >> Вау, хорошее заявление в конце. Каждый раз, когда вам приходится взаимодействовать с агентом, это сбой. Хорошо, следующий вопрос как бы масштабирует это, верно? По мере масштабирования карты знаний вашей организации, какие практические шаги вам нужно предпринять, чтобы обеспечить постепенное раскрытие? Итак, по мере того, как у вас становится все большая и большая кодовая база, по мере того, как у вас становится больше людей, как вы масштабируете своих агентов, чтобы они лучше работали с этим? >> Да. Так что, когда я изначально начинал этот проект, я работал над пустой репозиторией, создавал приложение Electron, верно? Знаете, V single package, все такое. И в итоге получилось беспорядок, верно? Потому что нет конфиденциальности пакетов, которая позволяет мне обеспечивать инварианты относительно того, какие API являются общедоступными, а какие нет. У агента не было конкретных точек входа в файловой системе, чтобы определить, какие домены отделены от других. Так что мы пошли по пути полной организации из 10 000 инженеров, тяжелой архитектуры, 750 пакетов в рабочей области PNPM, изолированных по домену бизнес-логики или уровню стека, отдельные маленькие пакеты утилит, которые инкапсулируют повторно используемую функциональность, которую мы линтируем при использовании, в которой мы можем кодировать пользу, и я действительно думаю, что в этом мире, даже если у вас на самом деле нет микросервисов, структурирование ваших репозиториев таким образом, чтобы вы могли фактически ограничивать поддерево каталога, которое вы просматриваете, чтобы выполнить большую часть изменений, помогает. И, знаете ли, код в файловой системе — это также текст, что означает, что это фактически запросы, которые вы даете своему кодирующему агенту. Так что, делая код максимально одинаковым, вы как бы делаете так, что независимо от того, где в репозитории ищет ваш агент, он развивает тонны передаваемого контекста, верно? У вас должен быть один способ, например, сделать вспомогательную функцию для ограниченной параллельности. У вас должен быть один способ построить наблюдаемую и инструментированную команду с побочными эффектами. У вас должен быть один OM, верно? У вас должен быть один язык программирования. У вас должен быть один способ написания скриптов CI. У вас должен быть один способ добавления дополнительных правил линта, эти виды вещей, потому что это означает, что токены, которые вы хотите, чтобы модель производила, легче предсказуемы и более последовательно предсказуемы, независимо от того, где она смотрит. Так что я бы сказал, найдите способы структурировать код так, чтобы он был локальным для поддерева в репозитории для большинства способов взаимодействия с этой системой, а затем найдите способ использовать этих агентов для полной миграции кодовой базы, чтобы она была одинаковой. Знаете ли, расширьте права и возможности кого-то в вашей команде быть диктатором, чтобы сказать: "Вот как это должно быть сделано, верно?" Или, знаете ли, выясните это вместе и, знаете ли, запишите это, развивайте код так, чтобы он отражал эту реальность, эти виды вещей. >> У нас есть несколько вопросов о ревью кода. Как вы подходите к ревью кода теперь, когда у вас такая высокая скорость? Вы просто не читаете код? Вы просто доверяете покрытию тестами? Как вы пишете хорошие тесты? Как вы снимаете это клеймо: "У меня есть ментальный блок. Мне нужно вручную все проверить перед тем, как я объединю PR"? >> Та же самая идея, где вам нужно посмотреть, на что вы тратите свое время, и найти способы тратить меньше. Знаете, когда мы начинали, верно, первое, что нужно было сделать, — это выяснить, как заставить агента надежно производить код, который мы будем принимать. И большая проблема, с которой мы столкнулись, заключается в том, что каждый инженер производит три-пять PR в день, даже в команде из трех человек, конфликты слияния были очень неприятными, верно? Потому что эти PR, как правило, были довольно большими. Мы работали над одними и теми же частями кодовой базы. Так что именно здесь мы двинулись в двух направлениях. Одно — это, как бы, немного больше разветвить код, чтобы минимизировать эти конфликты слияния, но также минимизировать время, в течение которого PR были открыты, чтобы мы сокращали вероятность возникновения конфликта слияния. И причина, по которой PR оставались открытыми так долго, заключалась в том, что нам нужен был обзор кода, потому что люди были блокирующим фактором в этом сценарии. Так что, чтобы сделать эту часть автоматически, я, по сути, попросил каждого инженера в команде взять один день в неделю, пятницу, мы называли это днем сбора мусора, когда вся наша работа заключалась в том, чтобы взять каждый кусок хлама, который мы наблюдали в течение недели, который затруднял слияние PR, и найти способы категорически исключить его возникновение в первую очередь, что и привело нас к замыканию этого цикла между обратной связью, которую люди давали на PR, указывающей на некоторый сбой контекста со стороны агента, получением этого в репозиторий, а затем поиском способов автоматического внедрения запросов в агента, чтобы он самоисцелялся, когда он производил это плохое поведение. И это своего рода то, как вы переходите от синхронного человеческого времени, потраченного на предоставление обратной связи в виде комментариев к обзору кода, к документации в репозитории, к автоматическому предоставлению этой документации либо через сбойный тест, либо через агента-рецензента, который настроен на обзор кода, как он написан в контексте этих документов. Но все это происходит путем размещения этих документов в одном месте, к которому все эти процессы могут подключаться. Знаете, мы попросили людей фактически разбить типы обратной связи по обзору, которую они давали, на, как бы, на персону, в которой они работали, как фронтенд-архитектор, инженер по надежности, масштабируемости и тому подобное. И затем, фактически, для каждой из этих персон мы запустили агента-рецензента, который срабатывает при каждом пуше и говорит: "Хорош ли этот код? Выявите любые P2 или выше, которые заблокируют слияние этого PR на основе этой документации, которая говорит, как выглядит хорошо". И с этим и постоянным добавлением в эти файлы мы начали видеть, как хлам уменьшается, уменьшается, уменьшается. >> У людей есть вопросы о ваших миллиардах токенов. Где, по вашему мнению, они распределены? Итак, сколько из них приходится на ревью кода? Где, где находится большая часть этого использования? И последующий вопрос для людей, которые только начинают. Скажем, они прыгнули и сделали план Pro за 200 долларов, верно? Если бы вам пришлось сократить использование на пятую часть, как людям следует максимизировать свое использование? Вы сталкиваетесь с ограничениями использования. Вы не хотите просто копировать и вставлять миллион строк кода каждые шесть часов. Нет попадания в кэш запросов. Но как нам следует думать об этом? >> Да. Так что я бы сказал, вероятно, треть, треть, треть между планированием, курацией тикетов, документацией, реализацией и вещами, которые запускаются в CI. >> Вы используете режим плана? >> Мы, я использовал exec plans, который был своего рода ранней версией этого, которую мы опубликовали, которая является своего рода прото-навыком, который говорит: "Вот как вы должны структурировать план с этапами и критериями приемки". Я на самом деле не использовал режим плана как часть "сбруи" вообще. Мое ожидание здесь заключается в том, что я должен иметь возможность бросить тикет и чтобы он выполнил работу в любом случае, не перенаправляя через план. Потому что в большинстве случаев я все равно никогда не буду его читать. Так что я считаю, что если вы используете план и одобряете его, не читая его вообще, вы фактически кодируете кучу инструкций, которые вы не обязательно хотите, чтобы выполнялись. Так что, если вы собираетесь использовать планы, моя рекомендация — загружать их как отдельные PR с просто планом, где вы фактически проверяете каждую строку этого и блокируете человеческое одобрение, прежде чем они будут объединены, а затем запущены. Потому что вы фактически потенциально тратите свое время на развертывание с инструкциями, которые, как бы, плохие. Так что вы хотите, как бы, минимизировать время, когда это происходит. Но я действительно думаю, что получение токенов для расходования в CI является необходимой частью этого, потому что написание кода больше не является трудной частью. Получение кода, который будет принят, и продвижение кода и продукта вперед — это то, что делает написанный код ценным. И, знаете ли, вы, вероятно, слышали афоризм, что старшие инженеры дают хорошие обзоры кода, как мы ожидаем, что наши старшие инженеры в качестве агентов будут делать то же самое. >> Кто-то спросил, является ли код одноразовым артефактом сборки? >> Да. >> Да. >> Я думаю, мы коснулись этого с symfony, который является своего рода оркестратором агентов, который мы выпускаем. Идея в том, что мы можем опубликовать библиотеку, которая на самом деле является суперчетко определенной спецификацией, компилированным артефактом которой является код. И я думаю, что использование LLM в качестве нечеткого компилятора — это интересный ментальный образ, верно? Весь контекст, который мы помещаем в кодовую базу для инженерии "сбруи", фактически является ограничениями и оптимизационными проходами, на которых код приемлем для построения в первую очередь. И это довольно похоже на статический анализ и оптимизационные проходы, которые что-то вроде LLVM сделает в процессе компиляции кода Rust. И своего рода замена одной модели на другую — это своего рода изменение вашего бэкенда генерации кода с, знаете ли, LLVM на crane lift в компиляторе Rust, и вы бы ожидали, что все правила относительно того, как выглядит приемлемый код Rust, будут производить действительный, надежный машинный код на выходе, даже если процесс генерации отличается, и вы получите разные инструкции x86. Так что тот же менталитет для LLM, замена разных моделей и тому подобное. Мы хотим, чтобы структура вокруг кода в основном ограничивала то, как он написан, до вещей, которые будут для нас приемлемы. >> На высоком уровне, можете ли вы дать нам картину того, для какого будущего вы строите? Имеет ли контекст все еще значение? Как люди занимаются инженерией, инженерией "сбруи", инженерией контекста? Как выглядит будущее? >> своего рода будущее, к которому я хочу стремиться, — это то, где я смогу взять бюджет токенов и квартал, полгода или год работы, взять человеческий ввод для ранжирования того, что является наиболее важными метриками успеха, метриками надежности, отдать это машинам, и пусть они постоянно работают и продвигают мой продукт вперед. Без того, чтобы мои руки явно были на руле. По мере того, как мы проходили от очень раннего прототипирования до внутреннего альфа, внутреннего бета, внешнего альфа, я чувствовал, что новые части процесса разработки программного обеспечения как бы начинались с нуля, и нам приходилось наращивать возможности, как эти, знаете ли, пятиугольные диаграммы личности, где я достигаю пика в этом направлении, возможно, я слаб здесь, и, знаете ли, когда мы впервые доходим до развернутого программного обеспечения, способность агентов выполнять дымовые тесты QA на наших собранных артефактах перед их продвижением к распространению была слабой. Мы не вкладывали никакого времени в это. Не было документов. Не было инструментов, которые агенты могли бы использовать, чтобы загрузить собранный артефакт, запустить его, покопаться, чтобы убедиться, что наши самые критические пользовательские пути были хорошо проверены и протестированы. Так что, поскольку я не хочу касаться компьютера, нам нужно было найти способы, чтобы агенты сами создавали инструменты для выполнения этой части. И существует целая вселенная программной инженерии, помимо написания кода, верно? Я занимаюсь триажем обратной связи с пользователями. Я занимаюсь триажем уведомлений. Я слежу за тем, чтобы в логах в продакшене не было утечек PII, я слежу за тем, чтобы, знаете ли, настроения в Твиттере были хорошими, и люди наслаждались моим программным обеспечением, чтобы наш персонал по работе с пользователями поддерживался хорошо написанными руководствами, которые позволяют им проводить триаж и смягчать высокообъемные проблемы пользователей, а затем переводить это в сам код, чтобы они не происходили в первую очередь, и поскольку мне больше не нужно производить код, мой разум может сместиться к этим другим более высокоуровневым или более расплывчатым действиям, но агенты достаточно хороши, чтобы делать и это, и выяснять, как записать процессы и критерии приемки становится своего рода метапрограммированием работы с использованием этих агентов. >> Это отличное завершение. Какое захватывающее будущее. Поаплодируйте Райану, ребята. >> Спасибо, ребята.