Transcription
[музыка] Как дела у всех? Еще не спите? >> Хорошо, отлично. Итак, как сказал роботизированный голос, я занимаюсь опытом разработчиков очень долгое время, и за всю свою жизнь я никогда не видел ничего подобного последним 12 месяцам. Вы знаете, каждые 2-3 недели инженеры-программисты вот так вот выглядели на экране. Хорошо. И если вы работаете в сфере опыта разработчиков, проблема еще хуже. Вы выглядите как этот парень на экране каждые несколько недель. Вы говорите: «О да, да, да, да, да. Вот новая горячая штучка». А потом кто-то другой подходит и говорит: «Ну, могу ли я использовать новую, новую горячую штучку?» И знаете, люди занимаются этим годами. Я долго работаю в сфере опыта разработчиков. Всегда все приходят и говорят: «О, могу ли я использовать этот инструмент, который вышел вчера?» А вы говорите: «Нет, конечно, нет». А теперь мы говорим: «Эм, может быть, да». Верно? И все это в целом приводит к тому, что будущее сейчас очень трудно предсказать. Итак, я думаю, многие люди, многие технические директора, многие люди, которые работают в сфере опыта разработчиков, люди, которые заботятся о помощи разработчикам, задают себе этот вопрос: пойдут ли все мои инвестиции впустую? Например, во что я могу инвестировать сейчас, чтобы, оглядываясь назад в конце 2026 года, я мог сказать: я точно рад, что инвестировал в это для своих разработчиков. И я думаю, что многие люди просто решили: ну, я не знаю. Думаю, это просто кодирующие агенты, и, думаю, они сами исправят все в моей компании, что, хотя они и потрясающие, они преобразующие, но это не единственное, во что вам нужно инвестировать как организации, занимающейся разработкой программного обеспечения. Итак, мы можем прояснить это, задав себе два вопроса. Первый: как мы можем использовать наше понимание принципов опыта разработчиков, чтобы знать, что будет ценным, независимо от того, что произойдет. Хорошо. И что нам нужно сделать, чтобы получить максимальную возможную ценность от AI-агентов? Например, что нам нужно исправить на всех уровнях вне агентов, чтобы убедиться, что агенты и наши разработчики могут быть максимально эффективными? И это не мелкий вопрос. Это те вещи, которые могут сделать вас или сломать вас как программный бизнес в будущем. Итак, давайте поговорим о том, что из этого является инвестициями без сожалений, которые помогут как нашим людям, так и нашим агентам. Итак, в целом, одно из представлений, о котором я думаю здесь, это вещи, которые являются входными данными для агентов. Вещи вокруг агентов, которые помогают им быть более эффективными. И одна из самых больших — это среда разработки. Какие инструменты вы используете для создания своего кода? Какой менеджер пакетов вы используете? Какие линтеры вы запускаете? Такие вещи. Вы хотите использовать отраслевые стандартные инструменты так же, как их использует отрасль, и, в идеале, так же, как их использует внешний мир, потому что именно это находится в обучающем наборе. И посмотрите, да, вы можете писать файлы инструкций, и вы можете изо всех сил стараться бороться с обучающим набором и заставить его делать что-то неестественное и нечестивое с какой-то сумасшедшей амальгамой или модификацией, которую вы сделали с этими инструментами разработчика. Например, вы изобрели свой собственный менеджер пакетов. Вероятно, вам не следует этого делать. Вам, вероятно, следует отменить это и попытаться вернуться к тому, как внешний мир занимается разработкой программного обеспечения, потому что тогда вы не боретесь с обучающим набором. А также это означает, что это означает, что вы больше не можете использовать редкие языки программирования. Посмотрите, я фанат языков программирования. Я люблю эти вещи. Я больше не использую их в своей повседневной работе по разработке агентного программного обеспечения. Как энтузиаст, я иногда прихожу и пишу на, знаете ли, передовых программных языках, но больше не в своей реальной работе. Итак, что люди иногда спрашивают меня: означает ли это, что мы никогда больше не будем иметь новых инструментов, потому что мы всегда будем зависеть от инструментов, которые модель уже знает? Вероятно, нет, потому что, как я сказал, энтузиасты все еще будут. И также, но я хотел бы сделать замечание. То, о чем я говорю, всегда было реальной проблемой. Например, всегда был какой-то разработчик в компании, который всегда подходил к вам и говорил: «Могу ли я использовать эту технологию, которая вышла на прошлой неделе и никогда не была проверена в корпоративной среде, для запуска моей службы с 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 секунд, у них будет гораздо лучший опыт. Вы можете улучшить проверку. Вы можете переделать как для тестируемости, так и для возможности рассуждать о кодовой базе. Вы можете убедиться, что весь внешний контекст и ваши намерения, «почему», записаны. Вы можете сделать каждый ответ во время проверки кода быстрее. И вы можете повысить планку качества проверки кода. Но если вы посмотрите на все эти вещи, есть один урок и один принцип, который мы извлекаем из всего этого, который охватывает даже больше вещей, чем это. И это, по сути, то, что хорошо для людей, хорошо для ИИ. И самое замечательное в этом, одну секунду. Самое замечательное в этом то, что это означает, что когда мы инвестируем в это, мы поможем нашим разработчикам, независимо от того, что произойдет. Даже если иногда мы ошибаемся в помощи агенту, мы гарантированно поможем людям. Большое спасибо. >> [музыка]