diagramanything
v0 · 2026
a small experiment

Tell us a topic. Get back one careful diagram.

Most explanations are written and most readers are visual. Diagramanything is a slow, hand-tuned answer engine: you say what you want to understand, we send back a single SVG that tries to fit on one screen and earn its lines.

>

The form is decorative for now — diagrams below are the current shipped catalogue. New requests are queued and answered slowly. See examples ↓

Recent diagrams

three of seventeen
№ 01

The harness around a coding agent

AI · systems
MODEL claude · gpt · gemini CONTEXT CLAUDE.md · readme · docs project conventions TOOLS read · edit · grep · run bash · web_fetch VERIFIER tests · linter · types "did it actually work?" MEMORY past chats · skills user preferences OUTPUT code · PR · message → user-visible artifact USER prompt · feedback · review verify ⟲ harness · n. — the structure that makes a model useful

A model alone is a curious oracle. A model in a harness is a worker. The interesting craft of 2025–2026 has been less about better models and more about the satellites: context shaping what the model knows, tools shaping what it can do, verifiers closing the loop on whether it succeeded. The dashed line is the most important — most agents that fail in production fail there.

№ 02

How a request reaches a static site on Cloudflare Pages

networking · web
browser cloudflare DNS CF edge (anycast) pages router asset bucket A example.com? → 104.21.x.x GET / · TLS handshake · Host: example.com match host → pages X internal RPC: which deployment? fetch /index.html 200 OK · <html>… (cached at edge for next visitor) ~5ms +30ms +1ms +5ms note: every box-to-box hop after the edge is intra-Cloudflare. user-perceived latency is dominated by the first three steps.

From the browser's point of view, a static site loads "instantly." Almost all the work — DNS lookup, TLS, edge routing — happens before the bytes even start. Once Cloudflare's edge has matched the host to a Pages project, the rest is internal traffic between Cloudflare's own services. The closer the user is to a Cloudflare PoP, the more this whole diagram collapses into "just a few milliseconds."

№ 03

OAuth 2.0 with PKCE — the dance, plainly

auth · web
USER CLIENT (your app) AUTH SERVER click "log in with X" generate verifier SHA256 → challenge redirect: /authorize?challenge=...&client_id=... login page · "do you allow this app to read X?" enter password · approve scopes redirect: ?code=ONE_TIME_CODE POST /token (code + verifier) SHA(verifier) == stored challenge? access_token + refresh_token "you're logged in" PKCE = Proof Key for Code Exchange. The verifier never leaves the client; the challenge can be public. Stops a stolen authorization code from being usable.

Vanilla OAuth 2.0 worried about server-to-server secrets. PKCE (pronounced "pixy") was added because mobile and SPA apps can't keep a secret. The trick: the client invents a random verifier, sends only its SHA-256 hash to the auth server up front, and reveals the verifier itself only when redeeming the code. Even if an attacker intercepts the authorization code, they don't have the original verifier and can't redeem it.