Y Combinator · Startup Ideas
API communication is broken — breaking changes go unnoticed, changelogs don't get read, and 30% of AWS downtime traced to unnoticed external API changes. Agentic coding tools now make a better model possible.
Watch
Tap any timestamp pill in the essay to jump the player to that moment.
The problem
The speaker opens with a confession of scale: over the past year, they worked at more than fifty API vendors — mostly early-stage startups — and found the same pattern everywhere. Breaking changes ship with little warning. New features quietly launch and go unnoticed. Changelogs don't get read. The failure mode is not unusual; it is the industry default.
The numbers get harder to ignore when the speaker invokes their time at AWS. At one of the most operationally sophisticated engineering organisations on the planet, over 30% of service downtime traced back to a single cause: external API and package changes that nobody caught in time. This is not a startup-scale problem. It is a structural one.
The friction made sense, once. Before autonomous tools, the only mechanism an API provider had to notify customers was documentation — a changelog, a blog post, an email that might reach the right person weeks after the change was already live. Passive communication was the only kind available. It just never really worked.
How they solve it
The argument pivots on timing. Two years ago, giving an external tool read/write access to your codebase was a thought experiment nobody was seriously having. Today it is standard practice. Agentic coding tools — Claude Code, Devin, Cursor — have already cleared the hardest adoption hurdle: developer trust. Enterprises are handing codebase access to external agents every day, provided the value justifies it.
The infrastructure for automated code changes already exists. What is missing, the video argues, is the application layer that connects an API provider's release process to the codebases of everyone who depends on it. The gap is not technical — it is a product one.
The proposed model inverts the update flow entirely. Instead of Stripe writing a blog post about a breaking change and hoping engineers eventually read it, a Stripe agent scans every customer codebase that uses the affected endpoint, identifies the exact lines of code that need to change, and opens a pull request with the migration already applied. The developer reviews and merges. The breaking change never breaks anything in production.
Two delivery shapes are viable. The first is per-provider: Stripe ships its own update agent, customers install it, and it handles Stripe-specific migrations autonomously. The second is a neutral aggregator — a single service that tracks changes across many API vendors and opens the right PRs when changes land. The video names that second shape plainly: Dependabot, but for APIs.
Takeaway
API providers shouldn't just announce changes — they should apply them.— Y Combinator, Self-Maintaining APIs
The changelog was the right answer for its time. Agentic coding tools just made it obsolete.