Ещё восемь месяцев с агентами

Дэвид Кроушоу делится опытом программирования с ИИ-агентами спустя восемь месяцев после предыдущего обзора: модели стали писать 90% кода, IDE устарели, а песочницы агентов не работают.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Ещё восемь месяцев с агентами

Eight more months of agents Автор: David Crawshaw Оригинальный текст:

Я описывал свой опыт программирования с LLM чуть больше года назад и обновил его для мира агентов восемь месяцев назад. С тех пор многое изменилось, так что вот обновление.

Агенты драматически улучшились за год

Мы прототипировали нашего первого агента Sketch, когда 12 месяцев назад вышел Claude Code. Мне посчастливилось быть там и испытать восторг в самом начале. Тогда они могли быть полезны для некоторых задач время от времени!

Сами оболочки агентов не сильно улучшились с тех пор. Есть вещи, которые Sketch хорошо делал полгода назад, а самые популярные агенты не могут и сегодня. Оболочка агента критически важна, там есть простор для инноваций, но эта область сейчас так же интересна, как оптимизации компилятора во время мегагерцовой гонки 1990-х.

Прямо сейчас всё решает модель.

Что касается моделей: есть множество публичных бенчмарков, но все они заиграны до смерти. Игнорируйте их. У компаний-лидеров явно есть хорошие внутренние тесты, потому что модели качественно изменились кардинально. В феврале прошлого года Claude Code мог писать четверть моего кода. В феврале этого года последняя модель Opus может писать девять десятых моего кода. Всё это нужно внимательно читать и регулярно корректировать, но теперь я могу и полагаюсь на модель, чтобы она делала корректировки за меня.

Не было никаких очевидных скачков в моделях. Ничего похожего на момент, когда GPT-2 начал отвечать. Однако явно произошло огромное инкрементальное улучшение способности кодирующих моделей достигать полезных результатов. (Весь этот, признаю, качественный прогресс — самый позитивный экономический сигнал, который я вижу сегодня.)

В большой компании моё время делилось как 80-20 между чтением и написанием кода. В стартапе бывало ближе к 50-50. Теперь это 95-5.

IDE явно уходят в прошлое

История IDE такая странная.

С одной стороны, IDE очевидно правильны. Конечно, у меня должна быть среда разработки, которая даёт столько информации и помощи, сколько я могу эффективно использовать. Лучшей IDE, которой я когда-либо пользовался, была Visual Studio C++ 6.0 на Windows 2000. Никогда не ощущал, что инструментарий был настолько полным и согласованным со своей средой.

После тех славных моментов в 1999 году я провёл больше своей программистской жизни вне IDE, чем в них. Правда о средах программирования в том, что это полный хаос. Unix был великолепен, а Ходячий замок, который мы прикрутили к перегруженному набору Unix-концепций — не очень. То же самое случилось с win32 API, который я использовал в VS6.0: всё ещё там, с гигантским беспорядком вокруг и поверх, и полностью неигнорируемым.

Потом вышел Copilot, и казалось, что IDE неизбежны. Не важно, как тяжело было встроить IDE в свою среду — приходилось делать эту работу, потому что LLM-автодополнение и редактирование были слишком мощными, чтобы их игнорировать. Они увеличивали мою скорость набора на 50%, а большая часть моего программирования ограничена скоростью печати, так что эффект был огромным.

В 2021 году IDE победили.

В 2026 году я больше не использую IDE.

Степень уверенности, которую я испытывал насчёт будущего с Copilot, и поразительный разворот, когда агенты дали мне лучший инструмент менее чем через четыре года, всё ещё удивляют меня.

Единственная IDE-подобная функция, которую я сейчас использую — переход к определению, с чем neovim справляется при минимальной настройке. Так что вот я здесь, 2026 год, и я вернулся на Vi.

В этом году Vi исполняется 50 лет.

Использование чего-либо кроме лидирующих моделей откровенно вредит

Огромная часть работы с агентами — это обнаружение их пределов. Пределы постоянно сдвигаются, что означает постоянное переобучение. Но если вы попробуете какую-нибудь дешёвую модель для экономии копеек вроде Sonnet или второсортную локальную модель, вы не просто потратите время впустую — вы усвоите неправильные уроки.

Я хочу успеха локальных моделей больше всех. Я находил LLM совершенно неинтересными до того дня, когда вышел Mixtral и мне удалось кое-как запустить его локально на очень дорогой машине. В тот момент, когда я подержал одну из них в руках, я наконец оценил это. И я знаю, что локальные модели победят. В какой-то момент лидирующие модели столкнутся с убывающей отдачей, локальные модели догонят, и мы перестанем зависеть от лидирующих моделей. Это будет замечательный день, но до тех пор вы не узнаете, на что способны модели, если не используете лучшие. Платите через нос за Opus или GPT-7.9-xhigh-with-cheese. Не волнуйтесь, это всего на несколько лет.

Встроенные песочницы агентов не работают

Постоянный поток «могу ли я запустить cat foo.txt?» от Claude Code и «я пытался, но не могу выполнить go build в моей очень-изощрённой песочнице» от Codex — это кошмар. Приходится отключать песочницу, а значит — обеспечивать свою собственную. Я перепробовал почти всё и настоятельно рекомендую: используйте свежую виртуальную машину.

У меня намного больше программ и сервисов, чем раньше

Вот почему я создаю exe.dev. Мне нужна виртуальная машина с неограниченным агентом, которую я могу тривиально запустить и ввести однострочник, который я иначе записал бы в Apple Note под названием TODO и забыл бы. В значительной части случаев Shelley превращает однострочник в полезную программу.

Мне веселее программировать, чем когда-либо, потому что так много программ, которые я хотел бы найти время написать, теперь реально существуют. Хотел бы я поделиться этой радостью с людьми, которые боятся изменений, приносимых агентами. Сам страх я понимаю — у меня есть более широкие опасения о том, какова конечная точка для интеллекта по запросу в нашем обществе. Но в ограниченной области написания компьютерных программ эти инструменты принесли столько исследования и радости в мою работу.

Я совершенно не понимаю анти-LLM аргументы

Новые технологии приносят много проблем и обоснованных опасений. Я провожу дни, пытаясь расширить пределы агентов, так что вижу их катастрофические провалы несколько раз в неделю. Значительные изменения также меняют рынки труда, что имеет много эффектов, хороших и плохих. В 1900 году 33% американцев жили на фермах, и 40% работали в сельском хозяйстве. В 2000 году менее одного процента жили на фермах и 1% работников занят в сельском хозяйстве. Это было чистой выгодой для мира — что не всем нам приходится работать, чтобы есть. (Цифры ещё более драматичны, если отступить на век назад.) Но много боли и разочарований может случиться и случилось по пути. Правильно беспокоиться.

Но гораздо чаще взвешенного анализа реальности происходящих изменений я вижу жёсткие анти-LLM позиции, с которыми год назад я не соглашался, а теперь просто не могу понять. Это звучит как кто-то, говорящий, что электроинструменты должны быть запрещены в столярном деле. Я глубоко ценю ручное столярное мастерство и овладение искусством, но людям нужны дома, и бригады на каркасных работах очевидно должны иметь циркулярные пилы. Для меня это утверждение так же очевидно, как «вода мокрая».

Многое должно измениться

Большая часть программного обеспечения теперь имеет неправильную форму. Большинство способов, которыми мы пытаемся решать проблемы, имеют неправильную форму.

Приведу пример: рассмотрим Stripe Sigma. Этот продукт — новая система SQL-запросов для вашей базы данных Stripe. В нём есть маленький LLM, помогающий писать запросы. LLM не очень хорош. Я хочу, чтобы Claude Code или Codex писали мои запросы. Но Stripe выпустил красивый UI Sigma со встроенным помощником до API. Есть закрытая альфа для SQL REST-эндпоинта, к которой у меня пока нет доступа. Поэтому вместо этого мой агент сделал ETL с нуля: использовал стандартные API Stripe для запроса всего о моём аккаунте, построил локальную базу SQLite, и теперь мой агент делает запросы к ней намного лучше, чем Sigma.

Я реализовал весь этот продукт Stripe (в части, касающейся меня), напечатав три предложения. Он решает мою проблему лучше, чем их продукт.

Вот в таком мире мы сейчас живём. Худшим продуктом, который мне приходилось использовать каждый день в этом новом мире, были облака, поэтому именно это я и создаю в exe.dev. Это намного сложнее, чем кажется, но весь смысл продукта в том, что вы никогда не должны чувствовать, что ваш агент должен переписать его часть за вас.

Попутно я выработал философию программирования, которую теперь применяю ко всему: лучший софт для агента — это то, что лучше для программиста. Практическая природа написания ПО для клиентов традиционно толкала нас прочь от этой философии. Продакт-менеджерам давно приходилось мягко объяснять инженерам: вы — не клиент. Ну, всё это перевернулось с ног на голову. У каждого клиента есть агент, который напишет код против вашего продукта за него. Создавайте то, что любят программисты, и все последуют.

Надеюсь, эта философия переживёт следующий год изменений, принесённых LLM.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot