Существует множество приложений для ИИ-программирования, и, какими бы впечатляющими ни стали большие языковые модели и создаваемые на их основе агенты, многие последние достижения в области разработки с помощью ИИ связаны с программным обеспечением, управляющим этими моделями, а не только с самими моделями.
В начале этого лета я поговорил с руководителем продукта Claude Code, компании Anthropic, Кэт Ву, о подходе этой компании к созданию такого ПО.
Ву неоднократно возвращалась к одному и тому же тезису в нашем разговоре: модели Anthropic (и их прямых конкурентов) совершенствуются настолько быстро, что планировать слишком далеко вперед или создавать вокруг них жесткие или ограничивающие функции не имеет особого смысла. Вместо этого команда продукта Claude Code пытается поддерживать то, что они называют «легкой обвязкой» (lean harness).
Обвязка — это программное обеспечение, созданное вокруг одной или нескольких ИИ-моделей, которое определяет, как они используются. Она решает, что видят модели, какие действия могут выполнять и как взаимодействуют с кодовой базой. Думайте об этом как о слое между моделью и реальным проектом разработчика.
Это не значит, что у Claude Code как приложения и обвязки нет жестких функций или дизайнерских решений, но его команда, похоже, склоняется к доверию тому, куда модели приведут их в течение следующего года.
Однако существуют и другие обвязки, помимо Claude Code. Есть Codex от OpenAI, Antigravity от Google, open source альтернативы вроде OpenCode, а также решения от стартапов, таких как Cursor или Augment Code. Каждая из них может иметь разные функции, акценты или представления о том, как модель может или должна использоваться в агентных рабочих процессах.
Один из ключевых выборов, который делает Claude Code, — это отказ от подходов, по умолчанию создающих структурированный контекст вокруг кодовой базы заранее.
«Судя по оценкам, мы не видим измеримых изменений», — сказала она о таких подходах. «И я думаю, мы в целом склоняемся к выпуску более легкой обвязки с меньшим количеством жестких инструментов, просто позволяя разработчикам добавлять свои собственные, если они захотят».
,
Augment Code сделал существенно другую ставку, хотя две компании не обязательно тестируют одни и те же вмешательства или оптимизируют под одни и те же результаты; его продукт предварительно индексирует репозиторий, используя эмбеддинги, модель поиска и векторную базу данных, а затем извлекает концептуально релевантный код. Чтобы получить другую сторону этой дискуссии, я поговорил с Винаем Пернети, вице-президентом по разработке Augment Code.
Пернети кратко описал отличающийся подход Augment Code, представил оценки преимуществ своей команды, ответил на некоторые аргументы в пользу более легкой обвязки и поделился своим взглядом на некоторые опасения разработчиков по поводу ИИ-инструментов и агентных рабочих процессов в целом.
Разговор с Винаем Пернети
Это интервью было отредактировано для краткости и ясности.
Ars Technica: Не могли бы вы объяснить, как работает контекстный движок Augment Code?
Винай Пернети: Если сделать шаг назад, чего пытается достичь конкретный разработчик? Он хочет реализовать определенную задачу и передает ее агенту. И интересная особенность современных агентов в том, что у них ограниченное контекстное окно, и каждый раз им нужно по сути получить весь необходимый контекст, а затем работать над ним.
Есть два подхода к контексту. Первый — основанный на grep. Claude Code, Codex и другие агенты делали это. Второй — семантический поиск. Для Augment мы всегда выбирали семантический путь, и я опишу его составляющие.
Я бы сказал, есть две основные части. Во-первых, у нас есть пара эмбеддингов и поисковой модели, работающих в системе, а затем у вас есть векторная база данных и целая высокооптимизированная серверная система, которая позволяет выполнять поиск за субмиллисекунды.
Ars: Есть ли у этого подхода преимущество в одном типе кодовой базы по сравнению с другим?
Пернети: Да, на самом деле оказывается, что преимущество проявляется в больших частных кодовых базах. И вот почему я так говорю.
Для всех публичных open source репозиториев, на которых проводятся большинство тестов, каждая модель по сути запомнила репозиторий. Эти модели достаточно велики, чтобы фактически запомнить весь репозиторий. Поэтому, когда вы пытаетесь что-то сделать, модели уже примерно знают, где искать, и могут быстро прийти к результату.
,
Тогда как при работе в частном репозитории модель никогда его не видела. И теперь цикл итераций для поиска результата становится намного длиннее, верно? Если у вас есть семантическое понимание всего вашего частного репозитория, вы можете задать вопрос и получить результаты гораздо быстрее.
Ars: Люди обеспокоены эффективностью использования токенов. Помогает ли этот семантический подход с этим?
Пернети: Мы определенно видели это в определенных ситуациях. Фактически, мы опубликовали пост в блоге — мы запустили Terminal-Bench с Claude Code и Augment Code на одной и той же модели. И мы достигли схожей точности, но были на 33 процента эффективнее, чем Claude Code. Так что я вижу, что это проявляется в более эффективном использовании токенов, потому что вы тратите меньше времени на исследование.
Ars: Anthropic сказали мне, что Claude Code не видит измеримых улучшений в оценках от включения большего количества инструментов семантической навигации по коду. Но затем я смотрю на ваш блог и вижу, что вы публикуете бенчмарки и другие утверждения, что это на самом деле очень помогает. Вы измеряете разные вещи, когда говорите об этом, или что упускают их оценки?
Пернети: Отличные вопросы. Я не знаю, какой конкретно поисковый движок они использовали, и я думаю, что еще одна ошибка, которую часто допускают, — это смешение понятий: не все поисковые системы равны, точно так же, как не все базы данных равны, верно? И под этим я подразумеваю, что модели и система, работающие вместе, то есть контекстный движок, имеют большое значение для качества результатов.
Так, например, в Augment мы потратили около 18 месяцев в начале основания компании в 2022 году — это было до ChatGPT — на исследование моделей поиска и эмбеддингов преимущественно для больших кодовых баз. Таким образом, было проведено много исследований о том, какие именно фрагменты кода нужно получить в этом пространстве эмбеддингов, когда вы пытаетесь достичь определенного результата. Все это закодировано в наших поисковых моделях.
И выполнение этого очень, очень быстрым способом — это система, которую мы построили вокруг этого. Поэтому, когда кто-то говорит: «Эй, я попробовал Claude Code с реализацией RAG, но не вижу преимуществ», это потому, что реализация и контекстный движок очень, очень разные, если это имеет смысл.
,
Ars: Что вы скажете на утверждение, что модели совершенствуются настолько быстро, что строить что-либо с какими-либо предположениями не имеет смысла? Это аргумент в пользу сверхлегкой обвязки или отказа от всего этого — просто потому, что вы не знаете, где все будет через шесть месяцев или двенадцать месяцев, по мере экспоненциального роста.
Пернети: В этом есть большая доля истины, но я думаю, что нужно смотреть на это с нескольких разных точек зрения.
В Augment мы думаем об этом так: для достижения высококачественных результатов нужны два ингредиента — интеллект и контекст. Когда модели становятся действительно хорошими, интеллект будет улучшаться экспоненциально, в этом нет сомнений. Но то, что они стали умнее, не означает, что у них есть контекст.
Теперь человек может получить нужный ему контекст, потратив на это токены. И здесь возникает второе измерение, о котором сейчас спрашивают все технические руководители, — это стоимость. Сколько вашего токен-бюджета уходит на сбор контекста и получение правильных результатов? Используете ли вы модель правильным образом для достижения наилучших результатов?
И вот здесь, я думаю, дизайн обвязки и контекст имеют значение. Так что для меня это комбинация интеллекта и контекста, и тогда это становится проблемой системной инженерии: как правильно распределить усилия по каждой из этих вертикалей, чтобы получить наиболее оптимальный результат с наименьшими затратами?
Ars: Среди наших читателей немало скептиков в отношении ИИ в разработке ПО. Я вижу два особенно распространенных возражения. Одно из них — они все еще чувствуют, что не могут достаточно доверять этим системам, что они создадут технический долг, который того не стоит. Другое — эти агентные рабочие процессы слишком дороги. Что вы думаете?
Пернети: Я затрону оба. Позвольте мне сделать предисловие для обоих. Я думаю, фундаментальная истина, с которой, надеюсь, все согласны, заключается в том, что модели продолжают улучшаться экспоненциальными темпами. Поэтому, что бы вы ни делали, вы хотите оседлать эту экспоненту, чтобы понимать, куда все движется, и ориентироваться, чтобы извлечь из этого выгоду.
Итак, возвращаясь к вашему вопросу о доверии, верификации и техническом долге, это правда, если вы подходите к этой проблеме как: «Я передаю это агентам и ухожу». Так это не работает, и поэтому я указываю, что это команды людей, работающие с командами агентов, где есть много моментов, в которых люди все еще лучше подходят для принятия решений, верно? Рецензирование спецификаций — это пример. Мы обнаружили, что агенты на самом деле не хороши в написании спецификаций. Поэтому вам нужно действительно работать с агентом, чтобы направлять его к написанию хорошей, качественной спецификации. Но как только у вас есть спецификация, мы находимся в точке, где они действительно хороши в выполнении. Так что нет смысла не использовать это.
,
Второе… технический долг, кстати, очень реален. Один из паттернов, который мы заметили внутри Augment — мы, очевидно, очень ориентированы на агентов — это то, что агенты очень хороши в дублировании кода… поэтому мы обнаружили, что нам приходилось проводить целенаправленные спринты по сокращению технического долга с помощью агентов. Прелесть в том, что вы можете сказать, что можете составить спецификацию, в которой говорится о том, что значит сократить технический долг, и они действительно хороши в ее выполнении. Так что я думаю, это способ решить эту часть.
И вторая часть, вы говорили о стоимости. Я думаю, здесь есть интересный момент. Если вы верите, что это способ работы в будущем, то как получить наилучший результат за свои токены? И вот здесь, я думаю, такие вещи, как контекстный движок, имеют значение. Для меня выбор правильной модели для правильной задачи имеет огромное значение.
Второе — это гораздо более философский, устремленный в будущее момент — по мере того, как возможности этих моделей продолжают улучшаться экспоненциально, и open source модели будут не отставать, наступит момент, когда, я думаю, пропорция токенов, идущих к передовым лабораториям и к open source моделям, начнет меняться. Вашу самую сложную проблему вы все еще будете бросать передовой модели, но этап кодирования, который я описал — когда я точно знаю, что нужно сделать, и я знаю, что описал это в спецификации — open source модель, возможно, сможет сделать это за вас. В этот момент ваши затраты значительно снижаются, верно? Поэтому вам нужна система, которая позволяет вам работать таким образом, и я думаю, что стоимость просто решится сама собой, как я это вижу.
,
Ars: Спасибо. Я ценю, что вы нашли время.
Пернети: Да, мне очень понравился разговор, Сэм.
Выводы
И Ву, и Пернети согласны, что ожидают продолжения улучшения передовых моделей текущими или даже более высокими экспоненциальными темпами, по крайней мере, в течение следующего года. (Ни один из них явно не затронул более длительный период времени.) Оба согласились, что это фундаментально меняет способ разработки ПО для многих организаций.
Практический спор, если он вообще есть, заключается в том, должен ли контекст собираться заранее или обнаруживаться заново во время каждой задачи — особенно в больших частных кодовых базах.
Они также иногда измеряют и оптимизируют разные вещи. Ву конкретно сказала, что Anthropic не обнаружила «измеримого улучшения производительности» от «нескольких доступных LSP». Важно отметить, что то, что Ву описывала, когда говорила это (LSP, или протокол языкового сервера), не так широко, как то, что делает обвязка Augment Code.
Когда Пернети и Ву описывают оценки инструментов или систем, выходящих за рамки grep, они не всегда говорят об одном и том же. Это одна из возможных причин (среди прочих), по которой они приходят к разным выводам.
Одна вещь, о которой Пернети мог рассказать, а Ву — нет, это возможность того, что передовые модели, такие как Opus или Fable от Anthropic, могут стать слишком дорогими, чтобы оставаться основными или единственными моделями в агентных рабочих процессах разработчиков и организаций, так что меньшие модели или модели с открытыми весами могут получить более широкое распространение.
По мере продолжения вычислительного кризиса некоторые модели с открытыми весами — включая те, что достаточно малы и достаточно квантованы для работы на локальном оборудовании или, по крайней мере, на оборудовании, обслуживаемом внутри организации — теперь приближаются к относительно недавней производительности передовых моделей на некоторых задачах кодирования. Остается возможным, что они также продолжат быстро улучшаться, став жизнеспособными для агентов кодирования во многих командах и проектах. Команды могут все чаще резервировать дорогие передовые модели для самых сложных проблем, направляя более рутинную, хорошо описанную работу на эти более дешевые или локально управляемые модели.
Независимо от того, какой подход станет доминирующим через год, более автономные рабочие процессы не устраняют необходимость в инженерном суждении. Если что, оно может стать более ценным, а не менее, поскольку увеличение скорости и масштаба производства делает плохие решения более дорогостоящими.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Samuel Axon
