Transcription
[Музыка] Сегодня я немного расскажу об агентах для написания кода и о том, как их эффективно использовать. Если вы похожи на меня, то обнаружили, что многое работает очень хорошо, а многое — не очень. Итак, немного обо мне. Меня зовут Роберт Бреннан. Я занимаюсь разработкой инструментов для разработки с открытым исходным кодом уже более десяти лет. Я и моя команда создали агент для разработки программного обеспечения с открытым исходным кодом под названием Open Hands, ранее известный как Open Devon.
Итак, чтобы заявить об очевидном, в 2025 году разработка программного обеспечения меняется. Наша работа сильно отличается от того, что было 2 года назад. И она будет сильно отличаться через два года. И я хочу убедить вас в том, что написание кода уходит. Мы будем тратить гораздо меньше времени на фактическое написание кода. Но это не значит, что разработка программного обеспечения уходит. Нам платят не за то, чтобы мы печатали на клавиатуре, а за то, чтобы мы критически мыслили о проблемах, которые перед нами стоят. И поэтому, если мы правильно подойдем к разработке на основе ИИ, это будет означать, что мы будем меньше времени проводить, наклонившись и щурясь в нашу IDE, и больше времени проводить, откинувшись на стуле и размышляя: «Что на самом деле хочет пользователь?», «Что мы на самом деле пытаемся построить?», «Какие проблемы мы пытаемся решить как организация?», «Как мы можем спроектировать это таким образом, чтобы это обеспечило нам будущее?» ИИ очень хорош в этом цикле разработки: написать код, запустить код, написать код, запустить код. Он не очень хорош в этих масштабных задачах, которые должны учитывать, должны учитывать эмпатию к конечному пользователю, учитывать бизнес-цели. И вот здесь мы, как инженеры-программисты, вступаем в игру.
Итак, давайте немного поговорим о том, что такое агент для написания кода. Я думаю, это слово «агент» сейчас часто используется. Его значение со временем начало меняться. Но в основе его лежит концепция агентности. Это идея совершения действий в реальном мире. И это основные инструменты в работе инженера-программиста, верно? У нас есть редактор кода для фактического изменения нашей кодовой базы, навигации по ней. У вас есть терминал, который поможет вам фактически запускать код, который вы пишете. И вам нужен веб-браузер, чтобы искать документацию и, возможно, копировать и вставлять код из Stack Overflow. Так что это основные инструменты работы, и это те инструменты, которые мы даем нашим агентам, чтобы они могли выполнять весь свой цикл разработки.
Я также хочу провести различие между агентами для написания кода и некоторыми более тактическими инструментами генерации кода, которые существуют. Мы начали пару лет назад с таких вещей, как функция автодополнения GitHub Copilot, где, знаете ли, где бы ни находился ваш курсор в кодовой базе, он просто заполняет две или три строки кода. А затем со временем вещи становились все более и более агентскими, все более и более асинхронными, верно? Итак, у нас появились IDE на базе ИИ, которые могут выполнять несколько шагов за раз без вмешательства разработчика. А затем теперь у вас есть такие инструменты, как Devon и Open Hands, где вы действительно даете агенту одно или два предложения, описывающих, что вы хотите, чтобы он сделал. Он уходит и работает 5, 10, 15 минут самостоятельно, а затем возвращается к вам с решением. Это гораздо более мощный способ работы. Вы можете многое сделать. Вы можете отправлять несколько агентов одновременно. Вы можете сосредоточиться на общении с коллегами или бездельничать на Reddit, пока эти агенты работают на вас. И это просто, это очень другой способ работы, но это гораздо более мощный способ работы.
Итак, я хочу немного поговорить о том, как эти агенты работают под капотом. Я чувствую, что как только вы поймете, что происходит под поверхностью, это действительно поможет вам развить интуицию о том, как эффективно использовать агентов. И в основе своей агент — это цикл между большой языковой моделью и внешним миром. Итак, большая языковая модель служит мозгом. А затем мы должны неоднократно совершать действия во внешнем мире, получать некоторую обратную связь от мира и передавать ее обратно в LLM. Итак, по сути, на каждом шаге этого цикла мы спрашиваем LLM, что дальше вы хотите сделать, чтобы приблизиться к своей цели на один шаг. Она может сказать: «Хорошо, я хочу прочитать этот файл». «Я хочу внести это изменение». «Я хочу выполнить эту команду». «Я хочу посмотреть эту веб-страницу». Мы выходим и совершаем это действие в реальном мире, получаем какой-то вывод, будь то содержимое веб-страницы или вывод команды, а затем возвращаем его в LLM для следующего хода цикла.
Чтобы немного поговорить о основных инструментах, доступных агенту. Первым снова является редактор кода. Вы можете подумать, что это очень просто. На самом деле это довольно интересная проблема. Наивным решением было бы просто передать старый файл в LLM, а затем заставить ее выдать весь новый файл. Но это не очень эффективный способ работы. Если у вас есть тысяча строк, тысячи строк кода, и вы хотите изменить всего одну строку, вы потратите много токенов, печатая все строки, которые остаются неизменными. Поэтому большинство современных агентов используют редактор типа «найти и заменить» или редактор на основе различий, чтобы позволить LLM вносить тактические правки внутри файла. Часто они также предоставляют абстрактное синтаксическое дерево или какой-то способ позволить агенту более эффективно перемещаться по кодовой базе.
Далее идет терминал, и снова вы подумаете, что текст на входе и текст на выходе должны быть довольно простыми, но здесь возникает много вопросов. Что вы делаете, когда есть долго выполняющаяся команда, у которой долго нет стандартного вывода? Вы ее убиваете? Вы позволяете LLM ждать? Что происходит, если вы хотите выполнить несколько команд параллельно? Запускать команды в фоновом режиме. Возможно, вы хотите запустить сервер, а затем выполнить curl против этого сервера. Множество действительно интересных проблем возникает, когда агент взаимодействует с терминалом.
И, вероятно, самый сложный инструмент — это веб-браузер. Опять же, здесь есть наивное решение, когда агент просто дает вам URL, а вы даете ему кучу HTML. Это очень дорого, потому что в этом HTML есть куча мусора, который LLM на самом деле не нужно видеть. Мы добились большого успеха, передавая ей деревья доступности или преобразуя в markdown и передавая это в LLM, или позволяя LLM прокручивать веб-страницу, если там много контента. А затем, если вы начнете добавлять взаимодействие, все станет еще сложнее. Вы можете позволить LLM писать JavaScript для страницы, или мы добились большого успеха, фактически передавая ей снимок страницы с помеченными узлами, и она может сказать, на что хочет нажать. Это область активных исследований. Месяц назад мы получили вклад, который удвоил нашу точность в веб-браузинге. Я бы сказал, что за этим определенно стоит следить.
И я также хочу поговорить о песочнице. Это действительно важная вещь для агентов, потому что если они собираются работать автономно в течение нескольких минут без вашего наблюдения за всем, что они делают, вы хотите убедиться, что они не делают ничего опасного. И поэтому все наши агенты по умолчанию работают внутри Docker-контейнера. Они полностью отделены от вашей рабочей станции, поэтому нет никакого шанса, что они запустят `rm -rf` в вашей домашней директории. Однако все чаще мы предоставляем агентам доступ к сторонним API, верно? Так что вы можете предоставить им доступ к токену GitHub или к вашей учетной записи AWS. Очень-очень важно убедиться, что эти учетные данные имеют строгие ограничения и что вы следуете принципу наименьших привилегий при предоставлении агентам доступа к выполнению этих задач.
Хорошо, я хочу перейти к некоторым лучшим практикам. Мой главный совет для тех, кто только начинает, — это начинать с малого. Лучшие задачи — это те, которые могут быть выполнены довольно быстро. Знаете, один коммит с четким определением завершения. Вы хотите, чтобы агент мог проверить: «Хорошо, тесты проходят, я, должно быть, сделал это правильно». Или, знаете ли, конфликты слияния устранены и так далее. И задачи, которые легко проверить для вас как инженера, были выполнены полностью и правильно. Мне нравится говорить людям начинать с мелких поручений. Очень часто у вас может быть пул-реквест, где один тест не проходит, или есть ошибки линтинга, или есть конфликты слияния. Куски рутины, которые вам не очень нравятся делать в качестве разработчика. Это отличные задачи, чтобы просто свалить на ИИ. Они, как правило, очень рутинные. ИИ делает их очень хорошо. Но по мере роста вашей интуиции, по мере того, как вы привыкаете работать с агентом, вы обнаружите, что можете давать ему все более крупные задачи. Вы поймете, как эффективно общаться с агентом. И я бы сказал, что для меня, для моих соучредителей и для наших самых активных пользователей, для меня около 90% моего кода теперь проходит через агента, и только примерно в 10% случаев мне приходится возвращаться в свою IDE и снова погружаться в кодовую базу.
Быть очень ясным с агентом относительно того, чего вы хотите, очень важно. Я особенно люблю говорить: «Вы должны сказать ему не только то, чего вы хотите, но и как вы хотите, чтобы он это сделал». Упомяните конкретные фреймворки, которые вы хотите использовать. Если вы хотите использовать стратегию разработки, управляемую тестами, скажите ему это. Упомяните любые конкретные файлы или имена функций, которые он может использовать. Это не только помогает ему быть более точным и более ясным относительно того, чего именно вы хотите получить в результате, но и ускоряет его работу, верно? Ему не нужно тратить столько времени на изучение кодовой базы, если вы говорите ему: «Я хочу, чтобы ты отредактировал этот конкретный файл». Это может сэкономить вам кучу времени и энергии, а также сэкономить много токенов, много фактических затрат на вывод.
Я также люблю напоминать людям, что в мире разработки, управляемой ИИ, код дешев. Вы можете выбрасывать код. Вы можете экспериментировать и прототипировать. Мне нравится, если у меня есть идея, например, по дороге на работу, я просто говорю Open Hands голосом: «Сделай X, Y и Z», и когда я прихожу на работу, у меня будет PR, ожидающий меня. В 50% случаев я просто выброшу его. Он не очень хорошо сработал. В 50% случаев он выглядит отлично, и я просто сливаю его, и это здорово. Это действительно весело — иметь возможность быстро прототипировать с помощью разработки, управляемой ИИ. И я бы также сказал, что если вы пытаетесь работать с агентом над конкретной задачей, и он делает ее неправильно, возможно, он близок, и вы можете продолжать итерации в рамках того же разговора, и он уже накопил некоторый контекст. Но если он сильно ошибается, просто выбросьте эту работу. Начните заново с нового запроса, основанного на том, что вы узнали из предыдущего. Это действительно, действительно, я думаю, новая мышечная память, которую вам нужно развить, чтобы просто выбрасывать вещи. Иногда трудно выбросить десятки тысяч строк кода, которые были сгенерированы, потому что вы привыкли к тому, что это очень дорогой набор кода. В наши дни очень легко просто начать с нуля. Опять же, это, вероятно, самый важный совет, который я могу дать людям. Вы должны просматривать код, который пишет ИИ. Я видел, как более чем одна организация попадала в беду, думая, что они могут просто «вайб-кодить» свой путь к производственному приложению и просто автоматически сливать все, что вышло из ИИ. Но если вы просто ничего не просматриваете, вы обнаружите, что ваша кодовая база растет и растет с этим техническим долгом. Вы найдете дублирующийся код повсюду. Все очень быстро выходит из-под контроля. Поэтому убедитесь, что вы просматриваете код, который он выводит, и убедитесь, что вы загружаете код и запускаете его на своей рабочей станции или запускаете его в эфемерной среде, просто чтобы убедиться, что агент действительно решил проблему, которую вы просили его решить. И мне нравится говорить: «Доверяй, но проверяй». Знаете, по мере того, как вы работаете с агентами со временем, вы разовьете интуицию относительно того, что они делают хорошо, а что нет, и вы можете в целом доверять им работать так же сегодня, как и вчера. Но вам действительно нужен человек в цикле. Знаете, один из наших главных выводов с Open Hands в первые дни: если вы открывали пул-реквест с Open Hands, этот пул-реквест отображался как принадлежащий Open Hands, рядом с пул-реквестом был маленький логотип рук. И это вызвало две проблемы. Во-первых, это означало, что человек, инициировавший этот пул-реквест, мог затем одобрить его и фактически обойти всю нашу систему проверки кода. Вам не нужен был второй человек в цикле перед слиянием. И во-вторых, часто эти пул-реквесты просто застаивались. Никто на самом деле не брал на себя ответственность за них. Если бы был какой-то не проходящий юнит-тест, никто не прыгал, чтобы убедиться, что тест проходит. И они просто как бы сидели там и не сливались, или если они сливались, и что-то шло не так, код на самом деле не работал. Мы не знали, к кому обратиться и сказать: «Кто это вызвал?» Не было никого, кого можно было бы привлечь к ответственности за это нарушение. И поэтому теперь, если вы открываете пул-реквест с Open Hands, на этом пул-реквесте ваше лицо. Вы несете ответственность за его слияние. Вы несете ответственность за любые сбои, которые он может вызвать в будущем.
Круто. И тогда я хочу просто закончить, пройдясь по нескольким вариантам использования. Это всегда довольно сложная тема, потому что агенты — отличные универсалы. Они могут гипотетически делать что угодно, если вы разбиваете вещи на мелкие шаги, которые они могут выполнить. Но в духе начинать с малого, я думаю, есть ряд вариантов использования, которые являются отличными вариантами использования для агентов с первого дня. Мой любимый — разрешение конфликтов слияния. Это самая большая рутина в моей работе. Сам OpenHands — это очень быстро развивающаяся кодовая база. Я говорю, что, вероятно, нет ни одного PR, который я делаю, с которым я обхожусь без конфликтов слияния. И мне нравится просто зайти и сказать: «В OpenHands исправь конфликты слияния в этом PR». Он приходит, и, знаете ли, это такая рутинная задача. Обычно очень очевидно, что изменилось до этого, что изменилось в этом PR, каково намерение этих изменений. И OpenHands справляется с этим, знаете ли, в 99% случаев.
Обработка отзывов PR — тоже любимая. Это здорово, потому что кто-то другой уже потратил время на четкое формулирование того, что он хочет изменить, и все, что вам нужно сделать, это сказать: «В OpenHands сделай то, что сказал этот парень». И снова, как вы можете видеть в этом примере, OpenHands сделал именно то, что хотел этот человек. Я не очень хорошо разбираюсь в React, и наш фронтенд-инженер сказал: «Сделай X, Y и Z», и он упомянул кучу модных словечек, которые я не знаю. OpenHands знал все это и смог отреагировать на его отзывы именно так, как он хотел.
Исправление мелких ошибок. Знаете, вы можете видеть в этом примере, у нас был ввод, который, знаете ли, был текстовым вводом. Должен был быть числовой ввод. Если бы я не был ленив, я мог бы покопаться в своей кодовой базе, найти нужный файл. Но мне было очень легко просто быстро, я думаю, я сделал это прямо из Slack, просто добавил OpenHands, «исправь эту вещь, о которой мы только что говорили». И это просто, знаете ли, действительно, мне даже не нужно запускать свою IDE. Это просто, это действительно, действительно приятный способ работы.
Инфраструктурные изменения — мне очень нравятся. Обычно они включают в себя поиск какого-то очень эзотерического синтаксиса в документации Terraform или что-то в этом роде. OpenHands и, знаете ли, лежащие в основе LLM, как правило, просто знают правильный синтаксис Terraform, а если нет, они могут искать документацию с помощью браузера. Так что эти вещи действительно хороши. Иногда мы просто получаем исключение «недостаточно памяти» в Slack и немедленно говорим: «Хорошо, OpenHands, увеличь память».
Миграции баз данных — еще одна отличная вещь. Это то, где я нахожу, что часто отступаю от лучших практик. Я не буду ставить индексы на нужные вещи. Я не буду правильно настраивать внешние ключи. LLM, как правило, очень хорошо следует всем лучшим практикам, связанным с миграциями баз данных. Так что опять же, это своего рода рутинная задача для разработчиков. Это не очень весело. LLM отлично справляется с этим.
Исправление не проходящих тестов, как в PR. Если код уже на 90% готов, и просто юнит-тест не проходит из-за изменения API, которое нарушает обратную совместимость, очень легко вызвать агента, чтобы он просто исправил не проходящие тесты.
Расширение тестового покрытия — еще одна вещь, которую я люблю, потому что это очень безопасная задача, верно? Пока тесты проходят, обычно безопасно просто слить это. Так что, если вы заметили место в своей кодовой базе, где вы думаете: «Эй, у нас здесь очень низкое покрытие». Просто попросите вашего агента расширить тестовое покрытие в этой области кодовой базы. Это отличная быстрая победа, чтобы сделать вашу кодовую базу немного безопаснее.
Затем, любимое занятие всех — создание приложений с нуля. Знаете, я бы сказал, что если вы выпускаете производственный код, опять же, не просто «вайб-кодите» свой путь к производственному приложению. Но мы все чаще обнаруживаем внутри нашей компании, что часто есть какое-то маленькое внутреннее приложение, которое мы хотим построить. Например, мы создали способ отлаживать траектории Open Hands, отлаживать сессии Open Hands. Мы построили целое веб-приложение, которое, поскольку это всего лишь внутреннее приложение, мы можем немного «вайб-кодить». Нам не нужно просматривать каждую строку кода. Оно на самом деле не ориентировано на конечных пользователей. Это было действительно, действительно весело для нашего бизнеса — иметь возможность быстро создавать эти приложения просто для удовлетворения наших собственных внутренних потребностей. Так что да, Greenfield — это отличный, отличный вариант использования для агентов.
Это все, что у меня есть. Я хотел бы, чтобы вы все присоединились к сообществу Open Hands. Вы можете найти нас на GitHub, allhandsaihands. Присоединяйтесь к нам в Slack, Discord. Мы будем рады строить вместе с вами. [Музыка]