No, AI is not Making Engineers 10x as Productive

Curing Your AI 10x Engineer Imposter Syndrome

05 August 2025
AI

几个月前，我经历了一段心理低谷。虽然我一直对自己的工程能力充满信心，但在浏览LinkedIn和Twitter时，我不禁感到自己的技能正在 hopelessly 落后。如果这些平台的信息可信，工程实践已经从中世纪式的代码编辑进阶了。真正的工程师现在比我高效10-100倍。我写这篇文章，希望能帮助那些有类似焦虑的人。

我是个多疑的人，所以听到这种说法时通常不会立即信服。我通常会翻白眼，就像有人告诉我简单的草药疗法能治愈所有疾病时一样。但这些10倍工程师声称的数量现在开始触及神经。万一我错了呢？如果我不立即学习使用AI，会错过机会变得无法就业吗？毕竟，有很多花哨的词汇在流传，这些词汇将人们谈论的“AI”与我熟悉的“AI”拉开了距离。

这些人正在使用✨代理式✨AI。他们使用✨思考✨模型，这些模型可以上网冲浪、运行测试并自我纠正错误。当然，我偶尔会打开聊天窗口，让它写一些代码，然后一旦得到所需的想法，就 promptly 丢弃大部分输出。但这些工程师让Claude完全接管方向盘，让代理在他们煮早晨咖啡时为他们提交5个PR。我是不是变成了恐龙，一个对着云大喊的老人？

让我感到焦虑的部分原因是，AI可能在我不知情的情况下发生了变化，因为我不太使用AI。因为我不太喜欢使用AI。审查代码的过程远不如编写代码愉快。我 stubborn 地享受编码的欲望是否让我落后了？

Diving In

最终，我达到了一个 breaking point，决定必须 head first 地投入AI编码。我尝试了Claude Code、Cursor、Roo Code和Zed，因为它们承诺代理式编码。我开始让AI在各种项目中编写各种代码。我尝试了不同的模型并进行了比较。我甚至 vibe coded 了一些东西，一次都没有手动编辑代码。

结果…还好。尽管有人声称今天的AI正在 fever pitch 地改进，但感觉 largely 和以前一样。它擅长编写样板代码，尤其是在Javascript中，特别是在React中。它不擅长跟上代码库的标准和实用工具。它在像Terraform这样的语言中 tend to struggle。它仍然会 hallucinate 库，导致 significant 安全漏洞。

AI仍然 struggle 吸收更大代码库的上下文，即使有很好的提示和CLAUDE.md文件。如果你使用一个不是StackOverflow最爱的库，它会在代理式查找文档后仍然 butcher 它。代理偶尔会做一些整洁的事情，比如修复它们破坏的测试。但通常它们只是浪费时间和tokens，来回往复，似乎每次失败都没有获得更深的知识。因此，AI对我来说的最佳用例仍然是编写一次性脚本。尤其是当我对单个脚本没有兴趣学习更深层次的基础知识时，比如编写自定义ESLint规则。

那些 dark warnings 说如果我不立即开始使用AI就会 hopelessly 落后，被证明是 unfounded。使用AI编码并不难学。显然？嗯，AI编码社区似乎 split on whether AI makes coding so easy a caveman can do it or that it requires an advanced, dedicated prompt engineer skillset。有一些东西你需要学习，但它们很快就能掌握。你学会如何将任务拆分成更小的部分，这样AI就不会在上下文窗口后期 lose its mind。像Claude Code这样的工具甚至可以自己做一点这个，尽管不总是可靠。你还学会识别AI何时偏离太远，是时候接管方向盘了。

一个 competent 工程师会在 moderate AI使用不到一周的时间内 figure this stuff out。此外，如果AI即将在任何分钟变得2倍、10倍或100倍更好（就像每个人一直说的那样），那么现在关于如何使用它的任何 lessons 对 future 都是 moot。

每次我遇到AI工作“just okay”时，奇怪的是它让我更焦虑，而不是 less。这意味着我找不到让其他人如此高效的 spicy secret sauce。我就是没有 what it takes：恐龙， meet asteroid， thy name is AI。最终，一些事情 shook me out of this slump。其中之一是这篇来自Ludicity的文章，直接 countering the claims of the AI pumpers。我写这篇文章来分享更多帮助我摆脱AI 10倍工程师 imposter syndrome 的事情。

The Math

让我们从简单的10-100倍生产力数学开始。10倍生产力意味着十倍的结果，而不是十倍的代码行数。这意味着你过去一个季度交付的东西现在一周半就能交付。这些数字应该让 even the truest AI believer pause。产品构思、故事点协商、bug修复、代码审查、等待部署、测试和QA的数量，这些传统上需要3个月的工作，现在在7个工作日内完成？要做到这一点，每一个这些瓶颈都必须 also seen have 10倍生产力 gains。

任何在实际公司中处理过实际代码的软件工程师都知道这是不可能的。你不能将3个月的代码审查来回压缩到1.5周。当你进行代码审查时：

• 标记你的审查者
• 希望他们能 sooner rather than later 处理（这会很 tough，因为他们 apparently 代码审查10倍于以前的代码）
• 在等待时 context switch 到其他事情
• 看到通知（可能 immediately，可能2小时后你的审查者 offline for the day）
• context switch 回审查
• 阅读他们的评论
• 相应响应
• rinse and repeat。

这个过程在 competent 公司中可以通过良好的标准和沟通实践变得 fairly efficient。但你说你让这个过程10倍 efficient 来处理10倍的工作？这 simply can not be done。

实际企业软件工程中涉及的人类过程没有 significantly 改变。产品经理可能使用ChatGPT做“研究”，但他们不会 suddenly pumping out 十倍于以前的 well vetted, well justified, well estimated 故事。他们不能 all at once 做10个用户访谈。设计师和QA测试员也是如此。雇佣10倍的PM来跟上不是 feasible。每次雇佣都有 diminishing returns，因为网络效应和官僚主义 take hold。

即使我们假设人们 mean only the actual code writing process is now 10-100x faster，我们仍然应该 skeptical of how this maths out。当你编写代码时，你真正花在键盘上 pushing buttons 的时间有多少？可能比你想象的少。你大部分 prime coding time 实际上是阅读和思考， often while waiting for compiling, a page refresh, or for tests to run。LLMs do not make rustc go faster。

LLMs产生的代码 often broken, hallucinated, or below codebase standards。这些错误的频率随着代码库的大小而增加。当这种情况发生时，你必须 re-prompt，这可能 instantly fix the problem 或 could be a huge waste of time。或者你可以进去自己修复代码。但然后你又回到了 measly 1x engineer status，可能更糟，如果你已经 so used to vibe coding you forgot how to code。如果你“embracing the vibes”甚至不看产生的代码，你 simply going to hit a productivity wall once the codebase gets large enough。一旦你这样做，你将不得不 reckon with the complete lack of standards and proper abstractions。

我认为 sometimes people lose the scale of just how big a 10x improvement is。10倍是你的迷你货车和创纪录的超音速陆地喷气机之间的差异。想象一下，试图在城市街道上以600英里/小时的速度驾驶你的10分钟通勤。你会在十分之一的时间内到达城市的另一边吗？不，因为即使一个60秒的红灯也会 eat up your entire time budget。F1赛车在基本弯道减速到迷你货车速度。事实证明，大多数活动都不是以最高速度进行的。

100倍生产力意味着你现在在两天内完成过去一年的工作。我甚至不需要 touch the ludicrousness of numbers at that scale。

Do 10x Engineers Exist?

这个辩论不是我想 weigh in on 的，但我可能不得不。我的答案是 sometimes, kinda。当我有过工程师 who were 10x as valuable as others 时，主要是由于他们 prevent unnecessary work 的能力。说服PM放弃一个 never feasible 的任务。让另一个工程师不构建那个不必要的微服务。进行开发者体验投资， save everyone just a bit of time on every task。记录你的工作，以便每个未来的工程师都能更快地加入。这些事情可以 over time add up to one engineer saving 10x the time company wide than what they took to build it。

这种性质的工作并不总是可用，所以伟大的工程师 only find themselves being 10x as productive in certain situations。在某个点，每个工程师都需要构建功能，一个伟大的工程师可能比初级工程师快两倍，但他们仍然会 hit the same bottlenecks as before。尽管故事点有缺陷，我从未见过一个工程师 actually complete ten times as many as an average engineer consistently。

值得注意的是，AI编码助手 do very little to prevent unnecessary work。相反，AI often seems to encourage hastiness and over-building。当我问架构问题时，它 often recommends something that I realize is not necessary after a good night’s sleep or a talk with a great engineer。所有其他条件相同，更快的编码员是更好的工程师吗？是的，但这不是10倍的差异制造者，而且很难 hold everything else constant。你越专注于尽可能快地 pumping out tasks，就越容易错过减少总工作量的重要时间节省器。

So are the AI-posters lying or what?

我认为AI-posters是以下混合体，按从 least to most malevolent 顺序：

• 善良但错误测量自己和他的人
• 个人或财务上 heavily invested in the success of AI的人（AI初创公司创始人、投资者等）
• 老板 outright trying to make their engineers feel precarious so they don’t quit, look for other jobs, or ask for raises

The good-natured engineer with bad math skills

根据我的经验，AI提供 rare, short bursts of 10-100x productivity。当我在几分钟内让AI编写一个自定义ESLint规则，否则需要 hours of documentation surfing and tutorials，这是一个 genuine order of magnitude time and effort improvement。这样的时刻确实发生在AI中。许多职业非编码员在用Lovable启动应用程序后的头几天感受到了魔力。

问题是生产力 does not scale。我每年编写不超过一个ESLint规则。这种生产力爆发 solely enabled by the fact that I didn’t care about this code and wasn’t going to work to make it readable for the next engineer。如果 constantly writing ESLint rules became a core job requirement，我会 sink the one-time cost to learn how ESLint internals work。之后，vibe code一个规则与我自己编写之间 simply wouldn’t be a big difference in the time，尤其是当你添加额外时间使我的代码 human readable for when I come back to this file in 6 months。

最终每个vibe coder reaches the point where the returns start heavily diminishing。他们的网站被黑客攻击，他们需要 actually sink the time to learn how security works。应用程序变得太大， context windows 无法处理，东西开始看起来和功能不一致。雇佣真正的知道他们在做什么的前端工程师来实现一致的设计系统和UX。

还有很多简单的偏见和盲点可以导致生产力幻觉。如果你离开大公司的深度去初创公司，你会 genuinely be shocked at how much more productive each engineer is。很容易将这归功于AI。有些人真的享受AI编码的技术新奇感，当你在新事物中工作时， often feel like you’re doing more than you ever did。我知道我第一次使用Python时 felt like I was “sipping rocket fuel”，但像所有其他技术一样，它总是 comes back down to earth。

我认为很多更 genuine 10x AI炒作来自 simply in the honeymoon phase or haven’t sat down to actually consider what 10x improvement means mathematically 的人。我不会 surprised to learn AI helps many engineers do certain tasks 20-50% faster，但软件瓶颈的性质意味着这不会 translate to a 20% productivity increase and certainly not a 10x increase。

Incentives matter

看，我不是AI初创公司 hater。如果你想将OpenAI的API插入你的医疗保健初创公司，我可能会 raise an eyebrow of concern over the risks，但我会对任何渴望在医疗领域 move fast and break things 的初创公司做同样的事情。我的目标不是说AI初创公司创始人或投资者是邪恶甚至 dishonest。我的观点是用你高中Econ 101教授 droll 的声音说，“Incentives Matter”。

如果你在运行一个AI初创公司，而其他每个AI初创公司都在告诉投资者他们 thanks to AI 看到了10倍的生产力， incentives are plain and simple：你应该公开和私下说同样的话。如果你的公司建立在AI的背上，你 incentivized to sell AI as a miracle solution in every part of life。如果你是一个工程师，你的老板问你：

嘿， thanks to AI，你得到了10倍的生产力，就像所有其他工程师一样，对吧？

你 strongly incentivized to say yes。当每个其他工程师也出于同样原因说 yes 时，那个CEO不是在 lying，他们只是 relaying what they heard。

我想向那些像我一样感到焦虑的人强调，这 nothing new。CEO不是 unbiased sources。高管们一直声称从Agile到Meyers-Briggs的一切都 unlocked limitless productivity。LinkedIn上总会有新的协同流行语，不要让它让你 down。事实上， stop scrolling LinkedIn at all。It’s a silly place。

Outright Malice

当有人说一些让人感到焦虑的话时，至少有些时候你应该 conclude it’s because that’s what the speaker wanted to happen。老板试图让他们的工程师感到他们的位置 precarious 也 nothing new。我们都记得 narrative that a 3 month coding bootcamp could churn out 4-year-degree quality engineers，所以你最好不要太 uppity 否则你会被一个做职业转型的文学学士取代。然后几年过去了，人们意识到 bootcamp grads were usually woefully underprepared for actual software engineering since they were not given the proper foundation。

Bootcamps和AI只是 long series of poorly born out threats to commoditize the highly expensive, highly professionalized field of software engineering 中的例子。它们是 rhetorical devices designed to imply precarity。你的老板不能 actually fire you and replace you with AI，但他可以让你 feel like he could，也许不要求加薪。

10x AI工程师故事的一些部分 likely being told by people who simply want you to feel bad for this purpose。有多少，我不知道。尽管在这些时代我们变得 highly distrustful of each other，我仍然相信大多数人 fundamentally decent，所以我不 inclined to believe it’s a high percentage。

Degrees of separation

我注意到关于AI编码炒作文章中的所有这些角色的一件事是，几乎总是有 a degree of separation from the writer to the actual productivity benefits。发帖者是创始人、经理或投资者，对别人的生产力做出 grandiose claims。二手来源没有问题，但如果你找不到一手来源，你可能会 start questioning the reliability of the information。

来自实际工程师的演示，展示他们如何用AI实现更多生产力， much more varied and much more muted in their praise。这些演示 largely show AI as the same technology you and I were familiar with before we got so anxious：一个整洁的文本生成器， sometimes does magic but often requires you to take the wheel。

在开源项目上使用AI，其中生产过程可以公开见证， famously been a hilarious failure。我从一些youtube视频中学到了如何更好地使用AI。这是上面那篇Ludicity文章中引用的一个好视频。我会为你剧透，这个工程师没有找到编码生产力的 fountain。

It’s okay to be less productive

即使在我克服了有一个秘密的工程师 clade who was now ten times as productive and strong and tall and sexy as I was 的想法之后，我仍然对我不太喜欢使用AI的事实感到一些焦虑。一旦魔力 wears off，vibe coding is a complete bore。阅读LLM生成的代码 sucks。礼貌地要求它使用一个 not hallucinated 库是 painful。但尽管所有这些，如果我 vibe coding 比常规编码高效20%，会怎样？如果有一个更高输出的路径可用，我做“正常”编码是错误的吗？

不。牺牲一些生产力让工作愉快是可以的。不止可以，在我们领域是 essential。如果你强迫自己以你讨厌的方式工作，你只会 burn out。只有这么多编码是编写代码，其余是解决问题、做系统设计、推理抽象和与他人接口。当你感觉良好时，你更擅长所有这些事情。对自己的工作感到自豪并欣赏工艺是可以的。从长远来看，你的代码库将受益于它。

数字音乐是否 objectively better than vinyl 不重要。翻转唱片是否 less “productive” than letting the streaming service automatically roll over to the next song in 100x less time 不重要。如果听一个70岁的唱片让你更快乐，就去做。如果你这样做，你会听更多音乐，而不是强迫自己使用更“高效”的流媒体服务。如果你以你喜欢的方式做，你会花更多时间编写代码，并编写更好的代码。

哦，这个 exact argument works in reverse。如果你做AI编码感觉良好，就去做。如果你感到如此兴奋，以至于编码比以往任何时候都多，那太棒了。我希望每个人都感觉那样，无论他们如何到达那里。

How to be a good AI leader

让你所有工程师 constantly anxious about their performance 对你的公司不好。它会让你的工程师不想为你工作。这是一个短期思维的配方，将鼓励工程师最大化坏指标，如代码行数。代码审查将被忽视，技术债务将 compound，从长远来看，整个公司将 footing the bill of those errors。

不切实际的10倍期望将 without fail 导致匆忙 thus subpar 工作。工程师需要有 room to breathe。Room to take a little bit more time to do the thing right。好的代码库和好的公司建立在今天和明天思考的健康平衡上。我很感激现在在这样一个公司工作，但许多人不是那么 fortunate。

不要 scold engineers for not using enough tokens。你的工程师是高度教育的专业人士，在一个极具竞争力的领域。软件工程师已经 infamous for an over-eager cycle of embracing and abandoning new languages and tools。如果你付这些人这么多钱，你应该信任他们，如果有一个超级惊人的生产力提升可用，他们会来找你要求专业计划。如果你担心错过所有其他人似乎正在获得的AI编码收益，注册一个LLM团队计划，举办一个培训课程，看看结果如何。这就是你需要做的一切。

Conclusion

没有秘密的草药 medicine that prevents all disease sitting out in the open if you just follow the right Facebook groups。没有AI编码革命 available if you just start vibing。你没有 missing anything。Trust yourself。You are enough。

哦，不要 scroll LinkedIn。或Twitter。Ever。

← Previous Tailwind is the Worst of All Worlds