What the telemetry says

Faros AI published an engineering report built on two years of telemetry from 22,000 developers across more than 4,000 teams. Not a survey about how AI feels, but workflow data before and after AI adoption inside the same organisations.

The delivery side improved:

• task throughput per developer up 33.7%
• epics completed up 66.2%
• pull request merge rate up 16.2%

The review side moved differently:

• median time a pull request sits in review up 441.5%
• average review time up 199.6%
• median time to first review up 156.6%
• daily pull request contexts per developer up 67.4%

Two numbers in the same report describe what happens when that pressure has nowhere to go:

• pull requests merged without any review up 31.3%
• incidents-to-PR ratio up 242.7%

So teams write more, and the queue in front of the reviewer grows faster than the queue behind the author. Some of that queue gets resolved by not reviewing at all, and the incident numbers follow.

What developers say about it

Sonar's State of Code Developer Survey, published in January 2026 with more than 1,100 developers, adds the human half:

• 96% do not fully trust that AI-generated code is functionally correct
• only 48% always check AI-assisted code before committing
• 38% say reviewing AI-generated code takes more effort than reviewing code written by a colleague
• AI accounts for 42% of committed code

Read the first two together and you get the shape of the problem. Almost nobody trusts the output, and barely half of them verify it. The trust gap does not turn into review work automatically. It turns into review work for the people who have the discipline or the responsibility, and into risk for everybody else.

That 38% is the number I recognise most.

Why checking is more expensive than writing

When you write code yourself, the mental model builds as you go. By the time the last line is in place you already hold the reasons behind every decision, including the ones you rejected. Review is not that. Review is reconstructing a model backwards from a finished artefact, without the discarded branches, without the moment where the author decided this approach was worth it.

That is expensive with a colleague's code, and it is more expensive with a model's code, because a model produces plausible work uniformly. A colleague signals uncertainty. Their commit message hedges, they leave a comment, they ping you about the part they are unsure of. Generated code arrives with the same confident surface everywhere, so the reviewer has no gradient to follow and has to give every section the same level of attention.

Add the context switching. A 67.4% increase in daily pull request contexts means the interruptions do not just multiply, they arrive on someone else's schedule. Work that runs on its own still comes back to you, and it comes back at a moment you did not choose. Each return costs the reload of a context you had already put down.

What this looks like on a small team

I build a product mostly by myself, with agents doing a growing share of the mechanical work. Automation ate the typing. It did not touch the checking, and it multiplied the number of things waiting to be checked.

I still cannot take a result from a model and send it to production without looking at it. Not once has that felt safe. So a layer of review always stays, and that layer is where the day actually goes. I have used AI coding tools for a long time, but the load only became obvious once individual completions turned into a set of automations running in parallel. The bottleneck stopped being how fast I write and became how fast I can rebuild context for work I did not do.

I do not have a clean set of rules that solves this. The things that visibly help me are unglamorous:

• smaller units of generated work, because review cost grows faster than diff size
• fewer parallel threads, even at the cost of throughput, because each extra thread taxes every other one on return
• tests written before generation, so a chunk of verification runs without me holding the whole model in my head
• treating "I do not understand why this works" as a blocking result, not a stylistic complaint

None of that closes the gap. It moves it a little.

The part worth arguing about

The industry conversation is still mostly about generation quality, on the assumption that better models shrink the review burden. The telemetry suggests review load is not a bug in current model quality but a structural property of delegating work you remain accountable for. Even at high accuracy, someone has to hold responsibility, and holding responsibility means rebuilding context.

That is why the productivity number and the review number in the Faros report should be read as one result and not two. Throughput up a third, review time up more than four times over. If your planning captured the first number and not the second, your team is absorbing the difference somewhere: in senior engineers' evenings, in merges nobody looked at, or in the incident count.

Where does your review time actually go, and what have you changed to make it survivable?

Sources: Faros AI, "The AI Engineering Report 2026: The Acceleration Whiplash" (telemetry from 22,000 developers across 4,000+ teams). Sonar, "State of Code Developer Survey 2026" (1,100+ developers, published January 8, 2026).

My first thought was that this is very hard to do in a way that actually holds. Text has no pixel layer to hide anything in. So I read how Anthropic plans to do it — and dug into how text watermarks work in general. The honest answer: it works, and it also breaks in a lot of ordinary situations.

How do you even hide a mark in plain text?

There are three generations of this idea. (A good breakdown of the mechanics went viral this week in a thread by ML engineer Daria Berezhnaia — I'm borrowing her framing for the first two.)

Zero-width Unicode. The ancient way: invisible characters tucked between words. Paste the text into Notepad and copy it back out — the mark is gone. Nobody serious uses this anymore.

Token-level (statistical) watermarking. When the model generates text, many word choices are near coin-flips: "the cat sits" vs "the cat lies" might both be ~50% likely. A secret key decides which of the equally-probable options the model picks, again and again across the text. Where the model is confident — 90% one option — the choice is left alone, so quality barely suffers. A detector with the key checks whether word choices are "skewed" in the right pattern. This is the academic classic (green/red token lists), and Anthropic's "embedded in the text itself" wording points this way.

Embedding-space watermarking. The subtler one. Inside the model, every step produces hidden states — vectors that trace how the model "thought". You can nudge those vectors slightly in a secret direction; word choices shift almost imperceptibly, nothing visible at the text level, but the statistical fingerprint is there. Research is now pushing this toward semantic clusters, precisely so that paraphrasing won't wash the mark out.

Where it stops working

Taken mostly from Anthropic's own documentation, plus what follows from the mechanics:

• Short text. Their wording: a very short passage leaves "too little text for a reliable signal". A mark spread across word choices needs volume, so a headline, a chat reply or a commit message is out of reach.
• Editing. Heavy editing, paraphrasing, translating, or mixing the output into your own writing all thin the signal out until it is gone.
• Older models, until the transition period for pre-August releases finishes.
• Screenshots and format conversion, which strip file metadata completely.
• Only the vendor can check. The key is secret, so there is no independent verification: Anthropic tells you whether Claude touched a text; you cannot audit the claim, and false positives on short "skewed-looking" text are a real statistical possibility. The detection tooling and its documentation haven't even shipped yet.

The part I did not expect

A detected mark says Claude processed the text, not that Claude wrote it. Anthropic states this plainly. Proofreading, translating and summarising leave the same mark as generating from scratch. I dictate my posts and run them through a model to fix grammar, so the thinking is mine and the mark would be there anyway.

Read it the other way and it is no stronger. No mark found proves nothing.

So the people this catches reliably are the ones who paste raw output and change nothing. Anyone who edits carefully, translates, or runs the text through a second model comes out clean — today there is no second embedding-space mark to replace the first one, and even when every lab ships one, each key stays locked in its own vault.

The voice side has the same hole — plus one more

OpenAI's audio watermarking repeats the pattern: their Verify tool answers one question — whether audio was "made by OpenAI" — not who authored the words. And voice adds its own escape hatch: the moment marked audio is transcribed to text, the audio watermark is gone. Speech-to-text is the analog hole of voice provenance.

So is it pointless?

I do not think so. A weak provenance signal beats no signal, someone had to move first, and Anthropic published the limitations instead of burying them. It just cannot carry the weight people will want to put on it, which is proof of who wrote something.

Would you want your own writing marked because you asked a model to fix your commas?

Sources: Anthropic — How Claude marks AI-generated content · thread on watermark mechanics by @dariadsss · OpenAI adds SynthID to GPT-Live voice · token-level watermarking: Kirchenbauer et al., "A Watermark for Large Language Models" · embedding-space: PASA, SimMark

Originally published on dev.to. I'm Aleksei, a software engineer. I dictate most of what I write.