AI 编码将导致开发者技能崩塌
Coding expertise is going to collapse from AI reliance
当前行业存在一个悖论：新手被要求使用 AI 工具以保持竞争力，但有效驾驭这些工具恰恰需要深厚的专家经验。JetBrains 的研究发现，过度依赖 AI 的初级开发者往往陷入“能力错觉”，跳过了关键的规划与调试阶段，导致真正的理解缺失。相反，那些刻意保留学习摩擦、将 AI 仅作为苏格拉底式对话伙伴而非代码生成器的开发者，反而能更好地掌握技能。如果我们将 AI 视为消除所有困难的捷径，而非辅助思考的工具，那么培养下一代专家的路径可能会彻底断裂，最终导致技术传承的崩塌。
对于软件工程或其他行业的初级从业者而言，我们的研究提供了关于利用 AI 工具进行有意识技能培养价值的一小份证据：认知努力——甚至是痛苦地卡住——对于培养精通至关重要。
HN 评论区
533- ryandvm
100% 同意。
我们已经在企业级层面看到了这一点。公司高层下达指令：“如果你还在手动写代码，那你就是做错了。”
好吧，这种做法在一段时间内确实行得通。我们确实在疯狂产出代码，但现实是，工程师产出代码的速度已经超过了人类理解和（老实说）审查的速度。这听起来很棒，直到你意识到“嘿，Claude，读一下这个 Jira 工单，并在代码库中实现这个功能”这种工作，其实并不值年薪 20 万美元。
情况变得更加复杂，因为我们从另一个方向也失去了对现实的把控：高层空投 AI 生成的宣言给产品负责人，而产品负责人不得不使用 AI 把这些垃圾转化为 1500 字的 Jira 工单，其中只有 10% 是必要的功能工作，剩下 90% 都是 LLM 生成的套话。
于是，软件工程师的工作发生了根本性的改变，以至于现在做软件工程师最难的部分，仅仅是过滤来自四面八方的 AI 生成产物，只为把功能推上线。
- apatheticonion
我看到大家非常强调无头代理（headless agentic）或“氛围编程”（vibe coding），但我没看到有人在讨论“引导式编程”（guided coding）有多棒。
我有超过 15 年的软件开发经验，我发现引导式编程会话——即使用集成了 LLM 的编辑器（如 Zed 或 VSCode），像往常一样写代码，但利用快速模型（flash model）来消除繁琐部分或进行规划——和氛围编程一样高效，产出的质量显著更高，实际上更令人愉快，而且能保持你的敏锐度。
快速模型（如 DeepSeek v4 flash）通常快到你没时间并行运行多个代理，你会锁定目标并快速连续发送提示，在逐步审查的同时构建高质量软件。你可以否决（VETO）糟糕的修改并重试，或者手动重写。
相比之下，我注意到无头代理编程往往是一个无法审查的黑盒。我发现的主要问题在于，即使有人类参与循环，缺陷也会不断累积，最终你不得不花费数百万 tokens 去修改一个僵化代码库中的琐碎问题。
归根结底，像 Qwen 的 27b/a3b 系列或 DeepSeek flash 这样的小型、高度缓存、快速的模型能力很强且运行成本相对较低。希望人们能意识到我们不需要 14 万亿参数的模型，这样我就能给我的工作站买些内存了。
- xyzelement
// 长期技能形成中持续摩擦的必要性。
故事的副标题已经说明了一切。
有些人会主动寻求摩擦。想想运动员或硬核极客。
最好的工程师是那些小时候就对计算机和学习着迷，并抓住每一个机会去追求的人。换句话说，他们自己找到了摩擦点。
对于这类人，寻求摩擦是常态，而 LLM 所做的只是移动了摩擦发生的位置。
例如，我合作过的最好的工程师并不一定拥有大量的汇编语言编程经验，因为那种摩擦已经不再必要。但他们能解决难题（如果问题真的需要汇编，他们也能去学）。
我认为受 AI 冲击更大的将是低层级的工程师。那些从未真正好奇和投入，仅仅把这当作一份工作的人。例如典型的海外工单搬运工。这类人从未主动去寻找摩擦，而这种做法以后将彻底行不通——如果我想要平庸或平均水平的东西，LLM 就足够了。
- LandoCalrissian
LLM 软件开发中“蛇吞尾”的现象，每次被提起时似乎都只得到一声耸肩。最好的情况是，可能有一小部分开发者拒绝用 AI 烧坏自己的脑子，而他们得到的回报似乎就是不得不去审查那些由烧坏了脑子的人写出的糟糕 AI 代码。
这完全不可持续。
- TonyAlicea10
作为一名技术教育者，我 100% 同意。LLM 不会变成一个“新编译器”，让我们不再需要关心代码。我们信任确定性系统是有原因的。
我一直对此非常担忧，甚至创建了一个名为 do-i-understand 的代理技能，专为新手开发者设计（也适合老手，因为技能会退化），LLM 会向你提问关于你即将提交的 PR 的问题。我发现这很有帮助：https://github.com/AnthonyPAlicea/skills/blob/main/skills/do...
无论如何，一场技能清算终将到来。
- aledevv
我强烈同意“认知摩擦是学习的引擎”这一概念。
首先，这是一个“依赖”问题：如果你停止锻炼逻辑和推理的“肌肉”，它就会逐渐萎缩，就像不用的身体肌肉一样。你会依赖外部工具，而这些工具取代了你曾经拥有的能力。
一个带来类似转变的历史例子是：当生产过程从工匠的头脑和双手转移到福特式工厂（和流水线）时，制造东西的技能从人类工艺转变为匿名的、结构化的流程。
一点一点地，传统工匠失去了他们的知识和“诀窍”。如今，家里有一件家具依赖于庞大的生产和供应链；“普通”人不再有能力自己制造它。
软件领域正在发生完全相同的事情。
我们是（现在的“前”）软件工匠。
- socketcluster
我的经验是，AI 显著提升了高质量代码库的价值。一个好的代码库基本上能自我编码。
有些我从零开始构建的项目，我会很放心地交给一群非技术的“氛围程序员”，我知道他们会很高效，产出也是安全的；因为现有的代码库已经体现了我关心的所有模式和原则。
如果在其之上添加大量氛围编程的逻辑，它可能会随时间缓慢退化，但我认为他们在功能方面可以走得很远，同时保持软件的可靠性。
尽管此类代码库的价值增加了，但人们还没有适应这一新现实。人们很糟糕，无法辨别什么是好代码。但真的很简单：好代码就是易于扩展和维护的代码；而且现在我们应该能很快检查出来，因为我们可以如此快速地迭代。
如果实现一个功能需要消耗大量 tokens，那么代码库很可能就不够好。
- oscillonoscope
我认为 AI 最可能的后果是促进通才的出现：那些拥有领域专业知识、能跨学科工作，并具备足够的编程知识来引导 LLM 的人。我不认为“纯”软件工程师会像过去十年那样被高度重视，但我认为这对其他学科也是如此。举个例子，在信号处理领域，通常是一个人设计通用算法，另一个人专门负责在嵌入式系统中实现该算法。随着编码代理质量的提升，不再真的需要这两个人了。现在，一个在两方面都有中等经验的人就能完成这项工作。
- vain
这似乎可悲地非常真实。
就在昨天，我在实现一些稍微棘手的 javascript（不是我的主要语言），在悬停时显示每侧 n 个邻居，如果一侧有缺口，则扩展到另一侧。在挣扎了大约 20 分钟试图把偏移量调对之后，我屈服了，直接让代理帮我做。
我相信我仍然能做到，但很伤心我没有像以前那样快速搞定。退化可能已经在起作用了。
- xtracto
是的，但这无关紧要。
用编程语言写代码是一种技能/必要性，是我们为了告诉计算机我们要它们做什么而创造出来的。
最初在 60 年代，这是通过以某种方式连接电路来完成的（想想 ENIAC）。然后我们设计了“可编程”计算机，并发明了一堆代码（计算机指令代码）来抽象掉那些电缆。
我们创建了编程语言，以进一步抽象硬件复杂性，并能够以人类之间更易传递的方式写下我们的愿望，同时仍能被机器计算。
但随着 LLM 和神经网络的出现，在某个时刻，这些抽象将不再必要。
计算机仍然会进行计算，但我们告诉它们想要什么的方式将会进化。
这很迷人。