Make Claude speak TO you, not LIKE you | Danilo Velasquez
Back to blog
Aug 5, 2026<br>•12 min read
Make Claude speak TO you, not LIKE you
I once told Claude, about a sentence it had just written for me: “I started reading that and it made me feel stupid, so I stopped.” That one line taught me more than any careful answer could have, because it marked the exact spot where the writing lost me.
It also pointed at something I had missed for a long time. Talk to Claude for a while and it starts to sound like you. Write formally and it answers formally. Crack a joke and it loosens up. Language models pick up the register and style of the person in front of them, and that mirroring is usually a nice property. But the way I talk is not the way I best take in information. Those are two different systems, and the mirroring only serves the first one. When Claude explains something new to me in my own comfortable style, it optimises for how I sound, not for what stays in my head.
So I stopped guessing and ran some tests on myself.
The mistake I was making
If you had asked me whether analogies help me, I would have given you a flat answer. It would have been wrong, because the honest answer has a condition on it, and I had never separated the two cases.
When I am learning a new concept and I ask for it to be explained, an analogy helps. It gives me a handle on something I have nothing to attach to yet. But when I am in the middle of work and Claude just tells me what it did, the same analogy is dead weight. I have to decode it for no reason, and it costs me the attention I wanted on the actual task.
So the rule is not “analogies, yes” or “analogies, no”. It is “analogies when I’m learning, not when I’m working”. I only found that condition because I tested the two situations separately instead of asking myself one flat question. That is the point of this post. You are probably wrong about how you best process information, and often the wrong is that you flattened a rule that needed a condition on it.
What I built instead
I wrote a communication protocol. It is a file my agent loads at the start of every session, and it tells Claude how to explain things to me specifically. Not “be concise”. Actual rules, each one backed by a small test of what I retained.
A few of the rules that came out of it:
Explain in short sentences linked by cause and effect, not bullet points. Loose facts in a list do not encode for me. A causal chain does. Same facts, very different retention.
Bold the key terms and values. I re-read. I always re-read. Instead of fighting that, the design makes re-reading cheap, so my eye finds the important word without parsing the whole sentence again.
Tie any explanation to a consequence for me before explaining it. This was the big one, and I would not have guessed it. When a topic did not connect to something I cared about, no amount of formatting saved it. I just did not retain it. Framed as a decision with a consequence for me, the same content stuck on the first try.
That last rule is the thing the exercise taught me that I value most, and it only showed up because a test forced it out. Interest is not a nice-to-have for my memory. It is a gate the information has to pass before formatting even matters.
None of these are aesthetic preferences. Each one earned its place by beating the alternative in a retention check.
The same explanation, two ways
To make this concrete, here is one short technical explanation written twice. Same facts, a debounced search input. The first version is how an assistant explains it by default. The second applies my rules. Neither is wrong, and the first is perfectly competent. The second is just tuned to how I read.
Default:
Debounce is a technique for limiting how often a function runs in response to a rapid stream of events. On a search input, the naive approach wires the request directly to the input’s change event, so every keystroke fires its own request. Type “laptop” and you’ve sent six requests, “l”, “la”, “lap”, and so on, most of which are already stale by the time they come back. That wastes bandwidth, hammers your backend, and can cause race conditions where an earlier response arrives after a later one and overwrites the correct results.
Tuned to my rules:
Without debounce , every key the user presses in a search field fires its own request. Typing “laptop” sends six requests: “l” , “la” , “lap” , and so on. Most of those requests are already stale by the time they come back. Stale requests waste bandwidth, hammer the backend, and cause race conditions: an earlier response arrives after a later response and overwrites the correct results.
Debounce is a technique that limits how often a function runs in response to a rapid stream of events. Instead of firing the request on each keystroke, debounce starts a timer set to a short delay, for example 300ms . If another keystroke arrives before the timer expires, debounce cancels the timer and...