Tech

AI Made Us Busier, Not Faster

July 11, 2026 · Marcus Webb, Liu Weipeng Dark Time~6 min read

Picture a developer at 11 pm. There's a half-finished feature on the screen, but instead of pushing it to staging, she's refactoring the auth module — again. The old version worked fine, but the new AI-assisted one is 40% shorter and, she's convinced, more elegant. She's been at this for six hours. The customer who asked for the feature three weeks ago is still waiting. Token usage: very high. Things shipped to users: zero. This is not a story about laziness. It's a story about a trap that everyone in tech is currently inside, and almost nobody is naming correctly.

A piece from Substack's i0exception (published June 30) circulated heavily on Hacker News last week, and the comment thread that followed was the most honest 400-post thread about AI and engineering productivity I've read in 2026. The core observation is uncomfortable: across teams, token usage is up, AI spending is up, adoption is up — and the rate of shipping, the thing that actually reaches customers, hasn't moved. We got better at the easy part. The hard part didn't get better. It got more obvious.

1The slope

You optimized the downhill. The uphill didn't change.

AI is brilliant at the part of engineering that used to be the annoying slog. That's the problem.

Writing boilerplate is now instant. Generating CRUD endpoints, migration files, unit test skeletons — gone in seconds. Engineers who used to groan at those tasks don't groan anymore. What do they do with the recovered time? This is where the Substack piece puts its finger on something real: they slide toward more of the same. More features, more refactors, more internal dashboards that three people will use. AI optimized the downhill slope of coding — the path of least resistance — without moving the actual constraint, which lives upstream. Review. Verification. Understanding what's even worth building. The decision about whether to ship at all.

⚡

Why it matters: when you speed up something that isn't the bottleneck, you don't go faster overall. You just produce more inventory in front of the jam. The queue doesn't clear; it grows.

Liu Weipeng called this out before AI tools existed, writing about how we optimize our studying: the effort you don't put into the right place doesn't count, no matter how hard you work. In Dark Time, he uses the phrase "optimizing the wrong thing" — grinding at a sub-problem while the real constraint goes untouched. A student who spends twelve hours color-coding notes but never once does a practice problem is in the same trap. The notes look great. The exam result doesn't.

2The gradient

Engineers follow the path of least resistance — always

When AI makes code generation easy, engineers do more code generation. Not because they're bad engineers. Because gravity.

Put it another way

A construction crew gets a power drill. It's much faster at driving screws. So they drive more screws — including a few hundred screws on the parts of the building that were fine already. The wall that's actually load-bearing, the one where the structural engineer needs to sign off, is still waiting for the structural engineer.

The Hacker News thread had a comment that's stayed with me: "AI isn't the problem. Bad decisions and poor architecture are the problem. AI just lets you feel them faster." This is exactly right and slightly incomplete. The decisions weren't necessarily bad before AI. What AI did was remove the friction that used to slow engineers down on the wrong work — friction that accidentally forced reflection. When generating a feature takes four hours of grinding, you naturally pause and ask whether the feature is worth it. When it takes forty minutes, you just do it. The friction was a disguised forcing function. We removed it, and nobody installed a replacement.

The Substack author frames this as the "easy gradient path": engineers drift toward work where AI helps most, not work that matters most. More feature additions. More refactors of things that already work. More tooling and internal dashboards. All low-ROI. All measurable in tokens. None of it is the hard conversation with a customer you've been avoiding.

3The bottleneck

The constraint just moved upstream. It didn't disappear.

Faster code generation moved the jam from writing to reviewing, from building to deciding — from easy to hard.

AI accelerates the downhill work (code gen, refactoring, scaffolding) but doesn't touch the real constraints upstream — review load, goal-setting, shipping decisions, and feedback loops. Engineers slide toward easy work by gravity; the bottleneck just moves where it's harder to see.

Liu Weipeng has a clean way to think about this in Dark Time: true investment = time × efficiency directed at the right place. Optimizing input speed on the wrong segment gives you the illusion of productivity. The engineers generating more code are working hard — genuinely hard — but they're adding inventory upstream of a constraint, not clearing it. This is what the Substack piece calls the productivity trap, and it's invisible from the inside because every metric except the one that matters (value in customers' hands) is pointing up.

4The exit

What the engineers getting most from AI actually do

They don't use AI to go faster at code. They use it to spend less time on code — so they can focus on what code can't do.

The Hacker News thread has a quiet cluster of engineers who report genuinely shipping more. Their pattern is consistent. They set goals before they open an editor. They treat code as a signal, not an endpoint — something you write to run against reality and then, often, throw away. And they discard code ruthlessly, because they know a feature that doesn't reach a customer is just warm inventory. The Substack post's framing for this: the real leverage is shortening the cycle to customer reaction, not making the existing cycle faster.

AI is best used as a reason to skip code you don't need, not as a reason to write more of the code you were already going to write anyway.

This maps cleanly onto what Dark Time says about time use: the engineers who win aren't the ones with the most hours logged or the highest token counts. They're the ones who are honest about where the actual constraint lives. When Liu writes about students who spend entire nights studying and still fail, he's describing the same trap — an enormous amount of sincere effort aimed at something other than the blocking problem. You can be exhausted and wrong at the same time. AI doesn't fix that. If anything, it makes the exhaustion arrive faster.

The line worth keeping

The bottleneck was never writing the code. It was knowing what code to write, shipping it before it went stale, and listening to what happened. AI didn't fix that. It just made it cheaper to miss it.

Framework from Liu Weipeng, Dark Time (暗时间) — true investment / optimizing the wrong thing / effort × direction. Reporting on i0exception's "The AI Productivity Trap" (Substack, 2026-06-30) and the associated Hacker News discussion. Figures on token usage, AI spend, and adoption growth are industry-reported directional trends, not audited data. Commentary, not professional advice.

技术

AI 让我们更忙了，不是更快

2026年7月11日 · 陈志远，刘未鹏《暗时间》约 5 分钟

晚上十一点，我一哥们还在改 auth 模块。功能三周前就该出了，用户还等着。他用 AI 把那段代码重构了两遍，短了四十行，他说更优雅。这一来一回用掉六小时，客户那边没有任何动静。这不是懒，也不是菜。这是 2026 年技术圈里每个人都掉进去了、但几乎没人说清楚的那个坑。

上周 Hacker News 上一篇文章被顶烂了——来自 Substack 的 i0exception（2026 年 6 月 30 日发布）。核心观察很不好听：token 用量上去了，AI 花费上去了，采用率上去了，发布速率没动。我们把容易的部分做快了，难的部分没变——它只是变得更刺眼了。

1坡度

你优化了下坡路，上坡路没变

AI 在工程里最擅长的那部分，恰好是以前最烦人的那部分。这才是问题。

写模板代码，现在是秒出。CRUD、迁移文件、单测骨架——几十秒搞定。以前要抱怨的那堆活，现在不抱怨了。省下来的时间去哪了？就是这里，Substack 那篇文章戳到的地方：工程师们开始往下滑——更多功能、更多重构、更多只有三个人用的内部仪表盘。AI 优化了编码的下坡路——阻力最小的那条——但没移走真正的约束，真正的约束在上游：代码审查、验证、搞清楚该做什么、要不要发版这种决策。

⚡

为什么要关心：把不是瓶颈的环节做快了，整体不会快。你只是在堵点上游堆了更多库存。队列不会清空，只会越来越长。

刘未鹏在 AI 工具出现之前就说过这件事，他说的是学习，但逻辑完全一样：努力不花在正确地方，就不算数，不管多努力。《暗时间》里他用的词是"优化错地方"——死磕一个子问题，而真正的卡点原封不动。一个学生花十二小时把笔记用彩笔抄一遍，一道练习题没做——同样的陷阱。笔记很好看，考试分数不好看。

2梯度

工程师永远沿阻力最小的路走——这是物理

当 AI 让生成代码变得容易，工程师就生成更多代码。不是因为他们差，是因为重力。

换个说法

施工队拿到了电钻，拧螺丝快多了。于是他们拧了更多螺丝——包括几百颗已经没问题的地方的螺丝。那堵真正承重的墙，需要结构工程师来拍板的那堵，还是在等结构工程师。

HN 评论区有一条话我记住了："AI 不是问题。糟糕的决策和烂架构才是问题。AI 只是让你更快感受到它们。"这话对，但说得不够完整。决策在引入 AI 之前不一定是糟糕的。AI 干的事是移走了一个摩擦——那个以前会让工程师在错误的工作上慢下来的摩擦，而那个摩擦无意中逼着人去反思。当做一个功能要磨四个小时，你自然会停下来问一句这值不值。当四十分钟能搞完，你就直接做了。摩擦是个隐形的强制装置。我们把它移走了，没人装上替代品。

那篇 Substack 文章把这个叫"轻松梯度路径"：工程师漂向 AI 最能帮上忙的工作，而不是最重要的工作。更多功能叠加，更多已经能跑的东西的重构，更多工具和内部仪表盘。全是低 ROI 的事。全能用 token 量来计量。全不是那个你一直在躲的和客户的硬对话。

3瓶颈

约束只是挪了上游，没消失

代码生成加速，把堵点从写代码挪到了审查、决策——从容易挪到了难。

AI 加速了下坡工作（代码生成、重构、脚手架），但没有触碰真正的上游约束——审查负担、目标设定、发版决策和反馈回路。工程师靠重力滑向容易的工作；瓶颈只是挪到了更难看见的地方。

刘未鹏在《暗时间》里对此有个干净的表述：真正的投入 = 时间 × 效率，方向要对。在错误的环节上把输入速度优化了，给你的是生产力的幻觉。那些生成更多代码的工程师是真的在努力工作——但他们是在一个约束上游堆库存，而不是在清它。这就是 Substack 那篇文章说的"生产力陷阱"，从里面看不出来，因为除了那个真正重要的指标（交到用户手里的价值）之外，其他所有数字都在往上走。

4出口

从 AI 拿到最多的工程师，实际上怎么做的

他们不用 AI 来把代码写得更快。他们用 AI 来少花时间在代码上——这样才能把时间放在代码做不到的事上。

HN 评论区有一撮工程师说确实发布多了。他们的模式很一致：打开编辑器之前先定目标。把代码当信号而不是终点——写出来是为了跑一遍、对上现实，然后经常直接扔掉。他们无情地丢弃代码，因为他们知道一个没交到用户手里的功能就是暖着的库存。那篇 Substack 文章的说法是：真正的杠杆是缩短"拿到客户反应"的周期，而不是把现有循环做得更快。

AI 最好的用法，是让你有理由跳过不需要的代码——不是让你有理由把本来就要写的代码写得更多。

这跟《暗时间》讲时间使用的逻辑完全对得上：赢的工程师不是 token 消耗最高的，也不是工时最长的。是那些对"真正的卡点在哪"保持诚实的人。刘未鹏写那些通宵学习却还是考砸的学生，描述的是同一个陷阱——海量真诚的努力，方向不对。你可以同时筋疲力尽和方向错误。AI 解决不了这个。某种程度上，它让筋疲力尽来得更快。

一句话核心

瓶颈从来不是写代码。是知道该写什么代码，在它过期之前发出去，然后听回来的声音。AI 没解决这个，只是让你错过它的成本变低了。

框架取自刘未鹏《暗时间》——真正的投入 / 优化错地方 / 努力×方向。报道来自 i0exception 的"The AI Productivity Trap"（Substack，2026-06-30）及相关 Hacker News 讨论。token 用量、AI 花费、采用率增长数字为行业方向性趋势，非经审计数据。本文为评论，非专业建议。

テクノロジー

AIは私たちを速くしたのではなく、忙しくした

2026年7月11日 · 藤井亮、劉未鵬『暗時間』約 7 分

夜の11時、知人のエンジニアがまたauthモジュールをリファクタリングしていた。3週間前からユーザーが待っている機能がある。でも画面には、AIを使って2度書き直した認証コードが40行短くなって光っている。「もっとエレガントだ」と言う。費やした時間は6時間。ユーザーへのリリース数はゼロ。これは怠慢の話でも、能力の話でもない。2026年のテック業界にいる全員が嵌まっていて、ほぼ誰も正しく名前をつけていない、あの罠の話だ。

先週、Substack の i0exception が書いた記事（2026年6月30日公開）がHacker Newsで荒れるほど読まれた。核心の指摘は耳が痛い——チーム全体でトークン使用量は増え、AI支出は増え、採用率は増えたのに、リリース速度は動いていない。簡単な部分を速くした。難しい部分は速くならなかった。むしろ、もっと目立つようになった。

1傾斜

下り坂を最適化した。上り坂は変わっていない。

AIはエンジニアリングの中で、かつて面倒だった部分を得意とする。それが問題だ。

ボイラープレートを書くのは今や一瞬だ。CRUDエンドポイント、マイグレーションファイル、ユニットテストの骨格――数十秒で出る。以前は文句を言っていた作業が、文句を言わせなくなった。回収した時間はどこへ行くのか。ここがSubstackの記事が指差す場所だ――エンジニアたちは下へ滑る。もっと機能を、もっとリファクタを、3人しか使わない社内ダッシュボードをもっと。AIはコーディングの下り坂を最適化した――最も抵抗の少ない経路を。でも本当の制約は移動しなかった。制約は上流にある。コードレビュー。検証。何を作るべきかの理解。そもそもリリースするかどうかの判断。

⚡

なぜ重要か：ボトルネックでない場所を速くしても、全体は速くならない。詰まった箇所の上流に在庫を積むだけだ。列は解消されず、長くなる。

劉未鵬はAIツールが存在するずっと前にこれを書いた。彼が書いたのは学習の話だが、論理はまったく同じだ。努力を正しい場所に向けなければ、どれだけ頑張っても意味がない。『暗い時間』で彼が使う言葉は「間違った場所の最適化」――サブ問題に全力を注ぎながら、本当のボトルネックは手つかずのまま。12時間かけてカラフルなノートを清書しても、練習問題を一問も解かなかった学生と同じ罠だ。ノートは美しい。試験の点数はそうじゃない。

2勾配

エンジニアは常に最も抵抗の少ない道を歩む――これは物理だ

AIがコード生成を楽にすると、エンジニアはより多くのコードを生成する。能力が低いからではなく、重力があるからだ。

別の言い方をすると

建設チームが電動ドリルを手に入れた。ネジ締めがずっと速くなった。だから彼らはネジをもっと締めた――すでに問題なかった箇所にも数百本。本当に荷重がかかる壁、構造エンジニアの承認が必要なあの壁は、まだ構造エンジニアを待っている。

HNのスレッドに一つのコメントが残っている。「AIは問題じゃない。悪い意思決定と粗末なアーキテクチャが問題だ。AIはそれをより速く感じさせるだけだ。」これは正しいが、少し足りない。AI導入前の意思決定が必ずしも悪かったわけではない。AIがやったことは、エンジニアが間違った作業で「自然と遅くなっていた」摩擦を取り除いたことだ――その摩擦は偶然、内省を強いていた。機能を作るのに4時間かかるなら、自然に立ち止まってその機能の価値を問う。40分で終わるなら、そのままやってしまう。摩擦は隠れた強制装置だった。それを取り除いたのに、誰も代わりを付けなかった。

Substackの記事はこれを「楽な勾配経路」と呼ぶ。エンジニアたちは最も重要な仕事ではなく、AIが最も役立てる仕事へと流れていく。より多くの機能追加、すでに動いているものの更なるリファクタ、ツールと社内ダッシュボード。すべて低ROI。すべてトークン数で測れる。どれも、ずっと避けてきた顧客との難しい会話ではない。

3ボトルネック

制約は上流へ動いただけで、消えていない

コード生成が速くなったことで、詰まりは「書く」から「レビューする、判断する」へ——簡単なところから難しいところへ移動した。

AIは下り坂の作業（コード生成・リファクタ・足場）を加速するが、本当の上流の制約——レビュー負担・目標設定・リリース判断・フィードバックループ——には触れない。エンジニアは重力で楽な仕事に流れる。ボトルネックは見えにくい場所へ移動しただけだ。

劉未鵬は『暗い時間』でこう整理する。真の投資＝時間 × 効率、方向が正しければ。間違ったセグメントで入力速度を最適化しても、生産性の幻想しか生まれない。より多くのコードを生成しているエンジニアたちは本当に努力している。でも彼らは制約の上流に在庫を積んでいるのであって、制約を解消していない。Substackの記事が「生産性の罠」と呼ぶのはこれだ。内側からは見えない。なぜなら、本当に重要な指標（ユーザーの手に届いた価値）以外は、すべての数字が上を向いているから。

4出口

AIから最も多くを得ているエンジニアが実際にやっていること

AIを使ってコードを速く書くのではなく、AIを使ってコードに費やす時間を減らす。コードにできないことに集中するために。

HNのスレッドには、本当にリリース数が増えたと報告するエンジニアの小さな集団がいる。彼らのパターンは一貫している。エディタを開く前にゴールを設定する。コードをシグナルとして扱い、ゴールとして扱わない――書くのは現実に当てて試すためで、その後しばしば捨てる。機能がユーザーの手に届かなければ、それはただの温かい在庫だと知っているから、容赦なく捨てる。Substackの表現を借りると、本当のレバーは顧客の反応を得るサイクルを縮めることであり、既存のサイクルを速くすることではない。

AIの最良の使い方は、不要なコードをスキップする理由を手に入れること――どうせ書くつもりだったコードをもっと書く理由を手に入れることではない。

これは『暗い時間』が時間の使い方について言うことと綺麗に対応する。勝つエンジニアは最も多くの時間を記録した人でも、最も多くのトークンを消費した人でもない。「本当の制約がどこにあるか」について正直でいられる人だ。劉が、徹夜で勉強しても試験で落ちる学生について書くとき、彼は同じ罠を描写している――阻んでいる問題以外のことへ向けられた、膨大な量の誠実な努力。疲弊していて、かつ間違った方向を向くことは同時に起きる。AIはそれを解決しない。むしろ、疲弊の到来を速くする。

核心を一行で

ボトルネックはコードを書くことではなかった。何を書くべきかを知ること、腐る前に出すこと、そして起きたことに耳を傾けること。AIはそれを解決しなかった。ただ、見逃すコストを安くしただけだ。

枠組みは劉未鵬『暗時間』（暗时间）——真の投資／間違った場所の最適化／努力×方向——より抽出。i0exception の「The AI Productivity Trap」（Substack、2026-06-30）および関連HackerNewsスレッドの報告に基づく。トークン使用量・AI支出・採用率の成長数値は業界の方向性トレンドであり、監査済みデータではない。本稿は解説であり、専門的な助言ではありません。