I ship MCP servers and agent automations constantly. Personal infrastructure, benchmarks, cron-driven agents that run while I sleep. At this point, standing up a new one is routine — a day of focused work, often less.
Which is exactly why I keep getting one thing wrong.
Every time I put one of these in front of someone new — a reader, a friend, a fellow dev who hasn't touched agents yet — I expect the reaction I'd have: oh, neat, a tool server. What I get instead is a wall of questions. What can it access? What happens if it misbehaves? Why would I let an AI touch my files?
For a long time I read those questions as resistance. They're not. They're diligence — the same diligence I did years ago and then forgot about.
Familiarity is invisible
When you've done something ten times, you stop seeing what it looks like the first time.
To me, an MCP server is a boring, known quantity. I know its blast radius. I know what it can and can't reach. I know what happens when it fails, because I've watched mine fail in every way there is — I've written a whole series about it.
But that knowledge didn't come from a demo. It came from months of breaking things on my own machines, where nothing was at stake and nobody was watching. That's the cost of comfort, and I paid it so long ago I forgot the receipt.
Someone meeting agents for the first time is being asked to pay that cost upfront, all at once, usually on a machine they actually care about. Of course they hesitate. I would too — I just don't remember it.
What actually closes the gap
Not better demos. I've tried. Three things work instead:
1. Make the worst case boring. Sandbox first. Everything reversible. When "what if it breaks?" is answered with "we switch it off and nothing is lost," first-time caution relaxes on its own. You can't argue people into comfort. You can build it.
2. One small win beats a grand vision. "Agents will change how you work" is inspiring to a builder and abstract to everyone else. What lands: automate one specific task the person would happily never do again, and let them feel the time come back. Twenty minutes reclaimed converts harder than any pitch. Adoption pulls. It doesn't push.
3. Meet people where they're already building. More and more non-developers are vibe-coding their own tools. The developer reflex is to judge the output. Wrong reflex. These people crossed the scariest gap — from "AI is a chatbot" to "AI builds things for me" — entirely on their own. "This is great, want a hand making it safer?" beats any advocacy campaign you could run.
The part where I was the problem
Full honesty: my default reaction to first-timer hesitation used to be frustration. This is easy. Why the friction?
Easy for me. I'd confused my familiarity with the thing being simple. Those are not the same. Everyone crosses this bridge at their own pace, and some weeks the pace is slower — mine included. That's allowed.
Frustration at people is wasted energy. Closing the familiarity gap is where the leverage is.
Why this matters more every month
The tooling gets easier every quarter. The familiarity gap doesn't shrink with it — because every wave of new capability creates a new crowd of first-timers. Whoever you are, however deep you're in, most of the world is on their first encounter with what you consider routine.
That's not a problem. That's the opportunity. If you've walked the road ten times, you're the best possible guide for someone on step one — but only if you can still remember what step one felt like.
Something new will ship next month and someone will meet it for the first time. Someone always does. Be the person who makes their first time easy.
Top comments (0)