Most of the AI-search advice being sold right now is fine for most B2B software. Structure your content so an engine can lift it, keep your review profiles current, make your entity unambiguous, earn honest third-party mentions. If you sell HR software or a help desk, that playbook mostly points in the right direction.
Then a developer-tools company runs it, spends a quarter on review sites and comparison-page outreach, and the AI answer for their category does not move. Not because the work was sloppy. Because the playbook was written for a buyer who does not exist in their market. Developers do not evaluate software the way the generic GEO guide assumes, and the sources AI search reads for developer tools are not the ones it reads for everyone else.
Your source layer is code, not reviews
For a typical B2B category the engine leans on review platforms and marketing comparison pages. Ask it for the best CRM and it pulls G2, Capterra, and a handful of “best CRM” roundups. That is why the review-site advice is everywhere, and for those categories it is right.
Developer tools sit somewhere else. When the engine answers “best library for X in Python” or “lightweight alternative to Y,” the sources it reaches for are your documentation, your GitHub repo, Stack Overflow threads, Hacker News discussions, and the language subreddits where the actual users argue. Review sites barely enter the picture, because the buyers never went there, so the engine learned not to lean there for this category. Run the questions and you will see it: the citations come back docs, GitHub, forum, dev blog, not a single G2 link.
That inverts the whole to-do list. The move that helps an HR-tech company, a cleaner review profile, does close to nothing for a dev tool. The equivalent lever here is documentation the engine can lift a working example from, a repo that looks alive, and honest presence in the technical threads where developers actually cross-check. Same principle as every other category, a source layer you do not fully control, but a completely different set of sources.
There are two developer questions, and they hit two different engines
Developers do not use AI search in one mode. They use it in two, and the two reward different things.
The first is building mode. A developer is in the editor asking an assistant to write the integration, and the engine reaches for whatever it can most fluently produce working code with. That is decided by what is in the training data: the tool with the most complete docs and the most copy-pasteable examples becomes the default the model writes without being asked. You win this one by being the API the engine already knows how to call, which comes from documentation depth and example volume, not marketing. This is the ChatGPT memory surface, and it moves on the model’s slow schedule.
The second is research mode. The same developer, earlier in the decision, asks “best X for Y” or “is X still maintained,” and here they tend to be in a retrieval engine like Perplexity that pulls live sources and shows them. This one you can influence in a crawl cycle, and it turns on current, retrievable evidence that you exist and are active. Treating “get cited” as one job is the mistake. For a dev tool it is two jobs on two clocks, and the work for each is different.
The developer cross-check is the filter no other buyer applies
Here is the part that makes developer tools genuinely different, and genuinely unforgiving. Developers are the buyer most likely to distrust the AI’s answer and go verify it. The engine says your tool is the modern choice, and the developer opens the GitHub in a new tab, checks the last commit date, scans the open issues, skims the docs, and forms their own view in ninety seconds.
That means a citation you cannot back up is worse than no citation. For a non-technical buyer, being named by the engine is often most of the win. For a developer, being named is the start of an inspection you will lose if the substance is not there. You cannot paper over a thin product or a neglected repo with clever content in this category, because the audience clicks through. The upside is the mirror image: if the docs and the repo and the threads all hold up, the citation compounds into trust faster than it does anywhere else, because the developer just confirmed it themselves.
“Is this still maintained?” is the wrong-fact that only bites here
No buyer of HR software asks whether the vendor is still maintained. Every developer asks it, of every dependency, out of hard experience. And the engine now answers it, out loud, in the recommendation.
A stale changelog, a last release dated eighteen months ago, a pile of unanswered issues: those are not just bad optics anymore, they are the cited fact that ends the evaluation. The engine will describe an actively maintained project as safe and a quiet one as risky, and it does not know your team is small and shipping, it only knows what the public signals say. Release cadence, changelog freshness, and issue responsiveness are a visibility factor for developer tools in a way they simply are not for other software. Silence reads as abandonment, and abandonment is disqualifying.
Before any of this, run the queries
One caveat the generic pitch never includes. Not every product sold to developers behaves like a developer tool in AI search. Some are bought by a VP with a budget, evaluated on a call, and those lean back toward the review-site pattern. The only way to know which one you are is to look.
Take your real buyer questions, the “best X for Y,” the “alternative to Z,” the “is X still maintained,” and run them through the engines yourself. Watch what gets cited. If it comes back docs and GitHub and forum threads, you are a developer tool for AI-search purposes and this is where the work lives. If it comes back review sites and analyst pages, you are closer to the standard playbook than you thought. Ten minutes of running the queries beats a quarter spent optimizing the wrong source layer. It is the same source audit every category needs, it just tends to land in a very different place for this one.
What I got wrong
The first developer-tools client I took, I ran like any other B2B SaaS engagement. We went after review-site placement and comparison-page outreach, the moves that had worked for a services client the quarter before. Three months in, the AI answer for their category was unchanged, and I could not honestly say the work had touched anything the engine was reading.
When I finally ran the source audit properly, the citations were almost entirely docs, a couple of Hacker News threads, and one heavily upvoted Reddit comparison. Zero review sites. The engine had never once pulled the sources we spent the quarter improving. What moved it was restructuring the documentation so the engine could lift a complete working example, getting the changelog and release notes current so the “is this maintained” question stopped returning a scary answer, and showing up honestly in the two technical threads that kept getting cited. None of that was on the generic checklist. All of it was sitting in plain view in the audit I should have run first.
Where this leaves you
Developer tools are not an edge case of AI search, they are their own case. The engine reads a different source layer for them, the buyers split their questions across two engines with two different jobs, they verify the answer harder than anyone, and they ask a maintenance question that no other category faces. Follow the playbook written for everyone else and you will do real work on sources the engine never opens for you.
The version that works starts by looking: run your buyer questions, read what actually gets cited, and put the effort where the engine is already looking, which for a developer tool usually means the docs, the repo, and the threads, not the review profile. It is less tidy than a checklist. It is the version that changes the answer your buyers are reading.
If you want your developer tool audited the way the engine actually reads it, the docs and repo signals, the threads it is pulling from, and the maintenance story it is telling your buyers, that is the engagement, and it runs on a documented method.