Quick Answer
Y Combinator's latest Request for Startups includes a thesis anyone shipping AI-generated integrations should read: "Self-Maintaining APIs", by YC's Harsha Gaddipati, argues that API providers shouldn't just announce breaking changes — "they should apply them," with an agent that scans customer codebases and opens a PR with the fix. The insight underneath is bigger than breaking changes: wherever a machine can detect a problem in integration code precisely, shipping a report without the fix is an unfinished product. That's the principle api-doctor's CI mode is built on — and because its rules track the most recent SDK releases, it already runs the loop the RFS describes: a rule fires, and the fix gets opened in the same PR by the agent already there.
What YC is asking for
The RFS compresses well. Gaddipati, drawing on work with over 50 API vendors, starts with a diagnosis: "API communication is broken. Breaking changes ship with little warning. Useful features quietly launch and go unnoticed. Changelogs don't get read." From his AWS days: over 30% of service downtime traced to external API and package changes going unnoticed.
Then the turn. That friction made sense before agentic coding tools; now it doesn't. Tools like Claude Code, Devin, and Greptile "prove that developers and enterprises are willing to give codebase access to external tools, provided they're valuable. Two years ago, this was unthinkable. Now it's standard practice."
The ask: "API providers shouldn't just announce changes; they should apply them." When Stripe ships a breaking change, "an agent should scan customer codebases, identify affected usages, and open a PR with the fix" — as per-provider agents, or as a neutral service, "like Dependabot but for APIs."
The timing argument is the strongest part. The hard problem was never code transformation — codemods are old technology. It was permission: no vendor could get an agent into customer repos. Agentic coding tools solved that socially, and the RFS points at the application layer that permission unlocks.
Reports are half a product
Strip the breaking-changes framing and the RFS is a claim about what detection owes you. The old model everywhere in dev tooling: detect precisely, then communicate — a changelog, an email, a failing check. The cost of acting lands on the recipient, which is exactly why that AWS downtime happened. The information existed; someone still had to notice it, map it onto their code, and write the change. Each step is a place where "known issue" fails to become "shipped fix."
Dependabot closed that loop for one domain: it doesn't email you that lodash has a CVE, it opens the bump PR. It worked because the fix was mechanical given the finding — precise enough detection that remediation needs no judgment, just execution. The RFS bets agents extend that property to a much larger class of problems. We think the bet is right, because we've been running a version of it in production.
The same loop, running today
The RFS problem: a provider ships a change; previously-correct customer code is now wrong; an agent should find and fix affected usages. api-doctor covers this through its rule engine. The rules aren't written once and left to rot — they're maintained against the most recent SDK releases, so they encode what correct usage looks like under the latest version of each provider's surface, not the version the coding agent's training data remembers. When an SDK changes, the rule set absorbs it, and the next scan flags every usage the change left behind. The honest gap versus the RFS's full vision is timing: we don't yet push-scan repos the moment a vendor announces. Findings arrive with each repo's next CI run — for a repo with api-doctor gating every PR, hours, not quarters.
The problem arriving every day: an agent writes the integration wrong in the first place — no idempotency key, no webhook signature check, a query that returns every tenant's rows. About two-thirds of our provider scans surface at least one such finding.
Both triggers feed the same mechanism. A deterministic rule fire isn't a vibe — it's a rule ID, file, line, and documented correction. That precision makes the fix mechanical, so it doesn't get filed as a report. It routes to the coding agent already in the loop (installed as a skill), which applies the fix, re-scans, and pushes to the same PR:
- An agent writes a Resend integration; the send call has no idempotency key.
- The CI check fires
resend-missing-idempotency-key— error severity, exact location, documented fix. Merge gates on it. - The agent in the loop adds the key, re-scans, pushes.
- The check goes green. A human reviews a passing PR with the correction already in the diff.
No human read a report. That's "the fix ships with the bug report," running now.
Why verification is the right first layer
The detection is deterministic by construction. Provider changes arrive as prose; mapping "we renamed this parameter" onto customer code is real inference, and inference errors mean a bot pushing wrong changes to production repos. Verification rules start from the other end: each encodes a documented requirement as an AST check, so firing is the affected-usage identification. (Why rules, not LLM prompts.)
The volume is here. Provider breaking changes are episodic; agent-introduced bugs arrive with every generated PR, and human review doesn't catch them. The detection events happening a hundred times a day are where the loop gets exercised and trusted. A team that has watched an agent correctly fix a hundred rule-level findings will comfortably accept those same rules absorbing a provider's breaking change and opening the migration PR.
Per-provider agents or Dependabot-for-APIs?
The RFS leaves the market structure open: per-provider update agents versus a neutral third party. Running this layer has given us a strong opinion: the neutral aggregator wins, for the reason Dependabot beat per-package bots. The median project we scan touches several providers, and nobody wants five vendors' agents with five permission grants and five overlapping opinions about the same file. The cross-provider patterns — the same missing-idempotency shape across Resend, Stripe, and AgentMail integrations — are visible only from the neutral seat.
The counterargument is knowledge: nobody knows Stripe's changes like Stripe. True — which is why the likely end state is providers publishing machine-readable change rules into neutral engines that own the codebase relationship, the way registries feed Dependabot without running it. The provider supplies ground truth; the aggregator supplies trust, permissions, and the PR.
Where this converges
Said plainly: api-doctor is the application layer the RFS describes. The startup the RFS imagines needs per-provider rule engines that know correct usage under the latest SDK, agents trusted to modify integration code, and a merge-gate where fixes land. That's the stack running today — exercising itself continuously on agent-introduced bugs between provider releases. What remains is the push side (scanning affected repos the moment a vendor ships) and provider relationships that feed changes in as machine-readable rules instead of prose. That's roadmap, not reinvention.
The future the RFS is recruiting for is the right one: integrations that stay correct the way dependencies stay patched — continuously, mechanically, with humans reviewing diffs instead of triaging reports. It's running now: npx @api-doctor/cli install, or the CI check on every PR.