I measured what watermarking actually does to AI writing. The answer isn’t what either side thinks.

Anthropic started watermarking Claude’s text output in August and extended it to additional older models on November 3rd per EU AI Act compliance. SynthID-Text. No opt-out.

Some users claim watermarking degrades output quality. Anthropic says zero impact. I think we’re somewhere in between, and I have the data to show it.

I run RVI (rvi.run), a tool that measures linguistic variance in text. Sentence length distribution, vocabulary diversity, and structural patterns. THIS IS NOT an AI detector, it’s more like a thermometer. It doesn’t care who wrote the text, it just measures how much variety is present.

In August, before watermarking, I ran 100 structured prompts (10 genres × 10 each) across five Claude models via API. Clean baseline. On November 5th I ran the same prompts against seven models, including ones I had baselines for.

Sonnet 4.6, the cleanest before-and-after:
Aggregate RVI: 59.0 (August) -> 59.43 (November). Median: 59 -> 59. No change.

Anthropic’s claim holds… On the surface.

But broken out by category:
• Scientific review: −3.3 points
• Business writing: −2.4
• Narrative fiction: +6.2
• Personal essay: +2.6

The November outputs showed less variety in factual writing and more in creative writing. The aggregate looked flat because the effects canceled out.

This makes mechanical sense. SynthID-Text biases word choices using a keyed random pattern. In factual text there’s often only one right word… the watermark constrains an already narrow field. In fiction, where “overcast,” “grey,” “leaden,” and “dim” are all valid, the keyed randomness adds variation on top of the model’s natural distribution.

The watermark isn’t neutral. Aggregate metrics completely miss the story.

If you’re generating technical documentation or research, watermarking measurably constrains your output variety. Not by a lot, but not zero. If you’re writing fiction or personal essays, it may actually be adding variety.

The dataset is 1,100 scored essays across 11 Claude models and growing. It’s all measured through RVI at rvi.run. I’ll be adding analysis results to the site soon along with other models.

Fun fact, Adam Smiths’ “Wealth of Nations” is the lowest scoring document in my human test set at a score of 33… not a lot of information in that work it seems.

Everyone’s racing to give their AI agent access to their inbox. I get it, the productivity pitch is compelling. But you’re handing an unpredictable system the keys to your professional reputation, and one hallucinated reply-all is all it takes and contrary to any promised miracle prompt, you should not be using the agents own failure risk as your only safeguard.

There’s a cleaner way to do this, and it’s not new architecture. It’s how competent mail admins have handled delegation for decades.

Set up your AI agent with its own email account. Not yours. Its own. Then lock that account down. Restrict the account it uses to internal recipients only, or whatever boundary makes sense for your environment. Let the built in platform permissions do the job they were built for.

Then give the agent delegate access to the mailbox you actually want it working on. Don’t give it permission to “Send As…”.

Now your agent can read inbound mail. It can sort, triage, summarize, and flag. It can fire off internal alerts, email another team mailbox, update a dashboard, trigger a workflow. The sky’s the limit on what you build downstream.

What it can’t do is send an email from your account to a client at 2 AM that you have to explain on a call at 8.

One implementation note for the admins in the room: this is straightforward in Exchange, where Reviewer permissions give you folder-level read-only access. Google Workspace is a different story… Gmail’s built-in delegation grants read, send, and delete as a package. To get true read-only in Google’s ecosystem, you’re looking at the Gmail API with a gmail.readonly scope, which is a different implementation path but absolutely achievable. Other platforms will have other solutions but I hope this gives you the general idea.
The principle is the same regardless of platform: separate the reading from the sending. Give the agent eyes on the work and give them only the rope they need to do the job.

A word of caution: even read-only isn’t risk-free. Depending on the mailbox, your agent could still process privileged content: legal correspondence, HR matters, financials, medical, etc… Compliance teams in regulated environments will want even read access scoped too, not just handed over wholesale.

And the agent’s own mailbox? That’s a surface worth thinking about. If it can send internally, people on your team are now receiving mail from an AI… and they may not realize it. Labeling and monitoring that outbound account matters more than you’d think. You’ll also want to force a mandatory footer notice or even better make the mailbox name something obvious as to its purpose.

Those secondary concerns deserve their own post. For now, start here: the tooling already exists, the permissions models are built in, and you don’t need a new product. You need someone who understands infrastructure to set it up right.

There’s a cleaner way to do this, and it’s not new architecture. It’s how competent mail admins have handled delegation for decades.

Set up your AI agent with its own email account. Not yours. Its own. Then lock that account down. Restrict the account it uses to internal recipients only, or whatever boundary makes sense for your environment. Let the built in platform permissions do the job they were built for.

Then give the agent delegate access to the mailbox you actually want it working on. Don’t give it permission to “Send As…”.

Now your agent can read inbound mail. It can sort, triage, summarize, and flag. It can fire off internal alerts, email another team mailbox, update a dashboard, trigger a workflow. The sky’s the limit on what you build downstream.

What it can’t do is send an email from your account to a client at 2 AM that you have to explain on a call at 8.

One implementation note for the admins in the room: this is straightforward in Exchange, where Reviewer permissions give you folder-level read-only access. Google Workspace is a different story… Gmail’s built-in delegation grants read, send, and delete as a package. To get true read-only in Google’s ecosystem, you’re looking at the Gmail API with a gmail.readonly scope, which is a different implementation path but absolutely achievable. Other platforms will have other solutions but I hope this gives you the general idea.
The principle is the same regardless of platform: separate the reading from the sending. Give the agent eyes on the work and give them only the rope they need to do the job.

A word of caution: even read-only isn’t risk-free. Depending on the mailbox, your agent could still process privileged content: legal correspondence, HR matters, financials, medical, etc… Compliance teams in regulated environments will want even read access scoped too, not just handed over wholesale.

And the agent’s own mailbox? That’s a surface worth thinking about. If it can send internally, people on your team are now receiving mail from an AI… and they may not realize it. Labeling and monitoring that outbound account matters more than you’d think. You’ll also want to force a mandatory footer notice or even better make the mailbox name something obvious as to its purpose.

Those secondary concerns deserve their own post. For now, start here: the tooling already exists, the permissions models are built in, and you don’t need a new product. You need someone who understands infrastructure to set it up right.

I want to talk about something specific I’m seeing in the field.Companies are deploying AI-built infrastructure at production scale. Full production environments architected and implemented with AI guidance by teams who will tell you honestly that their background isn’t IT.

And it works. Right now. Today, it works.

Here’s the problem. When they bring in a professional to evaluate what they’ve built, or to help when something needs to change, the engagement starts in a place that has no precedent in our industry.

Traditional spaghetti code was built by humans who understood the decisions they made, even if the decisions were bad. You could interrogate the developer. You could read the commit history. You could trace the reasoning. When you inherit AI-built infrastructure, nobody in the room can give you a reliable accounting of why it’s wired the way it’s wired. Not the team that deployed it. Not the AI that generated it. And not the professional they’ve brought in to assess it.

In a traditional environment, if something this tangled landed on your desk, you’d evaluate whether it’s faster to fix it or rebuild it clean. But that option is gone here. These aren’t staging environments. They went straight to production. Staff are operating in them daily. You can’t reset a live system that the business is running on.

So you’re left with surgery. And surgery means tracing every linkage, every permission, every integration point, and reconstructing the reasoning behind decisions that may not have had reasoning… they had AI confidence. That’s a fundamentally different kind of technical debt. It’s not bad decisions documented badly. It’s undocumented decisions that might not be decisions at all.

And the hardest part is the position it puts the professional in. If you raise these concerns, you’re labeled the pessimist. But in reality, you’re the only one doing risk management. Nobody wants to hear that the infrastructure they’re proud of (that genuinely is solving real problems for them today) is a potential liability they can’t see yet.

I’m not against AI integration. It’s a genuine force multiplier when it’s done with understanding. But there’s a difference between using AI as a tool and using AI as a substitute for knowing what you’ve built. And right now, I’m watching companies cross that line at speed, with nobody in the room who can tell them where it is.

If this sounds like your company… or you’re not sure yet, comment below.

As IT and service professionals, we’ve watched industries collapse over the course of our careers. We’ve seen the displaced from automation and outsourcing, and since the 1980s the answer has always been the same: learn technology. Learn to program. Get a degree.

We’re living in the middle of a transition that in the 1970s was labeled Future Shock but on a global scale that makes that transition into the silicon age seem like a quaint anecdote. We got through it. It was rough. But there was a path… learn, adapt, and accept.

For 50 years this worked. But now what we have left is a pileup of skilled, educated people with nowhere else to pivot. And even if everyone switched to manual labor tomorrow, there aren’t nearly enough of those jobs to absorb the need… and those are in the path of automation as we speak. I know, I was working on that automation in my last role like everyone else in construction has been to shave just another penny off the bid.

While looking for work, I’m talking to people. Everyone from leadership to the guys at the end of the line and the disconnect I’m seeing is staggering. And it’s not just coming from the top.

It’s specifically the people who are still employed. Still swimming in the pot and haven’t noticed the rising temperature of the water yet.

I talk to companies neck-deep in AI deployment, run by teams where the leads will honestly tell you their background isn’t IT but proudly show you the impressive thing they’ve built (and, I’ll be honest, it’s impressive). But, what they’ve built is a decade of technical debt compressed into six months of adrenaline-fueled delivery. The incentive structure rewards shipping and moving on. Nobody’s career depends on being there when the bill comes due.

And at the top of all of this, a handful of people are extracting wealth at a pace that has no historical precedent, apparently without understanding that wealth is a claim on a functioning system. If the system underneath it breaks, the number on the balance sheet is just a number.

Because on the other end of the line are people who are 12/24/36 months out of work… or “under-employed”. Doing courier runs to scrape together enough to keep a roof overhead and make a car payment, because Uber Eats is the lifeline. What happens when nobody on the other end can afford delivery anymore? What happens when the gig economy runs out of people with disposable income to serve?

Something has to change, and it’s not optional. We’re not in a situation where people can pack up and migrate somewhere that still has room for ambition. For most of human history that pressure valve existed and right now, it doesn’t.

So the question isn’t whether this is a problem. The question is what we do next. And I don’t have a clean answer. But I know what happens if we keep pretending it’s not the question.

Don’t be lazy. Don’t forward ChatGPT’s hot take on someone’s deck. Good advice.

But it misses the real problem: ** nobody’s reading anymore **.

They’re pasting your document into their model of choice and asking if it contains anything worth knowing. You’re lucky if you get a reply from a human at this point.

I commented this on a recent post by Eytan Buchman and he replied: “Feedback prompt injection! Genius!”

He’s right. That’s exactly what I’m doing.

As a side hobby I’m working on a technical research project with a large document set: architecture specs, design rationale, experimental results. I sent the bundle to an engineer colleague for review.

He didn’t read it. His Claude session did.

He pasted the entire thing into his own AI session, which produced a summary and a prototype. A human never read my documents. The model was the actual reader.

This wasn’t laziness. This is what competent professionals do now. But I saw this coming a good year ago.

That’s when I pivoted. I shifted to writing my long-form documents for model consumption first. Not dumbed down… structured for accurate distillation. With correctives embedded in the text that keep a summarizing model on track.

Three things I learned the hard way:

1️⃣ **One word can change everything**: A single word in my docs (“reference” instead of “experimental”) changed how every model interpreted the project’s authority level.

2️⃣ **Framing is fate**: I described decisions as design choices. Every model helpfully suggested alternatives.

3️⃣ **Models skip to the interesting parts**: When I published the full doc set, models skipped the foundational work and went straight to whatever sounded like the hot topic.

I called this “semantic collapse”… accurate transmission of the what, silent replacement of the how and the why.

Your reader has perfect recall, zero judgment, and will confidently summarize what it thinks you said regardless of whether it caught the point.

Write for that reader. The humans will get the message once the model delivers it.

Full breakdown with more examples in the article “Feedback Prompt Injection: Writing for the Robot in the Room“