DEV Community: Kara Silverman

Your Docs Are Doing Your Marketing Now (Whether You Like It Or Not)

Kara Silverman — Wed, 15 Jul 2026 16:15:36 +0000

TL;DR -

Nobody has one AI visibility number. You have six (one per model), and they disagree — a cloud infra company we audited scored 33% on ChatGPT/Gemini but 16% on Perplexity.
For dev tools, documentation is your top citation source — not the blog, not press. Our best performer pulled 17% of its category citations from its own domain vs. a 4.5% median.
One honest comparison page that includes competitors beat years of blog content: it drove a 33% owned-citation rate, the highest we measured.
A low Perplexity score means your live site isn't producing citable pages; a low Copilot score is a blind spot right where enterprise buyers research vendors.
Rebrands break AI visibility. One company's retired brand was 10x more visible in AI answers than its live one — redirects fix HTTP, not language models.
Your citations are leaking to Medium (37%), Reddit (32%), and YouTube (18%) — pages that could point at your domain instead.

Over the past six months, my agency Althea Labs has run brand visibility audits on 20+ companies measuring how often AI models (ChatGPT, Gemini, Perplexity, Copilot, Google AI Overviews/AI Mode) actually mention and cite them when developers ask questions in their category.

About half were developer tools companies: Observability, auth, cloud infra, databases, AI hardware. Which means we now have a decent dataset on how LLMs decide which dev tools to recommend.

Some of what we found confirmed what you'd expect, but if you work on a devtools product or you're the developer who somehow inherited "AI visibility" as a side quest there are three key learnings worth knowing.

1. Your documentation is your marketing department now

The best-performing devtools company in our dataset gets mentioned in 41% of AI answers in its category, with remarkably consistent performance across every model. When we broke down WHERE its citations come from, it wasn't the blog. It wasn't press coverage. It was:

Core documentation
SDK hubs
Protocol-level explainers (the "what is SAML vs OIDC" tier of content)

That company earns 17% of all its category citations from its own domain. The median across our whole portfolio is 4.5%.

Once you see it, the mechanism is pretty clear: When a developer asks an LLM "how do I implement X," the model reaches for content that is structured, specific, and extractable. Documentation is accidentally perfect for this. It has clear headings, canonical answers, code blocks, and no marketing language or fluff. A docs page that says exactly what a thing does, in what versions, with what limitations, is one of the most citable objects on the internet.

Another company in the Althea Labs dataset proved this with a sample size of one page. Their owned citation rate is 33%, the highest we've measured, and it's driven almost entirely by a single honest comparison page ("best X databases compared," including competitors) on their own domain. One well-structured, genuinely useful page outperforms years of blog content.

So, what can you actually do with this info? Treat documentation as a discovery surface, not just a support surface. Un-gate your white papers. Add comparison pages that include your competitors and tell the truth. Use spec tables and decision criteria instead of adjectives. If your docs answer the question better than a Medium listicle, the models will eventually notice because right now, across the categories we measured, Medium (37% citation rate), Reddit (32%), YouTube (18%), and yes, our very own DEV.to (16.5%) are eating citations that could point at your domain.

2. Your visibility varies wildly by model, and the gap tells you what's broken

Nobody has one AI visibility number. Everyone has six, and they sometimes disagree.

I want to show you a quick breakdown of a cloud infrastructure company Althea audited. It had 33% visibility on ChatGPT and Gemini, 16% on Perplexity, 18% on Copilot. For an edtech platform, we saw 56% on Gemini and just 9.6% on Perplexity. Across the 12 companies where we captured model-level splits, Perplexity came in below the other models for 10 of them.

The models sit on a spectrum from "training-data-driven" to "search-driven." ChatGPT and Gemini lean on what they learned in training on years of internet history, brand priors, and accumulated reputation. Perplexity barely does; it searches the live web and cites what it finds today.

So the Perplexity gap is diagnostic:

High everywhere, low on Perplexity → You're coasting on brand equity. The models "remember" you, but your current site isn't producing citable pages. That equity erodes every time a model retrains on a web where you're not the source.
Low everywhere, alive on Perplexity → Your content works but you have no entity footprint. The most extreme case in our data: one company registered 0% on ChatGPT, Gemini, Copilot, and both Google AI surfaces — and only existed on Perplexity, because it had a handful of genuinely citable pages and nothing else. That's a single point of failure. One change to Perplexity's retrieval behavior, and their AI visibility goes to literal zero.
Low on Copilot specifically → Pay attention if you sell to enterprises. One database company in our set showed 0% on Copilot and 0.5% on ChatGPT while doing fine on Google surfaces. Copilot is embedded in the exact environment where enterprise buyers do vendor research.

So, what can you actually do with this info? Measure per-model, not aggregate. Then fix the side you're weak on: Search-driven models want citable pages (structure, schema, llms.txt, clean sitemaps so crawlers actually reach your content); training-driven models want entity signals (Wikipedia/Wikidata, Crunchbase, consistent third-party coverage that repeats who you are and what category you're in).

3. If you rebrand without an entity migration, LLMs will keep recommending your old brand

One company in our dataset rebranded in the middle of last year. New name, new domain, redirects done properly, all the traditional SEO boxes checked.

Their old brand name ranks #3 in their category in AI answers and is mentioned 36% of the time. Their new brand name ranks #28 and is mentioned 3.7% of the time.

The retired brand is still 10x more visible than the live one.

Training cutoffs are the reasons for this issue. A model trained before the rebrand has never heard of the new company. It has years of docs, Stack Overflow threads, conference talks, and blog posts about the old name and messaging. Redirects fix HTTP; nothing about a 301 teaches a language model that two entities are the same thing.

And it decays slowly from there. Every quarter until the major models retrain on a web that consistently connects the old name to new one, the recommendations, the "what should I use for X" answers, and the tutorial mentions keep flowing to a brand that no longer exists.

So, what can you actually do if a rename/rebrand is on your roadmap? Treat the entity migration as a launch-critical workstream, not a comms afterthought. Update Wikipedia, Wikidata, Crunchbase, PitchBook, G2, and GitHub org metadata on day one. Get third-party coverage that explicitly states "X, formerly known as Y" so the models learn the equivalence from repetition in authoritative sources. Add Organization schema on your domain declaring the former name. Then monitor model-by-model until the new entity actually takes.

The wide angle view

The most encouraging stat in our whole dataset: The #1 most-visible brand in one category we measured appears in only 17% of AI answers about its own space. The "winner" is absent from 4 out of 5 answers. In dev tools, where documentation culture already produces the exact kind of content LLMs want to cite, that's not a threat. It's the most open distribution channel since early Google and the teams that treat their docs, comparison pages, and community content as citation infrastructure are going to quietly own it.

The Vertical Turn

Kara Silverman — Wed, 01 Jul 2026 14:41:07 +0000

Look at tomorrow's track list and count the rooms that have absolutely nothing to do with engineering. Go ahead, I'll wait.

Thursday’s schedule is running 12 parallel tracks. The AI in Healthcare, AI in Finance, and AI in GTM are brand new this year. On top of that, there are entirely dedicated audiences for founders, researchers, and data buyers. Trust me, that is not a scheduling decision. That is a deliberate segmentation decision that reflects where this industry is headed.

For three years, this conference spoke to one very specific audience: the AI engineer. The person writing the agent, wiring the retrieval pipeline, running the eval suite. That audience built a discipline from scratch and gave it a name. But this year, the organizers looked at who was actually hitting the registration page. People from companies like Vanguard, CVS Health, Intuitive Surgical, Two Sigma, Capital One, and more. It’s a marked expansion and a recognition of AI engineers existing not just at tech companies but in other areas of work as well.

Tomorrow's Healthcare track is running sessions on diagnostics, drug discovery, clinical workflows, and regulatory constraints. Finance covers trading, risk assessment, fraud detection, and compliance. GTM sits right next to both of them. These aren’t fluff panels about "the future of AI.” They are actual, practical working sessions for people who need AI to clear a compliance review, reduce false positives in a fraud model, or shorten a sales cycle. These are people who do not care what framework you used.

This is what real adoption looks like when it stops being theoretical. It’s not a bigger model or flashier demo. It’s a room full of clinicians, traders, and go-to-market operators who showed up because the tool finally got specific enough to matter to them.

AI Isn't Ready to Build Complex Software

Kara Silverman — Wed, 01 Jul 2026 13:19:40 +0000

In an industry currently swept up in the hype of AI coding agents, Micah Wylde, principal engineer at Cloudflare, offers a sobering reality check. Wylde is leading the development of a new suite of data platform products and has a front-row seat to both the power and the limitations of generative AI. Despite having his own "aha moment" last year when models became capable of generating significant amounts of code without heavy oversight, his hottest industry take right now is remarkably clear: AI models are still not good enough for complex software development.

For Wylde, who builds intricate database systems, the stakes are simply too high for AI to fly solo. Software at this level is nonnegotiable in its requirements, and it needs to produce completely correct results, ensure data is never lost, and remain highly maintainable over time. While an AI tool might successfully generate a massive block of code that satisfies your immediate prompt, it falls short on the bigger picture. As Wylde notes, AI "has no consciousness of what the lifetime of this project is." It solves the micro-problem in the moment while completely ignoring the macro-architecture, creating a massive gap for systems that demand rigorous, long-term stability.

So, how should developers navigate this gap? By doubling down on the fundamentals.

Wylde warns that while AI agents undeniably allow engineers to move much faster, they do not replace foundational computer science skills. To successfully orchestrate these agents and build complex systems today, engineers still must deeply understand how code actually works and how computers operate. Until AI models evolve to grasp the long-term maintainability of a codebase, the human engineer's true value isn't in generating raw code; rather, it's in architecting software that is actually meant to last.

The Evolution & Role of Context Engineering in AI Today

Kara Silverman — Tue, 30 Jun 2026 15:33:14 +0000

I was taking a break from the AIE Workshops on Monday and stepped out by the food stands to check out the crepes. That's when I saw a line literally wrapping the entire length of the Moscone West windows looking out onto Fourth Street. I couldn't imagine what a several-hundred-person line was for, and when I went to ask, they told me it was for the Context Engineering Workshop. That sent me down a rabbit hole exploring and understanding and learning. So now, for you, I will share what I got.

For the past couple of years, the AI world was obsessed with prompt engineering, aka the art of speaking to a machine. But as developers move from simple chatbots to complex autonomous agents, a new discipline has taken center stage: context engineering.

Mike Swift (@theycallmeswift), CEO of Major League Hacking (@mlhacks) , gave me some critical background. He pointed me to Dex Horthy of HumanLayer (who is actually speaking later this week), who basically coined the term at the first AI Engineer World's Fair. Dex's core thesis, said Swift, is that "agents get bad after about 100,000 tokens," which represents roughly 10% of their total available context window.

So context engineering is essentially managing an AI's working memory. Context engineering, Swift noted, is "managing how many times the loop goes around to how much you have to remember every time you do it." It is a counterintuitive concept for humans; the more we talk about a subject, the deeper our shared understanding becomes. But models work the opposite way. They lose focus as their context window fills up.

For many developers, meticulously curating this working memory is a practical necessity. I sat down with Ben Halpern (@ben), founder in residence at MLH and co-founder of DEV, who told me that context engineering is the "latest frontier of the optimization point" where developers can leverage their expertise. Beyond just keeping models coherent, Ben pointed out that developers who are doing product work manage context for "latency and cost effectiveness."

During our chat, I tested a somewhat spicy thesis I'd been developing: that context engineering feels like a proxy for control, perhaps even our "last real attempt at managing control" before models outpace us. Ben agreed that there is a massive opportunity for human impact here, while not fully buying into my thinking. He noted that because "model progress is going to be slower than the tooling progress," context engineering allows developers to "reduce the feeling of models as a black box." Instead of waiting for the next foundational model to magically fix memory limitations, developers can actively add value to workflows today.

Next, I talked with Dominik Kundel, who works on developer experience for Codex. Dominik argued that while strict context management is valuable, for example, in narrow, customer-facing support bots, it actively hinders general-purpose agents.

When developers meticulously craft context windows, Dominik said, "What you're doing is shrinking and limiting the possible range of tasks that it can solve." Instead of filtering what the model sees, Dominik advocates for progressive discovery. "I don't filter anything," he said, noting that Codex connects directly to vast, unstructured sources like Slack, Gmail, and Notion so that it can learn to navigate the noise on its own.

This unstructured approach enables what he calls "vague prompting." Because the agent has access to everything, you can talk to it like a colleague and ask it to "fix the thing that Karen asked me about yesterday." The agent will independently figure out which Karen is relevant, locate the Slack thread, and pull the necessary context. When I brought up my thesis about context engineering acting as a proxy for human control, Dominik acknowledged that strict management definitely makes outputs more predictable. However, he warned that this "determinism results in reduction capabilities" and a severe loss of flexibility.

Ultimately, walking away from Moscone West last night, it was clear that context engineering is far from a one-size-fits-all discipline. Whether a developer chooses to heavily filter an agent's working memory to maintain a human thumbprint or embrace progressive discovery to unlock vague prompting, the era of treating an AI's context window as an endless dumping ground is definitively over.

Reconciling the Distributed System: How the AI Engineer World's Fair Engineered Human Connection

Kara Silverman — Tue, 30 Jun 2026 15:08:52 +0000

On Sunday night, the sold-out 2026 AI Engineer World's Fair kicked off its orientation at Moscone West. The sheer scale of the event was staggering, featuring an estimated 7,000 attendees — a massive leap from the 1,500 who gathered at the Marriott down the street just last year. Amid this sprawling crowd, the core irony of the event was palpable: every technical talk could easily have been watched from home on YouTube, but instead the room was filled with people looking to be part of the experience IRL. One thing many first-time conference attendees — engineer, marketer, or creative — struggle with is talking to new people. Luckily, that was this gathering's true purpose: creating real human relationships.

Conference organizer @swyx opened the event with a relatable, if surprising, confession to the crowd: as a programmer and a writer, he is not a natural networker. Recognizing this common trait among developers, he introduced "NEO," or New Engineer Orientation, an initiative designed to bridge this social gap. NEO was created to give attendees a structured way to spark genuine connection and build relationships that would stay with them long after the technical sessions ended.

As the industry transitions from cloud computing to AI, the most valuable skills might not be strictly technical. The uniquely human abilities — to smile, laugh, and shake hands; to find community and process shared emotion — are still part of the equation. The AI Engineer World's Fair orientation proved that even in a sold-out crowd of brilliant engineers, people occasionally need a little analog help to break the ice.

Appreciate this very much, especially as a relatively new software creator myself.

Kara Silverman — Mon, 08 Jun 2026 14:19:38 +0000

MLH Team for Major League Hacking (MLH)

Jun 5

GitHub, Demystified

#github #beginners #opensource #software

9 min read