2. The Death of Tools and Libraries

March 8, 2026

I worked for Google for 6.5 years, from 2017 to 2024, and for all those years I was a part of a big organization in Cloud that published client libraries for all Google Cloud APIs. Those libraries are still there, providing a good developer experience accessing Cloud services for developers in 8 languages. When I joined the team, I took the vacant position of the "language lead" for Node.js, migrated libraries from JavaScript to TypeScript, wrote the first version of the Node.js library generator, and did many other cool things. I had almost zero Node.js (or JavaScript) experience when I joined, but that's a different story: Googlers are generalists, you know.

One of the big things when you publish libraries that have millions of downloads per week is compatibility. Semantic versioning, keeping a balance between releasing major versions not too often, but dropping support for ancient versions not too soon, making decisions now which turn out to be a huge compatibility hassle later; all that stuff. How to design a client library generator that would produce reasonable client libraries for hundreds of APIs, each of them thinking it is unique and wanting to ask for some very special feature? It's a nice problem, and Google libraries are really not too bad.

But you know what. All this cool work does not matter much anymore, because hello, Claude Code and friends.

The world of cheap code

Ironically, my first (and only, to this day) post here was about my experience with GitHub Copilot back in November 2021, and I was not too impressed. It took five more years, and no one is writing code manually anymore. Well, to be precise, a lot of people still do, including me; but for the majority of simple tasks it seems much easier and faster to offload the coding part to the agents, focusing on something they cannot do well now: designing a good solution for the problem. Talk to you in five years, I know, but this is where things are right now.

I'm writing this text in March 2026, and today it seems that agents—especially if you combine multiple of them, making one review the code written by another one–are pretty good at writing straightforward code. Let's be honest: straightforward code is what we write most often, and this job is mostly gone.

Does that mean that software engineers, as a profession, are gone too? Probably not—at least, not today. We are not typing a lot of code anymore, all these return and for and break and whatever keywords, but we all suddenly became tech leads and managers, overseeing the work of very knowledgeable, but very dumb executors, like a team of very fast typing software interns.

One important consequence of that is that simple code is very cheap now. As most client libraries are exactly that: straightforward, simple code, they are the first victim of this change.

Why do we need client libraries?

Imagine you need to call an API. The majority of API endpoints are regular HTTP endpoints, accepting parameters in some way (query string or JSON), and returning JSON. Of course, gRPC exists, but even in Google Cloud, the vast majority of APIs can be called using regular JSON endpoints; bi-directional streaming APIs such as StreamingRecognize in Speech-To-Text are notable exceptions which require gRPC.

So, if we are talking about sending and receiving JSON, why would you need anything more than your regular HTTP library to do that?

First, type safety. Libraries are supposed to know how requests and responses are supposed to look, which fields are allowed and which types to use for which values.

Next, libraries are trying to be idiomatic. That means that they use the language features available in the given language to make the API call look both super simple, and natural.

Last but not least, authentication. This is probably specific for Google Cloud APIs, but authentication is not fun at all, be it a service account or OAuth. Libraries hide this complexity under the hood, and your code just works after you figured out how to run gcloud auth application-default login.

I must've forgotten something else, but these are the important points. All of them combined build a case for adding one more dependency to your project.

But all these points don't matter anymore.

Not all client libraries are the same

The majority of the libraries Google Cloud ships are automatically generated based on the protobuf definitions. Just a few libraries are either fully handwritten, or have a substantial handwritten layer on top of the generated code; libraries like Pub/Sub, and Firestore are examples of this approach.

Now, if the API is so trivial that a simple code generator based on template substitution can generate a usable, good enough library to call that API, your coding agent can do it too, and it will. And it will only generate code to call the two or three API methods you care about, omitting the other 25 of those you never need. The LLM-generated code will handle type safety (wrapping the JSON construction and parsing), will be as idiomatic as possible, and will, of course, emit the code generating the proper token using google-auth-library.

If you are using something more heavy like Pub/Sub or Firestore, I wouldn't be so optimistic about dropping these dependencies and replacing with the custom code. Of course, JSON APIs exist for both Pub/Sub and Firestore, but there is a non-trivial translation layer between what you want from the library and the API calls it makes, and implementing (and debugging) this layer is probably not something you are paid to do.

So, some–maybe five?–libraries, out of more than 100, will stay, but the others just have no real reason to exist anymore. Bye-bye, the codebase I spent so much time on, no one needs you anymore.

Tools? Some tools die too

There was a niche for tools that do pretty much the same things as client libraries: they try to be a proxy between you and someone's APIs, figuring out what you need and sending a bunch of API calls to help you achieve that. The alternative is often clicking through some multi-step wizard in the browser.

I'm looking at you, fastlane.

I've been developing some mobile apps on iOS and Android for fun, and publishing them to the stores is the part I hated most. You either do everything in the browser, and the amount of clicks needed to release an update increases linearly with the number of localizations your app has; or you install fastlane, "App automation done right", and then you drown.

Well, maybe you don't, but I did, multiple times. Maybe it's something wrong with me, but I could never figure out this damned thing; it's just too huge. Maybe I should've paid someone to configure it for me, I don't know.

Some time ago I finally thought that enough is enough, opened Claude Code, and asked it to implement a small tool that would do just what I need to update the App Store and Play Store listings for the app I care about. I spent maybe two or three hours in total and got a tool that fits my use cases perfectly, and I've been happily using it for all my app updates now. I called it slowlane, because why not.

You know what's really fun about this? It made perfect sense to publish stuff like this before, but there is absolutely no reason to do it now. If anyone has a problem like I did, they won't search to see if anyone has solved their problem with some weird-named tool; they will just take Claude (or Codex, or Cursor, or anything else) and vibe-code the thing they need, for themselves. They might even publish it, and no one will care.

What next?

I don't know! But one thing is for sure: trivial code is very cheap now, and calling a network API is often quite trivial. We will probably write, or generate, a lot of disposable code, or at least code that will never be reused. Let's try to figure out how we live with that.