Your AI coding agent isn't hallucinating. It's out of date.
We've been building and testing an MCP server for library upgrades and migrations over the last few weeks, and one pattern kept showing up.
The biggest source of wasted effort isn't hallucination in the classic sense. It's an agent operating on outdated knowledge and not realizing it.
An agent that doesn't know what changed between versions doesn't fail cleanly. It writes plausible code, hits a build error, tries a different plausible fix, hits another error, and keeps going in circles. Each of those loops costs tokens and time, and none of them would be necessary if the agent knew the actual breaking change upfront.
Current documentation tools solve a different problem. They tell an agent what the API looks like today. They don't tell it what changed, what replaced it, or what silently behaves differently now. Knowing the current API and knowing the migration path are not the same thing.
For example:
- Next.js 14 → 15 changed several request APIs from synchronous to async
- The Vercel AI SDK 4 → 5 removed and renamed multiple interfaces
- The MCP SDK's upcoming v2 turned out to be a package restructuring, not a version bump
The agent often knows both versions exist. It has no idea what actually changed between them. So it starts guessing.
We've been building a way to give agents that missing piece directly: Asynthetic, an MCP server that serves hand-curated migration maps. Each one contains only the breaking changes for a specific version jump, with before/after code, deprecation timelines, peer compatibility requirements, and a citation back to the original source on every single entry. Nothing in the data path is LLM-generated. When there's no verified answer for what you asked, it returns found: false and tells the agent not to guess instead of making something up.
The part that took the most time wasn't writing the maps. It was verifying them. For the Next.js 14 → 15 map, every breaking change entry was tested against real builds, both Turbopack and Webpack, dev and production. Some of what the official docs say turned out to be incomplete in practice. Turbopack silently doesn't enforce the removal of the old u/next/font package the way Webpack does, so a default dev setup won't show you the break, only CI will. The React 19 "requirement" for the App Router isn't actually build-enforced either. An App Router app runs fine on React 18.3.1 in testing. None of that is a knock on the Next.js team's docs. It's just the gap between what a migration guide says and what a compiler actually does, and that gap is exactly what we wanted the tool to capture. It's in the map now as a caveat the agent can read.
Two maps are live right now, Next 14 → 15 and Vercel AI SDK 4 → 5, 40 breaking changes total, all cited. A third map for the MCP SDK is sitting there marked stale on purpose, because v2 turned out to be a package split rather than a version bump, and shipping nothing was better than shipping something wrong for that transition.
The part worth discussing isn't a specific number. It's that most of the cost in these agent loops seems to come from wrong turns, not from the actual fix once the agent knows what to do. Preventing the wrong turn seems to matter more than making any individual edit faster.
It's free, public beta, works hosted over Streamable HTTP or fully offline through npx asynthetic. Source-available under BSL, converts to Apache in 2030.
Repo's here if you want to look under the hood or find a case where a map is wrong: github.com/asyntheticai/asynthetic
Curious if others running Cursor, Claude Code, Devin, or similar agents are seeing the same pattern during upgrades and large dependency migrations.