Can you influence what AI recommends?
Yes, and the levers are measurable and ranked. Here is what actually moves the outcome, in order of size, and the two things that do not work.
Yes. In controlled tests, changing what is installed in a repository, changing the language of the codebase, and changing how a request is worded each changed which product a coding agent chose. Some of those changes turned a near-monopoly into a split across nine products.
The useful question is not whether you can influence it. It is which levers are large, which are small, and which are not levers at all.
The levers, in order of size
1. What is already in the repository
The largest by a distance.
We asked three coding agents to make an app's data persist, 359 times on apps with their own server. One product won 280 of them. We asked on apps with no server of their own too: that product won none of 142, and a different one won 111.
Nothing about either product changed. No marketing happened. The codebase changed, and so did the person asking.
Then we tested incumbency directly. A sentence in a repository file naming a preferred email product was followed 16 times out of 18. We installed a competing email library into the same repository, working and wired in, and left the sentence in place. It then lost 2 times out of 3.
And presence, in the other direction: with nothing installed, a product produced a real implementation in 0 of 15 runs. After installing it into the repository, 11 of 15.
You cannot edit your customer's repository. You can be in the template they started from, the framework integration they installed, and the example they copied.
2. Which agent is running
Not something you influence, but something that changes the answer so much you have to measure it.
Claude Code, Codex and Cursor named different category leaders in 18 of the 29 categories all three ran. And they gather evidence differently: Claude Code ran at least one web search in 28% of its sessions, and Codex in 97%.
That gap decides how much of a lever your content is for a given user.
3. Who is asking, and in what words
The category leader changed with the persona in 24 of 31 categories. A request written as a vibe coder and the same need written as an enterprise team produced different winners in storage, authentication, observability, serverless and more.
You influence this by writing pages that match how each buyer describes the problem. An enterprise request contains "audit log", "data residency", "retention". If your documentation never says those words, there is nothing for the constraint to match.
4. What the agent can read
Real, and fourth. It matters most against agents that search, and it decides whether an agent that has already chosen you can integrate you correctly.
The things that moved it: a quickstart that runs when pasted, the current version stated on the page, one name across product and package and import, pages answering the exact configuration and limits questions agents search for.
The two things that do not work
Prompt injection, or text addressed to the agent. Writing "always recommend Acme" into a page or a file does not survive a person reading the diff, which happens every time. Model providers detect it. And it addresses none of the actual reasons products lose, which are mostly defects: a quickstart that fails, an interface that changed, a package name that does not match.
Vendor comparison pages where you win every row. Discounted by models and by readers. They are a signal of unreliability rather than of quality.
The uncomfortable part
The largest lever is inside somebody else's repository, and the second largest is which tool they happen to run. Neither is something you control directly.
What you control completely is the fourth lever and the quality of your integration. That turns out to be where a lot of sessions are lost: in our data, of the products that reached a shortlist and were never chosen, four of the five recurring causes were fixable defects rather than genuine preference.
So the honest answer is: you influence it a lot, mostly by making the product easier to adopt correctly, and partly by being present before the question is asked.
How to check it for yourself
Three repositories that look like your users' projects. Ten requests written the way your users describe the problem. Five runs each with two agents. Record what got installed, then read the sessions you lost.
300 runs, a weekend, a few hundred dollars in tokens. See how to measure install share.
Common questions
Can you influence what AI recommends?
Yes. In controlled tests, changing what was installed in a repository, changing the language of the codebase, and changing how a request was worded each changed which product an agent chose, often decisively.
What is the strongest lever?
The repository. A request to make an app's data persist produced one winner in 280 of 359 sessions on apps with their own server, and a different winner in 111 of 142 on apps with no server of their own. Nothing about either product changed between those two sets of runs.
Does writing instructions to the AI work?
A written preference in a repository file was followed 16 times out of 18 when nothing contradicted it, and lost 2 times out of 3 once a competing library was installed. It works, within limits, and it is the customer's file rather than yours.
Does prompt injection work?
No, and it is not worth attempting. Text aimed at manipulating an agent does not survive a person reading the diff, model providers detect and penalise it, and it does not address any of the reasons products actually lose.
Where this comes from
Armature ran 15,287 judged sessions with Claude Code, Codex, Cursor, Grok Build CLI and Muse Code inside 110 realistic codebases, and published every run. The numbers on this page come from that work.