# When coding agents build it themselves instead of buying

> In five of eighteen categories the most common outcome was hand-written code, not a product. Where agents build rather than adopt.

Source: https://armature.tech/library/what-coding-agents-build-in-house
Published: 2026-09-03
Publisher: Armature, Inc. (https://armature.tech)

---

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

## The number

> Across 5,292 judged sessions, the rate at which a coding agent wrote its own implementation rather than adopting any product ranged from **0% to 52%**, depending entirely on the category. In performance testing, more than half of all sessions ended in hand-written code.

## The full table

| Category | Built in-house | What that means |
| --- | --- | --- |
| Performance CI | 52% | Hand-written code is the category leader |
| Evals | 29% | Second most common outcome overall |
| Agent frameworks | 25% | The largest single outcome in the category |
| Search | 23% | Bigger than any individual product |
| Product analytics | 23% | Second behind PostHog |
| Serverless | 17% | Substantial |
| Bot protection | 11% | Present |
| Authentication | 10% | Present |
| AI gateway | 9% | Present |
| Voice agents | 6% | Rare |
| Observability | 6% | Rare |
| Payments | 0% | Not one session |
| Databases | 0% | Not one session |
| Cloud | 0.5% | One session in 215 |
| Storage | 0% | Not one session |
| Deploy | 0% | Not one session |
| Sandboxes | 0% | Not one session |
| Email | 0% | Not one session |

## What separates the two ends of that table

Look at the bottom rows: payments, databases, storage, deploy, sandboxes and email, where not one session out of 1,618 ended without a product, and cloud at a single session out of 215. 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, search, product analytics. 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 events table.

> The rule is simple. If the first ten percent of the problem can be solved in fifty lines, an agent will write those fifty lines. It is good at writing fifty lines and it has no budget to consider.

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

| Agent | Wrote its own implementation |
| --- | --- |
| Claude Code | 19% of all runs |
| Codex | 10% of all runs |
| Cursor | 10% of all runs |

Claude Code builds rather than adopts nearly twice as often as the other two.

That is consistent with its other habit: on decision tasks, Claude Code ran a web search in 1.6% of runs against 53% 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 and your category is in the top half 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, 52% 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, databases, storage, deploy, sandboxes and email, the agent never considers writing it. 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

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

A hand-written implementation counts only when the agent actually wrote working code for it. An agent that discussed building it and then adopted a product counts as adopting a product.

Every run is published on [the sector boards](/leaderboards/sectors).

## Common questions

### How often do coding agents write their own implementation instead of adopting a product?

It depends entirely on the category. In performance testing, 52% of sessions ended with hand-written code. In payments, databases, storage, deployment, sandboxes and email it was zero.

### Which categories do agents most often build themselves?

Performance CI at 52%, evals at 29%, agent frameworks at 25%, search at 23% and product analytics at 23%.

### Does the agent matter?

Yes. Claude Code wrote its own implementation in 19% of all runs, against 10% for both Codex and Cursor. Claude Code is nearly twice as likely to build rather than adopt.

### Why does this matter to a vendor?

Because in those categories your largest competitor is not another company. Content that argues you are better than a rival does not help when the agent never considered adopting anything.

### What content beats a hand-written implementation?

A specific account of what breaks. The failure modes, the edge cases, what the maintenance costs after six months, each with numbers. General claims that a problem is hard do not work.

## Read next

- [Do Claude Code, Codex and Cursor pick the same tools?](https://armature.tech/library/do-claude-code-and-codex-agree) (Markdown: https://armature.tech/library/do-claude-code-and-codex-agree.md)
- [Agent discoverability: the complete guide](https://armature.tech/library/agent-discoverability) (Markdown: https://armature.tech/library/agent-discoverability.md)
- [How coding agents choose tools](https://armature.tech/library/how-coding-agents-choose-tools) (Markdown: https://armature.tech/library/how-coding-agents-choose-tools.md)
- [The same question, four different people, four different answers](https://armature.tech/library/how-personas-change-the-pick) (Markdown: https://armature.tech/library/how-personas-change-the-pick.md)
- [In-house rate](https://armature.tech/library/in-house-rate) (Markdown: https://armature.tech/library/in-house-rate.md)

---

Armature helps software products get discovered and used by coding agents.
Service: https://armature.tech/discoverability · Results: https://armature.tech/leaderboards/sectors · Contact: contact@armature.tech