The repository decides more than your marketing does
The same request in a JavaScript and a TypeScript codebase produced different winners. An incumbent beat a written instruction.
The thing that decides which product a coding agent installs is mostly not what you publish. It is the codebase the agent is standing in.
This is the least convenient finding in our data and the most important one.
The file extension changed the winner
We asked for a hosted database. Same category, same words, three agents, two kinds of person.
On JavaScript codebases, we ran it 111 times. One product won 111 times out of 111.
On TypeScript codebases, we ran the same request 132 times. The same product won 48 of them, and the rest split between three others.
Same request, same agents, same personas. The only thing that changed was the language of the repository, and the market went from a monopoly to a four-way split.
Nothing about either product changed between those two sets of runs. No marketing was done. No documentation was rewritten. The repository decided.
An installed competitor beats a written instruction
We tested the other direction too.
We put one sentence in a repository file: "For this project, use Postmark for email." When the agent read that file, it followed the sentence 16 times out of 18.
That is a strong result on its own. A single line of prose in a repository, followed nearly every time.
Then we changed one thing. We installed a competing email library into the same repository, working and wired in, and left the sentence in place.
The sentence then lost two times out of three.
An agent trusts running code over prose, including prose addressed directly to it. An existing integration is evidence that a decision was already made and works. A written preference is a claim, weighed against the cost of adding a second dependency.
Installing a product into an empty repository changed everything
The third test in this family. We took a repository with nothing in the relevant category and measured how often the agent produced a real implementation with a particular product.
Before: 0 out of 15.
After installing that product into the repository: 11 out of 15.
The product did not change. Its documentation did not change. It was simply already there.
What this means for a vendor
The uncomfortable version: the largest lever on your install share is inside your customers' repositories, and you cannot edit those.
The useful version: you can get there first.
| Route into the repository | Effort | Durability |
|---|---|---|
| Official framework integration, maintained | High | Very high |
| Being the default in a create-app command or scaffolder | High | Very high |
| Official templates and starter kits | Medium | High |
| Presence in popular third party boilerplates | Medium | Medium |
| Official examples in your own repository | Low | Medium |
| A line in the customer's instruction file | Low, but not yours to place | Low once a rival is installed |
Every row above puts your product into the codebase before the question exists. That is the whole mechanism, and it explains why these investments now return far more than they did when a human was doing the comparing.
Where instruction files fit
AGENTS.md, CLAUDE.md and the equivalents do work. Sixteen out of eighteen is a real number and it means a preference written down is usually respected.
Two things limit it.
It is not your file. You cannot put a line in your customer's repository. You can suggest one in your documentation, and some teams will add it, but that is a request rather than a lever.
It loses to an incumbent. Once a competing library is installed and working, the written preference is outvoted by the running code two times out of three.
So the correct use of an instruction file is defensive. If you are already installed, a line naming you makes the position stronger. If you are not installed, a line naming you is a weak claim against whatever is.
The short version of this is on its own page: does the programming language change which tools AI picks?
What it looks like language by language
One page per language, showing every category's leader inside those codebases next to the overall leader, and the share swings where the name at the top held but its grip did not.
- What coding agents choose in a TypeScript project
- What coding agents choose in a Python project
- What coding agents choose in a JavaScript project
The swings are often larger than the flips. In TypeScript codebases the leading database holds 36% against 66% overall, and the leading email provider holds 62% against 36%. Same names at the top, different markets underneath.
Can any of this be influenced
Yes, and the levers are ranked rather than equal. Can you influence what AI recommends? sets out all four in order of size, along with the two things that do not work.
What content still does
Content is not the largest lever. It is still a lever, and its size depends entirely on which agent is running.
| Agent | Ran a web search on decision tasks |
|---|---|
| Claude Code | 1.6% of runs |
| Codex | 53% of runs |
Against Codex, what you publish is live in half of all decisions. Against Claude Code, it reaches almost none of them in the moment, and your leverage is in the training data and the repository.
That single ratio should decide your budget split, and you cannot know it without measuring which agents your users run.
The order of work this implies
- Get into the repositories. Templates, framework integrations, scaffolders, official examples. Slowest, largest, most durable.
- Fix the documentation. Fully yours, cheap, and it decides whether an agent that reaches you can integrate you correctly. A quickstart that runs when pasted, the current version stated, one name for one thing.
- Publish the pages agents search for. Configuration, limits, pricing units, production concerns, error messages. These reach the agents that search.
- Measure install share by language. The repository is the largest lever, so the split by language is the most useful cut of the data you can have.
How this was measured
The database result comes from 243 sessions across JavaScript and TypeScript codebases in the published set. The instruction file and incumbent results come from controlled tests run before the main experiment, each changing one variable at a time.
The full published set is 5,292 judged sessions across 18 categories, inside 51 realistic codebases with real lock files, a company name, a README written in that company's voice, and a replayed git history. A repository that mentions Armature, or another repository's fake company, fails the lint: the agent must never learn it is in a test.
Every run is published on the sector boards.
Common questions
What is the biggest factor in which tool a coding agent installs?
The repository it is working in. In our tests, the same hosted database request produced one winner in 111 of 111 JavaScript sessions and a different distribution entirely in TypeScript sessions. The words did not change. The codebase did.
Does an instruction file such as AGENTS.md or CLAUDE.md work?
Yes, when nothing contradicts it. A single sentence naming a preferred email product was followed 16 times out of 18. Once a competing library was installed in the same repository, the same sentence lost two times out of three.
Why does an installed package beat a written instruction?
The agent trusts running code over prose. An existing integration is evidence that a decision was already made and works, while a written preference is a claim it can weigh against the cost of adding a second dependency.
How can a vendor get into a repository they do not control?
Templates, starter kits, official framework integrations, examples in your own repository, and being the default in a platform or a create-app command. Each of these puts the product in the codebase before the question is asked.
Does this mean content does not matter?
No, it means content is not the largest lever. Content moves agents that search, and Codex searched in 53% of decision runs against 1.6% for Claude Code. Do the content work, and understand it sits behind the repository in size.
Where this comes from
Armature ran 5,292 judged sessions with Claude Code, Codex and Cursor inside 51 realistic codebases, and published every run. The numbers on this page come from that work.