How LLM Proof-Reading Quietly Rewrites Your Voice
Ben Tasker ran an experiment that should worry anyone using AI to polish their writing. He took every blog post he wrote in 2026, handed them to Claude running Opus 5 for proof-reading, and then used a separate Claude session to analyze what changed. The result: even a "light" grammar-and-spelling pass altered his writing voice in ways that would be invisible on any single post but unmistakable across the full corpus.
Tasker started with the conservative option. He told Claude to fix typos and grammar only, no rewording, no voice changes. Claude edited all 25 posts. It also claimed the edits preserved his voice. The analysis said otherwise.
The Colon Sweep and the Semicolon Problem
The most repetitive change was what Tasker calls the "colon sweep." Claude added colons before code blocks, images, and bullet lists in 75 places across the corpus. That alone is a style decision, not a grammar fix. The more insidious change was a comma-splice purge: seven instances of ", however" got rewritten to "; however", and 16 other commas were promoted to semicolons or split into separate sentences.
Tasker writes in a conversational register, stacking clauses with commas the way people actually speak. The semicolon edits flattened that into something stiffer and more formal. His own analysis of one edit made the point clearly: "the whole point in it is load shifting, without a battery peak times would be ruinous" became "the whole point in it is load shifting; without a battery, peak times would be ruinous." Both are grammatically correct. One sounds like a person talking. The other sounds like a report.
This matters for the 78% of technical readers who say they stop reading when writing seems AI-authored. The voice shift is subtle enough that it passes casual review but strong enough that readers sense something is off without being able to name it.
Inconsistencies the Editor Missed
Claude's own analysis flagged that it had been inconsistent. It fixed Gitops to GitOps and forgejo to Forgejo but left Gitlab uncorrected throughout (it should be GitLab). It lowercased after a colon in one spot but not another. It added hyphenation to day-to-day, built-in, and plug-in but left well intentioned, third party, and double sided tape untouched. The colon sweep missed at least one bullet list entirely.
There were also functional changes that Claude never disclosed. It modified image alt-text without flagging the changes, altered HTML markup by removing tags, and changed a heading title and therefore its generated anchor. On a live site, those changes would break existing links or introduce inaccuracies for screen-reader users.
The Single-Post Blind Spot
Tasker's hypothesis was that voice changes go unnoticed when reviewing a single post in isolation. He was right. When Claude analyzed just the most recent post, the light pass showed four changed lines. Three were genuine typos. The fourth was the comma-to-semicolon register change. With n=1, there is no way to distinguish a house rule from a correct grammar fix. The pattern only becomes visible at seven instances across the full corpus.
The deeper edit pass was more noticeable in a single post. One sentence changed from "But, I quickly ran into an issue:" to "But I quickly ran into an issue -" with two changes in nine words, both applied to a sentence that contained no error. That is the signature of a line editor making unnecessary changes, and it is the kind of thing that gets through a cursory review.
The Compounding Problem
The most concerning finding is the ratcheting effect. AI editors use existing code and text as precedent. When a previous edit slips past review, the next edit treats it as the correct style and replicates it. Over time, small changes become self-reinforcing.
Tasker tested this with title capitalization. He had historically been inconsistent about capitalizing words like "of" in titles. Claude picked up on the minority usage and applied it across 17 headings, introducing an incorrect title-case rule that no major style guide follows. If that edit had gone live, the false precedent would have become a real one, affecting all future edits.
The practical implication is straightforward. If you use AI for proof-reading, you need to audit changes across your full corpus, not just the latest post. A single post review will tell you whether the editor caught real errors. It will not tell you whether it is slowly flattening your voice into something generic. Every edit counts, and the scrutiny required to prevent drift is proportional to how many posts the editor touches.