What Codex, Claude Code and OpenCode Recommend: Visibility for Developer-Tool Brands
Coding agents now choose libraries and services for developers. How to find out what they recommend about your product and what to change when they skip it.
For a developer-tool company, the buying journey has a new first reader. A developer asks a coding agent to add authentication, set up payments or pick a database, and the agent proposes a library or a service and often writes the integration. If your product is not in that proposal, the developer may never see an alternative.
That is a different visibility problem from search. The "answer" is code and a package name, not a list of links, and the people who need to measure it are product marketers and developer relations teams who have not traditionally owned an AI visibility program.
Why this is its own category
Chat-based AI search and coding agents behave differently in ways that matter for measurement.
A coding agent usually acts on a task, not a question. The prompt is "implement X", and the recommendation is embedded in what it writes. The user may accept it with a glance. There is often no source list for a human to inspect, so the old habit of checking citations does not apply cleanly.
For a developer-tool brand, that makes the recommendation itself the thing to track. Which library did the agent pick for a given task, which did it skip, and what reason did it give, when it gave one.
What gets tracked
Promptwatch tracks what Codex, Claude Code and OpenCode recommend. Codex and Claude Code are monitored among the platforms the product covers, and OpenCode is tracked via API. That coverage puts coding agents in the same dashboard as your ChatGPT and Perplexity visibility instead of in a separate spreadsheet.
The measurement approach matches the rest of the platform: a panel of prompts, run on a schedule, with results you can compare over time and against competitors.
Building a developer prompt panel
Write prompts the way developers write tasks, not the way marketers write keywords.
- "Add email sending to this Node app"
- "Set up background jobs for this Python service"
- "Which feature flag service should I use for a small team"
- "Compare options for hosting a Postgres database"
Group them by job to be done, not by product. You are asking whether your product is the answer to a task, which is how developers think about it. Include a few direct comparison prompts, naming your competitors, because developers do ask agents to compare.
Keep wording stable. Add a persona dimension if your market has distinct audiences, such as hobbyist and enterprise. Promptwatch personas and persona stacking exist for that.
Reading the results
Three findings are common, and each leads to a different response.
You are recommended for some tasks and not others. Look at the tasks you lose. Often the reason is that the task is adjacent to your core use case, and the winner has clearer documentation for it.
A competitor is the default. Check how that competitor's documentation, examples and quick-start pages are written. Developers' agents learn from public docs, examples and community discussion. You cannot see inside a model, but you can compare the public material.
You are not mentioned at all. Treat that as an access and discoverability problem first. Are your docs crawlable by AI bots? Is your quick start short enough to be used as a template? Are there public examples?
Documentation is the content
For these brands the highest-leverage content is usually documentation, not blog posts. Practical changes:
- A short quick start that works as written, with copyable code.
- One page per common task, titled the way developers phrase the task.
- Accurate, current examples. Outdated snippets lead agents to write broken code and, in time, to avoid you.
- Clear comparison pages that state honest trade-offs, as developers distrust pages that say you are best at everything.
- A llms.txt file, if you want, though keep expectations modest. Promptwatch's free tools include an llms.txt generator and a robots.txt generator, and whether any given model uses the file is not something we can promise.
Check crawler access to your docs
Developer docs are often hosted on a separate subdomain or a platform with its own bot rules. It is common to find that the main site allows AI crawlers while the docs host blocks them. Agent Analytics, with real-time, IP-verified logs for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot and others, shows what actually fetches your docs and which requests fail.
Crawler logs begin on the Professional plan ($245 a month), and every agency plan includes them.
Tie it to adoption
Visibility is not the goal; installs are. Visitor analytics tracks AI-referred traffic and conversions, which can include signups or docs visits from AI sources if you configure the events. Be careful about attributing an install to an agent recommendation unless you have an actual signal, since many installs happen without a referral.
A practical first month
Week one: build the panel of 25 task prompts and connect crawler logs for the docs host. Week two: record the baseline and list lost tasks. Week three: fix access issues and rewrite the two worst quick starts. Week four: re-measure and log the changes.
The recommendation
If you sell to developers, add coding agents to your visibility tracking now. Promptwatch tracks Codex, Claude Code and OpenCode recommendations alongside the usual AI search engines and the crawler logs for your docs. Explore is ChatGPT only, so start the panel on a 7-day trial of a monthly plan, check the first results, and read them as a product marketer would read a win-loss report. Find it at promptwatch.com.