Агентная разработка с помощью ИИ Инженерия JetBrains Мнение
Я обдумываю это уже около года. Ландшафт разработки изменился до такой степени, что нельзя пролистать новости и не встретить кого-то, кто заявляет: «Я больше никогда не открываю свою IDE» или «Я всё делаю в терминале». И такие рабочие процессы действительно подходят некоторым людям. Но не всем. Я искренне верю, что IDE воплощают в себе то, за что мы любим нашу работу. Возникает вопрос: как нам двигаться дальше по мере изменения мира?
Рабочий процесс изменился. Окружение должно соответствовать ему.
Кодинг-агенты перестали быть экспериментом; для многих из нас они уже стали повседневной частью создания ПО. Мы больше не ограничиваемся автодополнением по вкладке. Мы поручаем агентам содержательные задачи, которые затрагивают множество файлов, исследуют зависимости и выполняют рефакторинг между пакетами. Повседневный ритм инженерии эволюционирует: он всё меньше сводится к побуквенному вводу и всё больше — к управлению намерениями.
Представьте это изменение как переход от ручного пилотирования к использованию бортового компьютера современного самолета. Компьютер может справляться со сложным исполнением, но он способен на это, потому что подключен к приборам самолета: навигации, высоте, скорости и данным двигателей. Пилоту не нужно двигать каждый элемент управления в каждый момент времени, но ему по-прежнему нужна кабина, где он видит весь полет, понимает происходящее и может вмешаться при изменении маршрута.
Агентная разработка программного обеспечения работает точно так же. Агент может спланировать и осуществить серьезное изменение, но ему требуется насыщенное окружение, равно как и управляющему им инженеру. Анализ кода, навигация, информация о зависимостях, проверка типов, тесты и доступ к системам вокруг кода обеспечивают тот контекст, который терминал или изолированная сессия могут не показывать достаточно наглядно. Агент может запустить компилятор или тест; IDE делает результат частью общей картины проекта, поэтому вы можете понять не только то, что что-то сломалось, но и на что это влияет и почему.
Пилот также отвечает за полет, даже когда большую часть работы выполняет компьютер. Инженер отвечает за то, что отправляется в релиз, даже когда большую часть кода написал агент. Это означает просмотр изменений в контексте, понимание их последствий, а также способность объяснить и защитить результат в дальнейшем.
И здесь в дело вступает здравый смысл: решение о том, является ли предложенный маршрут правильным, а не просто о том, может ли самолет добраться до пункта назначения. Агент может создать работающую реализацию; инженер же решает, соответствует ли она архитектуре, пользователям и решаемой проблеме.
Именно здесь роль IDE становится особенно интересной. Это кабина пилота, где агенты и разработчики могут видеть один и тот же проект, использовать одни и те же приборы и совместно принимать решения, определяющие то, что идет в релиз. Промпт может запустить работу. IDE — это место, где вы управляете, проверяете и берете на себя ответственность за результат.
От «написания синтаксиса» к «управлению намерениями»
Это проблема контекста. Агент может рассуждать в рамках вашей кодовой базы, но если вы не видите то, что видит он, вы на самом деле не управляете им — вы просто надеетесь, что он все сделал правильно.
Агентные инструменты — это не преходящая мода. Они являются основой того, как многие из нас строят процессы сейчас, и это никуда не денется. Быть хорошим разработчиком никогда по-настоящему не означало печатать с высокой скоростью. Набор текста был лишь механической частью. Настоящая работа заключалась в том, чтобы понять, что требует изменений, и принять решение о дальнейших действиях. Набор текста занимал так много времени, что его было легко спутать с самой работой.
Теперь, когда набор текста не является узким местом, день выглядит иначе. Вы читаете план агента до его запуска. Вы ловите тот самый краевой случай, который он упустил. Вы задаетесь вопросом, является ли предложенное им изменение действительно правильным, а не просто работающим. Меньше времени на создание кода, больше времени на принятие решения о том, что код корректен.
Недавно я создал кое-что на стеке, с которым у меня практически не было реального опыта. Я хотел сделать расширение для браузера, но после чтения документации мне было неясно, как выполняются инициализация и настройка проекта.
Вместо того чтобы изучать каждую деталь перед началом работы, я перенаправил на эту проблему агента. Он взял на себя большую часть механической работы: от создания проекта и его настройки до подготовки первых элементов, в то время как я сосредоточился на том, что именно хочу создать. Мне не нужно было знать точный синтаксис или процесс настройки, чтобы выразить намерение. Агент не заменил обучение. Он дал мне рабочий проект, который я мог исследовать, изучать и улучшать, вместо пустого файла или пустого рабочего пространства. Открыв IDE, я смог увидеть, как элементы сочетаются друг с другом, проследить незнакомый код и направить следующий шаг, опираясь на нечто реальное.
Несколько лет назад этот проект не состоялся бы или продвигался гораздо медленнее, потому что препятствием всегда было «я недостаточно хорошо это знаю, чтобы начать». Агент снизил этот барьер. Он взял на себя часть механической работы, позволив мне сконцентрироваться на проблеме, направлении и решениях, которые имели значение.
Это также вовлекает вас в общую картину, даже при выполнении небольших задач. Если агент затрагивает дюжину файлов для того, что раньше решалось правкой двух строк, именно вы должны знать, были ли это правильные двенадцать файлов. Это означает, что теперь вы проводите больше времени на архитектурном уровне: больше думаете о том, как сервисы зависят друг от друга, на что изменение реально влияет на дальнейших этапах и соответствует ли план агента тому, как должна работать система. Раньше тикет/задача означали: «Мне нужно отредактировать эту функцию, чтобы решить проблему». Теперь это означает: «Мне нужно определить правильную структуру для всех изменений в целом, а затем указать агенту, что именно нужно отредактировать». Это сложно сделать из окна чата. Вы наблюдаете, как агент принимает реальные решения относительно вашей кодовой базы через интерфейс, который показывает вам по одному сообщению за раз. Если эти инструменты способны анализировать весь ваш проект, вы тоже должны иметь возможность видеть его целиком и понимать, как они на него влияют; в противном случае вы просто кликаете кнопку «одобрить».
Здесь же в игру вступают собственные инструменты IDE — не только для вас, но и для агента.
Верификация и понимание — вот где кроется ответственность
Это проблема ответственности. Корректность кода и то, что код принадлежит вам — это две разные вещи, и послеполетный разбор переживает только одна из них.
Генерировать больше кода теперь легко. Агент может написать вам работающую функцию за секунды, и в большинстве случаев она будет нормальной с первой попытки. Теперь это уже не самое сложное, и отношение к этому как к сложной задаче приводит к тому, что в релиз уходит то, чего никто в вашей команде на самом деле не понимает.
Узким местом стала верификация. Теперь мы беспокоимся о таких вопросах, как: «Правильно ли это?», «Учитывает ли это ситуацию, с которой действительно сталкиваются ваши пользователи?» и «Соответствует ли это тому, как должна вести себя остальная часть системы, а не только тому, как эта отдельная функция ведет себя изолированно?». Агент может сгенерировать код быстрее, чем вы успеете его прочитать, а это значит, что чтение — настоящее чтение, а не беглый просмотр диффов — теперь является самой медленной частью работы. И это нормально, потому что эта часть всегда должна была быть медленной.
Это важно, потому что нельзя владеть кодом, которого вы не понимаете. Если в написанном агентом коде обнаруживается баг, а в вашем коммите слияния написано «это написал агент», желаем удачи на этом звонке по разбору инцидента или в ретроспективе. Ваше имя стоит на коммите, поэтому вы должны понимать изменения достаточно хорошо, чтобы защитить их, отладить и объяснить кому-то другому. Именно это делает код вашим, и это не происходит от чтения краткой выжимки того, что сделал агент. Это происходит, когда вы разбираетесь с реальным изменением в контексте и тратите на это достаточно времени, чтобы быть уверенным в результате. Агент — это не тот, кого вызывают в 2 часа ночи, не тот, кто присутствует на разборе полетов, и не тот, чье имя указано в отчете о производительности. Это вы. Ответственность не перекладывается автоматически только потому, что автором кода стал кто-то другой, и ни одна команда не примет фразу «это сделал агент» в качестве замены «я понимал, что отправляю в релиз».
Кроме того, именно для этого IDE и создавались изначально. Задолго до появления агентов главной функцией IDE было позволить вам проверить решение проблемы, дать возможность перейти к определению, посмотреть, где вызывается функция, поймать ошибку типов до релиза и проследить переменную до места ее создания. Ни одну из этих функций не нужно изобретать заново для работы с агентами; ее нужно просто направить на результаты работы агента, а не на ваш собственный код. Инструмент для понимания кода существовал все это время. Единственное новшество заключается в том, что вы работаете не только со своим собственным кодом.
Гордитесь тем, что вы создаете
Это вопрос суждения, и на самом деле он никогда не касался самих агентов.
На самом деле это разговор не об инструментах. Это разговор о том, на чем строится дисциплина разработки программного обеспечения, и о том, сохранится ли это при переходе к работе с агентами или затеряется в ней.
Легко подумать: «Я почти сам не пишу код на клавиатуре», — и почувствовать себя отстраненным от процесса. Это не так, до тех пор пока фундаментальные мыслительные процессы остаются вашими во всех важных аспектах. Вы можете не вводить ничего с клавиатуры и при этом оставаться тем, кто разработал архитектуру, тем, кто знал, почему именно этот подход правилен, когда остальные члены вашей команды думали иначе, или тем, кто заметил скрытую ошибку, допущенную агентом, до того, как код ушел в релиз. Это не меньший объем работы, чем написание каждой строки вручную. Это та же самая работа, что и всегда, только без набора текста на клавиатуре.
Важно помнить, что инженеры на самом деле никогда не занимались производством кода. Инженеры решают проблемы. Код всегда был лишь средой, которая требовала больших затрат ручного труда для своего создания, поэтому этот труд стали ошибочно принимать за само ремесло. Агент, который пишет код быстрее, чем вы печатаете, не заменяет ремесло; он убирает ту часть работы, которая никогда по-настоящему не была главной целью.
Поэтому гордитесь тем, что всегда было вашей настоящей работой: принятием решений, архитектурой, финальным решением о том, что должно существовать и почему. Если агент помогает вам прийти к этому быстрее, это не уменьшенная версия инженерии. Это тот же самый стандарт, к которому относятся со всей серьезностью, просто теперь он движется с той скоростью, которую наконец-то позволяют технологии.
Любой капитан, летящий на автопилоте, все равно нуждается в кабине для контроля траектории полета. Приборы не заменяют пилота; они делают пилота способным безопасно управлять столь сложной машиной. Воспринимайте IDE как свою кабину пилота-программиста. Это не просто «приятное дополнение» к агенту. Это то, что делает управление им — а не просто общение с ним — действительно возможным.
Инструменты IDE для разработчиков И агентов
IDE обладают уникальными возможностями для решения вышеуказанных проблем, точно так же, как бортовой компьютер в самолете. Нам следует предоставить агентам доступ к тем же приборам и элементам управления, которые есть у пилота, а также к инструментам валидации и проверки. Насыщенная возможностями IDE также дает вам возможность проявить свои профессиональные суждения, помогая понять код и взять за него ответственность, предоставляя все необходимое для выполнения работы.
LLM носят вероятностный характер. Они делают предположения — хорошо обоснованные предположения, но все же предположения. Разработка программного обеспечения — нет. У системы типов нет собственного мнения о том, компилируется ли код; он либо компилируется, либо нет. Именно в этом разрыве между тем, как мыслит агент, и тем, как система ведет себя на самом деле, кроется большинство реальных багов.
Прямо сейчас большая часть этого разрыва устраняется постфактум. Некоторые агенты уже запускают компиляторы, линтеры и тесты прямо в процессе работы, что действительно полезно, так как позволяет отлавливать ошибки, которые в противном случае ушли бы в релиз. Но запуск проверки и реальное восприятие системы так, как это делает разработчик, — не одно и то же. Агент получает ошибку компиляции или времени выполнения, возможно, трассировку стека. Человек, использующий IDE, получает проверку типов, линтер и набор тестов, интегрированные в реальную навигацию и контекст — не просто результат «успех/неуспех», а причину этого. Исходя из этого, вы можете проследить источник и понять, как он связан с общей картиной. Инструменты больше не отсутствуют в цикле работы агента. Чего не хватает, так это глубины связанности и возможности выбрать правильный инструмент в нужное время.
Решение заключается не в том, чтобы заставить агента лучше угадывать. А в том, чтобы помочь ему принимать более осознанные решения. Та же детерминированная информация, которую предоставляет вам IDE (например, разрешение типов, линтинг и проверка ошибок в реальном времени), должна быть доступна агенту во время его работы, а не только человеку, проверяющему его код после. Агент, который может проверять собственные типы в процессе работы, видеть ошибку линтера в момент написания этой строки и запускать только что сломанный тест перед тем, как двигаться дальше, больше не полагается на вероятности. Он работает с той же надежной основой правды, на которую всегда опирались ваши инструменты.
Именно этот сдвиг и происходит сейчас. Дело не в более умных агентах, а в тех же детерминированных инструментах, которые мы создали для разработчиков и которые наконец-то направлены на то, что пишет код, а не только на человека, который проверяет его после.
Как только агенты смогут работать с теми же инструментами, на которые полагаются разработчики, возникает следующий вопрос: кто выбирает этих агентов и инструменты? Разработчики должны иметь возможность использовать лучший инструмент для задачи без необходимости перестраивать свой рабочий процесс или пробираться через лабиринт настроек. IDE должна оставаться стабильным уровнем, соединяющим агентов с мощными инструментами разработки, но она полезна только в том случае, если разработчики не привязаны к рабочей версии только одного конкретного провайдера.
У нас не должно быть «огороженных садов» из ИИ
Ставить на кон весь свой рабочий процесс, доверяя его единственному поставщику моделей — это реальный риск, а не гипотетический. Провайдеры могут менять цены, быть поглощенными другими компаниями, прекращать поддержку моделей, сталкиваться с сбоями в работе и на несколько месяцев отставать от конкурентов. Если для смены провайдера требуется менять ваши инструменты, рабочие процессы и конфигурацию, то издержки переключения становятся причиной оставаться на месте, даже когда появляется лучший вариант. Цель состоит вовсе не в том, чтобы заставить разработчиков управлять сложным набором интеграций. Все наоборот: предоставить им одну надежную среду, где они смогут использовать агентов и модели, КОТОРЫЕ ОНИ ХОТЯТ, с необходимым контекстом проекта и инструментами разработки, без лишних препятствий.
Именно здесь на помощь может прийти протокол Agent Client Protocol (ACP). ACP предоставляет IDE и агентам кодирования общий способ общения, уменьшая потребность в отдельной кастомной интеграции каждый раз, когда добавляется новый агент. Это может сделать агента родным для IDE, не делая при этом саму IDE зависимой от единственного провайдера. ACP избавляет от рутинной работы по интеграции; ему вовсе не обязательно лишать разработчика свободы выбора.
В этом даже не учитывается тот факт, что с выходом каждой новой модели общая риторика сводится к тому, что именно она должна стать основной в дальнейшем. Если весь ваш конвейер разработки завязан на API одного провайдера, каждое из таких событий становится вашей проблемой тоже. Это не решение по выбору инструмента; это зависимость, которую вы приняли на себя, по сути, не выбирая ее. И все мы прекрасно знаем, что происходит, когда мы берем на себя зависимость — рано или поздно она доставит нам хлопот при возникновении изменений.
Решение заключается вовсе не в выборе правильного провайдера. Правильного провайдера просто не существует; тот, кто лучше всех сегодня, не обязательно будет лучшим через месяц, и при той скорости, с которой развивается эта сфера, ранняя привязка к чему-то одному приводит к тому, что в итоге вы защищаете выбор, сделанный по причинам, которые перестали быть актуальными. И когда эта новая модель в конечном итоге выходит, она должна пройти через горнило ваших потребностей в разработке ПО, прежде чем вы почувствуете себя уверенно, «доверяя» ей.
Это означает, что сама IDE не должна иметь предвзятого мнения о том, какая именно модель выполняет работу. Смена провайдеров, запуск разных моделей для разных задач, тестирование новой в неделю ее релиза — ничто из этого не должно требовать перенастройки всей вашей системы. Если смена моделей превращается в целый проект, вы не станете этого делать и в итоге застрянете с тем, что выбрали в первый раз по умолчанию, а не по собственному выбору.
Именно в этом на практике и заключается концепция Bring Your Own Keys (BYOK). Вы приносите учетные данные для моделей и провайдеров по вашему выбору (обычно это ключ API, а иногда аккаунт или подписка) и подключаете их к IDE. IDE остается местом, где сосредоточены контекст проекта, интеллигентная работа с кодом, инструменты и ревью. Провайдер предоставляет модель, в то время как вы сохраняете контроль над использованием, лимитами и затратами. Переключение означает выбор другого настроенного провайдера или модели, а не перестройку вашего рабочего процесса.
ACP и BYOK решают разные части одной и той же проблемы. ACP помогает IDE подключаться к различным агентам через общий интерфейс. BYOK позволяет разработчикам выбирать учетные данные провайдера, стоящие за этим опытом. Одно обеспечивает совместимость, другое сохраняет контроль. Нативный опыт взаимодействия с агентами должен облегчать выбор, а не отнимать его.
Это не просто приятное дополнение для тех, кто любит повозиться с настройками. Это способ оставить рычаги влияния на вашей стороне, а не на стороне провайдеров. Вы используете то, что действительно хорошо прямо сейчас, отбрасываете то, что не работает, и никогда не ведете переговоры из позиции, когда переключение стоит дороже, чем бездействие.
Используйте инструменты, которые решают проблему
Вопрос, который действительно стоит перед нами: почему бы не использовать агентов и IDE вместе? Вопрос в том, КАК. Цель разработки программного обеспечения в конечном счете заключается в решении бизнес-задач с помощью ПО. За прошедшие годы «программное обеспечение» сильно изменилось: от хождения по холмам в обе стороны по снегу ради компиляции перфокарт до простого набора того, что вы хотите, и материализации этого в реальность. Сегодня я использую агентов в своей IDE, и сочетание интеллекта, предоставляемого IDE, с рассудительностью и скоростью агента приносит огромное удовольствие. Но это поистине первый шаг в трансформации того, как мы используем эти новые наборы инструментов для выполнения нашей извечной задачи: решения проблемы.
Таково наше мнение о том, куда движутся IDE и агенты. Нам интересно услышать ваше.
