Tech

The Code Review Still Assumes a Human Wrote It

July 8, 2026 · Marcus Webb, Out of Control~6 min read

Somebody at Veracode had a good idea: hand the same 80 coding jobs to more than a hundred different AI models, then run the output through a security scanner and count what breaks. The number that came back was 45%. Nearly half the code these things wrote shipped with a hole from the OWASP Top 10 — the short list of ways software gets broken into. That part surprised people. Here's the part that should worry them more: it's been sitting at 45% for a year and change, no matter how many "smarter, safer" models got announced in between.

Half of it comes out with a hole in it

Let's be clear about what got tested, because the number's only useful if you know what it counts. Veracode didn't scrape live production apps. They gave the models a clean, controlled task — write this function — and checked the result against known vulnerability patterns. So 45% is not "45% of shipped code is getting hacked." It's closer to: hand the machine a fresh assignment, and about half the time it hands you back something with a latch left open.

Some latches it leaves open more than others. Against log injection — someone slipping fake lines into your logs — the code failed 88% of the time. Against cross-site scripting, XSS, the classic trick of smuggling a script into a web page, it failed 86%. Those aren't exotic attacks. They're the first two things anybody who's done security work would check for. And the language mattered, a lot. Java came out the worst by a wide margin, blowing the test more than 70% of the time. Python, C#, JavaScript sat lower, in the 38 to 45% range. Not good. Just less bad.

Across 100+ LLMs on 80 real coding tasks, 45% of generated code carried an OWASP Top-10 vulnerability; 88% failed to defend against log injection and 86% against XSS. Java failed over 70% of the time, while Python, C# and JavaScript sat at 38–45% — and the pass rate did not improve through 2025 into early 2026. Source: Veracode, "Spring 2026 GenAI Code Security Update," 2026. Framing: Kevin Kelly, Out of Control. A controlled completion-task benchmark, not a claim about shipped production code; one working engineer's read, not a verdict on any tool.

Why "wait for the next model" won't fix this

Everybody's instinct here is the same: give it a year, the models get better, the number drops. That instinct is the whole problem, and it comes from an assumption nobody says out loud. We built code review around the idea that a careful person wrote the thing. A person is slow. A person writes a few hundred lines a day, on a good day, and gets tired, and asks a coworker. So review became a spot-check — glance at it, trust the human did most of the thinking, catch the odd slip. That model held for forty years because the thing feeding it was a human hand.

Now the hand is a machine that emits more code, faster, than any reviewer can actually read. Kevin Kelly had a name for this decades ago in Out of Control: bottom-up generation outrunning top-down control. You can't inspect a grown system into being safe the way you inspect a machined part. A wristwatch, you can take apart and verify every gear. A garden, you can't — it grows faster than you can check each leaf, so you stop trying to inspect it and you manage the conditions instead. Software just crossed from the watch side to the garden side, and most shops are still holding a jeweler's loupe.

You can't inspect a grown system into safety

When the machine writes faster than any human can read, review stops being a spot-check on a trusted author. It has to become a test you run on the living thing — every time, no exceptions.

Stop trusting the author. Test the living thing.

So here's the shift, and it's not complicated, it's just a different place to put your faith. Old way: you trust the writer, so you glance at the output. New way: you trust nothing about where the code came from, and you test the running system, hard, on every change. That's the immune-system model, and Kelly leaned on it hard — a body doesn't keep itself healthy by having a supervisor inspect each cell as it's born. It grows a system that constantly probes what's already alive and kills what's wrong. You don't grow safety by looking harder at the moment of birth. You grow it around the thing, after, and you keep it running.

In plain shop terms: the security gate can't live in a person's eyeballs anymore. It has to live in tooling that runs on its own — the scanner, the test suite, the checks that fire on every commit whether the author was a person, a model, or your own tired self at 2 a.m. Treat all three the same. Assume none of them left the latches shut. The 45% isn't telling you the code is doomed. It's telling you the reviewer you've been counting on — the careful human upstream — quietly stopped being the one writing the code, and the review never got the memo.

What this means for you Monday morning

If you ship software, do one thing this week: find the place in your process where a human being is the security check, and assume that human is now rubber-stamping machine output they don't have time to read. Because they probably are. Then move the check into something that runs on its own — a scanner in the pipeline, a test that has to pass, a gate that doesn't get tired and doesn't trust the byline. Not because the AI is bad at coding. It's often fast and useful and fine. But fast and useful and fine is exactly the thing that walks a hole right past a tired reviewer at the end of a long day. The tools got faster. The old review didn't. Close that gap yourself, before someone else finds it for you.

Facts from Veracode, "We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests." / "Spring 2026 GenAI Code Security Update" (2026): 100+ models across 80 tasks, 45% carrying an OWASP Top-10 flaw, 86% failing XSS, 88% failing log injection, Java worst at >70%, others 38–45%, flat across 2025 into early 2026. Framing from Kevin Kelly, Out of Control (bottom-up generation outruns top-down control; you grow safety around a living system, you don't inspect it in). Honest limits: 45% is a controlled completion-task benchmark, not a claim that 45% of shipped code is being hacked; this is a fast-moving field and one working engineer's read, not a verdict on any specific tool. AI-written code isn't doomed — the review process is what has to change.

技术

那道代码审查，到今天还默认是个人写的

2026年7月8日 · 陈志远，《失控》约 5 分钟

Veracode 干了件挺聪明的事：把同样 80 个编程任务，丢给 100 多个不同的 AI 模型去写，写完拿安全扫描器过一遍，数数栽了多少。结果出来一个数——45%。这些玩意儿写出来的代码，将近一半带着个 OWASP 十大漏洞里的口子（OWASP 十大，就是软件最常被人从哪儿撬开的一张短名单）。这个数把人吓了一跳。可真该让人后背发凉的是另一头：它在 45% 上卡了一年多，中间不管发布了多少个号称"更聪明、更安全"的新模型，它就是不动。

一半的代码，出来就带着口子

先说清楚它到底测了个啥——这数得知道它数的是什么，才有用。Veracode 没去扒线上跑着的真实应用。它是给模型一个干净、受控的任务："把这个函数写出来"，再拿写出来的结果，比对已知的漏洞套路。所以 45% 不是"上线代码里 45% 正在被人攻破"。它更接近这个意思：你随手给机器派一个新活儿，大概有一半的时候，它交回来的东西上，有个门闩没插。

有些门闩它比别的漏得更狠。日志注入——就是有人往你的日志里塞假记录——它 88% 的时候都挡不住。跨站脚本，XSS，那个把脚本偷偷夹进网页的老把戏，它 86% 的时候也挡不住。这俩不是什么冷门偏招。是任何一个干过安全的人，头两个就会去查的东西。而且看语言，差得还挺远。Java 最惨，甩开一大截，70% 多的时候都栽。Python、C#、JavaScript 低一些，在 38 到 45% 这一带。不是好，是没那么烂。

在 100 多个大模型、80 个真实编程任务上，45% 的生成代码带有 OWASP 十大安全漏洞；88% 挡不住日志注入、86% 挡不住 XSS。Java 失败率超过 70%，Python、C#、JavaScript 在 38–45%——而这个通过率从 2025 一路到 2026 年初都没变好。来源：Veracode，"Spring 2026 GenAI Code Security Update"，2026。框架：凯文·凯利《失控》。这是受控的补全任务基准，不等于"上线代码里 45% 被攻破"；仅一位一线工程师的解读，不是对任何工具的判决。

为啥"等下一代模型"救不了这事

你别看这事，大家的第一反应都一样：再给它一年，模型更强了，这数就掉了。可就是这个反应本身，才是真正的麻烦——它底下压着一个谁都没挑明的假设。我们这套代码审查，从头到尾是围着"这东西是个仔细的人写的"搭起来的。人慢。一个人一天状态好也就写几百行，会累，会去问旁边工位的同事。所以审查就变成了个抽查——扫一眼，信这人脑子里大半的活儿都想过了，逮个把手滑就行。这套模型能撑四十年，是因为喂给它的，一直是一双人手。

现在那双手，换成了一台机器，吐代码的速度，比任何一个审代码的人真能读进去的速度都快。凯文·凯利几十年前在《失控》里就给这事起过名：自下而上的生成，跑赢了自上而下的控制。一个长出来的系统，你没法像验一个车床加工的零件那样，靠"检查"把它检查成安全的。一块手表，你能拆开，每个齿轮挨个验过去。一座花园，你验不了——它长得比你一片叶子一片叶子查还快，于是你干脆不查它了，改去管它的水土光照。软件，刚好就从手表那头，迈到了花园这头；可大多数团队手里，还攥着个珠宝匠的放大镜。

长出来的系统，你没法靠"检查"检查成安全的

机器写得比人读得还快的时候，审查就不能再是对一个可信作者的抽查了。它得变成一道你对着活系统去跑的测试——每一次，一次不落。

别再信作者，去测那个活着的东西

所以要转的这个弯，说白了不复杂，就是换个地方搁你的信任。老办法：你信写代码的人，所以你就扫一眼输出。新办法：代码打哪儿来的，你一概不信，你去狠狠地测那个跑起来的系统，每改一次就测一次。这就是免疫系统那套路子，凯利特别看重它——一个身体保持健康，靠的可不是派个监工，把每个新生的细胞挨个检查一遍。它是长出一套系统，不停地去探那些已经活着的东西，谁不对劲就干掉谁。安全不是靠你在"出生那一刻"看得更狠长出来的。它是你事后，绕着这东西长出来、再一直跑着的。

翻成工地上的话：安全这道关，不能再长在一个人的眼珠子上了。它得长在能自己跑的工具里——那个扫描器、那套测试、每次提交就自动打一遍的检查，不管这次的作者是个人、是个模型、还是凌晨两点累趴下的你自己。这三个，一视同仁。默认谁都没把门闩插好。那个 45% 不是在说这代码没救了。它是在说：你一直指望的那个审查员——上游那个仔细的人——已经悄没声不再是写代码的那个了，可你那道审查，压根没收到通知。

这事儿周一早上对你意味着啥

你要是也发软件，这周就干一件事：找出你流程里、那个"由一个人来当安全关卡"的地方，然后假设这个人现在就是在给他根本没时间读的机器输出盖橡皮章。因为他多半就是。找到了，就把这道关挪进一个能自己跑的东西里——流水线上的扫描器、一道必须过的测试、一个不会累也不认署名的闸门。不是因为 AI 写得烂。它常常又快又好用，挺行的。可就是这个"又快又好用挺行的"，最容易在长长一天的末尾，从一个累坏了的审查员眼皮底下，把一个口子大摇大摆地放过去。工具变快了，那套老审查没变。这道缝，你自己先把它合上，别等着让别人替你找出来。

数据出自 Veracode "We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests." / "Spring 2026 GenAI Code Security Update"（2026）：100 多个模型、80 个任务，45% 带 OWASP 十大漏洞，86% 挡不住 XSS，88% 挡不住日志注入，Java 最惨超过 70%，其余 38–45%，2025 到 2026 年初一路没变好。框架取自凯文·凯利《失控》（自下而上的生成跑赢自上而下的控制；安全是绕着活系统长出来的，不是靠检查检查出来的）。诚实的边界：45% 是受控的补全任务基准，不等于"上线代码里 45% 正在被攻破"；这是个快速演进的领域，也只是一个一线工程师的看法，不是给哪个具体工具下判决。AI 写的代码不是没救——要变的是那套审查流程。

テクノロジー

あのコードレビューは、いまだに「人間が書いた」前提なんです

2026年7月8日 · 藤井亮、『コントロールの喪失』約 7 分

Veracode がなかなか面白いことをやりました。同じ 80 個のコーディング課題を、100 以上の違う AI モデルに書かせて、出てきたコードをセキュリティスキャナに通して、いくつ壊れるか数えたんです。返ってきた数字が 45%。こいつらが書いたコードの半分近くが、OWASP トップ10 の穴を一つ抱えて出てきた（OWASP トップ10 っていうのは、ソフトがどこから破られやすいかの短いリストです）。ここまでで、みんな驚いた。でも本当に背筋が寒くなるのはその先で——この 45%、一年ちょっとずっと動いていないんですよね。間にどれだけ「より賢く、より安全」な新モデルが発表されても、です。

半分は、穴を開けたまま出てくる

まず、何を測ったのかをはっきりさせておきます。この数字は、中身を知らないと使いようがないので。Veracode は、本番で動いてるアプリを漁ったわけじゃない。モデルにきれいな、制御された課題を渡して——「この関数を書いて」——出てきた結果を、既知の脆弱性のパターンと突き合わせた。だから 45% は「本番コードの 45% が攻撃されている」じゃないんです。もっと近いのは、機械に新しい仕事を一つ渡すと、だいたい半分の確率で、掛け金の外れたものが返ってくる、という話。

で、外れやすい掛け金と、そうでもないのがある。ログインジェクション——誰かがあなたのログに偽の行を紛れ込ませるやつ——に対しては 88% の確率で防げなかった。クロスサイトスクリプティング、XSS、あのスクリプトをこっそりページに忍ばせる古典的な手に対しては、86% の確率で防げなかった。どっちも珍しい攻撃じゃないです。セキュリティをやった人なら、最初に見る二つ。それに、言語でずいぶん違った。Java がぶっちぎりで最悪で、70% 超で失敗する。Python、C#、JavaScript はもう少し低くて、38〜45% あたり。良いんじゃなくて、まだマシ、なだけ。

100 以上の LLM を 80 の実際のコーディング課題で試すと、生成コードの 45% が OWASP トップ10 の脆弱性を持ち、88% がログインジェクションを、86% が XSS を防げなかった。Java は 70% 超で失敗し、Python・C#・JavaScript は 38〜45%——そしてこの通過率は 2025 年から 2026 年初頭まで改善しなかった。出典：Veracode「Spring 2026 GenAI Code Security Update」2026。枠組：ケヴィン・ケリー『コントロールの喪失』。これは制御された補完課題のベンチマークであり、「本番コードの 45% が攻撃される」という話ではない。現場の一エンジニアの読み方であって、特定のツールへの判決ではない。

「次のモデルを待てば」では直らない理由

ここでみんなの直感は同じで——あと一年もすればモデルが賢くなって、この数字も下がるだろう、と。でも、その直感そのものが問題の正体なんです。しかも、誰も口に出さない前提の上に乗っている。僕らのコードレビューは、「これは慎重な人間が書いたもの」という考えの上に組み上げられてる。人間は遅い。一人が一日に書くのは、調子がよくても数百行で、疲れるし、隣の人に聞いたりする。だからレビューは抜き取り検査になった——ざっと見て、人間が大半は考えたはずだと信じて、たまの手滑りを拾う。この形が四十年もったのは、それを支える手が、人間の手だったからなんですよね。

今、その手が、レビュアーが実際に読める速さより速くコードを吐く機械に変わった。ケヴィン・ケリーは何十年も前に『コントロールの喪失』でこれに名前を付けています。ボトムアップの生成が、トップダウンの制御を追い抜く、と。育った系は、旋盤で削った部品みたいに「検査」で安全にはできないんです。腕時計なら、分解して歯車を一つずつ確かめられる。庭は、できない——葉っぱを一枚ずつ調べるより速く育つから、検査するのをやめて、代わりに水や日当たりを管理する。ソフトはちょうど、腕時計側から庭側へ渡ったところ。なのに大半の現場は、まだ宝石屋のルーペを握ったままなんですよね。

育った系は、「検査」で安全にはできない

機械が人間の読める速さより速く書くなら、レビューはもう、信頼できる作者への抜き取り検査ではいられない。生きているものに対して毎回走らせるテストに、なるしかないんです。一度も欠かさず。

作者を信じるのをやめて、その生きているものをテストする

だから切り替えるべきはここで、正直こみ入った話じゃなくて、信頼を置く場所を変えるだけなんです。昔のやり方：書いた人を信じるから、出力をざっと見る。新しいやり方：コードがどこから来たかは一切信じないで、動いている系を、毎回の変更ごとに、きつくテストする。これが免疫系のモデルで、ケリーはここをすごく重視した——体が健康を保つのは、監督者が生まれてくる細胞を一つずつ検査するからじゃない。すでに生きているものを絶えず探って、おかしいやつを殺す系を、育てるからなんですよね。安全は「生まれる瞬間」をきつく見て育つものじゃない。あとから、そのものの周りに育てて、走らせ続けるものなんです。

現場の言葉に直すと：セキュリティの関所を、もう人の眼球に置いておけない。自分で走る道具の中に置くしかないんです——そのスキャナ、そのテスト群、コミットのたびに自動で回る検査。今回の作者が人でも、モデルでも、深夜二時に疲れ果てた自分でも、同じ。三つとも同じ扱いで。誰も掛け金を締めていない前提で。あの 45% は、コードがもう駄目だと言ってるんじゃない。あなたがずっと頼りにしてきたレビュアー——上流のあの慎重な人間——が、いつのまにかコードを書く人じゃなくなっていて、しかもレビューの方には、その連絡が届いていなかった、と言ってるんです。

月曜の朝、これがあなたに何を意味するか

もしあなたがソフトを世に出す側なら、今週ひとつだけやってください。自分たちの工程の中で、一人の人間がセキュリティの関所になっている場所を見つけて、その人はいま、読む時間もない機械の出力に判子を押しているだけだ、と仮定する。たぶん、実際そうなので。見つけたら、その関所を、自分で走る何かの中へ移す——パイプラインのスキャナ、通らないと進めないテスト、疲れないし署名も信じない関所へ。AI がコードが下手だから、じゃないんです。たいてい速くて、役に立って、ちゃんとしてる。でもその「速くて役に立ってちゃんとしてる」こそが、長い一日の終わりに、疲れたレビュアーの脇を、穴を一つ堂々と通り抜けていくものなんですよね。道具は速くなった。昔のレビューは、なっていない。その隙間は、誰かに見つけられる前に、自分で塞いでおきましょう。

データは Veracode「We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests.」／「Spring 2026 GenAI Code Security Update」（2026）から：100 以上のモデル・80 の課題、45% が OWASP トップ10 の欠陥を持ち、86% が XSS を、88% がログインジェクションを防げず、Java が最悪の 70% 超、他は 38〜45%、2025 年から 2026 年初頭までずっと横ばい。枠組はケヴィン・ケリー『コントロールの喪失』から（ボトムアップの生成がトップダウンの制御を追い抜く；安全は生きた系の周りに育てるもので、検査で入れるものではない）。誠実な限界：45% は制御された補完課題のベンチマークで、「本番コードの 45% が攻撃されている」ではない。動きの速い分野の、現場の一エンジニアの読み方であって、特定のツールへの判決ではありません。AI が書いたコードが駄目なのではなく、変わるべきはレビューの工程なんです。