The real unlock from AI isn't speed, it's not having to translate yourself
- 10 minsI’ve been iterating on an AI skill for a few weeks that does one narrow thing. It writes pull request descriptions, review comments, and code comments in my voice instead of the AI’s default voice. This is not particularly interesting at face value, nor is it unique. Plenty of attempts, both serious and humorous, have been made to “distill” one’s personal and/or professional essence into an agentic model one way or another. And initially, my motivation was mundane too - I was just tired of fixing things in generated prose that personally bothered me, or things I didn’t want to subject my colleagues to suffering through.
More or less, I was able to solve the majority of my frustrations, and that is when something rare happened, solving one problem didn’t result in shifting my attention to every other engineering problem I still was responsible for; it removed an unknown bottleneck for my usage of models. I stopped re-reading my own pull requests like they belonged to someone else, and more like I had written them myself.
Now, to be clear - I didn’t write them in most cases. But instead of reviewing a pull request that ostensibly could’ve come from anyone or anything, it suddenly read like something I’d have written myself. Not that I was fooled, or it was perfect, but it captured a sufficient level of likeness.
There’s a more personal layer under this too. I’m neurodivergent, and translation is a background process for me most of the day - taking what I actually mean and re-rendering it into whatever phrasing will land cleanly with whoever’s in front of me. That’s not a metaphor, it’s closer to what autism researchers call masking (see Hull et al.’s “Putting on My Best Normal”). It’s a familiar cost, not a new one, to anyone who does it. What’s different about a pull request review with a voice-matched draft is there’s no one left to translate for. It’s just me and the model, and for once the output in front of me doesn’t need a pass through that filter before I can fully grok it. You don’t need to be neurodivergent to relate to this, especially in professional settings (after all masking is just type of code switching), but it doesn’t hurt.
This is a small thing to notice, because the obvious AI productivity story is still speed. It writes, I ship faster, capitalism continues. But speed has rarely been my goal as a craftsmanship-oriented engineer and what I hadn’t considered is a second, quieter cost that speed doesn’t touch, and as it turns out there’s real cognitive science behind why it exists. Even after years and years of meta analysis of how we build better, safer, stronger as engineers, I hadn’t considered the potency of this skill.
Extraneous load, not intrinsic load
John Sweller’s Cognitive Load Theory splits mental effort into three kinds, intrinsic load (the actual difficulty of the problem), germane load (effort spent building useful understanding), and extraneous load (effort spent on anything that doesn’t serve the task, like a badly organized diagram or a confusing UI). The theory’s whole point is that extraneous load is the one worth eliminating, because it competes for the same limited working memory as the load that’s actually productive.
Reconciling an AI’s generic phrasing against a pull request changeset I already understand is textbook extraneous load. The task, verifying that a pull request description accurately represents the diff, doesn’t require parsing an unfamiliar voice on top of the content. That parsing step adds nothing to my understanding of the change. It’s pure overhead, and it’s the kind Sweller’s theory says should be designed out, not tolerated as the cost of using AI.
The DevEx framework that Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler proposed names cognitive load as one of three pillars of developer experience, alongside feedback loops and flow state. Their framing is usually applied to codebases and tooling. A confusing build system or an undocumented API adds cognitive load the same way a confusing pull request description does. Voice mismatch is a smaller, more personal version of the same problem, but it’s the same mechanism. GitHub’s own SPACE-based research on Copilot found that around 87% of developers reported reduced mental effort on repetitive tasks, which is consistent with this. The win isn’t raw output, it’s what gets freed up when a task stops costing attention it didn’t need to cost (and that doesn’t even touch on the health benefits for people who aren’t continually over-tasked mentally).
Why familiarity specifically lowers the cost
There’s a well-documented effect in reading comprehension called processing fluency. Text that’s easier to parse, because it’s familiar in phrasing, structure, or vocabulary, gets verified faster and with more confidence than text that says the same thing in an unfamiliar register. A pull request body in my own voice is fluent to me in exactly this sense. I’m not parsing new sentence rhythms while also checking facts, I’m doing one pass instead of two.
That’s also where the honest caveat belongs. Processing fluency is the same mechanism behind the illusory truth effect, where information that’s easy to process gets judged as more likely true, independent of whether it actually is. Fluent text lowers your guard along with your effort. If a voice-matched pull request body is quicker to accept, it should be for the right reason, that reconciling it took less work because there was less to reconcile, not because familiarity made me skim past an actual error.
Maintaining a diligence against the casual favoritism this might foster with your model is important - but isn’t incredibly difficult as long as you maintain control of thought leadership (which is a deep topic in and of itself; if this is a pain point for you, this approach probably won’t serve you).
Does it even register as a context switch
Gloria Mark’s research on interrupted work puts the average recovery time after an interruption at 23 minutes and 15 seconds, and that number gets misquoted constantly. It isn’t 23 minutes of blank downtime, it’s the time until you’re fully back on the original task, including whatever smaller tasks and re-orientation happen in between. About 40% of interrupted tasks don’t get resumed the same day at all. The mechanism behind the cost isn’t the interruption itself, it’s re-engaging a different mental model, then reloading the one you dropped.
Reviewing your own pull request in a stranger’s voice fits that mechanism even though nothing external interrupted you. You’re nominally still on the same broad task, still looking at your own diff, but reconciling unfamiliar phrasing against a change you already understand means loading a second mental model (whose sentence is this, what did they mean by it) on top of the first (what did I actually build). That’s a real context switch wearing the disguise of continuous work, and it’s likely one of the reasons it goes unnoticed as a cost; nobody’s calendar shows a switch, so nobody counts it as one.
This part hasn’t been measured, so it’s a hypothesis rather than a finding, but it’s a testable one. If voice-matched text never forces that second mental model to load, it wouldn’t just make the switch cheaper, it might mean the switch never gets tagged as a switch by whatever part of the brain decides a re-orientation is needed. A cost that’s merely smaller still shows up somewhere. A cost that’s never triggered doesn’t show up at all, which would explain why this is so easy to miss and so hard to put a number on. If it wasn’t already clear, I’m not a scientist of any kind, so take this loosely.
How I baselined
My undergrad was an IT degree with an English literature minor, so I took all four years of coursework, essays, and workshop critiques that I still had sitting in old file folders. I chunked that entire corpus and fed it to a privacy-respecting local model, one pass to distill sentence structure, vocabulary, and argument shape out of essays that had nothing to do with code. Then I ran the same distillation against my GitHub history, pull requests, review comments, commit messages, the actual record of how I talk about code specifically. Then again, on my public persona, substack, lowlydba.com, StackOverflow, etc.
The style guide the skill runs on today is primarily the second distillation layered on the first, literature-trained rhythm underneath, engineering-specific voice on top.
Doing the distillation locally instead of through a hosted API was deliberate; four years of personal academic writing is not something I wanted sitting in someone else’s training pipeline. The literature corpus turned out to matter more than I expected. Coursework enforces habits, like arguing a claim instead of asserting it, or landing a paragraph on a real conclusion, that a corpus of only pull request text never would have surfaced, because most pull request text isn’t written well enough to teach those habits back.
What’s already been said, and what hasn’t
The closest formal research on the AI side is personalization work like Google’s “User-LLM” paper and a 2025 ESEM study on aligning code reviews, both framed around review quality and acceptance rates for the reader. GitHub’s own Community discussion on low-quality contributions is one of the better ongoing records of that fatigue from the maintainer’s side (polished-looking pull requests that don’t hold up once you actually read them), worth watching as the conversation develops. What I haven’t seen written up is the narrower, author-side claim that voice-matched AI output lowers the cost of verifying your own words against your own already-finished thought, and that this is extraneous load in Sweller’s specific sense, not a vague feeling of unease.
That narrower claim isn’t only about me, either. A colleague who’s read a year of my pull requests has the same processing-fluency advantage I do; they’ve already built the model of how I phrase a caveat or flag a gap, so a voice-matched description is fluent to them too, not just easier for me to write. A stranger’s polished-but-generic voice is extraneous load for a familiar reviewer in exactly the way it’s extraneous load for me. Neither of us needs to parse an unfamiliar register to get to the actual diff. That’s the reader-side version of the same mechanism, and it’s the part the personalization research above hasn’t measured yet, because it’s framed around a model learning an individual user’s preferences, not a team’s shared familiarity with one particular author’s voice.
The practical version
If you maintain a lot of pull requests, comments, or docs with AI assistance, the win isn’t just that a draft appears faster. It’s whether reading that draft back costs you anything. A style guide built from your own past pull requests, specific rules about contractions, about stating opinions as opinions, about never softening a known gap into a hedge, is a more direct fix than a vague “sound more human” prompt, because it targets the extraneous load directly instead of hoping a friendlier tone happens to remove it.
I think its worth testing on your own writing. Time how long it takes to verify a pull request description an AI generated in its default voice against one generated from a style guide built on your own writing. I’d bet the gap is bigger than it looks on the page. What’s closing it is extraneous cognitive load, the specific, named cost Sweller’s theory already gave us a word for, long before AI showed up to produce more of it.