Tech

AI Makes Code Review Harder, Not Easier

July 12, 2026 · Marcus Webb~7 min read

Jellyfish surveyed 812 senior engineers and found that code churn — lines written then deleted within two weeks — went up 39% on AI-assisted teams. Seventy-five percent of tech leads expect medium-to-heavy technical debt within twelve months. Thirty-four percent of developers say their career path is now unclear. Productivity went up. Something else went with it. That something is the cognitive cost of reading what the machine wrote.

30-second takeaways

Writing code is encoding; reviewing AI code is decoding — and decoding always costs more, information-theoretically speaking.
Code churn grew 39% on AI-assisted teams. Seventy-five percent of tech leads expect significant debt within a year.
The burnout isn't from longer hours. It's from the specific mental work of verifying output you didn't build.
The fix isn't less AI. It's an honest count of where the cognitive work actually went.

1NEW NORMAL

After AI arrived, a developer's day quietly changed shape

The tools shipped the promise. The calendar kept the receipts.

Before AI coding assistants, an engineer's day had a rhythm you could recognize. Read the ticket. Sketch the approach. Type it out line by line, run the tests, argue with a colleague about the PR. Writing was most of the time, and the writing was also thinking. The code in your head and the code in the file were working the same problem at the same time. You knew why every line existed because you put it there.

That rhythm broke. In 2026, on an AI-heavy team, the session opens differently: type a description into the chat, wait thirty seconds, receive three hundred lines. Generation is now nearly instant. What expanded to fill the recovered time is not rest. It is review. Not the quick scan you do of your own work — where you know what every variable does and why it's there. The slower kind. Someone else's logic, written fast, in a style you didn't pick, for a problem the machine only half-understood from your prompt. Evil Martians documented exactly this shift in 2026: the job description for senior engineers at AI-heavy shops quietly rewrote itself. The headline number — ten-times productivity — stayed in the pitch decks. The footnote — "and now you review ten times as much unfamiliar code per day" — did not.

The bottleneck moved from generation to verification. The tooling, the process, and the headcount never got the memo.

2INFO THEORY

Reviewing AI code is harder than writing code — not a feeling, a mathematical fact

Wu Jun's The Beauty of Mathematics gives us the words for what's actually happening here.

Shannon's information theory draws a line between two things. Encoding: you already understand a message, and you write it out in a symbol system. Decoding: you receive a string of symbols and reconstruct meaning you didn't already have. Encoding starts with comprehension. Decoding ends with it — maybe. These are not symmetric operations. To decode something new, you have to independently reconstruct the full context. You can't just check the symbols. You have to rebuild the world those symbols refer to.

Writing code is encoding. You have the problem model in your head. You translate it, step by step, into the symbol system the compiler reads. Each line costs roughly one unit of externalizing something you already understand. Reviewing AI-generated code is decoding. The AI had a problem model — assembled imperfectly from your prompt — and translated it into symbols. To check whether those symbols are right, you can't just read them. You have to build an independent problem model and compare. That reconstruction is not cheaper than the original encoding. In most cases it's more expensive, because you're doing it defensively — against output that may contain plausible-looking errors you have no memory of putting there.

Here's the thing. Reading and verifying a 100-page math proof takes about as long as devising it in the first place, sometimes longer. The proof is sitting right there on the page, complete, but to trust it you have to re-derive it in your head. Same asymmetry, AI-generated code. The machine wrote fast. The person checking cannot take shortcuts the machine never needed.

Writing your own codeEncoding — you already hold the problem model

Reviewing AI codeDecoding — must reconstruct the model independently

Cognitive cost ratioDecoding ≥ Encoding in almost every information-theoretic analysis

3TECH DEBT

When 39% of the code is "AI churn," it stacks into one large future invoice

Speed on the front end doesn't disappear. It defers.

Code churn is a proxy for code written before the problem was fully understood. Developer writes a function, realizes it's wrong, deletes it within two weeks — that's churn. Every project has it, at some baseline rate. Jellyfish found AI-assisted teams were churning 39% above baseline. The most plausible explanation isn't that AI writes bad code in an obvious way. It's that AI writes code that looks correct, passes the quick scan, gets merged, and then surfaces its flaw two sprints later when it runs into a piece of context the model didn't have. By then, the original code is woven into four downstream modules. Unwinding it is expensive.

Jellyfish Developer Productivity Report 2026 · Code churn grew 39% with AI-assisted teams; 75% of tech leads expect medium-to-heavy technical debt within 12 months; 34% of developers see no clear career path—and 32% are considering leaving the field entirely.

The 75% debt prediction from tech leads is the other shoe. They're not predicting bad code exactly — they're predicting code nobody fully understands, accumulating faster than any team can refactor. The debt isn't in the syntax. It's in the missing mental model. Every function merged without a human who built the understanding from scratch is a future incident waiting for the right context collision to set it off. At 39% higher churn rates, you're not just shipping more features. You're minting more future surprises per sprint than your incident-response team was ever sized for.

4WHAT THIS MEANS

The answer isn't less AI — it's an honest accounting of where the real work went

A hammer that doubles your nail rate also doubles the inspection time. You'd plan for that. Plan for this.

The diagnosis here is not "AI bad, go back to typing everything yourself." The speed is real. It matters. What happened is that the speed got measured and celebrated, while the cognitive transfer — from building to verifying — went largely unpriced. That gap is now showing up as burnout numbers, churn rates, and tech lead anxiety about debt. The useful response isn't a moral position on AI. It's a process question: what does it actually cost to absorb AI-generated code into a codebase you can reason about, and are you putting that cost anywhere in the budget?

Three adjustments make a real difference immediately. First, treat review time as load-bearing work, not overhead. The review at the end of the sprint, speed-run before the Friday deploy, is exactly where the 75% debt prediction comes from. If AI generates in minutes what used to take hours, those hours didn't go away. They moved to the review column. That column needs real time blocked for it. Second, keep at least one human who built the mental model from scratch on every significant piece of AI-generated code. That person is not a bottleneck. They are the link between the code in the repo and an actual understanding in a human brain. Without that link, you own code nobody can reason about when something breaks at 2 a.m. Third, track churn and treat rising churn as an early-warning signal, not just a velocity number. Churn that outpaces your review capacity is technical debt accruing at exactly the pace it takes to become unmanageable. The 39% figure is an average. Some teams are already past the point where catch-up is affordable.

The real ask is not harder work or fewer tools. It's honest work: count the cognitive cost of what you're doing, budget it deliberately, and stop calling verification overhead when it's actually the job. Wu Jun's point in The Beauty of Mathematics is that information has a cost arithmetic can describe but intuition frequently undercounts. In the AI-coding context, the undercounted item is not the tokens generated. It is the independent semantic reconstruction every reviewer must perform on every function they didn't write. That cost is, by information theory, at least as large as the original generation, and in practice often larger. You don't fix a wobbly table by sanding the top.

Ten-x code generation at thirty-percent review coverage is not a productivity gain. It's a scheduled debt payment wearing a costume.

Price the decoding. It doesn't go away because no one put it in the sprint plan.

取材：吴军《数学之美》（Shannon 信息论部分）；Evil Martians《AI-assisted engineers are burning out》（2026）；Jellyfish 开发者生产力报告（2026）；数据以原报告为准。

技术

AI 让代码审查比写代码更累

2026 年 7 月 12 日 · 陈志远约 6 分钟

🎧 听播客版 AI 朗读0:00 / 5:30

Jellyfish 调了 812 个高级工程师，结论是：用 AI 辅助写代码的团队，代码 churn——就是写完两周内又删掉的那些行——比基准高了 39%。75% 的技术负责人觉得未来 12 个月内技术债能累积到中到重级。34% 的程序员说职业路径现在看不清了。生产力是上去了没错。但有个东西也跟着上去了，没人在 PPT 里提——那就是读机器写的东西，累。

30 秒读懂

写代码是主动编码；审 AI 代码是防御性解码——信息论上，解码永远比编码更贵。
AI 辅助团队代码 churn 增长 39%；75% 技术负责人预期一年内积累出显著技术债。
倦怠不是来自工时加长，而是来自验证"自己根本没写的代码"这件事的特定认知消耗。
解法不是少用 AI，而是诚实地核算认知工作究竟转移到了哪里。

1新常态

AI 来了以后，程序员的一天悄悄换了形状

工具兑现了承诺。日历把账单收好了。

以前没有 AI 助手那会儿，工程师的一天有个能认出来的节奏：看工单、想方案、一行一行敲出来、跑测试、跟同事为 PR 吵架。写代码吃掉了大部分时间，而写代码这件事本身就是在想问题。脑子里的逻辑和编辑器里的代码，是同一个东西的两个面，同时往前走。每行为什么在那里，你门儿清——你自己放的嘛。

这个节奏断了。2026 年，在重度依赖 AI 的团队，一天的开场变了：打开聊天框，描述一下需求，等半分钟，收到三百行。生成快得像变魔术。那省出来的时间干嘛了？不是休息。是审代码。而且不是你看自己写的那种——变量叫什么、为啥在这你全知道，扫一眼完事。是那种慢的、费劲的：别人的逻辑，写得很快，风格不是你定的，解决的是机器从你那个 prompt 里七拼八凑理解的问题。Evil Martians 2026 年把这事记了下来：AI 重度团队里，高级工程师的活儿悄悄改写了。PPT 里还是"效率提升十倍"。脚注里该写的"每天还要审十倍陌生代码"，没有。

瓶颈从生成挪到了验证。工具、流程、人手，一个都没跟过来。

2信息论

审查 AI 代码，比自己写代码更累——不是主观感受，是数学事实

吴军《数学之美》里有个框架，正好说的就是这事。

香农信息论把两件事分开说：编码——你脑子里已经有个意思，把它翻译成一套符号；解码——你收到一串符号，从里面把意思还原出来。编码从理解出发，解码以理解收尾，前提是能成功。这俩不是对称的操作。解码一条新信息，你得从头独立地重建整个上下文，光核对符号不够用，你得把那些符号背后的那个"世界"重建出来。

说白了：写代码是编码。你脑子里已经有问题的模型了，你只是一步一步把它翻译成编译器能看懂的语言。每写一行，消耗的不过是"把你本来就懂的东西表达出来"那点功夫。审 AI 生成的代码是解码。AI 有个问题模型——从你那个 prompt 七拼八凑来的，不完整——它把那个模型翻译成了符号。你要验证这些符号对不对，光读是不够的，你得自己独立建一个问题模型，再来跟它对。这个重建过程，不比当初写代码便宜。多数情况下更贵——因为你是在防御状态下干这件事，对着可能混有"看起来没问题"的错误的代码，而那些错误不是你放进去的，你脑子里没有任何线索。

数学里有个老比方：验证一篇一百页的证明，花的时间跟自己从头推出来差不多长，有时候还更长。证明已经完整摆在纸上了，但你要信任它，就得在脑子里重走一遍。AI 代码也一样。机器写得飞快，但来验证它的人，绕不过机器从来不需要走的那些弯路。

自己写代码编码——脑子里已经有问题的模型

审 AI 代码解码——必须独立重建问题模型

认知成本比解码 ≥ 编码，在几乎所有信息论分析中

3技术债

当 39% 的代码是"AI churn"，它会打包成一张大账单

前端省下来的时间没消失——它是分期付款，账单在后头。

代码 churn，说白了就是"问题还没整明白就写出来的代码"的代理指标。你写了个函数，发现写错了，两周内删掉，这就叫 churn。哪个项目都有这个，有个基准率。Jellyfish 发现 AI 辅助团队的 churn 比基准高了 39%。最合理的解释不是 AI 明摆着写出了烂代码——而是 AI 写的代码看起来没问题，过了快速扫视，合并进去了，然后等两个 sprint 后，碰到一块模型当初没有的上下文，问题才冒出来。那时候那段代码已经钩进了四个下游模块，拆起来很贵。

Jellyfish 开发者生产力报告 2026 · 代码 churn 在 AI 辅助团队中增长 39%；75% 技术负责人预期 12 个月内出现中重级技术债；34% 开发者看不到明确晋升路径——32% 考虑转行。

75% 技术负责人的债务预测是另一只鞋落地。他们预测的不完全是"坏代码"，而是没人完全弄明白的代码，以比任何团队能重构的更快速度堆起来。债不在语法里，在缺的那个心智模型里。每一个被合并进去、却没人从头真正搞懂的函数，都是一颗定时炸弹，等着合适的上下文碰到它的那天。churn 高出了 39%，你不只是在更快交付功能，你是在每个 sprint 制造更多的"未来惊雷"——比你的事故响应团队从一开始估算的要多得多。

4这对你意味着什么

不是少用 AI，而是诚实核算认知工作转移到了哪里

电锯让你锯木头快了一倍，验收那块你还是得认真量——这钱省不了。

这里的结论不是"AI 不好，回去自己一行行敲"。速度是真的，而且很重要。问题是：速度被量了、被表扬了，而那个认知工作的转移——从自己建东西变成防御性地验别人的输出——没人核算过。这才是倦怠数字、churn 率、技术负责人焦虑的根。有用的回应不是站道德立场说 AI 好不好。是个流程问题：把 AI 写的代码消化进你能讲清楚的代码库，这实际上要花多少钱，你算进去了吗？

三件事能马上见效。第一，把审查时间当承重墙，不是边角料。sprint 末尾、周五下午赶着部署前快速过一遍——那种审查，正是 75% 债务预测的来源。AI 几分钟搞定以前几小时的活，那几小时没消失，它们挪到了审查那一列，那一列得排真实的时间块。第二，每一块有分量的 AI 代码，至少留一个人是从头真正搞明白过的。那个人不是瓶颈，他是代码和"有人理解这段代码"之间的那根线。没这根线，凌晨两点出事你手里就是一堆没人能看懂的文件。第三，追踪 churn，把 churn 上涨当预警，不只是速度数字。超出审查能力的 churn，是在以"刚好能让你来不及管"的速度堆债。39% 是平均数，有些团队已经过了能追上来的那个点。

你别看这事像是在加班或者少用工具，其实都不是。就一件事：诚实。把认知成本算清楚，有意识地排进预算，别再把验证叫"开销"——它就是这份工作本身。吴军在《数学之美》里说的是，信息有个成本，算术能描述它，直觉老是低估它。在 AI 写代码这事上，被低估的不是生成了多少 token，是每个审查者对每一个他没写的函数要独立重建语义——这个成本，信息论上至少和原始生成一样大，实践里往往更大。图啥？省了打字的时间，多出来一倍验证的账单，这买卖你得算清楚。

30% 审查覆盖率下实现十倍代码生成——那不叫生产力提升，那叫伪装成效率的分期付款。

解码的成本算进去。没人写进 sprint 计划，不代表这笔账消失了。

テクノロジー

AIはコードレビューをコードを書くより難しくした

2026年7月12日 · 藤井亮約 10 分

Jellyfish が812名のシニアエンジニアを調べたら、こんな数字が出てきました。AIアシスタントを使うチームでは、コードチャーン——書いてから2週間以内に消えたコード行——がベースラインより39%増えていた。テックリードの75%は「12ヶ月以内に中〜重度の技術的負債が積み上がる」と見ており、34%の開発者はキャリアパスが見えなくなったと言う。生産性は上がった。それは本当です。でも一緒に上がってしまったものがあって、それがピッチデッキには一切出てこない——機械が書いたものを読み解くコスト、です。

30秒で読む

コードを書くことは能動的な符号化であり、AIコードをレビューすることは防御的な復号化だ——情報理論的に、復号は常により高コストになる。
AI支援チームではコードチャーンが39%増加。テックリードの75%は1年以内に深刻な技術的負債の蓄積を予測している。
疲弊の原因は労働時間の増加ではない——自分が構築していない出力を検証する特定の認知的労力にある。
解決策はAIを使わないことではない。認知的な仕事が実際にどこへ移ったかを正直に把握することだ。

1新常態

AIが来てから、エンジニアの一日はひっそりと形を変えた

ツールは約束を果たした。カレンダーは領収書をちゃんと保管していた。

AIコーディングアシスタントが来る前、エンジニアの一日には体で分かるリズムがありました。チケットを読んで、頭の中でアプローチをこねて、一行一行タイプして、テストを走らせて、PRをめぐって同僚とひと悶着する。書くことが時間の大半を占めていて、書くこと自体が考えることでした。頭の中のコードとエディタのコードが、同じ問題を同時に削っていた感じです。なぜその行があるかは分かっていた——自分で置いたんだから。

そのリズムが壊れたんですよね。2026年、AIを多用するチームではセッションの始まり方が変わりました。チャットを開いて、欲しいものを説明して、30秒待って、300行が降ってくる。生成はほぼ瞬間です。省けた時間に入ってくるのは休憩じゃなくて——レビューなんですよ。しかも、自分のコードをざっと眺めるあの感じじゃない。変数が何者でなぜそこにいるか全部分かってる、あの楽なやつじゃない。もっとゆっくりで、もっと消耗する種類のレビューです。自分が選んでいないスタイルで速く書かれた見知らぬロジック。あなたのプロンプトから機械が半分しか理解できなかった問題の産物。Evil Martiansは2026年にこのシフトを記録しています。AIを多用するショップのシニアエンジニアの仕事は、静かに書き換えられた。見出しの数字——10倍の生産性——はピッチデッキに残った。脚注——「そして今や一日に10倍の見慣れないコードをレビューしている」——は消えた、と。

ボトルネックは生成から検証へ移った——しかしツールも、プロセスも、人員配置も追いついていない。

2情報理論

AIコードのレビューはコードを書くより難しい——主観ではなく、数学的事実だ

吴军の『数学の美しさ』に、これを語るための言葉がちゃんと用意されているんですよ。

シャノンの情報理論は二つのことを分けて考えます。符号化——自分がすでに分かっているメッセージを、ある記号体系で書き出すこと——と、復号——記号列を受け取って、まだ持っていない意味を自分の中で作り直すこと。符号化は理解から出発して、復号は理解で終わる、うまくいけば。この二つは対称な操作じゃないんですよ。新しいものを復号するには、文脈を丸ごと独立して作り直す必要があります。記号を確認するだけじゃ足りない——その記号が指している「世界」を、自分で再建しないといけない。

コードを書くことは符号化です。頭の中に問題のモデルがある。それをコンパイラが読める言葉に、一歩一歩翻訳していく。一行書くたびに消費するのは「すでに分かっていることを外に出す」コストだけです。AIが生成したコードをレビューするのは、復号化です。AIには問題モデルがあった——あなたのプロンプトから不完全に組み立てたやつが——それを記号に訳した。その記号が正しいか確認するには、自分で独立した問題モデルを作って突き合わせないといけない。この再構築は元の符号化より安くない。大抵の場合、もっと高くつく。なぜかというと、防御モードでやることになるからです。自分が入れた覚えのない、それでいていかにも正しそうなエラーが混じってるかもしれない出力を前にして。僕も昔、これで丸一日溶かしたことあります。「読めばわかる」と思ったら、全然わからなかった。

数学でよく言われる話がありまして。100ページの証明を読んで検証するのに、最初から自分で考えつくのとほぼ同じ時間がかかる。時にはそれ以上です。証明は紙の上に全部書いてある。でも信頼するには、頭の中でもう一度辿り直すしかない。AIが生成したコードも、まったく同じ非対称性なんですよね。機械は速く書いた。確認する人間は、機械が一切必要としなかった道を、一歩一歩歩かないといけない。

自分でコードを書く符号化——すでに問題モデルを保持している

AIコードをレビューする復号化——問題モデルを独立して再構築する必要がある

認知コスト比ほぼすべての情報理論分析で　復号 ≥ 符号化

3技術的負債

コードの39%が「AIチャーン」のとき、それは大きな請求書として積み上がる

省いたスピードは消えない——後払いになってるだけです。

コードチャーンというのは、「問題がちゃんと分かる前に書かれたコード」の代わりに測れる指標です。関数を書いて、間違いに気づいて、2週間以内に消す——これがチャーン。どんなプロジェクトにも一定量ある。Jellyfishが調べたら、AI支援チームはベースラインより39%多くチャーンしていた。一番もっともな説明は、AIが明らかにひどいコードを書くわけじゃない、ということです。AIが書くのは正しそうに見えるコード。さっと見た感じはOKで、マージされる。でも2スプリント後、モデルが持っていなかった文脈のかけらにぶつかったとき、初めて欠陥が顔を出す。そのときにはもう、そのコードは4つの下流モジュールに絡みついていて、解くのに高くつく、という流れなんですよね。

Jellyfish Developer Productivity Report 2026 · AI支援チームでコードチャーンが39%増加；75%のテックリードが12ヶ月以内に中〜重度の技術的負債を予測；34%の開発者はキャリアパスが見えず、32%が転職を検討している。

テックリードの75%が負債を予測しているというのも、同じ話の続きです。彼らが予測しているのは「ひどいコード」じゃないんですよ。誰も完全には理解していないコードが、どのチームもリファクタリングできる速度を超えて積み上がっていくこと、です。負債は構文の中にあるんじゃない——欠けている心的モデルの中にある。ゼロから理解を構築した人間なしにマージされた関数は全部、適切な文脈の衝突が引き金を引く日を待っている地雷なんですよね。チャーンが39%高い状態というのは、単に機能を速く出すだけじゃなくて、一スプリントあたりに「将来の驚き」を、インシデント対応チームが想定していた以上のペースで仕込んでいる、ということです。

4あなたにとって

AIを減らすのではなく、認知的な仕事が本当にどこへ行ったかを正直に把握することだ

かんなの速度が倍になったら、仕上がりの確認も倍かかる。大工ならそこまで計算に入れるはずです。

「AIが悪い、全部自分でタイプしろ」という話じゃないんですよ。スピードは本物だし、重要です。問題は、スピードは測定されて褒められたけど、認知的な仕事の移転——自分で作るから他人の出力を防御的に検証するへ——がほぼ計上されていなかったこと、です。それが今、バーンアウトの数字、チャーン率、テックリードの技術的負債への不安として出てきているんですよね。有用な対応はAIへの道徳的立場じゃない。プロセスの問題です：AIが生成したコードを自分たちが説明できるコードベースに吸収するのに、実際どれだけかかるのか。それ、見積もりに入ってますか？

三つの調整で、すぐ違いが出ます。ひとつ目——レビュー時間を「間接費」じゃなくて「荷重を支える柱」として扱う。スプリント末に、金曜のデプロイ前に急いで流すあのレビューが、75%の負債予測の出所なんですよ。AIが数分で生成するようになった分の時間は消えたわけじゃなくて、レビューの列に引っ越しただけです。そこに本当の時間を押さえないといけない。ふたつ目——分量のあるAI生成コードには、少なくとも一人、ゼロから理解を構築した人間を残す。その人はボトルネックじゃない。リポジトリのコードと「誰かが理解している」という事実をつなぐ一本の線です。その線がないと、深夜2時に障害が出たとき、誰も読めないコードを前に立ちすくむことになる。みっつ目——チャーンを追いかけて、チャーンの上昇を速度の数字じゃなくて早期警報として見る。レビュー能力を超えたチャーンは、手が届かなくなるちょうど足りない速さで負債を積んでいます。39%は平均値です。すでに追いつけないラインを越えているチームもある、ということです。

結局、しんどい仕事とか、ツールを減らすとか、そういう話じゃないんですよね。正直にやる、それだけです。認知コストをちゃんと計上して、意図的に予算に入れて、検証を「間接費」と呼ぶのをやめる——それが仕事そのものなんだから。吴军が『数学の美しさ』で書いているのは、情報にはコストがある、算術で記述できる、でも直感はそれをよく低く見積もる、ということです。AIコーディングで低く見積もられているのは生成されたトークンの数じゃない。自分が書いていない関数ひとつひとつについて、レビュアーが独立して意味を再構築しなければならないコスト——それが、情報理論的には元の生成と少なくとも同じ大きさで、実際にはしばしばもっと大きい。道具だけ速くなっても、そこは速くならないんですよね。

30%のレビューカバレッジで10倍のコード生成——それは生産性の向上じゃなくて、分割払いに変装した予定の支払いです。

復号のコストを計上する。スプリント計画に誰も書かなかったからといって、その請求書は消えない。

取材：吴军『数学の美しさ』（シャノン情報理論の章）；Evil Martians《AI-assisted engineers are burning out》（2026）；Jellyfish 開発者生産性レポート（2026）；データは原レポートに基づく。