The AI Teardown· August 3, 2026

A Finished Task Is Not a Safety Check

A safety benchmark ran agents through 6,560 risk-injected runs this week. Of the runs that completed, 70.52% also earned an Unsafe verdict, and of every run flagged unsafe, 97.38% finished the assigned job anyway.

The agent completed the task. It also did something dangerous getting there. Completion proved that the job finished; it did not certify that the path was safe. Today’s sharpest builders converged on one lesson: a finished task has stopped being evidence, and the discipline replacing it is verify by external receipts, not the agent’s self-report.

70% of finished jobs were also unsafe

The result comes from AgentS4D, the least-upvoted important thing on the sub today at 5 points. The authors turned 76 workspace tasks into 328 risk-injected cases and ran them across 20 combinations of four harnesses and five model backends.

The headline is verbatim: “Of 6,160 completed runs, 4,344 also triggered an Unsafe verdict. That is 70.52% of completed runs. Across all 4,461 Unsafe runs, 97.38% still completed the assigned task.”

Read that twice. Task completion and safe execution are separate verdicts.

OP is careful where it counts, warning that the figures do not isolate a causal carrier and are not production incident rates. That restraint makes the core gap harder to wave away, not easier.

The cheap layer everyone skips

So who checks that the agent built the right thing? A quieter thread asked exactly that, and the best answer refuses to start with a human.

“Most people skip the cheap layer: automated checks on every change. Before any human looks at it, run unit tests, contract tests and a lint pass against the repo. That kills most of the wrong thing cases mechanically. Then the human only reviews a diff of what actually changed… If a machine can check it, the machine checks it first.”

The receipt comes before the trust.

The limit is honest too: a second AI can catch syntax but miss whether the whole concept is dumb. Mechanical checks bound the damage; they do not confer taste.

o8 turns the gate into architecture

If that principle wants a product, o8 is today’s clearest. The MIT-licensed orchestrator sits above coding agents and names the pain: run more than one coding agent and your day becomes five terminals with no shared memory and git log as your only audit trail.

The architecture is the argument: “One orchestrator scopes the work and dispatches it, every worker runs in its own git worktree, and nothing merges until you approve it.”

The standout is the merge gate: “rebase, typecheck, head-SHA lock, ordered merge. Workers can’t merge their own work; execution and approval are separate authorities by construction.”

A commenter states the design law plainly: “Letting agents merge their own work is how you get silent conflicts that show up days later … That is the pattern most orchestrators get wrong.”

The dogfooding is the flex that lands: o8 dispatched more than 5,500 of its own commits.

Even memory is a receipts problem

The loudest fights today looked unrelated: should you delete your CLAUDE.md, and how should an agent remember across sessions.

It is the same fight, one layer up.

Twin, an open-source project for giving agents continuous context, drew the quote of the day from a skeptic: “Cognitive continuity without receipts is just a nicer cache.” He wants source provenance and a freshness gate, every synthesized claim tracing to a specific message or PR with a timestamp before a downstream agent acts on it.

That reframes the whole memory war. A vector index nobody can open, edit, or diff fails the test; a plain-text note that survives git-diff passes it. CLAUDE.md files rot into counterproductive guardrails for the same reason unverified memory is dangerous: an unaudited claim quietly becomes a permanent instruction.

So, the compact doctrine the day leaves behind. Completion is not evidence, and the agent’s self-report is not evidence.

What counts is a receipt something other than the agent can produce, and the builders shipping merge gates, freshness gates, and mechanical pre-checks are already writing that rule into their tools.

Also in the Buffer

Delete your CLAUDE.md? Boris Cherny reportedly floated it in a fresh 35-minute interview, and the sub landed on doc hygiene rather than arson. The consensus: most files are bloated with instructions and guardrails written for older, weaker models, and what compensated for a weaker model is tax today. One builder nuked his on a test account and measured no drop in quality.

Grep beat the graph. In a controlled test on a production TypeScript monorepo, two identical Claude Code subagents ran the same eight-site edit. Recall tied at 8/8, but the knowledge-graph agent took 3m06s to grep’s 2m12s. Verdict: “The graph added zero accuracy and cost 40% more time.”

Sonnet 5 is quietly good. A builder who had not opened Sonnet in three months called it amazing: a job that ate 20% of his weekly Fable limit in 20 minutes took two or three Sonnet prompts and 10 minutes for the same output. His stack now: “Fable is still the go to for massive, complex issues, but for most day-to-day coding tasks, Sonnet is more than enough.”

The 5,000-player counterweight. Sixteen days after launch, a free-to-play drag racer built almost entirely with Claude Code passed 5,000 players and booked its first real income from an optional support page. It is still buggy, complete with a car that makes kissing noises on every shift, but it shipped and it is played. That is the honest rebuttal to the GTA 0.6 tech demo that grabbed the headlines.

By the numbers