Transcription
[музыка] Как поживает каждый? Всё ещё не спите? >> Хорошо, отлично. Итак, как сказал роботизированный голос, я занимаюсь опытом разработчиков очень долгое время, и я никогда в жизни не видел ничего подобного последним 12 месяцам. Вы знаете, каждые 2-3 недели инженеры-программисты делают такое лицо на экране. Хорошо. И если вы работаете над опытом разработчиков, проблема ещё хуже. Вы похожи на этого парня на экране каждые несколько недель. Вы говорите: «О, да, да, да, да, да. Вот новая горячая штучка». А потом кто-то другой подходит и говорит: «Ну, могу ли я использовать новую новую горячую штучку?» И знаете, люди делают это годами. Я долго работаю над опытом разработчиков. Всегда все приходят и говорят: «О, могу ли я использовать этот инструмент, который вышел вчера?» А вы говорите: «Нет, конечно, нет». А теперь мы говорим: «Эм, может быть, да». Верно? И всё это в целом приводит к тому, что будущее сейчас очень трудно предсказать. Итак, я думаю, многие люди, многие технические директора, многие люди, которые работают над опытом разработчиков, люди, которые заботятся о помощи разработчикам, задают себе этот вопрос: пойдут ли все мои инвестиции впустую? Например, во что я могу инвестировать сейчас, чтобы, оглядываясь назад в конце 2026 года, я мог сказать: «Я точно рад, что инвестировал в это для моих разработчиков». И я думаю, что многие люди просто решили: «Ну, я не знаю. Я полагаю, это просто кодирующие агенты, и я полагаю, они сами исправят всё в моей компании, что, хотя они и удивительны, они преобразуют, но это не единственное, во что вам нужно инвестировать как в организацию разработки программного обеспечения». Итак, мы можем прояснить это, задав себе два вопроса. Первый: как мы можем использовать наше понимание принципов опыта разработчиков, чтобы знать, что будет ценным, независимо от того, что произойдет. Хорошо. И что нам нужно сделать, чтобы получить максимальную возможную ценность от ИИ-агентов? Например, что нам нужно исправить на всех уровнях вне агентов, чтобы убедиться, что агенты и наши разработчики могут быть максимально эффективными? И это не мелкий вопрос. Это те вещи, которые могут сделать вас или сломать вас как программный бизнес в будущем. Итак, давайте поговорим о том, что из этого является инвестициями без сожалений, которые помогут как нашим людям, так и нашим агентам. Итак, в целом, одно из представлений, о котором я думаю здесь, — это вещи, которые являются входными данными для агентов. Вещи вокруг агентов, которые помогают им быть более эффективными. И одна из самых больших — это среда разработки. Какие инструменты вы используете для создания своего кода? Какой менеджер пакетов вы используете? Какие линтеры вы запускаете? Такие вещи. Вы хотите использовать отраслевые стандартные инструменты так же, как их использует отрасль, и, в идеале, так же, как их использует внешний мир, потому что именно это находится в обучающем наборе. И посмотрите, да, вы можете писать файлы инструкций, и вы можете изо всех сил стараться бороться с обучающим набором и заставить его делать что-то неестественное и нечестивое с каким-то сумасшедшим объединением или модификацией, которую вы сделали с этими инструментами разработчика. Например, вы изобрели свой собственный менеджер пакетов. Вам, вероятно, не следует этого делать. Вам, вероятно, следует отменить это и попытаться вернуться к тому, как внешний мир разрабатывает программное обеспечение, потому что тогда вы не боретесь с обучающим набором. А также это означает, что это означает, что вы больше не можете использовать редкие языки программирования. Посмотрите, я фанат языков программирования. Я люблю эти вещи. Я больше не использую их в своей повседневной работе по разработке агентского программного обеспечения. Как энтузиаст, я иногда прихожу и пишу на, знаете ли, передовых программных языках, но больше не в своей реальной работе. Итак, что люди иногда спрашивают меня: означает ли это, что мы никогда больше не получим никаких новых инструментов, потому что мы всегда будем зависеть от инструментов, которые модель уже знает? Вероятно, нет, потому что, как я сказал, энтузиасты всё ещё будут. И также, но я хотел бы сделать замечание. То, о чем я говорю, всегда было реальной проблемой. Например, всегда был какой-то разработчик в компании, который всегда подходил к вам и говорил: «Могу ли я использовать эту технологию, которая вышла на прошлой неделе и никогда не проверялась на предприятии, для запуска моей службы с 100 000 запросов в секунду, обслуживающей миллиард пользователей?» И я говорю: «Нет, вы не можете этого сделать сейчас, и вы не могли этого сделать вчера. Это всё ещё то же самое». Ещё одна вещь: чтобы предпринять действия сегодня, агентам нужен либо CLI, либо API для выполнения этого действия. Да, есть компьютерное использование. Вы можете заставить их писать Playwright и оркестрировать браузер. Но зачем? Например, если бы у вас был CLI, который агент мог бы просто выполнить нативно в своём обычном формате, который он понимает наиболее нативно, то есть текстовое взаимодействие, почему вы выбрали бы сделать что-то другое, особенно в области, где точность имеет огромное значение и где эта точность драматически влияет на эффективность агента? Одна из самых важных вещей, в которые вы можете инвестировать, — это валидация. Таким образом, любая объективная детерминированная валидация, которую вы предоставляете агенту, повысит его возможности. Так что да, иногда вы можете создать это с помощью агента. Я расскажу об этом через секунду. Но на самом деле неважно, как вы это получаете или откуда вы это получаете. Вам просто нужно подумать, как у меня есть высококачественная валидация, которая выдает очень четкие сообщения об ошибках. Это то же самое, что вы всегда хотели в своих тестах и линтерах, верно? Но это ещё важнее для агентов, потому что агенты не могут угадать, что вы имеете в виду под ошибкой 500 Internal Server Error без другого сообщения, верно? Например, им нужен способ фактически понять, в чем была проблема и что им следует с этим делать. Однако здесь есть проблема. Итак, вы думаете: «Хорошо, я просто заставлю агента сделать это. Они напишут мой тест, и тогда я буду в порядке». Но вы когда-нибудь просили агента написать тест для совершенно нетестируемой кодовой базы? Они делают что-то вроде того, что происходит на экране здесь. Они напишут тест, который гласит: «Привет, босс, я нажал кнопку, и кнопка нажалась успешно. Тест пройден». Например, есть своего рода большая проблема, которая есть у многих предприятий, в частности, это большое количество устаревших кодовых баз, которые либо не были разработаны с учётом тестирования, либо не были разработаны с учётом высококачественного тестирования. И, возможно, у них есть только некоторые высокоуровневые сквозные тесты, и у них нет отличных модульных тестов, которые агент мог бы фактически запускать итеративно в цикле и которые выдавали бы действенные и полезные ошибки. Итак, ещё одна вещь, в которую вы можете инвестировать, что будет неизменно ценным как для людей, так и для агентов, — это структура ваших систем и структура ваших кодовых баз. Агенты лучше работают с более структурированными кодовыми базами. И для тех из вас, кто никогда не работал на крупном предприятии и не видел очень старых устаревших кодовых баз, вы можете быть не знакомы с тем, о чем я говорю. Но для тех, кто видел, вы знаете, что существуют кодовые базы, о которых ни один человек не может рассуждать каким-либо успешным образом, потому что информация, необходимая для рассуждения об этой кодовой базе, отсутствует в кодовой базе, а структура кодовой базы делает невозможным рассуждение о ней при взгляде на неё. Да, агенты могут делать то же самое, что и люди в этом случае, то есть проходить итеративный процесс попыток запустить что-то и посмотреть, что сломается, но это настолько снижает возможности агента по сравнению с тем, что он просто может посмотреть на код и рассуждать о нём точно так же, как снижаются возможности человека. И, конечно, как я уже сказал, всё это должно вести к тестируемости. Если единственное, что я могу сделать с вашей кодовой базой, — это нажать кнопку и узнать, успешно ли нажалась кнопка, и не видеть взрыва за ней, например, если нет способа получить эту информацию из кодовой базы из теста, то агент тоже не сможет этого сделать, если только он не перепишет её, или вы не перепишете её сначала. И вы знаете, много говорят о документации. Всегда много говорили о документации в области опыта разработчиков, в области улучшения вещей. И люди спорят об этом. Инженеры ненавидят писать документацию. И ценность её часто обсуждается: какой тип документации вы хотите или не хотите, хотите или не хотите. Но вот в чём дело. Агент, давайте просто рассмотрим это в контексте агента. Агент не может читать ваши мысли. Он не присутствовал на вашем устном совещании, у которого не было стенограммы. Хорошо? Сейчас во многих компаниях мира полагаются на такие коллективные знания, чтобы понять требования к системе. Почему пишется код? Какова спецификация, к которой мы стремимся, если вещи не записаны? И это звучит очевидно, но есть много вещей, которые фундаментально написаны. Например, если код понятен, как и все остальные шаги, которые мы прошли до сих пор. Вам не нужно повторно объяснять, что находится в коде. Поэтому, вероятно, существует целый класс документации, которая нам больше не нужна, или вы можете просто спросить агента: «Эй, расскажи мне о структуре этой кодовой базы в целом», и он просто сделает это, но он никогда не сможет узнать, почему вы её написали, если это не записано где-то, или вещи, которые происходят вне программы, например, какова форма данных, поступающих с этого URL-параметра, в качестве примера, если вы уже написали код, есть валидатор, и это объясняет это, но если вы ещё не написали код, он не знает, что поступает из внешнего мира. Так что, по сути, всё, что не может быть в коде или чего нет в коде, должно быть как-то записано где-то, к чему агент может получить доступ. Теперь мы рассмотрели своего рода несколько технических аспектов вещей, которые нам нужно улучшить, но есть момент, касающийся разработки программного обеспечения в целом, и это всегда было правдой, и одно из того, что вы слышали, — мы тратим больше времени на чтение кода, чем на его написание. Разница сегодня в том, что написание кода стало чтением кода. Так что даже сейчас, когда мы пишем код, мы тратим больше времени на его чтение, чем на фактический ввод данных в терминал. И это означает, что каждый инженер-программист становится рецензентом кода, по сути, своей основной работой. Кроме того, как и любой, кто работал в компании, которая глубоко внедрила агентское кодирование, мы генерируем гораздо больше PR, чем когда-либо прежде, что привело к тому, что сам процесс проверки кода, крупномасштабная проверка кода стала узким местом. Так что одна из вещей, которую нам нужно сделать, — это выяснить, как повысить скорость проверки кода как для больших проверок кода, которые нам нравятся, когда вы отправляете PR, и кто-то, знаете ли, пишет комментарии к нему, и вы обмениваетесь мнениями, так и для итеративного процесса работы с агентом. Как ускорить способность человека смотреть на код и знать, что с ним делать? Итак, принципы довольно схожи для обоих, но точный способ их реализации немного отличается. Что вас больше всего волнует, так это сделать каждый отдельный ответ быстрым. Вы на самом деле не хотите сокращать общее время проверки кода в целом, потому что проверка кода — это процесс качества. То же самое и с итерацией агента. Например, что вы хотите от итерации агента, так это добраться до места, где вы получили правильный результат. Вы не хотите просто сказать: «Ну, я думаю, у меня истекло 5 минут, поэтому я проверю этот мусор, который не работает, верно?». Но вы хотите, чтобы итерации были быстрыми. Не только итерации агентов, но и время отклика человека на агента должно быть быстрым. И для этого им нужно стать очень хорошими в проведении проверок кода или в знании следующего шага, который нужно предпринять с большим количеством кода. На уровне крупной проверки кода, одна вещь, которую я вижу, которую я считаю своего рода социальной болезнью, заразившей многие компании, — это когда люди хотят проверки PR, они просто отправляют сообщение в Slack в канал команды и говорят: «Привет, может ли кто-нибудь из вас десяти проверить мой PR?» И что, и вы знаете, что это означает, что один человек делает все эти проверки. Вот что на самом деле происходит. Например, когда вы смотрите на статистику проверки кода таких команд, есть один человек, у которого 50, а у другого — три, два, пять, семь, потому что есть только один человек, который очень отзывчив. Но это означает, что если вы начнете генерировать значительно больше PR, этот один человек не сможет справиться с нагрузкой. Вам придется распределить её, и действительно единственный способ распределить её — это назначить её конкретным лицам, иметь систему, которая распределяет её между этими лицами, а затем установить SLO с некоторым механизмом принуждения. И ещё одна вещь, например, GitHub сегодня не очень хорошо справляется с тем, чтобы чётко определить, чья очередь действовать. Например, я оставил несколько комментариев к вашему PR. Вы теперь ответили на один из моих комментариев. Должен ли я снова вернуться сейчас? О, подождите. Нет, нет, теперь вы внесли изменение. Должен ли я вернуться сейчас? Хорошо. Нет, нет, теперь вы ответили на больше комментариев. В основном я полагаюсь на то, что люди говорят мне в Slack: «Я готов, чтобы вы снова проверили мой PR», что является ужасной и неэффективной системой. И ещё одна вещь, о которой вам нужно много думать, — это качество проверок кода. И я имею в виду это снова как для отдельных разработчиков, работающих с агентом, так и для людей, которые делают это в конвейере проверки кода. Вы должны постоянно поддерживать высокую планку. Я знаю, что у людей есть другие мнения по этому поводу. И да, в зависимости от временных рамок, в течение которых вы ожидаете, что ваше программное обеспечение будет жить, вам может не потребоваться столько программного дизайна. Например, посмотрите, программный дизайн — это не цель совершенства. Это цель «достаточно хорошо» и «лучше, чем было раньше», верно? Но иногда «достаточно хорошо» для очень долгоживущей системы — это гораздо более высокая планка, чем люди ожидают. И если у вас нет процесса, способного отклонять вещи, которые не должны быть включены, вы, скорее всего, увидите снижение производительности от ваших агентских кодеров с течением времени, поскольку система становится всё более и более сложной как для агента, так и для человека. Проблема в следующем. Во многих компаниях люди, которые являются лучшими рецензентами кода, не тратят своё время на проверку кода. Они проводят всё своё время на совещаниях, проводя высокоуровневые обзоры, занимаясь стратегией. И поэтому мы не учим младших инженеров быть лучшими инженерами-программистами и лучшими рецензентами кода. Поэтому у нас должен быть какой-то механизм, который позволяет лучшим в этом заниматься через ученичество. Если у кого-то есть лучший способ сделать это, чем проводить проверки кода с людьми, я хотел бы знать, потому что за 20 с лишним лет, что я этим занимаюсь, я никогда не находил способа научить людей быть хорошими рецензентами кода, кроме как проводить с ними хорошие проверки кода. Теперь, если вы не сделаете всё, о чем я говорил, какова опасность? Опасность в том, что вы берёте плохую кодовую базу с запутанной средой. Вы отдаёте её агенту или разработчику, работающему с этим агентом. Агент производит относительный уровень ерунды, а разработчик испытывает больше или меньше разочарования и, в зависимости от того, насколько он настойчив, в какой-то момент сдаётся и просто отправляет свой PR на проверку. Они говорят: «Я думаю, это работает». И тогда, если у вас низкокачественные проверки кода или рецензенты кода, которые перегружены, они говорят: «Я не знаю. Я не знаю, что с этим делать. Я думаю, это нормально». И у вас просто будет много, много, много плохих PR, одобренных штампом, которые продолжают проходить, и вы попадаете в порочный круг, где то, что я ожидаю, и мой прогноз заключается в том, что если вы находитесь в этом цикле, ваша производительность агента будет постоянно снижаться в течение года. С другой стороны, мы живём в удивительное время, когда, если мы повысим способность агентов помогать нам быть продуктивными, то они смогут фактически помочь нам быть более продуктивными, и мы фактически попадаем в добродетельный цикл вместо этого, где мы фактически ускоряемся всё больше и больше и больше. И да, некоторые из этих вещей звучат как очень дорогие фундаментальные инвестиции, но я думаю, что сейчас самое время их сделать, потому что сейчас одно из времён, когда вы получите самое большое отличие в вашем бизнесе с точки зрения скорости разработки программного обеспечения, если вы сможете сделать эти вещи по сравнению с другими отраслями или компаниями, которые структурно не могут сделать эти вещи. Итак, подводя итог, вот несколько вещей. Не буквально всё в мире, что вы можете сделать, не вызывает сожалений, но вы можете стандартизировать свои среды разработки. Вы можете создавать CLI или API для всего, что требует CLI или API. Эти CLI или API должны работать во время разработки. Кстати, ещё одна большая вещь, которую люди упускают, — иногда у них есть вещи, которые работают только в CI. Если ваш CI занимает 15-20 минут, и, знаете ли, агенты гораздо более настойчивы и терпеливы, чем человек. Так что, например, но они также более склонны к ошибкам, чем люди. Так что, например, они запустят вещь, а затем запустят ваш тест, а затем запустят вещь, а затем запустят ваш тест, а затем запустят вещь, а затем запустят ваш тест, и они сделают это примерно пять раз подряд. Если это займёт 20 минут, продуктивность ваших разработчиков будет подорвана. В то время как, если это займёт 30 секунд, у них будет гораздо лучший опыт. Вы можете улучшить валидацию. Вы можете рефакторить как для тестируемости, так и для возможности рассуждать о кодовой базе. Вы можете убедиться, что весь внешний контекст и ваши намерения, «почему», записаны. Вы можете сделать каждый ответ во время проверки кода быстрее. И вы можете повысить планку качества проверки кода. Но если вы посмотрите на все эти вещи, есть один урок и один принцип, который мы извлекаем из всего этого, который охватывает даже больше вещей, чем это. И это, по сути, то, что хорошо для людей, хорошо для ИИ. И самое замечательное в этом, одну секунду. Самое замечательное в этом то, что это означает, что когда мы инвестируем в это, мы поможем нашим разработчикам, независимо от того, что произойдет. Даже если иногда мы ошибаемся в помощи агенту, мы гарантированно поможем людям. Большое спасибо. >> [музыка]