Tech

The Agent Can Type All Day. The Job Was Never Typing.

July 6, 2026 · Marcus Webb, Dark Time~5 min read

You've felt it. The agent's cranking out code, the diff is stacking up, and you'd swear you're moving twice as fast as you were last year. Then the sprint ends and somehow the same amount of stuff got done. That gap — between how fast it feels and how fast it actually went — isn't in your head. Somebody finally went and measured it, and the number's a little embarrassing.

The survey nobody wanted to publish

A team surveyed 2,989 developers — pulled from about 8,000 engineers at BNY Mellon — about writing code with GitHub Copilot. Eighty-six percent said they were satisfied. Happy with the tool. Then the same survey asked how much time it actually saved them, and roughly 60% said less than an hour a week. Less than an hour.

Here's the part that stuck with me. When they lined up "how satisfied are you" against "how much time did it save," the two barely moved together — a correlation of 0.34, which in plain terms means the thing that makes you love the tool is mostly not the thing that saves you time. The paper's called Beyond the Commit, out this year, and they backed the numbers with interviews of eleven of those developers. Zoom out and it gets worse: an NBER paper this February surveyed around 6,000 executives, and more than 80% of their firms reported AI had made no measurable dent in productivity over three years. No measurable dent.

So where does the time actually go?

Here's the thing about writing code: you barely do it. One of those engineers put a number on it — when you're refactoring, 70 to 80% of the time is reading the code, and maybe 10 to 20% is actually typing new lines. The typing was never the slow part. It's the same as any repair job. Ever watch someone chase a weird electrical fault in an old house? They spend three hours with a meter and a flashlight tracing which wire does what, and ninety seconds with the screwdriver. The screwdriver was never the bottleneck. The knowing-which-wire was.

And that's exactly where the agent comes up short. Same survey: the folks who handed the agent a whole task and said "go" did worse than the folks who chopped it into small pieces and fed them one at a time. One engineer said the AI "typically fails at code improvement without a lot of context and very specific instructions." Another said the reason the experienced people still had the edge, when something broke in production, was that they "know exactly where the issue is." The tool can write the fix. It just doesn't know where to point it.

An old book already named this

Twenty-odd years back a Chinese programmer named Liu Weipeng wrote a book, Dark Time, mostly about how people actually learn and think. One idea runs through the whole thing: the knowledge that makes you good at something doesn't sit in a file you can email. It's a network in your head — a web of connections you built by reading, getting burned, and reading some more. He's got a line I keep coming back to: if you can't teach it clearly, you probably don't really understand it. Flip that around and you've got the whole problem with the agent. Teaching it — writing the spec clear enough that a thing with no memory of your codebase can act on it — is the same act as understanding it yourself. The stuff you can't write down clearly enough to hand off has a name: tacit knowledge. And it's not some small leftover. In real programming it's most of the job.

Refactoring is 70–80% reading code and only 10–20% writing (developer interviews in "Beyond the Commit," 2026); the agent takes the writing, but the tacit project knowledge — knowing where the issue is — stays in your head. Framework: Liu Weipeng, Dark Time (knowledge as a network you can't hand off). One engineer's read of a fast-moving field.

What this means for you on Monday

Stop handing the agent the whole task and hoping. The survey already ran that experiment for you, and the people who did it came out behind. Chop the work into pieces small enough that each one has a clear, written spec — because that's the only part the agent can actually take. And notice what you're doing when you write that spec: you're dragging the thing out of your head and making it explicit, which is the exact work Liu calls the real thinking. His other line is that writing something down is how you think it through — not a record of thinking you already finished. Same here. The spec you write for the agent is you figuring out the problem. The agent just types up the answer you already found.

You can only hand off the part you can write down

Most of real programming is reading and knowing where the issue lives — a network in your head you can't email. The agent gets the typing; the knowing stays with you.

So no, the tool isn't a fraud, and the 86% aren't wrong to like it. It's genuinely nice to not type the boilerplate. But "nice" and "faster" turned out to be two different measurements, and the survey caught them coming apart. The work that's left after the agent takes the typing is the work that was always the actual job — reading the code, holding the map in your head, knowing which wire to pull. That part didn't get automated. It got exposed.

Framing drawn from Liu Weipeng, Dark Time (knowledge as a network in your head; if you can't teach it clearly you don't really understand it; writing as thinking). Survey and interview figures are from "Beyond the Commit: Developer Perspectives on Productivity with AI Coding Assistants" (2026) and an NBER executive survey (February 2026). This is a fast-moving field and one working engineer's read, not a verdict on any specific tool — plenty of teams do get real gains.

技术

AI 能替你敲一整天键盘——可这活儿，从来就不是敲键盘

2026年7月6日 · 陈志远，《暗时间》约 4 分钟

你肯定有过这感觉。AI 一顿输出，代码哗哗往外冒，diff 越堆越高，你敢说自己比去年快了一倍。可这个迭代做完一算，干成的活儿，跟以前差不多。这个落差——感觉飞快、实际没快多少——不是你的错觉。真有人把它量出来了，那数字还有点难看。

一份没人愿意发的问卷

有个团队调研了 2989 名开发者——从纽约梅隆银行（BNY Mellon）大概 8000 名工程师里抽的——问他们用 GitHub Copilot 写代码的感受。86% 说满意，挺喜欢这工具。可同一份问卷接着问：它到底给你省了多少时间？大约 60% 的人说，一周省不到一个小时。一个小时都不到。

最扎我的是这一条：把「你多满意」和「它省了你多少时间」这两列摆一块儿对，几乎对不上——相关系数只有 0.34，说白了就是，让你爱上这工具的那点东西，跟真替你省时间的那点东西，基本是两码事。这研究今年发的，叫《Beyond the Commit》，数字背后还配了对其中 11 位开发者的访谈。你再往远了看更难看：NBER 今年 2 月调研了约 6000 名高管，超过 80% 的公司反馈，过去三年 AI 对生产率没有可测量的提升。一点可测的都没有。

那时间到底花哪儿去了？

写代码这事儿吧，你别看它叫「写」，真正敲键盘的时间少得可怜。那批工程师里有人给了个数：重构的时候，70% 到 80% 的时间在读代码，真正敲新代码的顶多 10% 到 20%。敲键盘，从来就不是最慢的那段。这跟修东西一个道理。你见过老师傅查老房子的电路故障没？拿个万用表加手电，仨小时都在顺线——这根通哪儿、那根管啥，最后拧螺丝就九十秒。慢的从来不是那把螺丝刀，是「搞清楚是哪根线」。

AI 差的正是这一口。还是那份问卷：把一整个任务丢给 AI、说句「你去干」的人，反而干得不如把活儿拆成小块、一块一块喂进去的人。有位工程师说，AI「在没有大量上下文和非常具体的指令时，通常搞不定代码改进」。另一位说，出了线上问题，老手还占优，就因为他们「清楚知道问题在哪儿」。工具能把补丁写出来，可它不知道该往哪儿打。

有本老书早就给这毛病起过名

二十多年前，有个中国程序员刘未鹏写过一本《暗时间》，大半在讲人到底是怎么学、怎么想的。有条线贯穿全书：让你真正厉害的那点本事，不装在一个能发邮件发出去的文件里。它是你脑子里的一张网——靠一遍遍读、一次次踩坑、再接着读，一点点连起来的。他有句话我老想起来：你要是讲不清楚，那多半是你自己还没真懂。反过来一想，这不就是 AI 的死穴嘛。教会它——把需求写清楚到一个对你代码库毫无记忆的东西也能照着干——这件事本身，就跟「你真搞懂了」是同一件事。那些你没法写清楚、交不出去的东西，有个名字叫隐性知识；它可不是剩下的一点边角料，在真实的编程里，它就是活儿的大头。

重构里 70%–80% 的时间在读代码，真正写代码只占 10%–20%（《Beyond the Commit》2026 的开发者访谈）；AI 接走了「写」，可隐性的项目知识——知道问题在哪儿——留在你脑子里。框架：刘未鹏《暗时间》（知识是一张交不出去的网）。一位一线工程师对快速演进领域的解读。

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

别再把一整个任务囫囵丢给 AI，然后干等着了。这个实验问卷替你做过了，这么干的人是落在后头的。把活儿拆到每一块都能配一份写清楚的需求——因为那一块，才是 AI 真正接得住的。还有，你留意一下你写那份需求时在干嘛：你是在把脑子里那张网往外掏、把它摊成明文，而这一步，恰恰就是刘未鹏说的、真正的思考。他还有句话：写下来不是把想好的记个账，写本身就是把事想清楚的过程。这儿一模一样。你给 AI 写的那份需求，就是你在把问题想明白；AI 不过是把你已经找到的答案敲成字。

你只能交出你写得清的那部分

编程的大头是读代码、是知道问题在哪儿——一张你脑子里、发不出邮件的网。敲键盘那段归 AI，「知道」那段还在你手里。

所以这工具不是骗人的，那 86% 喜欢它也没喜欢错。不用手敲那些样板代码，确实舒服。可「舒服」和「更快」，到头来是两把不同的尺子，这份问卷正好逮住它俩分了家。AI 把敲键盘那段接走之后、剩下的那点活儿，本来就一直是真正的正事——读代码、脑子里揣着那张地图、知道该拔哪根线。这部分没被自动化掉。它只是被晾出来了。

框架取自刘未鹏《暗时间》（知识是你脑子里的一张网；讲不清就是没真懂；写作即思考）。问卷与访谈数字出自《Beyond the Commit：开发者眼中的 AI 编程助手与生产率》（2026）及 NBER 一份高管调研（2026 年 2 月）。这是个快速演进的领域，也只是一个一线工程师的看法，不是给哪个具体工具下判决——不少团队确实拿到了真实的收益。

テクノロジー

エージェントは一日中タイプできる。でも仕事は、タイピングじゃなかった

2026年7月6日 · 藤井亮、『暗時間』約 6 分

たぶん、感じたことありますよね。エージェントがコードをどんどん吐いて、diff がみるみる積み上がって、去年より倍は速い気がする。でも、そのスプリントが終わってみると、片付いた量は前とだいたい同じ。この差——「速い気がする」と「実際に速かった」のズレ——は、気のせいじゃないんです。ちゃんと測った人がいて、その数字が、ちょっと気まずいんですよね。

誰も出したくなかったアンケート

あるチームが 2,989 人の開発者——BNY Mellon（ニューヨーク・メロン銀行）の約 8,000 人のエンジニアから抽出——に、GitHub Copilot でコードを書く感触を聞きました。86% が「満足」。ツールが気に入ってる、と。でも同じアンケートが次に聞くんです。実際、どれだけ時間が浮きましたか、と。すると約 60% が「週に一時間未満」。一時間も、浮いてない。

で、いちばん刺さったのがここで。「どれだけ満足か」と「どれだけ時間が浮いたか」を並べても、ほとんど噛み合わない——相関はたった 0.34。噛み砕くと、ツールを好きにさせている要素と、実際に時間を浮かせている要素は、だいたい別物なんですよね。今年出た『Beyond the Commit』という研究で、数字の裏には 11 人へのインタビューも添えてあります。もっと引いて見ると、さらに厳しい。NBER が今年 2 月に約 6,000 人の経営層に聞いたところ、8 割超の企業が「この三年、AI で測れるほどの生産性向上はなかった」と答えている。測れるほどの向上が、一つもない。

じゃあ、時間はどこに消えてるのか

コードを書くって、実は「書く」時間、ほとんどないんですよね。さっきのエンジニアの一人が数字を出していて——リファクタリングだと、70〜80% はコードを読む時間で、実際に新しい行をタイプするのはせいぜい 10〜20%。タイピングは、もともと遅い工程じゃなかった。これ、修理と同じなんです。古い家の変な電気トラブルを直す人、見たことあります？テスターと懐中電灯で、どの線がどこに通ってるかを三時間追って、ドライバーを握るのは九十秒。詰まってたのはドライバーじゃなくて、「どの線か」を突き止めるところなんですよね。

で、エージェントが弱いのが、まさにそこ。同じアンケートで、タスクを丸ごと渡して「やっといて」と投げた人より、小さく刻んで一つずつ渡した人のほうが、うまくいっていた。あるエンジニアは、AI は「大量の文脈と、とても具体的な指示がないと、コード改善はたいてい失敗する」と言っています。別の一人は、本番で何か壊れたとき経験者がまだ強いのは「問題がどこにあるかを正確に分かっているから」だと。ツールは直しは書ける。ただ、どこに向ければいいかを、知らないんですよね。

この症状、昔の本がもう名前をつけていた

二十数年前、劉未鵬という中国のプログラマーが『暗時間』という本を書きました。大半は、人が実際どう学び、どう考えるか、という話です。一本の線が全体を貫いていて——あなたを本当に強くしている知識は、メールで送れるファイルに入ってない。頭の中の網なんですよね。読んで、痛い目にあって、また読んで、少しずつ結んできた網。彼の一言が、僕はずっと引っかかっていて。「うまく教えられないなら、たぶん本当には分かっていない」。ひっくり返すと、これがエージェントの急所そのものなんです。教えること——あなたのコードベースの記憶をまったく持たない相手でも動ける程度に、仕様をはっきり書くこと——それ自体が、「本当に理解する」ことと同じ作業なんですよね。うまく書き出せない、渡せないもの。それには暗黙知という名前があって、余りものの端っこじゃない。実際のプログラミングでは、そっちが仕事の大半なんです。

リファクタリングは 70〜80% がコードを読む時間で、実際に書くのは 10〜20% だけ（『Beyond the Commit』2026 の開発者インタビュー）。エージェントは「書く」を引き受けるが、暗黙のプロジェクト知識——問題がどこにあるか——は頭の中に残る。枠組：劉未鵬『暗時間』（渡せない網としての知識）。動きの速い分野の、一エンジニアの読み方。

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

タスクを丸ごとエージェントに渡して、祈るのは、もうやめましょう。その実験はアンケートがもう回してくれていて、そうやった人たちは後ろに回っている。仕事を、一つひとつにはっきり書いた仕様がつく大きさまで刻む——エージェントが実際に受け取れるのは、そこだけなんですよね。そして、その仕様を書いているとき自分が何をしているか、ちょっと見てほしくて。頭の中の網を外に引きずり出して、明文にしている。これがまさに、劉未鵬の言う本当の思考なんです。彼のもう一つの言葉に、書くのは考え終わったことの記録じゃなくて、書くこと自体が考え抜く手段だ、というのがあります。ここも同じ。エージェントに書く仕様は、あなたが問題を解いている最中そのもの。エージェントは、あなたがもう見つけた答えを、タイプするだけなんですよね。

渡せるのは、書き出せる分だけ

プログラミングの大半は、読むことと、問題がどこにあるかを知ること——メールで送れない、頭の中の網。タイピングはエージェントに、「分かっている」はあなたに残るんですよね。

だから、ツールが詐欺なわけじゃないし、86% が気に入ってるのも間違いじゃない。定型コードを打たなくて済むのは、素直に快適です。ただ、「快適」と「速い」は、結局は別々のものさしで、アンケートがその二つの離れる瞬間を捕まえた。エージェントがタイピングを持っていったあとに残る仕事は、もともとずっと本当の仕事だったもの——コードを読み、頭の中に地図を保ち、どの線を抜くかを知る。そこは自動化されなかった。ただ、むき出しになったんですよね。

枠組は劉未鵬『暗時間』から（知識は頭の中の網；うまく教えられないなら本当には分かっていない；書くことは考えること）。アンケートとインタビューの数字は『Beyond the Commit：AI コーディング支援と生産性についての開発者の視点』（2026）と NBER の経営層アンケート（2026 年 2 月）から。動きの速い分野の、現場の一エンジニアの読み方であって、特定のツールへの判決ではありません——実際に確かな効果を得ているチームも少なくありません。