TL;DR: When a developer asks a coding agent to build something, the agent can choose an API, install its SDK, and write the integration. That decision leaves no traditional search query, ranking, or referrer for your analytics to track. If the agent chooses your competitor, you may never know you lost an integration.
Think back to the last API you integrated before coding agents. You probably searched something like "best authentication for Next.js", opened a few results, read the docs, grabbed an API key, and started building. Each step left some signal: a query in Search Console, a visit in Google Analytics, or a developer signup.
Now imagine the same developer opening Claude Code and typing "Add authentication to my Next.js app with a managed auth provider." The agent chooses an auth provider, reads its documentation, installs the SDK, and writes the sign-in flow. The developer reviews the changes and moves on. A decision was made, but your analytics may never have recorded it.
1. Your analytics can't see what coding agents choose
The search query is the first thing to disappear. Developers describe tasks rather than products, and coding agents often work without searching the web. In early sampling, Vercel found that coding agents ran a web search in roughly one out of five prompts. When agents do search, they generate their own queries, which aren't visible in your Search Console.
The ranking disappears too. There are no ten blue links for developers to compare. An agent may choose one provider and move directly to implementation. Being considered but not selected can look identical to never being considered.
The referrer is also missing. If an agent chooses your API, it may fetch your documentation directly without loading your analytics scripts. If it chooses a competitor, you see nothing. Even successful integrations might first appear as developer signups attributed to Direct traffic.
Traditional analytics tell you who visits your website. AEO tools tell you whether ChatGPT mentions your product. Neither reliably tells you which APIs coding agents choose and why.
2. The API an agent recommends is the API that gets integrated
When developers evaluate tools themselves, they might compare several providers, try different SDKs, and reconsider their choice. Coding agents compress that process. They can select a provider, read its documentation, install its SDK, and write working code before the developer evaluates an alternative.
This makes coding agents fundamentally different from AI answer engines. ChatGPT might recommend several auth providers, but the developer still decides which one to implement. Claude Code can make that choice and complete the integration. Once the code works, there's little reason to switch.
And the integration experience can vary dramatically between providers. In our Q1 benchmark, we gave Claude Code the same auth task with two providers. With Auth0, the agent needed 4 tool calls and zero errors. Another auth API required 61 tool calls and 23 errors, most of them on redirect URIs and middleware. Both eventually worked, but one required about fifteen times as many tool calls.
These were provider-specified evaluations. In a real unbranded developer task, the agent may choose one provider without testing the alternatives. The developer ends up with whichever API the agent selected, even if another could have completed the task more efficiently.
With answer engines, recommendations influence decisions. With coding agents, recommendations can become working code.
3. Find out whether coding agents recommend you or your competitors
Devtool companies need to answer three questions:
- Are you chosen? When developers ask Claude Code, Codex, or Cursor to build something in your category, does the agent select your API or a competitor?
- For which tasks? An agent might choose you for one task and a competitor for the next. In our runs, Claude Code picked the open-source Auth.js for "Add authentication to my Next.js app" and Auth0 once the task said "with a managed auth provider".
- Why? Which documentation did the agent read? What influenced its decision? Did SDK quality, existing knowledge, or integration failures make a competitor more attractive?
A growth lead at an API company told us that seeing an AI tool cite their product wasn’t enough. They wanted to understand why the agent chose them.
The simplest way to find out is to test real developer workflows. Write down two or three tasks developers would give coding agents, then run each task several times across Claude Code and Codex using fresh environments. Most importantly, leave your product name out of the prompt. "Use Auth0 to add login" tests whether an agent can integrate Auth0. "Add authentication with a managed auth provider" tests whether the agent chooses Auth0 in the first place.
Record which provider gets selected, what documentation the agent reads, and whether the integration succeeds. A single run is an anecdote. Repeated runs across different agents and tasks reveal patterns.
If coding agents are becoming a new distribution channel for developer tools, you need to know when they choose you, when they choose your competitors, and why.
