2. Последние дни тулзов и библиотек

8 марта 2026 г.

Я работал в Google 6.5 лет, с 2017 по 2024 год, и всё это время я был в большой организации в Google Cloud, которая выпускала клиентские библиотек для всех Google Cloud API. Они всё ещё существуют, помогая разработчикам удобно работать с клаудными сервисами на восьми языках. Когда я только пришёл в команду, меня поставили на вакантную позицию "language lead" по Node.js, где я перетащил библиотеки с JavaScript на TypeScript, написал первую версию генератора библиотек на Node.js и сделал много других интересных вещей. Кстати, у меня почти не было никакого опыта с Node.js, когда я пришёл в компанию, но это отдельная история: Google нанимает «генералистов».

Когда вы публикуете библиотеки, у которых миллионы скачиваний в неделю, вы вынуждены очень много думать про совместимость. Semver, хрупкий баланс между выпуском мажорных версий слишком часто и отказом от поддержки старинных версий слишком скоро, всякие решения, которые в моменте кажутся хорошими, но вскоре приносят кучу проблем с совместимостью, вот это вот всё. Вообще, сделать генератор клиентских библиотек, который бы производил приемлемые библиотеки для сотни API, каждое из которых думает, что оно уникально и требует особые фичи — это интересная проблема, и гугловые библиотеки, на самом деле, вполне норм.

Только проблема: всё это больше никому не нужно, потому что привет, Claude Code и компания!

Мир дешёвого кода

Забавно, что мой первый (и до сегодняшнего дня последний) пост тут был про мой опыт с GitHub Copilot в ноябре 2021 года, и он меня тогда не то что бы прямо поразил. Прошло пять лет, и никто уже не пишет код вручную. Я, конечно, преувеличиваю: многие пишут, да и я сам пишу, но для большинства простых задач кажется намного проще и быстрее попросить агентов написать код, а самому заняться чем-то, что они пока не могут делать: придумать хорошее решение проблемы, например. Посмотрим, что будет ещё через пять лет, но пока вот так.

Этот текст я пишу в марте 2026 года, и сейчас кажется, что агенты — особенно если брать сразу нескольких, чтобы один агент ревьюил код другого — отлично пишут простой код. Ну и давайте признаем: чаще всего мы как раз пишем простой код. Эта работа в целом изчезает.

Означает ли это, что профессия разработчика тоже исчезает? Кажется, нет; по крайней мере, пока нет. Мы больше не пишем кучу кода вручную, все вот эти return, for, break и прочее, но мы все внезапно стали техлидами и начальниками, управляющими командой очень начитанных, но очень тупых исполнителей, как команда быстро печатающих стажёров.

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

Зачем нужны клиентские библиотеки?

Пусть вам нужно сделать API call. Большинство endpoint-ов — обычные HTTP endpoints, принимающие какие-то параметры (в query string или JSON) и возвращающие JSON. Понятно, что существует gRPC, но даже в Google Cloud большинство API доступны через HTTP+JSON, единственное исключение — bidirectional streaming, как у StreamingRecognize в Speech-To-Text API, для таких API нужен gRPC.

Так вот если мы говорим про отправку и приём JSON, то для чего нам вообще могут понадобиться библиотеки, помимо стандартной HTTP-библиотеки?

Во-первых, типизация. Библиотеки знают, какие там запросы и какие ответы у данного API, какие поля разрешены и значения каких типов мы ожидаем.

Во-вторых, идиоматичность, то есть использование свойств языка так, чтобы вызовы API выглядели просто и понятно.

Ну и, в конце концов, аутентификация. Это, возможно, специфично для API Google Cloud, но там правильно аутентифицироваться вручную очень непросто, что с service account, что с OAuth. Библиотеки успешно это прячут от разработчика, так что достаточно сказать там что-нибудь типа gcloud auth application-default login, и всё работает.

Я точно забыл что-нибудь ещё, но это основные пункты. Вы смотрите на эти пункты и решаете, что ладно, добавим к проекту ещё одну зависимость от клиентской библиотеки.

Но, внезапно, это всё стало неважно.

Не все библиотеки одинаково полезны

Большинство клаудных библиотек сгенерированы автоматически из protobuf'ов. Только несколько библиотек или написаны полностью вручную, или имеют большой написанный вручную «слой» поверх сгенерированного кода. Такие библиотеки, например, Pub/Sub и Firestore.

Но постойте. Если API настолько тривиально, что простой генератор кода, который работает на темплейтах, может сгенерировать нормальную клиентскую библиотеку, то агент и подавно сможет сделать то же самое, а то и лучше. И, прошу заметить, агент сгенерирует код для вызова только тех двух или трёх функций, которые вам нужны, а остальные 25 не сгенерирует. Агентский код позаботится о типах (завернёт и развернёт JSON в ваши переменные), будет идиоматичным и с аутентификацией тоже разберётся при помощи google-auth-library.

Но если мы смотрим на что-то побольше, типа Pub/Sub или Firestore, то там ситуация сложнее, и мне не кажется хорошей идеей прямо сейчас заменять эти библиотеки на сгенерированный код. Ну да, и Pub/Sub, и Firestore можно дёргать напрямую с JSON через HTTP, но там в обеих библиотеках довольно нетривиальный уровень между тем, чего вы ожидаете от библиотеки в своём коде, и тем, что она в итоге передаёт и получает, и вряд ли вам платят за написание и отладку этого кода.

Так что, может быть, где-то пять библиотек из сотни останутся, но остальные вообще непонятно, с какой целью теперь существуют. Жаль прощаться с этим кодом, я потратил на него много времени и усилий, но что поделаешь.

А что с тулзами?

Была такая особая ниша для тулзов, которые делали примерно то же самое, что клиентские библиотеки: дёргали чьи-то API для решения ваших задач. Обычно альтернативой является протыкивание скольки-то страниц в браузере.

Я сейчас говорю, например, про fastlane.

Я в свободное время иногда пишу мобильные приложения для iOS и Android, и публикация в сторы занимает какое-то совершенно неразумное время. Либо это всё делается через браузер с кучей кликов (чем больше у приложения локализаций, тем больше кликов на каждую публикацию апдейта), либо вы ставите fastlane, девиз которого "App automation done right", и... и всё очень плохо.

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

Так что я тут недавно подумал, что всё, хватит! Запустил Claude Code и попросил сделать маленькую тулзу, которая сделает вот ровно то, что мне нужно, чтобы выкатить апдейт приложения в App Store и Play Store. Потратил часа два или три в сумме и получил код, который решает именно мою проблему, и с тех пор использую его и горя не знаю. Назвал эту штуку slowlane, ну а что.

А знаете, что тут самое забавное? Раньше было как: сделал что-то такое — опубликуй, кому-нибудь ещё пригодится. А сейчас не так! Если кому-то что-то такое понадобится, он ровно так же сядет с Claude (или с Codex, Cursor и что угодно ещё) и навайбкодит такую же тулзу, которая ему нужна. Может даже опубликовать, только всем уже пофиг.

И что же дальше?

Понятия не имею! Но одно точно: простой код теперь стоит очень дёшево, а дёрнуть API по сети обычно довольно просто. Мы, видимо, теперь будем писать (или, точнее, генерировать) кучу одноразового кода, который никто и никогда не будет переиспользовать. Осталось понять, как со всем этим жить!