A Mild Take on Coding Agents
SaaS isn't dead yet, but big pieces of the ecosystem continue getting lopped off
Coding agents are really good now. The voices of haters, grumbling that AI just spits out spaghetti code slop, have continued lowering to a mumble. At the same time, twitter techfluencers are proclaiming (again) the end of SaaS, of software engineers, yadda yadda. That all continues to be hyperbole, but some parts of the software development ecosystem have legitimately been killed by AI coding. Based on capability today—and what it likely will be soon—service SDKs and their devrel teams are the next to go.
A couple years ago, when tech yappers were claiming all code would be AI-generated by the end of summer, the output from coding agents was code that looked right, but didn’t work very well. However, it was good at answering questions: asking how specific code bits worked, or where a bug might be, was about as effective as going to Stack Overflow. Except without the grouchy people yelling at you for asking dumb questions or waiting for an answer. AI only got better, and thus:
Last year was the “year of agents” and promised that those pesky people you work with would be replaced. While this led to a lot of firings and rehirings, the outcomes did reflect the abilities in coding. An agent was about as good as an intern: simpler code worked now, but at a certain level of complexity it totally fell apart. Just like the SO headshot, this began to replace the corresponding structure of interns and junior devs. College grad engineer hiring dropped 20% from 2022 highs and internship postings dropped 30% from 2023. The pendulum might, and hopefully will, swing back on this, since missing a generation of engineer growth would be awful. But as it stands, the kids are not very alright.
Today, AGI is in the air again as Opus 4.5 hoists the banner that GPT-5 so ignominiously dropped. AGI: still hyperbole! But progress does march on, and this time AI is coming for SDKs that provide language-specific interfaces to service/platform APIs. The agents are good enough now that they can read the API documentation and write code for you that just uses fetch or whatever. From the perspective of a big company, if you have a public API and know a coding agent will be writing the calling code, why spend time making a library? Just document the API well, and the agent will look it up and use HTTP. For developers, this is a quality of life improvement too: gone can be the days of navigating the SDK/API gap, finding bugs, changing to a different client library, finding different bugs, throwing your laptop in the river. I recently had Claude set up facebook oauth for me and it tasted like a glorious future. Argue all you want about what developers should or should not wholesale hand off to AI, but I dare you to tell me you’re gonna miss implementing oauth flows.
There is a whole career of managing the phone lines between public APIs and developers, and that is probably the next on the chopping block. Working with third party APIs is not something we need to keep going forward: if it’s just code working with other code, it’s logical that the broker would be computer.
This may be feeling a bit AI booster-y, like AI dating concierges talking to each other. And it may rhyme with bad outcomes, like teachers having AI generate assignments, that students then just give to AI to complete. But the difference here is the domain: this is not dating or learning, but building software; writing code for my application to talk to yours.
But no, SaaS still isn’t dying yet. Any engineer who knows what “unknown unknowns” means understands why. But if we come back down to Earth and get real about it: removing complexity in your own code by having an agent figure out the external bits is…a promise of AI fulfilled, no?