When coding agents build it themselves instead of buying

Every vendor in a category counts the other vendors. In seven of the 31 categories we measured, the biggest competitor was not a vendor at all.

The number

The full table

What separates the two ends of that table

Look at the bottom rows: payments, deploy, sandboxes, vector search, in-app chat and calls, and AI SRE, where not one session out of 2,197 ended without a product, and email, cloud and storage, where the agent wrote it itself in two, two and eight sessions. Every one of them requires something an agent cannot write. A merchant account. A server that stays up. A machine somewhere. An IP address with a sending reputation.

Now look at the top: performance testing, evals, agent frameworks and search, plus usage-based billing, the five at 20% or more. Every one of them can be started with a script. A benchmark loop. A file of test cases and a comparison. A while loop over an API. A LIKE query.

An agent does not know that the fifty lines will be wrong at volume, or that the edge cases are where the work is. It knows what it can see, and what it can see is that the problem looks tractable.

The agent matters too

Claude Code builds rather than adopts more than twice as often as Codex, and Muse Code slightly more often still.

That is consistent with another habit: Claude Code ran at least one web search in 28% of its sessions, and Muse Code in 43%, against 97% for Codex. An agent that does not go looking for candidates has fewer candidates in front of it, and the implementation it can write itself is always in front of it.

If your users run Claude Code or Muse Code and your category is near the top of that table, this is your single biggest competitive problem.

What this changes about your content

In a category with a high in-house rate, most vendor content is aimed at the wrong argument.

The usual content says: here is why we are better than the alternatives. That argument only matters to a buyer who has already decided to buy something. In performance testing, 56% of sessions never got to that question.

The argument you need first is different, and it is harder to write well:

Show what breaks, specifically. Not "search is harder than it looks". Instead: what happens to a LIKE query at two million rows, what typo tolerance actually requires, why relevance ranking is not sortable by one column, what happens to the index during a bulk write.

Put a number on the maintenance. "Teams that build this themselves typically spend X on it in year two" is an argument. "It is a lot of work" is not.

Name the edge cases. A list of the twelve things a hand-written version will get wrong, each in one line, is the most useful page you can write for this problem. An agent can read it and weigh it.

Do not argue against building in general. The agent is right that a script works for the first case. Concede that, then show where the line is. Content that overclaims gets discounted.

Where to put that content

It has to be readable at the moment of choice, which means it has to be findable by the queries agents actually run. Those queries are specific and often scoped to a site:

site:example.com/docs limits index size bulk write performance production
site:example.com pricing records requests plan official

So the page that beats a hand-written implementation is usually in the documentation, not the blog. A page called "when you need this and when you do not", with the failure modes and the numbers, sitting inside the docs where an agent searching for production concerns will find it.

The other side of the table

If your in-house rate is zero, this is not your problem and you should not spend a page on it. In payments, deploy, sandboxes, vector search, in-app chat and calls, and AI SRE, the agent never wrote it itself. You are in a straight vendor comparison, and the levers that matter are the ones you fully control: a quickstart that runs when pasted, a stated current version, matching names, and presence in the repository.

How this was measured

15,287 judged sessions across 31 categories. Real coding agents at pinned versions, in sandboxes, inside 110 realistic codebases. A judge from a model family that builds none of the five agents read every session blind and recorded whether a product was adopted or the agent wrote the implementation itself.

A hand-written implementation counts when the captured evidence supports that choice. Implementation quality is assessed separately. An agent that discussed building it and then adopted a product counts as adopting a product.

Every run is published on the sector boards.