An advertiser selling a Postgres product wants to reach people writing backend code, not people writing shaders. That is a reasonable thing to want, and serving it badly is how ad systems end up reading everything.

The whole vocabulary

ADCode's editor derives tags from what you have open, drawn from a fixed list of 45:

Languages — lang:rust, lang:typescript, lang:python, and 18 more.
Frameworks — fw:react, fw:django, fw:rails, and 8 more.
Tools — tool:docker, tool:cargo, tool:terraform, and 6 more.
Platforms — platform:web, platform:backend, platform:mobile, platform:desktop.

That is the complete list. It is compiled into the editor, and the server cannot add to it. A tag the server does not recognise is dropped; a tag the *client* does not recognise was never sent.

What the server receives

A request for an ad contains the tags, whether your theme is light or dark, and how many cards to return. That is all of it.

It does not contain a filename. It does not contain a repository name. It does not contain a line of code, a symbol, an error message, or a commit. There is no field in the request where those could be put.

Why this is enough

An advertiser targeting lang:rust reaches people with Rust open. That is a better signal than most ad networks manage from far more invasive collection, because it is *current* — not inferred from browsing history six weeks ago.

The trade-off is that targeting cannot get more specific than the vocabulary allows. An advertiser cannot reach "people whose tests are failing" or "people working on a payments service". We think that ceiling is a feature.

Verification, not trust

The other half of the system is that an advertiser only pays for a card that was really served and really seen. Every serve writes a record; a receipt that does not match one earns nothing and bills nobody.

That protects the advertiser from paying for fabricated views, and it protects you, because it means the system has no incentive to serve ads it cannot verify.