Why coding agents pick your competitor over you

A developer opens their editor, types a one-line request, and an agent goes to work. Somewhere in the next thirty seconds it picks a library. It won’t tell the developer why, and it definitely won’t tell you.

That decision is now a meaningful share of your funnel. It happens before your site gets a visit and before your funnel records an event, and it rarely turns on the thing your marketing leads with. This post is about how the decision actually gets made, and about the two very different ways it goes against you.

The agent optimizes for “can I finish this?”

Humans evaluate tools aspirationally. We read the feature ceiling, the brand, the case studies, and we imagine the best version of what we could build. Agents evaluate operationally. An agent arrives holding a concrete task, a limited budget of steps, and a context window it cannot afford to waste, and it reaches for whatever it believes it can complete without getting stuck.

Believes is the operative word. The agent cannot try every candidate, so it predicts, from what training left in its memory and what it retrieves mid-task, which product will get it to a working result in the fewest steps. Your feature velocity plays no part in that prediction. Whether your quickstart runs top to bottom plays a large one.

What “better” means inside the loop

The reframe changes every comparison. A clear quickstart beats a comprehensive one, because the agent can execute it without improvising. A typed SDK with obvious method names beats a powerful but ambiguous one, because the agent guesses less. A present, well-described MCP server beats a REST API the agent has to assemble calls against by hand. Speed to first success beats depth of capability, because the loop ends at the first working result.

None of that is your headline feature. All of it decides the run. We took every one of these surfaces apart, with the fix for each, in the playbook. This post stays on the harder question of why you lose in the first place.

The two ways you lose

Teams picture the failure as a fair fight. The agent weighed you against a competitor and chose them. That does happen, and when it does the transcript usually states the objection in plain language. You were considered and rejected, and the reason is right there to read.

The quieter and more common failure is absence. The agent forms its consideration set in a second or two, from what training left in memory plus the first search it runs. If neither surfaces you, there is no comparison to lose. You were never in the room. Nothing in the transcript mentions you, so nothing anywhere tells you it happened.

These are different problems with different fixes. Rejection is a positioning and evidence problem, and it gets fixed on the surfaces the agent reads at decision time. Absence is a mindshare problem, and it gets fixed where consideration sets form, in the sources agents search and the indexes they consult. Positioning effort spent on an absence problem polishes an argument nobody hears.

Defaults are winner-take-all

Selection inside a scenario rarely spreads across the field. In the audits we run, one product absorbs most of the trials, a second picks up the rest, and everyone else gets zero. The agent carries a default for each job, the default is strong, and it stays frozen until a model update or a compelling retrieval dislodges it.

That concentration is why small selection gaps compound. The product holding the default gets picked again and again in identical runs, while products outside the set stay invisible no matter what they ship next. Getting into the set is the fight. Once you are in it, the operational comparison above decides the rest.

The number that tells the truth

This is why a selection rate is so clarifying. It never asks whether your product is good. It asks how often, across repeated live runs of a realistic scenario, the agent actually picked you, and it comes with the transcript for every decision it counts.

Your analytics cannot produce that number. The decision happens inside the agent’s context, upstream of every event you record. A lost selection produces no pageview, no bounce, and no abandoned signup. It looks like soft demand, right up until you watch a run and see the agent recommend someone else by name.

What to do about it

Read your own docs as if you had five steps and no patience. Better, watch an agent try to finish a real task on your product and note the first place it hesitates. Then work through the seven surfaces in the playbook, in the order they decide runs.

And measure it before you fix it. Our free audit runs the scenario battery for you and reports your selection rate, which of the two losses you are taking, and the exact surface where each one happened.