亚马逊CEO称用AI取代初级开发者是“最愚蠢的想法之一”
招聘应届毕业生能为职场注入新思维。他们带着最新趋势塑造的创新理念，怀揣着开拓进取的动力。
亚马逊云服务(AWS)首席执行官马特·加曼驳斥了AI将取代初级开发者的观点，并阐释了AI在工作场所的正确应用方式。
加曼列举了企业不应削减初级开发者岗位的三大关键理由，强调他们“实际上是最熟悉AI工具的群体”。
人工智能不应取代初级开发者的三大理由
在科技界痴迷于人工智能取代人类劳动力的当下，亚马逊云服务(AWS)首席执行官马特·加曼正反驳着业内最流行的成本削减理念之一。
在《连线》杂志《大访谈》播客中，加曼向那些急于用AI削减成本的企业发出警示：
当被问及为何曾将用AI取代初级员工称为“最愚蠢的主意之一” ，并阐述他如何认为具有能动性的人工智能将在未来几年真正改变职场。
1) 初级开发者往往更精通人工智能工具
首先，初级员工通常比资深员工更擅长使用人工智能工具。
“第一点，根据我的经验，许多最年轻的员工实际上对人工智能工具最为熟练。因此他们最能发挥这些工具的最大价值。”
应届毕业生成长于新技术环境，因此适应能力极强。许多人在求学或实习期间就接触了人工智能工具。他们热衷探索新功能，寻找高效编码方法，并善于挖掘人工智能助手的最佳应用场景。
根据2025 Stack Overflow开发者调查，55.5%的初级开发者表示在日常开发中使用AI工具，比例高于资深开发者。
对新工具的熟练掌握使他们能更高效地工作。相比之下，资深开发者已形成固定工作流程，可能需要更长时间适应新工具。最新研究显示，超过半数的Z世代员工正在帮助资深同事提升AI技能。
2) 初级开发者不应成为默认的成本削减手段
其次，初级员工通常是成本最低的群体。
“第二点，他们通常成本最低，因为刚毕业的应届生普遍薪资较低。因此若考虑成本优化，他们绝非唯一需要优化的对象。”
初级员工的薪资福利通常较低，因此裁撤他们并不能节省大量开支。若企业试图通过此举省钱，从财务角度看并不划算。
因此，当企业谈论提高利润率时，初级员工不应成为默认或唯一目标。真正的优化与成本削减需要审视整个公司，因为还有许多其他可削减开支的领域。
事实上，30%裁员以期节省开支的企业最终反而增加了支出，其中许多后来不得不重新招聘。
3) 裁撤初级员工将断绝人才输送渠道
*第三，企业需要新鲜血液。 *
“第三，这种做法终将自食其果。若企业既不建立人才储备体系，也不培养并提拔基层员工，往往会发现这些群体才是最佳创意的源泉。”
不妨将企业比作运动队。若只保留资深球员却不招募新秀，当老将退役时会怎样？届时将无人懂得如何继续比赛。
此外，招聘应届毕业生能为职场注入新思维。他们带着最新趋势塑造的创新理念，怀揣着开拓进取的动力。
更重要的是，他们构成了企业未来人才储备的基础。若企业彻底停止招聘初级员工，等于切断自身人才输送管道。长此以往，内部晋升的领导者将日益匮乏。
德勤报告指出，美国科技从业人员增长速度预计将达到整体劳动力增速的两倍，凸显了技术人才的紧缺。若缺乏强大的初级开发者储备，企业恐将面临技术人才短缺危机。
当前若未能培养足够的初级人才，团队未来将难以填补岗位空缺——尤其当项目规模扩大时。
核心结论
这绝非空谈。作为全球最大云计算平台之一的掌舵人，加曼亲眼见证着从奈飞到美国情报机构等各类企业如何实际运用人工智能。
而他所见所闻令他忧心忡忡——短视思维可能给企业未来数年带来损害。加曼的观点植根于长远战略。若企业仅依赖AI处理任务却不培养新人才，终将面临人力短缺。
尽管如此，加曼承认未来几年仍将充满波折。“你们的工作将发生改变，”他表示。他相信AI不仅能提升企业生产力，也能增强员工效能。
当技术让某件事变得更容易，人们就会想要更多。人工智能能加速软件开发，使企业能够推出更多产品、开拓新市场、服务更多客户。
开发人员将承担超越编码的职责，快速适应新技术将成为关键能力。但最终他传递出充满希望的信息。
正因如此，杰弗里·辛顿强调计算机科学学位仍不可或缺。这与马特·加曼的观点不谋而合——未来高价值岗位亟需掌握核心基础知识的新锐人才。
“我坚信在中长期内，人工智能创造的岗位数量必将超过其最初淘汰的岗位”，加曼如是说。
人们在讨论“用AI取代初级员工”时忽略的关键在于：初级员工的价值从来不在于廉价的键盘劳动力。他们是组织中唯一能毫无顾忌地提出“愚蠢问题”而不丢脸的人群，而这些问题往往是你发现抽象概念毫无意义的唯一信号。
AI的作用在于消除初级工程师那些屈辱又枯燥的日常：通过盲目模仿Stack Overflow寻找正确API、埋头处理模板代码、因遗漏导入语句而耗费数小时。若模型能为他们压缩搜索空间，你就能把更多入职时间用于讲解“系统架构的实际逻辑”，而非“我们公司风格的for循环用法”。
若你建立这套体系后却决定“太棒了，现在完全不需要初级员工了”，本质上就是在打造一家没有记忆、没有培养体系的公司——只剩不断缩小的资深圈层争论战略，却无人能真正成长为他们。
我总爱在https://hackernewsai.com/通讯里加入优质的人工智能与工作主题讨论。
“不丢脸”？你指的是哪种文化？我在西方公司工作时，这类提问从未被禁止——事实上，当资深人士提出他人习以为常的“愚蠢”问题时，往往恰恰彰显其高见。
完全赞同这个观点，我发现正是资深人士会提出“愚蠢”问题。在这个动荡的经济环境下，人人都担心丢脸…但资深人士同样能提出极具洞见的问题，因此即使他们的“愚蠢”问题也显得睿智…他们通常能通过深入一层、引入讨论细节，将愚蠢问题转化为精妙提问。这对初级员工而言可能很困难。
作为带领众多初级员工的团队负责人，我的经验是：他们极度害怕丢脸，往往喜欢夸夸其谈。作为团队负责人，我刻意用语言表达自己的疑虑和知识盲区，以此营造团队成员坦诚交流的氛围。但关键在于你必须在特定领域真正精通——因为你需要激励他人效仿你的专业态度…若他们不认可你的技术实力，就不会尝试效仿你。
在我看来，只有在某些领域展现出深厚的知识储备和卓越的推理能力后，才能放心地提出看似愚蠢的问题。我努力发掘团队成员各自的优势与不足。对于不足之处我会提出建设性批评，但始终致力于识别并认可每个人的独特超能力——那些让他们在团队中真正脱颖而出的特质。当人们对自己的“超能力”充满信心时，即使在其他领域表现欠佳，他们依然能保持自信。但准确识别“超能力”至关重要——既要避免让初级员工苦练天生缺乏的技能，也不该让他们在该求助时妄下结论。
深有同感！这既源于我多年前作为初级员工的经历，也来自如今与初级(乃至非初级)员工共事的观察。
吹得可大了。克劳德也是。他用极具自信的语气喷出的胡言乱语简直令人惊叹。
赞同。我常直接说“蠢主意：X”来试探那些被忽略的盲区、未充分探讨的领域，或是未经验证的臆断。令人惊讶的是，即便是资深人士也常把臆断当成事实宣扬，这实在令人恼火。
但具体该怎么做呢？我很想实践这种方法，却苦于找不到真正的“超能力”。比如如何区分“超级能力”与“比别人强但远不及我/X先生那种真正拥有超能力的人”？究竟该在什么阶段开始鼓励这种做法？
你提到克劳德(LLMs)这个例子很有意思！我确实觉得存在某种相似性——或许正因为AI有时会产生幻觉，人们也逐渐对人类这种投机性语言使用方式产生了容忍度。
关于发掘每位团队成员的超能力；与某人共事数月后，我开始注意到他们思维方式中的某些规律。有时他们随口一句或某个提问，便让我对他们改观。或许他们思维敏捷擅长组装，或许动作迟缓却精于构建稳定的核心组件。或许他们与我相似，或许他们拥有我缺乏的技能，又或许他们对问题的关注点或解决方式与我迥异，但这些特质对项目和团队都大有裨益。
这有点像玩一场奇特的国际象棋游戏：开局时看不清棋子，所有人初始都像兵卒；但随着时间推移，你发现某人是骑士，某人是主教，某人是皇后……当视野逐渐清晰时，你便调整策略。
完全赞同。有年夏天我曾与IBM杰出研究员紧密合作，他会议中勇于提出“愚蠢问题”的姿态令我印象深刻。有时他确实信息闭塞，但更多时候他是在质疑会议室里其他人习以为常的默认假设。
遗憾的是，IBM那种“思考至上”的文化在其他机构很少能见到。如今我仍常怀念这种氛围。
不过强制响应时间和每年仅10天休假，足以让我望而却步 😉
百分百赞同，若能给更多赞就好了！
即便身为主管，当无人发问时我仍会提出看似愚蠢的问题——因为当我看到众人面露难色或意识到无人回应时，便明白这种问题能确保核心观点深入人心。我从未因此遭受轻视，也绝不阻挠团队成员发声——恰恰相反，我始终鼓励大家勇于表达。
公平地说，这些问题听起来并不“愚蠢”。
有些问题确实愚蠢，毫无价值可言。
关键在于分辨二者差异，而这需要经验积累。
> 有些问题确实愚蠢，毫无价值可言。
但它们确实能告诉你：提问者要么尚未理解(这本身就是有价值的信息)，要么只是为了提问而提问(这也同样有价值)。
这正是楼主所言——这类问题往往不可或缺，但资深人士不会问，因为会丢脸。只有新人有资格“不懂”。
这取决于公司文化和团队氛围。在某家公司，我的季度反馈是“会议提问太少”，主要因为项目流程简单且需求文档明确。而在另一家公司，提问却让我收到反馈说我可能经验不足，无法独立管理项目——而我完全有能力做到。这真是把双刃剑。
但就个人而言，作为资深从业者，我宁愿在问题爆发前因提问被认为能力不足，也不愿因提问不够而在执行项目时管理失当。坦白说，后者的后果更严重。
> 我的季度反馈是“提问不够多”
听起来你的经理觉得有必要给出反馈，而这已是能想到的最安全说法。
即便企业文化鼓励提问，愚蠢的问题依然不该问。
有些问题能彰显资历与成熟度，另一些问题若被问出，只会让人疑惑：过去N年你到底在干什么？凭什么拿高管薪水？
许多问题的早期征兆——比如关键信息沦为内部秘传而非文档化——往往在提出后者时暴露无遗。
公司文化。我待过的某些公司会因质疑决策而解雇员工，另一些则欢迎批评。除非有人开口，否则你永远无法真正了解所处环境。你敢冒这个险当第一个吗？
> 你是否愿意冒险成为第一个发声者？
当然。若我所在的公司糟糕到质疑决策就会被解雇，那最好尽早发现。这种公司不值得我投入时间和精力。
是的，因为我宁可不去那种公司，另谋高就。
在当前市场环境下，你可能别无选择，只能硬撑一阵子
想象一下高度竞争的环境，在那里显得愚蠢可能会被当作武器对付你。这种情况确实存在(我亲身经历过英国和澳大利亚的情况)
就我个人而言，IBM澳大利亚分公司不鼓励提问，而埃森哲、康科迪亚、安永、澳大利亚联邦银行、澳新银行等公司都鼓励提问。
我不会说在澳大利亚大多数地方，不鼓励提问会成为常态。
我整个职业生涯——无论在新西兰还是澳大利亚——提问都被当作武器(正如我上述所言)
无论毕业生、初级职员、资深员工还是团队负责人——我的头衔对回应方式毫无影响
你身处的是有毒的工作环境。大多数职场并非如此。
(我相信你说的大多数情况确实如此。)
组建工会
上面描述的那些充满关怀、支持员工自由探索新想法、质疑假设的工作环境，简直像天堂。
或者只是戴着粉色眼镜的理想化。
如今我资历稍深些。
每当遇到不理解的事，我会这样说：“呃，可能只有我搞不懂，但这点我实在不明白…”
身为CTO，我最常说的就是“帮我理解X”
担任高管时会涉及权力动态。你有权提问，但对初级员工而言，提问往往意味着技能/经验不足的评判。资深人士常忽略这点：提问者被默认具备一定能力，而新人则不享有这种默认权限。
我最爱的CTO/CIO缩写是“PFM”。比如：“接着我们运行PFM流程，输出结果就能实现…”
PFM——纯粹的魔法
至今仅有人问过一次缩写含义…本质上它用于抽象化复杂流程，若逐条解释反而显得冗余。
会议结束后我主动询问了。
糟糕的工作环境比比皆是，这类公司常会用AI取代初级开发者。
我所在的公司正处于新CEO的拆解过程中。公司不会倒闭，但未来12-18个月我们只能自焚求生。
没错，我的高级客户总监老板常说"我是个白痴。能解释下’X’代表什么吗？虽然大家可能都想知道，但都怕问出口。
作为经常提问的人，我深有体会。说到底我并不自负，所以几乎都会主动求解——尤其遇到缩写或行业术语时… 通常我会先用浏览器快速搜索，但若结果仍不明所以，就会直接提问。
“愚蠢的问题”几乎与“先斩后奏总比事后求饶容易”是相辅相成的。很多时候，直接行动反而更好。提出简单问题或推动事情进展，往往能避免更多麻烦。理解至关重要。
我认为这不同。我会抛出疯狂想法，但核心知识/专业能力扎实，尽量避免信口开河。(若涉及非专业领域，我会主动说明。当你的话语开始产生影响力时，明确标注这一点很重要。)
产品经理说出某些话时，确实会让我对这位资深工程师的敬意打折扣。
我也理解初级工程师在完全不懂领域时更敢于发表意见。疯狂创意和建设性批评值得鼓励，但达到一定层级后，我开始期待更基础的专业能力。
知识领域如此多元，局限于单一专长实属狭隘；那些默默耕耘五年、维持大型构建农场运行、迁移项目并协助修复工单的“慢热型”从业者，往往拥有你浅尝辄止时所缺乏的深厚经验。
企业文化 ≠ 国家文化 ≠ 个人文化。这些概念可能千差万别。
我曾与韩国同事共事，当我指出架构过于复杂导致开发效率下降时，他们完全采纳了我的意见。虽然最终保留了原架构，但他们并未表现出任何难堪，反而努力论证其合理性。
我也合作过英国、希腊和俄罗斯同事，他们完全不愿听取同事反馈，只会发号施令。
即便是同一个人：我认识一位自称共产主义者的人，除了政治话题外对任何事物都持开放态度。
我表弟刚入职第一天，就把数据库清空了。(经典案例，我懂)
前辈们非常理解，更重要的是这引发了关于备份、开发环境与生产环境管道等关键问题的讨论。
但可以肯定的是，我表弟为此感到极其尴尬，挽回颜面成了他最关心的事情。
真正该感到难为情的是那些前辈——他们竟给任何人，更别说初级员工，授予如此高的权限。
我绝对干过这事！谁需要在MySQL数据库里再建个叫“mysql”的数据库？删掉它，入职首日干得漂亮！
我发现情况各不相同。
Meta？随时提问题。
亚马逊？倒不那么鼓励。
天真也有好处——比如新人未经百般磨砺时敢于大胆尝试。真怀念那种充满激情与乐观的状态。
Facebook的“小红书”里有句类似的话：
当你尚未意识到自己做不到什么时，反而能成就非凡之事
这点至关重要却常被低估。有些视角唯有通过未经世事的眼睛才能看清。
但反过来说，若我们稍有不慎，新人就可能在其他业务部门制造出极不切实际的期望 😉
文化因地而异。
说不清…这似乎是Hacker News上推崇的模式，但我任职过的多家美国公司都未见此风。人们确实害怕显得愚蠢。“丢脸”或许被视为东方文化特质，但实际运作中这里也如出一辙。
我遇过最棒的副总裁常在会议中突然停下说：“或许我是这里最笨的人，但我不明白[讨论内容]，能帮我理解清楚吗？”
没人知道他是真不懂还是在试探气氛，但这种态度总是令人感激。
我整个职业生涯
“你他妈的问这个干嘛，这种事你应该知道”
或
“你他妈的为什么不自己查”
编辑：网上专门有个章节收录“LMGTFY”回复，因为总有人问这种问题。
或
“这他妈的不是明摆着的吗”
或者
“我他妈非得给你拼出来吗”
我很有可能患有自闭症，这意味着——是的，我需要别人表达得更明确些。
AI在帮我捕捉那些通常会忽略的潜台词方面做得相当出色。当我提出真正有帮助的问题时，收到的负面反馈也减少了。
完全颠倒的视角：
> “你他妈的问什么？这种事你应该知道”
因为你提到了新西兰：我父亲是工具制造师，他说欧洲和新西兰有天壤之别。在德国/荷兰，他会受雇于资历更深的工具制造师。后来他在新西兰工作时，像在欧洲那样向老板请教问题，却得到了这样的回应：因为老板才是专家，而他的新西兰老板只是个管理者。
提问是好事，但并非所有问题都该问。显然，那些通过谷歌搜索或阅读文档就能解答的问题不在此列。
明白了——该问就问，但别问那些你其实已知答案的问题。
编辑：当然，除非你在文档里搜索时得到(字面意义上的)70+条结果，只因你不知道自建维基里使用的确切表述…
或者当问题涉及特定领域知识时(即该领域专家理应知晓，而你只有成为专家才能掌握…)
等等
提问时请提供背景信息。
例如："嘿鲍勃，我查了这里、那里和别处都没找到正确信息。能否指引我查找方向或直接告知答案以便我记录下来"
因为多数人在提问前连最基础的自查都不愿做，导致重复解答相同问题成为巨大困扰。
但若能证明你已先行努力查找答案，他人将更乐于提供帮助。
目前我在这条讨论串里已看到两个例子，有人对提问者做出(可能带有攻击性的)评判
能否说明你为何认定对方提出的问题未被解答？
能否解释为何你的回应是做出尖锐评判，而非先弄清事情原委？
>明白了——提问题可以，但别问那些你早已知晓答案的问题。
更准确地说，提问前请先快速谷歌搜索或查阅文档。若简单搜索或查阅文档仍未找到答案，再提问。
我曾供职于一家公司，员工在全员开发邮件列表(该列表存档可检索，实际上不断积累着知识库)上提出基础问题时常遭批评。公司更倾向于让员工向同团队同事求助。即便解答他人疑问者也会因“乐于助人”而受责。这两类批评主要来自管理者而非开发者，且通过上司直接反馈给当事人。此外，这种文化还存在传播问题——不知为何(/s)，它难以向新人传递良好的技术理念和共同的技术愿景。
> 他们是组织里唯一还能问“蠢问题”而不丢脸的人
我强烈反对这种观点，在我看来，一个不敢问“蠢问题”的高级开发者根本毫无价值。尽管问吧，我们需要共同探索，又不是读心术。我认识的优秀资深开发者都会提问并坦承未知。这种谦逊在我看来正是优秀资深开发者的核心竞争力。我们工作的本质就是不断提问(通常是对自己提问最多)并找出答案(即代码)。
初级开发者本应多提问，而当你成为资深开发者时，无论问题听起来多么愚蠢，你问的都是关键问题。
你和被你回应的人观点一致。对方说资深开发者可以问愚蠢的问题，而初级开发者往往不敢提问。
> 人们在讨论“用AI取代初级员工”时忽略的关键在于：初级员工的价值从来不在于廉价的键盘劳动力。他们是组织中唯一能提出“愚蠢问题”而不丢脸的群体，而这些问题往往是你发现抽象概念毫无意义的唯一信号。
这观点在我看来几乎完全错误？任何层级的员工都能提出“愚蠢问题”并揭露“荒谬抽象概念”，这本应是健康组织的常态。若仅有新人能做到这点，不仅荒谬，更是本末倒置。我认为资深员工才最清楚抽象概念是否合理，而非新人。
业务新人应当有勇气挑战企业长期积累却不再质疑的假设。
然而他们往往最缺乏安全感——不知该问题会惹恼谁、让谁难堪、使谁难堪，尤其当问题暗示某些历史决策存在谬误时。
这点极具价值却常被忽视。我建议中级、高级及资深工程师持续质疑决策，并营造鼓励质疑的文化氛围。
初级开发者若身处这样的文化环境会自然而然地质疑——毕竟他们尚未形成固有认知。这正是可贵之处。
> 我建议中级、高级及资深工程师持续质疑决策，并营造鼓励质疑的文化氛围。
别告诉我你没在FAANG工作过，却又说你没在FAANG工作过…
我在几家FAANG公司工作过，只要以建设性且专业的方式提出质疑，这种行为几乎总是被视为积极的。
但当决策已定且你的顾虑已被听取后，若仍拒绝接受该决策，这种行为就不会被认可。若你反复纠缠同一问题，人们会感到恼火。
我给工程师的建议始终是：
你的职责是确保决策者(而非你本人)掌握做出合理决策所需的信息。你应当坚持辩论的情形是：(a) 有充分理由相信重要信息未被听取或理解，或 (b) 新信息浮现且你确信可能改变决策。若不存在上述两种情况，即使你不同意管理层的决定，也应承认自己已完成本职工作，让管理者履行他们的职责。只有当(a)或(b)发生变化时才需重新提出，在此之前切勿轻举妄动。
我从职业生涯早期/L4级别到资深工程师/L7级别，在FAANG公司的基础设施部门历经多个团队，始终因勇于提问而受到鼓励和奖励——即便这些问题曾导致数百万美元的意外成本，甚至有一次造成全网计算能力约1%的损失。
我认为关键在于提问方式。必须通过保持好奇心、研读文档等方式花时间理解现状及他人视角，而非像许多人惯常那样，以提问为幌子强行发号施令。
或许我被当作御用弄臣，所以才能肆无忌惮地质疑——不过我认为并非如此 🙂
问题如何导致损失？是你的提问揭露了已存在的问题，导致团队不得不修复？
正因如此，我们中有些人刻意避开FAANG公司。
我从未在FAANG公司工作过，也无意加入。
我曾在Stripe任职，该公司某些方面做得相当出色。但即便在2022年，它仍像家巨型企业，因组织领导层问题而丧失了部分初创精神。我不得不引导工程师们重拾这种曾被吓退的脆弱感。但建立信任本就是领导力的体现，优秀人才往往渴望质疑并推动改进。
身为FAANG的资深工程师…别跟我说你没在FAANG工作过，除非你根本没在FAANG工作过。
我曾就工作与生活平衡发表演讲——我坚信这些观点，必要时甚至会与总监及以上层级争论(虽然很少发生)——演讲中关键部分在于阐述：当你能明智地描述自身知识、技能和预估能力的局限时，整体表现会变得多么出色。
若因此受罚，说明你只是身处烂职位，遇上烂上司。别把这种情况归咎于我们其他人。
通常质疑决策的人会被驳回，是因为他们缺乏对决策的全局理解，且(恕我直言)缺乏有力论据。这仅仅是因为他们聚焦于业务的某个狭窄层面，导致视野和认知受到扭曲或局限。
航空业作为监管最严的行业之一，要求机组人员接受明确培训：即使面对自认更专业的上级，基层人员也必须勇于提出疑虑。
许多重大事故正是由此引发。比如特内里费空难中，飞行工程师通过无线电听到跑道未清的疑虑却被过度自信的机长无视。
这种思维模式精准揭示了为何一群高智商人士在无人质疑时仍会做出灾难性决策。面对质疑者，不必纠缠于其论点的漏洞，而应关注他们掌握的、你尚未获取或未深入分析的信息。若你确信掌握了组织所有信息，大可独断专行；或许你会像2000年后的史蒂夫·乔布斯那样幸运。
> 这仅仅因为他们聚焦于业务的某个狭窄层面
但这难道是坏事吗？当技术决策存在下行风险时，我合理期待：
– 受影响的利益相关方提出异议
– 决策者安抚其顾虑(理想路径)或分级处理并上报
我认同你的观点。即便多数质疑未必能为企业带来最佳折中方案，仍值得鼓励人们对决策提出质疑。
这确实是最理想的情况。
质疑固然重要，但另一面是有人借提问之名推行个人议程——针对已被其他/更高层人员反复讨论的议题。这种情况终需处理。可我看到的只是叽叽喳喳的提问在浪费会议时间。
> 质疑决策者通常会被驳回，因为他们缺乏对决策的全局理解，且(恕我直言)缺乏有力论据。
往往需要数月运作失灵，直到客户宣告“不再与你们合作”，或是“超时超支”问题突然膨胀到数据层面暴露出危机。或是直到核心团队突然彻底瓦解。我目睹的每一次崩溃前，都有人试图沟通却遭压制。
这并非管理层永远“全面正确”，而下属只是视野狭隘或论据薄弱——他们通常根本不知基层实情。无论是因情绪抵触还是嫌耗时，管理层拒绝倾听的情况屡见不鲜。
我无法量化“通常”的程度，但在我公司质疑决策者往往遭到打压，因为决策者通常(绝非双关)能力匮乏，而质疑恰恰暴露了这一点——即便并非本意。我所知的许多企业腐败至极，能力出众者反而被视为威胁现状的危险分子。
我们大多数人都没做到，你真行
我认为存在两种模式：
其一是“每队一名初级员工”模式。我支持这种模式，理由恰如你所述。
另一种模式我最近见过，是初级与资深工程师70/30的比例。资深工程师负责任务分配，所有执行工作都交给初级开发者。这会形成“要么晋升要么离职”的压力，几乎没有指导机会。如果70%的工程师经验不足四年，团队运作会相当艰难。
第二个模式基本上就是医院模式。
由一位资深医生监督四名实习医生。例如手术室就采用这种模式：设置四个手术室，配备四名经验较少的麻醉师，再安排一位资深麻醉师轮流值守四个手术室，并在紧急情况发生时随时待命。
坦白说，我认为大家都在只见树木不见森林。年轻医生的核心价值并非“提问”，而是成长为合格的资深医师。
这也解释了为何当前行业普遍推行的“削减四分之三年轻医生编制”政策，终将引发极其严重的反噬效应。人工智能/大型语言模型终将撞上天花板(其实早已撞上)，届时所有人都会争抢资深员工，却发现人手枯竭——因为没人愿意承担培养新人的“负担”。你以为现在的开发者薪资已经离谱？再等四五年就知道了。
弗雷德·布鲁克斯曾提出“外科团队”架构：随着成员经验增长，他们会“分化”出新团队——即最资深的“外科医生”最终离开原团队，成为新团队的“外科医生”。
《人件》终究不可能面面俱到。
医院模式或许可行，但让资深程序员带领众多初级人员处理多数任务的模式则不然。我认为更接近真实医院团队的模式——由不同领域的专家组成团队，辅以若干初级成员——成功概率会高得多。
> 更接近真实医院团队的模式，由不同领域的专家组成
这并非医院运作模式。外科部门不会组建跨学科精英团队来指导新手外科医生，只会安排资深外科医生带教经验较少的同行。
实际存在的是跨部门协作/交接机制，以及肿瘤外科医师这类跨学科角色。
同理，开发运维资深人员也不会培训前端初级人员。
手术团队包含外科医生、麻醉师、负责器械管理的护士(监督手术器械使用)、可能还有设备管理护士。这些成员之间不存在初级与资深的从属关系。
我的运营团队采用第三种模式，灵感源自德国工匠体系。团队分为初级工、熟练工和大师级。初级工通常毫无头绪，需要具体指导，例如“这里有28个标记点需在混凝土中安装螺栓，按要求完成，我将解释原理”。熟练工应能制定项目解决方案，并向大师级挑战以验证其是否符合大师的质量标准。
实际操作中，每名大师可带一至两名熟练工。而这两三人又能反过来指导三至四名初级员工完成有效工作。
这种模式也为员工在公司内的成长提供了自然路径：初始阶段执行标准指令，随后参与遵循既往成功标准的项目，最终成长为项目标准化推动者。
我初入职场时经历过团队仅配一名初级工程师的阶段，那段岁月极具价值——让我掌握了设计与编写高性能服务的能力。此后我多在70/30模式的企业任职，被视为资深工程师。偶尔我会坐下来快速完成大型软件项目，只为确认自己仍具实力；但更多时候，我像园丁般悉心照料，期盼那些纤弱的枝条能茁壮成长为参天巨木。
关于初级员工的定义存在主观性，但我接触过的所有公司都采用70-30(或更高比例)的模式。在此评估中，我将初级定义为：技能不足以独立完成工作/多数时间需要指导监督者；资深定义为：能独立工作者。
我基本认同你的观点，但AI的混乱也恰恰说明你的抽象概念毫无意义。
问题在于人们宁愿相信AI“愚蠢”也不愿面对现实。
我同意，常规操作已不复存在，但代价是什么？理解“系统如何协同运作”意味着解决问题、阅读代码和调试。若不通过“屈辱而枯燥”的任务培养这些基础能力，初级工程师如何真正理解系统运作机制，而非仅知其表象？
我认为当前最大挑战在于资深工程师如何指导新人。AI确实降低了入门门槛，但唯有全面掌握技术栈并经历试错，才能真正成长。
在混合型拉取请求中，要判断该花时间纠正人类的假设还是AI的假设，简直难如登天。这种模式下，PR评审过程中产生的所有学习成果都面临流失风险，而我们目前尚无良策挽回(除非AI主动告知——公平地说，确实存在一些优秀的评审机器人)。
初级工程师如今向AI学习。而AI则从强化学习成本函数中汲取经验。这些成本函数由几乎毫无实战经验的博士们设定 😉
结果耐人寻味。首先，初级工程师备受煎熬。曾经沉浸式编码调试的美好体验，如今沦为焦虑等待AI是否能胜任的煎熬。
资深开发者同样痛苦——指导学徒曾是乐趣与收益并存的体验，与年轻人共事令人振奋，如今这一切荡然无存。
代码质量持续下滑，禅修般的编程状态被打破，强化学习成本函数如今高高在上。
唯一快乐的只有那些不幸的博士们 ;$
我感受到这篇帖子潜藏着大量怨恨/包袱。
难道初级工程师的价值仅在于提出“愚蠢”问题来剔除无用抽象？这就是你的观点？
若真如此，我初级时期早就悠闲度日了。
初级员工通常只分到杂务或低优先级工作，而资深员工才能接触“重要”项目。
另一方面，初级员工的问题要引起重视可不容易，所以我完全不同意你的说法。
这完全取决于工作环境。有些公司会刻意给初级员工分配重要任务来培养他们。
我认为多数机构从指导初级员工身上学不到多少东西，至少在培养前几批后就不再如此。
初级员工只是…维持平衡的必要存在。若人数过少，中高级开发者的成本将不断攀升，因此企业会招聘大批初级员工，让他们在岗培训，以此实现平衡。
说真的，公司若操作得当，可能在十年间持续低薪压榨从初级晋升的资深员工，直到他们察觉时，整个行业的薪资水平早已今非昔比！
我不认同这是初级员工的核心价值。这只是不错的附加价值，而非雇佣他们的初衷。我认为真正的价值在于后期的人才培养体系，以及团队的持续壮大。
我依然认为核心问题在于经济环境。资深开发者更容易填补岗位空缺，因此招聘初级岗位的吸引力下降。所谓“用AI替代初级开发者”，或许只是行业拙劣的自保手段。
没错，AI最有价值的作用是引导人们熟悉那些他们不太了解的流行开发环境。
换言之，从AI中获益最大的是初级开发者——他们对主流开发环境仍存在认知盲区。资深开发者在新环境启动项目时也能受益，但他们每次接触的新场景仅限一两个，而初级开发者面对的则是全方位的新领域。
换个角度说，AI能让初级开发者更快创造更多价值。这反而提升了他们的价值，而非削弱。
这观点令人费解——根据我十五年的经验：资历越深的人，反而越爱提问。
AI将取代工作岗位。企业将IT/开发预算投入某项技术，意味着其他领域必遭削减。
我也不认同初级员工、年轻人、资深人士、职员、主管、杰出专家/院士等群体应被AI取代。虽然这种情况必然发生，但本不该如此。当前Gemini 3 Flash/Claude Opus 4.5级别的AI，在辅助与审核机制下已能完成多数开发者当前的工作。它无法包揽一切且会失败，但若企业不在乎后果，裁员在所难免。
别浪费时间试图用反AI论调保住饭碗。要么学习AI技术继续干活直到连管理岗位都用不上你，要么就另谋出路。
> 人们将IT/开发预算投入某项事务，意味着其他领域必遭削减。
这在正常时期并非运作规律。
但正常时期需要具备基本能力的管理者、相对竞争的经济环境以及基于实力的招聘机制。我承认这次可能如此运作，但这依然是愚蠢的做法。
身为资深工程师，我始终以提出“愚蠢”问题为荣，绝不愿在无法坦诚追求知识的环境工作。
赞同。
> 盲目崇拜Stack Overflow
此话何解？我理解的“盲目崇拜”是指制造虚假偶像的行为，例如制作木质耳机或修建跑道试图吸引永远不会降落的飞机。
这指的是将网站上的代码或指令复制到自己的项目中，却完全不理解其工作原理或应用场景。
例如：你遇到Windows系统问题。搜索后发现“sfc /scannow”似乎是解决Windows问题的热门方案。你直接运行该命令，却从未弄清sfc工具的功能、是否适用于当前问题等。这种行为就是对解决方案的盲目模仿。
我认为这种行为是指从StackOverflow复制粘贴代码片段，却不理解代码是否(以及如何)能解决问题。
编程领域的“货运崇拜”现象自80年代末便已存在。
http://www.catb.org/jargon/html/C/cargo-cult-programming.htm…
https://en.wikipedia.org/wiki/Cargo_cult_programming
人们真正忽略的并非AI取代初级员工，而是早在AI出现前几年，几乎所有行业的高管就已对招聘初级员工失去兴趣。
如今人工智能不过是整个经济问题的替罪羊。高管们发现了“一招妙计”：将初级员工的工作堆给资深员工，直到他们辞职。同时拒绝招聘新人以刺激短期利润。现在每家公司都面临同样困境：招聘一名资深员工，实际上需要五名资深员工来接替那个被分层堆积了五年工作量的人。这当然是凡人无法胜任的。如今企业甚至缺乏能培养成资深员工的初级人才。
优秀的初级员工往往专注于工作本身。他们通常没有家庭负担，能将全部精力投入工作，天真无邪的好奇心和积极进取的精神为团队注入正能量。
> 全心投入工作且怀有纯粹好奇心
他们还擅长把公司机密输入ChatGPT。
/讽刺
这其实是我早期从事销售工作后获得的超能力。
我从未接受过正式训练，所以总是一问到底直到有人彻底证明。销售本身也需要不断发掘那些不会自然浮现的问题，从而触及人们真正想要的核心——这不过是同一枚硬币的另一面。
>他们是组织里唯一还能问“蠢问题”而不丢脸的人
这正是高管、销售和客户经理的唯一职能。他们通常还带着十足的自信——随心所欲地质疑他人氛围，指挥他人氛围，全然不顾后果。
这个观点挺有意思，但“留着新人问蠢问题”绝非多数公司雇佣初级员工的初衷。
据我观察，初级员工开会时根本不敢提问。资深工程师反而更可能提出有价值的深度问题。
我们雇佣初级工程师，是为了将简单但耗时的工作交给他们处理，从而让我们能专注于更重要或更困难的问题。我们也期待初级工程师通过完成简单任务积累经验，最终掌握解决复杂问题的能力。
如果现在停止招聘初级工程师，那么5-10年后我们将失去优秀的资深工程师。
我认为初级开发者的核心价值在于：这是培养资深开发者的唯一渠道。相较于人工智能，其另一优势在于——软件工程的核心工作并非编写代码，而是处理诸如规划功能、标记问题、运行维护等其他事务。
更不用说现实中企业面临资深员工持续离职/退休的困境。培养初级员工正是为了接替公司未来的资深岗位。除非你认定企业将走向消亡或人工智能将彻底取代所有岗位，否则必须持续培育这条人才管道。
天啊。听起来你身处一家有毒的企业。我认识的中高级工程师都主动提出那些看似愚蠢的问题。我指导过的每位初级员工，我都告诫他们：最大的失败源于不及时频繁地提问。必须营造鼓励提问的企业文化。
最终趋势将是资深开发者被配备AI助手的初级开发者取代。原因恰如你所言：AI会提出那些看似愚蠢却关键的问题，甚至在一段时间后自行解决。
当开发者从重复性工作中解放出来，他们将开始追问更多“为什么”，这对整个组织而言将是极大的进步。
拿任何产品来说——近50%的功能处于闲置状态，维护这些功能实属工程资源的浪费。让初级开发者用Claude代码花三个月梳理代码库，就能找出这些隐藏的冗余功能，并主动清除或要求清除它们。
虽然需要时间摸清代码层级结构，但他们终将掌握要领。老派开发者届时只能选择晋升或离职。
为何Claude代码能帮助发现闲置功能？最终用户使用功能，而非AI。我需要从终端客户处确认功能是否闲置，而配备LLM助手的初级开发者若不向代码库添加新功能，根本无法提供此类信息。
此处将Claude代码作为近似案例。两年后，分析工具将集成到AU助手中，它们完全能够识别未使用功能。
你认为老一辈现在如何打发时间？
某种程度上，你描述的难道不是大多数行业和组织中，从业者从初级到中级再到高级的成熟过程？责任晋升的本质不正是：培养处世智慧、政治信誉和组织认知？学会避开陷阱？
我多么希望三个月甚至三年能足够长，让我彻底理解那些交错组织的缘由与政治博弈，以及支撑内部各类工作的系统与代码丛林…
肯特·贝克2025年12月12日相关博文：《押注新人价值正不断提升》https://tidyfirst.substack.com/p/the-bet-on-juniors-just-got…
> 以此方式工作的初级工程师能大幅压缩成长周期。原本耗时数天的任务如今仅需数小时完成。这并非因AI代劳，而是AI压缩了搜索空间。他们不再耗费三小时研究该用哪个API，而是花二十分钟评估AI筛选出的方案。但节省的时间并未投入到另一项低回报功能中，而是用于学习。[…]
> 若您是考虑招聘的工程经理：招聘初级工程师的回报率已提升。并非初级工程师发生了变化，而是当善用“魔法灯”时，它能加速学习进程。
在文档中摸索、学习如何及何处寻找答案，难道不是学习过程的一部分吗？
我认为，那些绕过晦涩文档困境的机器，从长远来看反而有害…
在实体书籍迷宫中筛选信息、学习如何寻找正确答案的过程难道不是学习的一部分吗？
我认为那些绕过晦涩书籍困境的学习机器，从长远来看反而有害…
确实如此。书籍蕴含大量文档中难以寻觅的阐释性内容。图书馆里相关书籍彼此相邻陈列。我不知多少次去图书馆寻找特定资料，却意外发现更引人入胜的读物。有时甚至毫无目的性地漫步书海…
作为初级研究员，我很乐意自主完成这些工作(也确实如此！)。
这类讨论初衷总是好的，学习过程中的阻力确实极具价值。但对话中的省略号似乎总在暗示我们该刻意制造阻力。
实则大可不必。我身边就有对学习毫无兴趣的同龄人，给他们增加阻力也无法强迫学习。而对那些热衷研究的伙伴施加阻力，只会适得其反。
若新人学不会，多半是因为他们本身缺乏兴趣(嘿，我理解)，而非你的培养流程有缺陷。
开始询问应聘者最喜欢的书籍吧。这是识别真正热忱者的最简便方式。
我还要补充：若纯粹以学习为目标，额外投入的时间确实极具价值；但商业™需求往往要求方案立即落地。
你对我省略号的解读有些过度了 🙂
请理解为：“谁知道你若去图书馆随意翻阅，会发现什么呢！”
我欣赏你的态度和清晰的思维。
当今年轻一代同样会遭遇棘手的困境，而这些挣扎本身就是学习的过程。问题领域自会带来足够的挑战：人为制造困境有何意义？
> 确实如此。书籍蕴含大量文档中难以寻觅的实用阐释材料
书籍常存在“骗局陷阱”——那些备受推崇的著作往往只有在你已熟悉该领域时才真正有用。
例如：我曾上当买了《Unix环境高级编程》，书中大量概念仅被展示却未作解释。真是白花钱，这本书让我后悔没在购买前先找盗版。
说到底，看几个YouTube视频再查阅操作系统手册，比读那本书有价值得多。
我怀疑其他“备受推崇”的书籍也存在同样问题。
这本应在线上实现，只要更多期刊开放获取就能做到。
其实我不同意。作为在这些期刊发表过大量论文的人，我可以告诉你：浏览期刊远不如去图书馆读一本书更能激发探索新领域的兴趣。根据我的经验，书籍往往能整合重要成果并以通俗易懂(教学化？！)的方式呈现，这是多数期刊难以做到的——尤其考虑到如今许多论文主要为积累终身教职材料和争取科研经费而写。早期论文在这方面尚可(比如2000年前的)。
我倒不反对这个观点。只是追溯你感兴趣的研究概念时，至少能更轻松地找到70年代的经典论文或教科书作为起点。
关于在线搜索结果，你也能得出类似的观察结论。
多年前初次打开QBasic时，我还是个小毛孩。在线帮助文档既没取代我信赖的QBasic教材(顶多算是补充)，也无法代写程序。它只是静静待命，等着我按下F1键。
而人工智能却截然不同…
我不确定你在此想表达什么，或者你是否试图通过声称在线文档造成的危害与使用书籍相当来贬低我的观点？
两点说明：
1 – 我认同你的观点。优质的印刷资源具有不可估量的价值，在当今时代依然完全合理。
2 – 许多资源本就不存在纸质版本，比如API文档，所以我不明白书籍在此情境下能提供什么帮助。
这确实是个耐人寻味的问题。快速精准检索信息固然有其优势，但搜索范围必然收窄，最终导致结果趋于同质化。
终有一天，我们必须设法让人工智能接受更优的新方法。这将如同人类发起宣传攻势，说服上帝为她的子民部署新指令。
> 不可避免导致结果趋于同质化
这种结果很快就会显而易见，对吧？所以真正的突破要么是推动AI突破另一重极限，要么让人类回归专业化——那些最终会变得枯燥机械的工作，直到AI赶上人类水平。
嗯，没错——这正是我仍坚持坐下来读那些该死的书的原因。机器只是用来刷新记忆的工具。
你虽是戏谑之言，却道出了本质。必须通读全书才能理解上下文。你本就该研读手册和文档——它们的存在绝非为了取悦读者。
学习如何学习
我记得搜索引擎曾遭遇类似质疑：那些积累了内部知识库的人，不愿看到资源检索变得如此简单。
质疑逻辑如出一辙：如果谷歌瘫痪了怎么办？若谷歌给出错误答案怎么办？若你对谷歌产生依赖怎么办？但我敢打赌，每位阅读本文的人都每天使用搜索引擎作为快速获取所需信息的工具。
我认为阅读文档具有极强的、极强的价值：你常能从中获取摘要中缺失的背景信息与细节。
微软文档就是绝佳范例——仅浏览左侧目录，我常会发现工具具备的某些功能特性：1)此前未曾知晓；2)并非主动搜索目标。
关键在于：通往单一答案的路径，往往伴随着对无关洞见的意外发现。若仅获取目标问题的答案，便会错失对所用工具或平台更广阔功能领域的自然探索过程。
我将人工智能搜索/摘要比作只游览知名旅游景点。当然，你可以搭乘班车前往那家人人必访、社交媒体上铺天盖地的餐厅或景点，但这种旅行方式会让你错过沿途所有可能邂逅的绝妙美食、特色店铺和风景——若选择步行探索，这些惊喜本可尽收眼底。阅读文档更像是探索随机角落，发现意料之外的体验，最终对所到之地的了解远超仅游览主要景点。
作为资深开发者，我通常清楚该提出哪些需求——毕竟构建过众多系统，积累了丰富经验。初级开发者呢？他们可能不知该问什么，因此永远无法发现那些能带来额外洞见、值得储存在大脑褶皱中以备未来的“绕行路线”。对初级开发者而言，这就像他们唯一能体验的旅程，只是去那些众所周知的旅游陷阱，而非探索与发现。
我自1993年便活跃于Usenet。那时的网络认知绝非如今这般普及，我们视DejaNews为天赐福音。
这些论点或许成立。我不会放弃谷歌和Stack Overflow，但怀疑当年以《K&R》或手册页为起点时，我的学习效率更高。建立个人知识库远胜于照搬他人成果，其中蕴含巨大价值。
当然没人阻止新手沿用传统方式，但同样没人教导他们这种可能性。
不，尝试实践才是宝贵的过程。过去二十年的编程生涯中，我的信息检索方式已发生翻天覆地的变化。但对程序运作机制的直觉依然有效——每当出现所谓“新”编程潮流，你总能听到老前辈们引用“七十年代就有论文讨论过这个”，而他们通常是正确的。
因此，若人工智能能加速迭代并验证你的假设/推论，我认为这绝对是净收益。但若你只是换种说法乞求它替你解决问题——那你确实把自己降格为低劣的大型语言模型代理了。
天生好奇者终将保持好奇并因此获益，其余人永远只会选择最短路径完成任务。
> 天生好奇者终将保持好奇并因此获益
或许吧。但这类人往往因追求事实完整性而更迟缓地得出解决方案。
当众人争先恐后时，慢吞吞者会因深刻理解而获益，还是因糟糕的指标受罚？
> 当众人争先恐后时，慢吞吞者会因深刻理解而获益，还是因糟糕的指标受罚？
放慢脚步总是有可能的(尽管收益递减)。
或者换作收益与风险/成本的表述：我认为“快速但理解肤浅”与“缓慢但理解深刻”应视为连续体两端。
优劣取决于情境及“犯错代价几何”的态度。若错误代价高昂，显然更全面的理解方式更优；若错误成本低廉，快速迭代自然更佳。
大型语言模型工具的影响？这类工具会放大两种情况的效果。借助模型构建全面理解的速度更快，如同自动补全功能或高级编程语言能加速开发进程。
> 学习如何及何处寻找答案本身就是学习过程的一部分？
没错。现在你甚至可以问AI文档存放位置。
挣扎本身并非目标。请放心，生活中还有无数其他值得奋斗的事物。
关键在于两者兼顾。你需要定期阅读文档学习零散知识来拓展认知，但当你正苦恼如何将字符串转换为正确字节格式并作为二进制大对象(或其他格式)存储到数据库时，显然不是进行知识拓展的时机。文档向来具有多重用途，其中解答直接疑问的功能虽有改进，但仍不够可靠，因此你仍需亲自核查。
问题不在于AI让晦涩文档变得可用，而在于它让优质文档变得不可读。
许多优质文档能让你深入理解技术实现背后的逻辑与缘由。
若此论成立，个性化精熟学习法便不应如此卓有成效
https://en.wikipedia.org/wiki/Mastery_learning
但问题在于，我们谁都没有导师来指导并验证我们使用库的方法。人工智能也做不到这一点。
最妙的是当AI直接编造文档的时候
这完全取决于学习的内容。比如基于AWS SDK编写脚本。API文档庞大臃肿(设计糟糕，每个条目文档加载耗时极长)，而实际使用的API仅占极小部分。我认为“学会查找正确API”并非有价值的知识；真正有价值的是“从基础示例出发设计(小型)程序/脚本”的能力——这能让我减少在琐碎任务(如文本搜索)上的时间浪费。
> 这完全取决于学习内容本身。
关键在于区分“查找信息”与“委托执行功能”的本质差异。
我担心会出现部分工作者严重依赖“接下来该做什么，机器人灵魂伴侣？”这种依赖行为。
不 🙂
任何任务都存在“核心难度”与“附带难度”。文档阅读的困难属于附带难度，它消耗精力与专注力。
你的论点等同于反对使用谷歌或StackOverflow。
并非如此。阅读文档有其规律，正如阅读代码有其规律。一旦掌握诀窍，效率就会大幅提升。新手阅读缓慢的根源在于理解不足。
抱怨文档就像抱怨学术论文为何不像小学教科书那样写。
在我看来，苦于混乱文档完全属于额外复杂性。优质学习资源既能提升效率，又能优化教学效果。(当今基于LLM的聊天工具有多优秀则是另一个问题。)
没人提过文档结构混乱的问题。阅读结构严谨的复杂材料本就极其困难，读过黑格尔的人都能证明。
但若有人因不懂黑格尔而依赖AI摘要，我绝不会相信他脱口而出的任何话。
艰难探索本身具有价值。
为何如此？
若能立即获得答案，挣扎的意义何在？
研究并非编码工作。因此不会削弱开发者对所负责代码库的熟悉度——这恰恰是人们对AI的普遍担忧。
不同意。尽管文档常过时，但维护门槛已降低，团队应竭力为开发者和AI提供有效文档。这反过来也降低了撰写优质文档的门槛——团队接触优质文档的机会增加了。
若你持续阅读优秀著作，便会逐渐精于辨别文字优劣。
尽管去浪费时间筛选一堆错误答案吧。与此同时，我们其他人能获取正确解答，快速吸收信息后继续解决新问题。
而你在此过程中一无所获。恭喜你，此刻你已落后于那位“浪费时间”的同行——他积累的知识储备将成为未来发展的基石。
这种观点有误。人们在使用AI时能学到很多，关键在于使用方式。多年前若只是照搬Stack Overflow代码而不理解原理，同样会遇到问题。
如今本质无异，只是获取代码所需的努力程度降低了。
我每次使用AI时，都会逐行阅读理解代码再提交。这并不难，反而让我收获更多。
没错，确实如此。而且这绝对有害。
如果文档写得糟糕，你除了学会如何控制挫败感外什么都学不到。
1965年：学习如何打孔自己的穿孔卡片是学习过程的一部分
1995年：与文档搏斗，学习如何寻找答案的过程是学习的一部分
2005年：在Stack Overflow上摸索，快速找到他人已问过的答案是学习的一部分
2015年：用搜索引擎找答案是学习的一部分
2025年：用AI获取答案是学习的一部分
…
软件质量是否一直在提升？
当然。我虽错过穿孔卡片时代，但经历了后续所有阶段，软件质量(总体而言)远高于从前。
借助新工具，我们产出的软件数量激增。质量始终维持在市场可接受的水平(而市场也不愿为更高质量支付额外成本)。
没错，25年前人们写的代码同样糟糕透顶
XML导向编程及其他技术在那时被“发明”
这种说法既不合时宜又错误。
学习打孔卡片之所以有用，是因为需要理解卡片打孔不当可能引发的故障类型。但这从来不是编程的核心环节，通常由程序员以外的人员承担。
1995年，文档引发的困扰大多源于文档质量低下。确实有人出版过优质文档，无论是纸质书籍还是电子版。微软知识库文章通过CD-ROM提供给无网络用户，查阅起来相当便捷。
2005年尚无Stack Overflow，该平台的诞生正是基于搜索引擎普及的环境。你完全可以对调2005年和2015年的条目，这样描述会更准确。
对2025年的论述不予置评。
> 学习打孔卡片之所以有用，仅在于它能让你理解卡片打孔不当可能引发的故障类型。但这从来不是编程的核心环节，通常由程序员以外的人员承担。
我原以为所有计算机科学家职业生涯中都听过迪杰斯特拉的这番论断。看来我错了？具体语境如下：
> 著名计算机科学家埃德斯杰·迪杰斯特拉确实批评过交互式终端，本质上更推崇穿孔卡片和批处理所需的严谨方法。
> 尽管许多程序员推崇终端的交互性与即时反馈，但迪杰斯特拉认为交互系统助长的“试错法”导致思维松散和程序设计拙劣。他坚信批处理环境——要求提交前必须进行严谨无误的编码——能培养编写稳健、周密代码所需的纪律性。
> 《真正教授计算机科学的残酷性》(EWD 1036)(1988年演讲/论文)
说真的，我整个计算机科学家生涯听到的抱怨如出一辙。不妨展望2035年——届时必有红迪网友哀叹旧方法优于新方法，理由是“旧法更艰辛，苦行修心有益品格”。
迪杰斯特拉在EWD1036中并未提出该主张。你所指涉的普遍哲学思想实则记载于EWD249——恰巧该文确实提及了穿孔卡片：
> 面对此类情况的简单粗暴做法是：我们必须能够修改现有程序[…] 该任务本质上属于文本处理范畴；顺带一提，这种需求曾被用作支持穿孔卡片而非纸带作为程序文本输入介质的论据。然而程序文本的实际修改属于文书工作，可通过多种方式处理；我的观点是[…]
他随后描述了今日所称的“分支”或“条件编译”(当时两者差异甚微)。“借助AI获取答案”，确实如此。至少你还算有礼貌地使用了块引用语法，但直接将AI生成的垃圾内容粘贴给他人实属极不礼貌。若真要采纳，请私下进行，别在公开讨论区展示。
你归因于迪杰斯特拉的立场确实有可辩护之处——但这与亲手打孔完全是两回事。现代等效做法应是在提交拉取请求后，仅在CI环境中运行完整测试套件： 这种机制能促使你采用确保测试不会失败的编程方式，而非单纯迭代至测试通过(若存在覆盖率缺口则后果不堪设想)。因为同事们一眼就能看出你是否随意改动导致无关代码崩溃——这种情况多少有些难堪。
我建议阅读EWD1035和EWD1036——务必亲自阅读原文，而非依赖AI摘要。尽管你可能对部分观点存疑，但迪杰斯特拉在这些论文中阐述的核心观点是正确的。EWD514或许也值得参考——但若我把所有认为有用的迪杰斯特拉论文都列出来，恐怕要耗费整天时间。
最后引用EWD480中一段话，它基本驳斥了你对迪杰斯特拉观点的曲解(同时也批判了你的整体方法论)：
这种灾难性的混淆值得特别警示，仅指出存在一种编程观点——认为穿孔卡片与用铅笔还是圆珠笔做数学题同样无关紧要——远远不够。它值得特别警示，不仅因为其危害性，更因其表面光鲜！[…] 当有人胆敢指出你传播的知识大多至多相关性一般、易变且可能令人困惑时，你只需耸耸肩说：“这已是现有最佳成果，不是吗？”仿佛这种教学方式存在正当理由——而细究之下，这门学科根本不存在…… 然而我深感忧虑，这种教授计算机科学的方式实在太过普遍。否则我们又该如何解释“计算机科学家的知识半衰期仅有五年”这种屡见不鲜的论断？这难道不是在说他们所学尽是垃圾与废话吗？
EWD系列的完整文本可查阅https://www.cs.utexas.edu/~EWD/。
毫不夸张地说，确实如此。
现在回去工作吧。
对资深工程师而言，处理语法、API、类型问题、解析错误等属于工作中的基础环节。真正的工作在于解决宏观层面的问题。
但对许多初级工程师来说，这恰恰是最困难的部分。他们(目前)无需承担宏观层面的责任。
何谓“宏观问题”？是缺乏领域知识？还是缺乏对代码库多年积淀的深刻理解——这些正是资深工程师的优势所在？在我所在的团队，不存在“问题太大”而不能由初级工程师承担的情况。这正是“初级”蜕变为“非初级”的唯一途径——靠实践而非依赖所谓资深者(我本人就是其中之一)
所谓“更宏大的课题”，是指整体技术方向与架构设计——做出避免自我设限的决策，将可维护性内化为实践准则，围绕组织架构与工作习惯进行系统设计等等。
但这些都是需要通过实践和接触积累的经验，我依然认为人工智能至少能通过提炼技术领导力领域的众多书籍，形成实用摘要来提供帮助。
好奇问下，你主要做前端吗？我能理解前端场景(但浏览器特有的复杂性等仍需应对)
从事后端和大型分布式系统开发时(至少在我看来)，涉及的深度远超前端。比如一致性类型及其实践中的权衡取舍、Lamport时钟的实现与正确使用细节、优质API设计、重构过程中的无穷细节等等。
此外，两者都需要培养对系统架构长效性的洞察力(如何避免每五年就不得不重写系统)。
我基本认同新手成功的最佳途径是跳进深水区——当然需要指导。在内部机制相当晦涩的分布式系统领域，导师制至关重要。但我发现光靠讲解无法真正让知识内化，通过任务实践进行指导才是最佳方式。
>好奇问下，你主要负责前端吗
把关？
若脱离截止期限和时间限制，后端团队为何不能让所有任务都适合初级人员？
你不可能给新手分配需要多年开发经验才能掌握的精细任务。若全程监护或许可行，但这又有什么意义？所谓“精细度”本就难以具体描述，而作为指导过不少新手的导师，我发现多数人确实缺乏这种能力——人工智能通常也不具备。初级员工需要挑战能力边界但不过度的任务才能成长。放任他们在复杂项目中胡搞不是好方法。
软件工程技能是真实存在的，它既非领域知识，也非特定代码库的认知。它是良好的判断力——一种抽象能力，能为复杂问题创造/识别优质解决方案。
> 若全程监护，或许可行，但如此有何意义？
在长期企业中，意义在于为团队培育持久的技能体系。在小范围内强化团队的集体智慧亦是如此。
然而工作形态已然演变，经济环境日益排斥长期建设，导致那些无法立即产出成果或创造收益的努力难以获得支持。
资深者的职责在于洞察初级者的能力边界，分配既具挑战性又可实现的任务，并提供指导。
若你真信这套理论，说明你待过些糟糕透顶的职场
或许我自己并不觉得它们糟糕，但口味各异。所谓工程极乐世界，是否就是那种任何任务都能由初级工程师完成，而通过经验积累形成的工程技能概念根本不存在的境界？
> 所谓工程极乐世界，是否意味着所有任务都能由初级工程师完成，而通过经验积累形成的工程技能概念就此消亡？
既然如你所言，初级工程师除了通过实践还能如何获得工程技能？
不必要的复杂性、完全随机的临时设计、过度强调某一行为而忽视其他方面。在不该使用设计模式的地方滥用模式，写完代码就忘记运维存在，使用熟悉却不适配的语言和框架。这样的例子不胜枚举，我时常目睹——而AI只会让情况更糟，因为它总会用“您完全正确！”来验证这些错误。
祝你好运去维护这样的系统。
这种事只会发生在烂团队的烂地方
每个团队都存在不同程度的无能。若所有团队都完美无缺，那工作就该结束了——因为他们总能一次就把产品做对。无需修复漏洞，无需功能更新，更不会有2.0版本。
当心，你的自负可能让你误入歧途。
带着同样的自负搞开发31年了，但谁知道呢。这些年我唯一学到的就是：只要遇到那种看人不是看能力，而是看你妈生你多久的地方，赶紧逃之夭夭。
老实说，作为资深工程师，我最看重AI的正是这点。经验让我通常能明确需求，但常渴望用新框架或范式实现——若能直接向人提问，对方定能心领神会。可面对术语繁多的框架，若找不到精准关键词，依然令人抓狂。通常我只需坐下来阅读官方文档中相关主题的大约6屏内容，就能在70%处找到解答问题的关键句子。
但你知道什么最擅长处理一堆词元，然后给我一堆概率相邻的词元吗？没错！很多时候即使AI给出的语义完全离谱，光是知道这些词元足够相邻，就让我在构思下一个问题时占尽先机——当然偶尔AI也会意外给出语义正确的结果。
当初加入时我还能做到这些。
而我始终在质疑：“…因为精妙运用时，它能加速学习。” 真的如此吗？
我们如何定义这里的“学习”？我常举的例子是：真正“理解”平方根概念的学生，即使面对仅有四则运算功能的计算器(x, ÷, +, -)，也能通过反复试算得到结果；而只“学会”按√键的学生，面对这种计算器就会“卡壳”。那么当“魔法按键”浮现提供答案时，他们真的“学得更快”了吗？还是说他们只是更依赖“魔法”来完成本应自己完成的工作？
这让我想起一些零散的思考。
我2000年代中期高中毕业，直到大学三年级才开始在数学课上使用计算器。我坚持所有计算都手写在纸上。早期遇到一位优秀的数学老师，教会我如何在纸上清晰呈现计算过程和解题思路。我交过的试卷里，单题用纸量常超过他人整份试卷的用量。
这种方式极大提升了我对数字及其相互关系的理解能力，也帮助老师们精准定位我的认知误区。
不仅如此：我怀疑你光是浏览题目时，脑海中就已对答案的合理区间有了预判——任何不符合预期结果的解法都会让你停下来重新检查。
而使用预言机时，这种直觉判断完全消失了。
保持好奇心至关重要。每当遇到新事物，我总通过向大型语言模型提问来获取大量知识：“请解释——我得到X结果，但你为何执行Y操作？”
我们正处于钻石时代半——只需持续保持好奇心，偶尔放缓交付速度，确保为学习预留时间即可。
我认为这正是“善用神灯加速学习”中“善用”的真谛。
今年夏天我们有三位实习生——借助AI技术，他们确实能高效产出成果。虽然部分代码和假设不够完善，但确实帮助我们快速发布了多个版本来缓解客户问题。因此使用初级人员存在权衡：既能加速功能落地，也可能需要后期重构。
为何他们比配备三个大型语言模型的资深工程师更胜一筹？
这与使用AI编码助手的权衡颇为相似
> 他们只需花二十分钟评估AI提供的方案，而非耗费三小时研究该用哪个API
据我观察，实际情况并非如此。他们往往在开发环境中使用Cursor等代码生成工具，只要生成的代码功能正常且在模糊距离下看似“良好”(指“小范围代码”层面)，就会提交超大PR，实际思考工作全推给审阅者。
这种做法很糟糕，这些初级工程师要么接受改进培训，要么就该“被管理出局”。
他们的职责是交付经过验证的代码。
这促使我撰写了长文版本：你的职责是交付经过验证的代码https://simonwillison.net/2025/Dec/18/code-we-have-proven-to…
深有同感。我见过修改请求里包含生成的OpenCV LUT映射，只因新手不明白所需的其实是个简单的插值函数。
症结永远在于你不知道自己不知道什么。AI无法解决这个问题。
我认为AI的最大价值在于能绕开术语障碍。不懂某个词？问AI。想了解历史背景？没问题。概念难以理解？请用高中生阅读水平解释。
> 善用精灵，加速学习。
呃…“善用”这个词承担了相当沉重的任务。而90%企业的激励机制根本不鼓励“善用”。
真正的激励是快速交付——这意味着将AI大炮对准代码库轰炸几小时，榨出个“技术上可行”的方案，完全不考虑大规模架构设计，也不积累应用各部分如何协同运作的知识(因为根本不存在“协同意图”)。测试可能存在，但往往缺乏合理性且极其脆弱。
总之，部署大批缺乏良好指导却能日产数千行代码的应届生，无异于加速我常在6-8年历史的初创公司代码库中目睹的崩溃进程。此时，所有所谓模式的例外清单已远超遵循模式的案例，每个被追溯的缺陷都会牵出漫长的历史决策链——每条错误决策都需要耗费数日才能妥善纠正(且纠正过程还会引发连锁反应影响其他模块)。巧合的是，此时AI代理也最无用武之地——它们根本无法预料代码库中那些离奇的怪癖。
我是否在说AI毫无用处？并非如此。它在原型设计和实现产品市场契合度方面表现出色，若能由具备批判性思维的人来解读其输出结果，效果尤佳。但我绝不会让缺乏经验的新手使用AI——他们尚未有机会从我多年积累的诸多错误中汲取教训。
并非反对肯特·贝克关于新手使用AI的见解，但AI对其自身写作的影响明显负面。他早期的内容读起来有趣得多。他在Substack上近期非文章形式的“动态”亦是如此。例如，将本文前置的同主题“笔记”(https://substack.com/@kentbeck/note/c-188541464)与实际内容对比即可发现差异。
*部分初级工程师确实进步了。
我本不愿如此苛责，但初级工程师面临的最大困境在于：面对海量新信息时，他们既无法有效梳理也无法合理取舍，更遑论决策。即便AI缩小了搜索范围，若他们仍无法有效(或独立)完成最终决策，这种辅助也毫无意义。
有些初级工程师似乎天生具备这种能力。他们可能仍不擅长搜集所有必要信息，但一旦获取信息就能做出最终关键决策。如今借助AI，他们基本消除了搜索难题，得以更专注于决策本身。
问题在于极难辨别工程师属于哪种类型。而资深开发者通常早已掌握这种能力。
>但若善用这瓶神灯，它能加速学习进程。
这根本是“孩子们会用AI学习理解”的敷衍程度
不，孩子们只会复制粘贴答案，然后跑回他们最爱的多巴胺发射器
在让AI给我答案的过程中，我学到了很多东西，因为我想理解它为什么这么做。这让我省去大量修复注定失败方案的时间，得以专注分析成功案例。
失败或许有其价值，但我认为成功更具启发性。既然大型语言模型无需我参与就能成功，我更该把时间投入它失败的领域，这样才能创造真正价值。
理解“为何有效”是一回事，理解“为何必须如此实现而非其他方式，以及存在哪些替代方案”则是完全不同的层面。AI仅展示无数正确实现方案中的一个。你或许能理解单一实现方式，却未必掌握其背后的完整理论体系
>在让AI给我答案的过程中，我学到了很多东西
我认为你学到的远比你想象的少。正如人们不会通过看别人解题来学习数学，阅读ChatGPT的输出也不会让你成为更好的工程师/问题解决者。
若我明确目标与方法，且存在实现路径，这难道不算解决问题？我只是减少了对机器可自动化环节的关注。
至于工程师的进阶之路，在我这个职业阶段，这叫管理。
你当真认为这是人类的学习方式？
这是本Common Lisp教材的示例
https://gigamonkeys.com/book/practical-a-simple-database
通常的做法是：按书本指导操作获得结果，再自行探索。根本不存在摸黑摸索自己道路的情况。
一旦掌握了有效方法与无效途径，你就能奠定扎实基础去攻克更复杂的课题。这正是拥有优秀教材和/或良师益友的价值所在——他们能引导你走向精通之路。相比之下，使用老虎机简直是种折磨。
我倒不觉得更折磨。事实上，若让我重学Lisp，看到能从零开始构建有趣的东西，肯定比当年Racket课程里那些玩具程序更有动力。
况且很多领域本就如此——正因缺乏优质教材，人们才只能靠这种方式学习。
先定义“有趣”的标准。
我曾指导几位学员参加安卓开发速成班，对他们而言，能运行默认示例并熟悉IDE界面就是有趣的体验。记得我初学Python时，光是完成基础变量声明和算术运算就充满乐趣。学习C语言时能写出井字棋程序也是同样的感受。
我认为让初学者抱有资深开发者才有的期望，正在造成巨大伤害。比如向连Linux存在都不知道、从未接触过POSIX概念的人宣称“两个月就能学会Docker”。
请务必阅读以下文章：https://www.norvig.com/21-days.html
或许有人(多数人？)会这样做，但那并非我们关注的对象。
正如有人会照抄教科书答案，真正有趣的是那些探究解决方案背后原理的孩子。
当然我也可能错了——我刻意远离现代社交媒体技术生态(TikTok、Instagram之流)，可能早已与时代脱节(而且我乐在其中)。
没错，他们实习期结束后就找不到工作了。
我内心那个愤世嫉俗者认为，这是把初级员工当作提升AI指标的工具。有了人类挡箭牌/传声筒，资深员工在审核AI产出时自然会降低批判性。
搜索无疑是AI/大型语言模型最出色的功能。
我基本认同。我的认知模型是“搜索结果经过滚筒抛光机处理”——既不标注来源，又混杂可信与不可信信息，还倾向于更常见的来源类型。
这或许正是其本质所在。用AI生成内容不过是在潜在空间中寻找某个点。
该模型是在人工智能兴起前的互联网环境中训练的。未来几年当新技术涌现却可能不再遵循相同文档规范时，会发生什么？这并非无解难题，但可能引发意外后果——比如用户必须付费让AI服务商处理其数据。类似于购买搜索引擎的广告位或AdSense之类的服务。
若你从2025年起发布新技术，却不愿投入足够精力制作适用于大型语言模型的文档(含优质示例)，让用户能将其导入编程助手，那你就是在损害自身技术的发展前景。
这难道不是老生常谈？文档的重要性有什么新意？
若你的技术面临已存在于训练数据中的竞争对手，让大型语言模型用户平等获取该技术的唯一途径，就是确保存在可直接输入模型的简明文档。
这就是为什么手册页上越来越常见“复制页面”按钮，例如：https://platform.claude.com/docs/en/get-started
若大型语言模型普及，实际“浏览网页”的人将减少，从而降低信息发布需求。至少，人们向Stack Overflow提问供模型学习的情况会减少。这可能形成知识孤岛：模型在AI出现前已大量发布的内容领域表现优异，而对AI后发展的新技术则作用有限。
我的首条回应是“且容我揭示真实商业世界的运作机制”……不过我们不妨更细致地剖析这个现象
自台式电脑普及以来，数以千计的中小型企业本可受益于软件系统。成千上万的“顾问”涌向附近的会计师事务所、零售商、小型制造商或律师事务所，展示新型桌面软件并宣称能提供定制化解决方案。
如今我们知道，这对多数中小型企业及顾问都未能奏效。鲜少有人能打造出“足够优秀”的定制数据库应用——并非缺乏尝试，而是平台迭代速度、功能竞争、愚蠢的噱头设计等因素，都让小型顾问团队望尘莫及。最终结果是基础办公软件的巨头垄断，而非为小企业量身定制的成千上万套小型系统。
那么2025年的现状如何？“初级”开发者该做什么？设计开发？不。AWS锁定服务中的模板化流程，早已远超小型创新软件的设计能力。AWS操作自动化将成为市场刚需——这算“初级开发者”的工作吗？
这只是个小众洞见，并非全貌……但……附注：可将“桌面软件”替换为“手机”重新解读
需要指出的是，撰写文档或构建电子表格的方式终究有限。大量业务流程具有高度定制性，企业必须在定制开发、流程调整或忍受低效之间做出抉择——毕竟缺乏技术解决方案会导致目标难以轻松达成。
Lotus Notes正是这类定制软件细分市场的成功案例，它不仅蓬勃发展，更催生出成熟的咨询生态系统。
> Lotus Notes正是典型例证
今天才知晓Notes竟仍存世。我原以为它早已销声匿迹。
此分析令我困惑。难道您认为所有企业级软件都被MS Word和AWS取代了？
当然不是——任何领域都不存在“所有软件”这种说法。你回复的帖子中哪里提到“企业级”？“企业级”特指最大型企业和机构。
我既没说“所有软件”也没说“企业软件”，你却惊讶于我的表述…嗯
我不会被权威论调左右，但这观点实在糟糕透顶。
“AI”工具最适合经验丰富的开发者使用，而非新手。只有资深开发者具备审查生成代码的能力，能判断代码合并后是否会引发更多问题，或通过调整修改使其可用。
初级开发者缺乏这种能力。他们唯一的做法就是运行代码，测试是否满足需求，如果比较认真，会尽力理解并测试代码。但由于他们承受着尽快交付以取悦同事和管理层的压力，很可能直接接受工具首次生成的任何可行方案。
这使得初级开发者使用“AI”既危险又适得其反。允许此类开发的公司将很快在技术债务的重压下停滞不前，陷入布满漏洞的雷区却无力应对。
不幸的是，在“AI”领域，初级开发者根本没有晋升高级的途径。多数人会倾向于将这些工具当作快速生成软件的拐杖，而非提升自身技能的学习工具。这应当引起所有关心行业未来的人的重视。
> 初级开发者并不具备此类能力。他们唯一能做的就是运行代码、测试是否满足需求，若足够认真，则尽力理解并测试代码。
这种观点也极其糟糕…其实主要是措辞不当。初级开发者具备技能、天赋，平均智力不逊于其他程序员，甚至常有一定经验，他们缺乏的是工作履历。他们绝对有能力理解代码而非仅执行代码。诚然经验极其宝贵，尤其在理解如何构建长期可维护的可靠代码库方面具有特殊价值，但丰富经验并非硬性要求。你们能权衡取舍、善于吸取建议、快速学习等等。
你说得对，我措辞确实过激了。我的本意是对比他们能否对生成的代码进行质量评估，以及必要时理解如何修改。这正是任何领域专家才能具备的能力。我绝非暗示缺乏经验者无法掌握这些技能，更不认为他们智力不足。只是该领域本身存在门槛，使多数人难以达到这个水平。虽有例外，但对多数人而言难度极高。若这些新工具完美无缺倒不成问题，可惜我们离那阶段还很遥远。
我不同意。根据我的经验，AI承担了大部分工作，而初级工程师本就薄弱的技能反而退化。结果资深工程师不得不审查AI产出的垃圾代码，再让新手重新让AI掷骰子。
赞同，这就像让AI代写作业。少数人会借此学习，多数人只会复制粘贴，让AI生成PR后整天泡在Slack上。但至少他们“在努力”，所以不会被解雇。这需要资深工程师亲自指导他们理解提交的变更逻辑，并解释选择这些方案的缘由。
我实在受够了PR评论里满屏的“但Copilot说…”这种回应。
我见过两种情况。好经理照样能驾驭这种局面。
没错，但并非所有经理都称职，也并非所有局面都能掌控。
别把这和此人掩饰本能的能力混为一谈。他正把“资深”职位重新定义为初级，但在数字世界里文字毫无意义。金钱层面的转化就是：原本价值2美元的东西现在只值1美元。
因为这最符合商业逻辑。
回复里充斥的麻醉剂简直令人惊叹。太惊人了。
自称“全职内容制作人”的人，怎么可能了解行业真实状况？
https://substack.com/@kentbeck
他目前在参与哪些软件项目？
https://en.wikipedia.org/wiki/Kent_Beck
公平地说，即便我欣赏贝克，但有些人确实名气过大，逐渐脱离了普通公司的实际环境。这类人常给出仅适用于少数顶尖企业的建议，对其他公司毫无参考价值。
这不恰恰印证了我的观点吗？从维基资料看，他主要是以编程领域意见领袖的身份出名，而非程序员本身。
那又怎样？他的履历简直就是追逐潮流的记录。现在投身“人工智能”热潮，真令人惊讶。
这种极端愤世嫉俗的观点完全忽视了他数十年的贡献。
很多情况下，他参与构建的潮流浪潮，恰恰是你指责他“蹭热度”的对象。
> 很多情况下，他参与构建的潮流浪潮，恰恰是你指责他“蹭热度”的对象。
我甚至无法判断你是否在讽刺(虽然我希望你是！)，这让我感到不安。
此人可是极端编程的发明者，更是《敏捷宣言》的首位签署者。他遗忘的软件开发知识，比这个论坛上多数人毕生所知的还要多。
在我看来，他的核心竞争力在于管理软件团队，而非开发软件。
某人的成就并不意味着他不会持有错误观点或犯错。个人崇拜对进步有害。无论观点出自何人之口，都应给予同等重视并接受同等审视。
这根本不是问题所在。提问者明确询问的是“此人的成就何在”，而肯特·贝克作为科技界的元老，成就可谓数不胜数。
他当然可能犯错，毕竟是凡人。但这并非我的论点。
不，这确实不是问题所在。
当你连肯特·贝克是谁都不知道时，这些问题根本不重要。
问题的核心在于：当人工智能工具被恰当运用时，它能提升学习效率，从而改变对初级开发者的投资经济性——这种改变是积极的，与主流讨论中对这些工具的负面评价截然相反。这是个值得探讨的有趣观点。
你在此援引权威的做法既不合时宜又明显缺乏依据，因此遭到反对票。
我当然知道肯特·贝克，但敏捷开发和极限编程并未令我信服。
维基百科页面揭示的新信息是：他曾供职于YCombinator旗下公司。这才是反对票的缘由。
这好比1970年宣称计算器能取代会计师。AI编程自有其价值，但发展道路漫长。若真要说，初级开发者与AI编程助手的结合确实引发了全新议题：
借助AI编程助手学习编程，是否真能造就比传统学习者更优秀的程序员？
有趣的观点…我发现某种规律…人们总以为AI无所不能…但实际情况是初级开发者往往比资深者更懂AI工具…这正是AWS CEO指出的问题…他说初级员工通常最熟悉AI工具，裁掉他们毫无意义… 他还提到初级员工通常成本最低，裁员节省的开支微乎其微…更警示道：若断绝人才输送管道，组织未来将断根…作为指导初级员工的导师，我亲眼见证他们如何用AI加速学习…他们能提出精准问题，快速迭代实践，并将发现分享给团队… 资深员工固守旧有工作流程，有时难以适应新工具…但人工智能无法塑造企业文化或理解产品背景…这些仍需人才逐步成长…因此我不担心AI取代初级员工…更忧虑企业扼杀自身未来人才管道…让科技精灵助力，但切勿抛弃学徒。
更重要的是，初级工程师往往最常引入创新工具…比如我完全不知道谷歌IDE竟提供免费无限额度(尽管界面糟糕透顶)…正是年轻工程师告诉我这个功能！！
我见过资深和初级工程师都引入新工具。资深者频率或许较低——但仅因我们曾以不同名称见过类似方案，明白其并非创新。(有时时机终于成熟，有时则因旧问题重蹈覆辙)
我见过资深工程师向新人提出新颖想法——至少对新人而言是新颖的。
举个例子。这些年接触过无数代码库…有位新工程师看到我最近写的带标签的代码时(！)脸色都变了。他认定“goto == 错误”。(我们讨论的是C语言。)
但这段代码涉及苹果的CoreFoundation库。几乎每次调用CF都可能失败(CF API会返回NULL)。更关键的是，向CF调用传递NULL参数(比如尝试将CF对象追加到CF数组时)会导致硬崩溃。CF从不检查参数(因为这会降低效率——亲爱的读者，所有合理性检查都得你自己做)。
因此你的代码可能类似于：
CFDictionary dict = NULL;
dict = CFCreateDictionary();
if (!dict)
随后你可能继续创建数组等操作——将它们插入字典，最终返回该字典。同样，每次调用CF函数时都需检查NULL值，必要时跳转至bail标签。
在’bail’标签下方，可对所有未返回的非空实例调用CFRelease()。这就是我们自行回收垃圾的方式。:-)
无论如何，goto标签让代码更简洁：无需将NULL检查的if语句嵌套得深不可测。
新工程师坦言惊讶于标签竟有此用武之地。(当然，CF本可以更容忍NULL，直接优雅退出也行。)
我在一家对工具使用限制极多的公司工作。每当有新人入职，我们总要花大量时间监督他们，确保他们不使用不该用的东西。
最典型的例子就是实习生们总想用谷歌文档处理所有事务，而且还用的是个人账户。我至少得制止他们十几次，引导他们使用微软办公软件。
还有些人会执意使用扩展性差的免费工具，只因大学或业余时期的习惯使然。引导他们采用已获批准且与全系统集成的企业级解决方案往往耗费大量精力。典型例子就是有人用个人笔记本运行Ansible，而我们明明配备了Ansible自动化平台——该平台不仅更适合全球任务调度，还能自动将日志导入Splunk生成审计轨迹。
我震惊于人们竟未察觉科技公司正试图让开发者依赖这些工具，以此确保“租金”收入流。不过嘛，我懂什么呢。这不过是云超大规模扩张的翻版罢了。别买自己的硬件，租我们的！瞧，我们连计量系统都建好了！
但愿人们能看清。整个AI浪潮本质是巨头用资金掩盖的租金攫取，这再明显不过。免费资源终将枯竭，而各项服务的租金却会永存。
我早看透了，但现在谁还在乎。所有模型在编码辅助场景下都是可互换的。
很快你就能在本地运行代码助手了，就像现在能靠GPU运行复杂图形模拟(游戏？)那样。
硬件成本上涨的情况下我不敢确定。不过如果采购由IT部门负责，那确实与你无关。
“但初级开发者往往比资深者更懂AI工具”
抱歉，这具体指什么？你是说初级开发者比资深开发者更懂得如何设计有效提示词吗？
他们的意思是初级开发者更可能围绕AI工具构建工作流程，因为年轻开发者在工作方式上更具可塑性，更容易适应AI工具。
总体而言我不太认同。就我个人而言，过去十年我一直在使用vim，任何需要运行电子应用的AI工具对我来说都行不通。但许多从VS Code转来的资深同事则没有这类障碍
说到vim——为vim添加并配置Copilot插件很简单(它在后台运行Node.js应用，但若你有500MB闲置内存就几乎察觉不到)。
Vim版Copilot与Cursor功能不同，例如不支持多行Tab键自动补全。
所有主流工具都提供命令行界面，这点值得一提。
除非你想审查变更或调整某些设置，否则根本不需要Vim。
作为资深开发者，我观察到新人确实更擅长运用AI工具——他们每日投入更多时间编码和工具操作，需要这些工具理解代码库或提升效率。而资深开发者常被会议、为新人编写规格说明/工单、代码审查等事务占据时间。面对已熟悉的代码库，他们往往懒得为简单修改编写提示。
有些老狗就是不愿学新把戏。
若你眼中的AI仅限于提示词，那你属于“不会用”的群体。
亚马逊内部有软件开发平台，工作流程有文档记录且设有制衡机制。因此CEO希望增加精通AI的初级开发者比例，相应减少资深开发者数量。此外，产品背景需由产品经理和用户体验设计师提供。
中小型企业往往缺乏这类防护措施或文档规范，此时就需要经验丰富的人员协助。
抱歉，这评论里满屏省略号到底怎么回事？
这是种意识流写作方式。这种风格时而流行时而过时，但总有人坚持使用。
他们有个Emacs插件能自动把省略号变成三连点！
他们是不是在拼命强调自己没用LLM写帖子？/s
因为LLM会用Unicode水平省略号…
https://www.compart.com/en/unicode/U+2026
说实话我觉得这会是未来趋势
“为您的核心读者量身定制的手工生成内容”
不，模型可以针对任何内容进行微调和训练。像ChatGPT和Gemini这类常见消费级产品有特定风格——非常礼貌且乐于助人，但也有训练成好斗风格的模型，有模仿莎士比亚文风的模型，各种各样都有。有人完全可以训练出模仿HN评论风格回复帖子的模型，你大概永远都不会察觉。
> 我发现规律了…
我也发现了。解雇你们的高级开发人员吧。(哈哈，不是开玩笑。)
不不，必须开除他们。
等不及看那份“天啊一切都着火了，资深开发者在哪？”的离职补偿协议了。
> 他说初级员工通常最熟悉AI工具，裁员毫无道理。
尽管词义定义本可自由发挥，但多数人仍认为经验最丰富者才是资深。我确信这始终是核心观点：别裁撤资深员工。称谓本身无关紧要。无论你称他们为初级或资深，裁撤经验最丰富者向来被视为荒谬之举。
不，他的意思是初级开发者虽然整体开发经验较少，但在AI工具使用方面经验更丰富。(这在宏观层面或许成立——根据我的经验，经验较少的开发者确实更热衷于采用并高度依赖AI工具。)
虽然词义定义本可自由裁量，但多数人认为“初级”与“资深”的标签应指向核心工作内容而非边缘技能。既然工作要求使用AI工具，这些经验最丰富者理应被视为“资深”。没人会建议裁掉编织或越野摩托领域的初学者——毕竟他们只是新手。
不，工作本质是开发软件。使用AI工具只是工作中的一部分。在整体工作经验不足而某项技能经验丰富的情况确实存在。
工作目标从来不是开发软件，而是为客户解决问题。软件开发只是工具箱里的工具。如今使用AI亦是如此。因此，团队中拥有AI应用经验者具有重要价值。
这并非新观点。业界始终认同经验丰富者的价值。“裁减初级员工”的讨论从未涉及放弃有价值的人才。将此论调扭曲为“淘汰经验型人才”——仅仅因为其经验领域不符合你任意设定的标准——实属荒谬。
> 既然工作要求使用AI工具
且不论此论调本身荒谬，试想“资深”员工通常需具备多少年经验？而ChatGPT向公众开放至今不过数年，更遑论尖端编程智能体。
> 想想“资深人士”通常需要多少年经验
这完全取决于经验的指向。若涉及农耕这类受自然限制每年仅能经历一次不同情境的领域，则需数十年积累才能被视为“资深”。
但在每几毫秒就能接触新场景的领域，经验积累周期可大幅缩短。这种情况下，即便投入有限精力，两三年也足以成为“资深”。若在这种环境中历练数年仍未“见识遍”，那你根本算不上“资深”——因为你几乎从未真正投入其中。
七成资深开发者(通常是五十岁以上的大叔)会因你尝试使用Claude代码而怒不可遏。我：“老兄，这代码比你那团浆糊般的中年大脑写得强多了。” 另一边的我：“我这团浆糊大脑也一样。”
我认为大型语言模型是人类智力的映射。若人类因模型而变笨，模型也会随之退化。我甚至幻想在某个反乌托邦世界里，用2023年前数据训练的模型会成为抢手货。
讽刺的是，新人反而损失更大。50+的家伙们大概率能混到退休。
这总结太敷衍了吧，你根本没提出任何新观点
你说得对，但我对此的看法已改变
一年前我绝对会百分百赞同你。资深工程师们既因自满而拒绝审视AI工具，又因自尊心作祟抗拒创新，而公司政策更通过强制订阅Co-Pilot等方式，彻底扼杀了他们尝试任何新工具的动力。反观初级工程师，他们更愿意冒险——毕竟企业对云端AI工具的监控体系其实并不严密。
但如今，尽管许多组织仍维持原状——只是增加了更多刻意设计的Co-Pilot订阅服务——我认为资深工程师们也在规避公司政策，并逐渐熟悉各类工具。
我目前所在的组织完全放任自流，为加速交付配备了所需的AI编码与应用工具。因此我的认知可能已脱节。
或许那些更安于现状的企业仍与一年前别无二致。
或许吧，但你这番话听起来像是初级工程师比资深工程师更有价值。那不如解雇大部分/全部资深工程师，看看后续局面会如何。
在任何规模足够大的组织里，编码绝非资深工程师的主要工作内容——除非是某种代码血汗工厂。初级工程师几乎无法承担那些将项目从头脑风暴会议转化为正常运行且有保障产品的粘合工作。
至于价值——企业显然能在非理想状态下没有初级员工照样运转。但我不认为它们能没有资深员工，除非只是用模板快速拼凑CRUD功能或电商网站。
还有个近期多项研究共同印证的现象：通过语言模型快速获取的知识往往流于表面，难以持久且缺乏深度。众多案例之一：每当需要处理复杂的正则表达式逻辑时，我总会深入研究规范与实现细节，甚至多次挑战其极限(或意识到任务超出正则表达式能力范围)，而非仅因基础测试通过就直接复制粘贴结果。这种方法论可推广至诸多复杂领域。这也关乎企业的长远发展。
我理解你的观点且部分认同，但这把双刃剑的锋芒不容忽视。
> “第一，根据我的经验，许多资历最浅的员工反而最擅长运用AI工具，他们往往能最大化发挥这些工具的效能。”
这种“经验”莫非来自抄袭作业？你确定这是值得优先培养的技能？
> “其次，他们通常成本最低——刚毕业的应届生薪资普遍较低。若考虑成本优化，他们并非唯一需要优化的对象。”
哈哈哈。听起来像在威胁。补充背景：亚马逊素以层级排名和经理裁员配额著称，其员工关怀度远不及谷歌。
> *“第三，这种模式终将自食其果。若企业既不培养人才梯队，也不指导新人成长，往往会发现最佳创意正源于此。” 我原以为科技行业早已放弃对初级员工的长期培养与投资——毕竟普遍认为，无论如何培养，他们大多会在18个月内跳槽。如今多数企业招聘只看重短期产出，完全是交易式招聘。
那么AWS对软件工程师的长期留存率如何？
许多行业都存在一个重大却鲜少讨论的问题：企业内部缺乏人才“输送管道”。自1980年代起，“自主培养人才”的理念已逐渐式微，企业转而从外部招聘。软件行业可能尤为突出，但其他领域同样存在此现象。
AWS是否打算建立内部人才输送管道，从初级员工开始培养，正如这场演讲所暗示的？
他们并未如此，正因如此，其CEO才需要让所有人相信必须持续高强度招聘初级员工——这样AWS就能在必要时挖走这些员工。
我认为多数初级员工频繁跳槽的原因在于：他们往往以极低薪资入职，两年后仅获得微幅加薪。而跳槽则能获得大幅薪资提升。
至少在香港，我接触的初级员工普遍如此，其他地区情况不详。
若还不明显的话，他的计划就是让其他公司培养初级员工，待他们晋升资深时再挖角。
只挖资深！别来什么三流中层！
作为资深工程师，我能用AI修复陌生语言和框架的应用程序。我足够了解技术，能阻止它提出荒谬绝伦的方案。
但我并未真正学习。这并非我的目的——我只想修复漏洞。嗯。
我确信人工智能终将引发技能退化危机。
值得深思。
人工智能的诱惑如此强烈，未来真正有价值的将是持续学习者。或许该让AI解释/教学而非直接索要解决方案。或者干脆不用AI。
我认为使用人工智能的诱惑如此强烈，未来真正有价值的将是那些持续学习的人。
对于渴望学习的人而言，人工智能是绝佳的导师。
> 但我并非在学习。我的目标是修复漏洞。嗯…我确信人工智能终将引发技能退化危机。
漏洞修复完成后，你完全可以研究其运作原理。
这种使用AI的方式也不应导致你丧失现有技能。
我尚未在实践中见到这种模式：重度AI使用者既能生成解决方案，又能后续真正理解并从中学习，且具备有效性或深度认知。
这如同阅读数学证明的答案而非亲身推导，或抄写书籍摘要而非完整阅读。探索设计空间与选择特定解法的过程不复存在——你只看到最终结果，却无从知晓其他可能路径。更缺乏可供学习的反馈循环，因为该循环本身也是AI生成的。
诚然，无人能阻止你事后重现问题自行求解以获取同等学习效果，但通过研究已修复的漏洞(或其他变更)来学习的过程终究截然不同。
现实中这种模式的可行性，恰如“后续补上测试”这类承诺往往难以持续落实。修复完一个漏洞，你接下来要做的往往是修复另一个漏洞、开发新功能、编写文档等，而非纠结于已“完成”的工作。
讽刺的是，AI在“后期补写测试”方面表现出色。它能有效完善代码的测试覆盖率，并生成可复用的测试框架，激发开发者进行更深入的测试。
我虽非深度AI用户，但曾用它为前端进行过几次灵感编码。这让我更深入理解React应用的布局逻辑，以及React提供的模块化组件如何运作。虽然效果远不及从零开始学习书籍，但有时可运行的原型对产品计划的价值远超学习编程语言本身——若不通过灵感编码实现原型，简直是在白白浪费时间和价值。
确实如此，用测试作比喻很贴切。
关键往往不在于修复错误本身，而在于整个探索过程。学习各类软件组件的运作逻辑与协同方式，掌握用于排查问题的工具技巧。
> 我确信人工智能将引发技能退化危机。
我也这么认为。这将形成三重打击：
1. 大多数开发者(无论资深与否)都会被“让AI代劳”的诱惑吸引，导致长期人才队伍经验匮乏。
2. 学生将倾向于用AI完成作业，导致应届毕业生一无所知。我亲眼见证过这种现象。
3. AI生成的垃圾代码将开始污染Github等未来大型语言模型训练的素材库，引发质量崩溃。
我希望我们能以某种方式避免这场崩溃，但目前看不到阻止它的方法。
我认为资深人士自有判断力，知道是否需要学习。至少我是这么告诉自己的！
年轻一代的情况是：那些对技术原理感兴趣的人，如今拥有我们当年不曾有的学习工具。
而结果终究如故：部分新人会用心提升，另一些则不会。我确信许多初级员工会满足于流水线式地生产粗制滥造的产品，但真正优秀的人才自会主动追求更深层次的理解。
另一方面，若只是临时抱佛脚，等到再次需要运用该技能时，你早已忘记所学内容。
但没有AI辅助时，在确定正确一次性解决方案的过程中，神经连接仍在形成。
这些神经连接(或其缺失)对长期理解能力的构建具有深远影响。
正是如此。否则我对$that_technology的掌握程度本应更高。
恰恰相反，能够获取(基本/可验证)正确的解决方案来应对具体相关的问题，正是绝佳的案例学习方式。
或许还需辅以经典的“阅读手册”(RTFM)，但这确实能让我们摆脱软件工程领域普遍存在的“瞎子领瞎子”式StackOverflow模式。
我总觉得这是在人工智能炒作之后的倒退——当时人们纷纷避开计算机科学专业，或转投其他专业。最终我们可能再次面临开发者短缺的局面，这倒挺有意思的。
2005至2008年间我在大学就读，当时有许多人都劝我别学计算机科学。理由是印度和东南亚等低成本地区的外包软件开发人员会压垮薪资水平，由于竞争激烈，软件开发者年薪不该指望超过5万美元。
更近期的例子是放射科医师行业，这个职业曾被预测将被深度学习和神经网络彻底取代。但谷歌搜索显示，美国放射科医师当前年薪平均在34万至50万美元之间。
这或许就是职业领域的“血流成河时买入”法则。
我二十多岁时才转学计算机科学，虽然一直摆弄电脑却没早些接触编程。大学顾问也对我说过同样的话，还说他当年学计算机毫无价值。那是2012年。
我毕业前就拿到了工作offer。如今在本地拿高薪，98%时间远程办公，工作时间灵活。真庆幸没听那个人的话。
大学里唯一学到的是：顾问根本不靠谱。他们要指导多少学生？还指望他们知道什么最适合你？我的顾问硬要我读大一就选修特定数学课——微积分预备课，完全无视我AP考试证明自己早已超越该水平的事实。白白浪费了时间和学费。
回首往事，我犯过的最昂贵错误莫过于2003年左右说服自己放弃计算机科学方向，转而选择更“实用”的领域。
你一针见血，举例也精准到位。
2010年我还在读高中时，就听过类似论调——说外包业务转移到印度/东南亚等地，让计算机科学学位/职业(在美国)成了糟糕选择。这并非无中生有，新闻报道、网络言论，甚至某些自称前软件开发者的亲戚朋友都在这么说。我没有听信，现在庆幸自己坚持了选择。
大学毕业之际，深度学习成为新热点，我又听闻放射科医生将在五年内被自动化取代的论调。当时我既无意读医学院，也不认识任何经历过医学院的人，对这个话题知之甚少。表面上看，这种说法似乎有道理，我就把它当作“听起来挺靠谱”的观点记在心里。
时至今日，我认识了不少读过医学院的人，对市场也更加敏感。事实证明，那不过是又一场大众炒作。那些宣称“天啊放射科医生全要被电脑取代”的新闻早已从我的信息流消失，而我认识的放射科专业毕业生无一就业困难——他们的起薪甚至远超FAANG公司的入门职位。
我完全不记得自己想通过这条评论表达什么观点了，但你举的例子与我个人经历高度吻合。
我认为这些问题并非非此即彼。外包确实能让你在亚洲国家雇到更便宜的劳动力，但无法彻底消灭本地所有岗位。实际情况是：绝对平均水平/平庸者会被外包和人工智能取代，而顶尖人才仍能获得丰厚薪酬，因为他们确实物有所值。
因此我认为大量初级员工确实会被AI取代——并非因资历浅，而是多数人无法超越基础AI创造更高价值，而企业始终追求员工价值最大化。懂得这点并主动超越最低要求的新人将脱颖而出，其余者终将被淘汰。
> 我认为许多初级员工终将被AI取代，并非因资历浅薄，而是多数人无法超越基础AI创造更高价值——企业始终追求员工价值最大化。懂得此理并超越最低要求的新人将脱颖而出，其余者则将被淘汰。
这与当年对外包开发者的论调如出一辙。2008年的逻辑是：当你能以1万美元年薪从印度聘请拥有20年经验的资深开发者时，谁还会花5万美元雇佣初级员工？
现实情况：只需参加3-6个月的JavaScript速成班，五年后就能转行获得15万美元年薪的工作。软件开发行业当时就是如此供不应求。
若必须成为“顶尖人才”才能生存，这个领域已不值得涉足。
要对抗外包/廉价劳动力和人工智能的冲击，我同意这个观点。
更近期的例子是放射科医生，这个职业本应被深度学习和神经网络所取代。谷歌搜索显示，美国放射科医生目前的年薪在34万至50万美元之间。
归根结底，放射科医生终究是医生。
没错，他们薪资高昂的唯一原因在于人为设置的准入壁垒。
确实，当人们高谈阔论竞争与末日论时，恰恰说明市场需求旺盛。
你可以押注宣称一夜改变现状的新事物，也可以继续做当下行之有效的事。即便新事物成功，所谓一夜成功也更不现实。在此期间积累的洞察力，将助你把握变革带来的机遇。无论哪种选择，你都赢了。
没有竞争反而意味着需求缺失。
竞争有时确实过剩，但若只看数量而不论质量，往往只是错觉。印度虽有大量廉价工程师，但若想获得优质产品，就必须付出更高代价。
谁又能真正责怪学生呢？若是我处在他们位置，此刻恐怕也不会费心学习计算机科学。从他们的角度看，人工智能是否虚有其表并不重要；关键在于那些追逐AI热潮的企业是否愿意雇佣你。
该死，照现在企业对工程师推崇“氛围编程”的程度，我大概该去学木工了。
三四年时间足以让这些公司直面残酷现实。
“人工智能炒作导致新生避开计算机科学专业，在读生纷纷转专业”
这趋势实在糟糕。
让我想起2001年左右的同龄人，他们虽热爱编程却放弃计算机学位，认为所有软件工程岗位都会外包到印度等国，自己毫无发展空间。代价高昂的错误！
确实如此，我甚至知道有经验丰富的开发者彻底转行。我认为未来几十年对软件工程师而言将极其有利。需求将呈爆炸式增长，而供给却在萎缩。我们仿佛又回到了2010年。
传统编程方式仍会存在，但人工智能本质上是代码2.0版本，如今许多人工智能专属领域已非传统软件开发技能所能胜任。
具体指哪些？
它特别擅长编写Brainfuck代码。
或许他们的招聘渠道也正受影响。过去两三年间，多数企业以“人工智能将取代他们”为由削减实习岗位并减少招聘零经验者，导致当前具备两三年经验的潜在候选人数量大幅萎缩。
从历史经验看，这类候选人曾是招聘的黄金群体：风险低于零经验工程师，经验尚浅易于快速融入企业定制化工具流程并培养为长期员工，且薪资成本极低。
这虽是政策倒退，但我认为并非为预防开发者短缺而预先布局——更像是迎合市场对人工智能日益增长的质疑，毕竟人工智能取代所有知识工作的宏大愿景并未实现(至少近期不会)。
这与那些曾将区块链/加密货币/NFT/Web3吹捧为未来的群体如出一辙——当热潮退去后，他们便转向下一个骗局(当前正是人工智能)。如今他正收敛言论，为人工智能热潮降温做准备，试图在未来任何领域都显得理性且与时俱进。
“我们始终反对这种做法”
官方说辞将是：“我们始终建议只要能提升生产力就应采用它。”
指出这种立场并非一贯存在，只会让你显得“消极”。
说得对，虚伪谦逊与立场平衡拿捏得恰到好处。工资抑制只是意外副产品而非初衷，姑且称之为附带损害吧。
读到这篇文章格外有趣，因为相关新闻刚出炉：
https://www.business-standard.com/amp/world-news/amazon-euro…
或许他们意识到，在可预见的未来，企业应用场景仍需人类参与AI决策链，而初级员工(及来自低成本地区的人才)成本更低，能让经济账更合理。
赞同。
鉴于最近Reddit上关于初级开发者的讨论，这类人实在太多了，这确实挺有意思的。
> 转专业
转什么专业？
作为资深工程师，我并不惧怕AI取代工作的能力，真正让我担忧的是那些自以为AI能取代我们、却掌控着决策权的半吊子。
所以他的意思是该用擅长AI工具的应届生取代资深工程师？考虑到亚马逊的高离职率，这种观点倒也不意外。
我几位在科技巨头担任资深/高级工程师的朋友，基本认定未来几年自己的职位会因今年语言模型的飞跃性进步而岌岌可危。
我转行做咨询/外包工作，虽不像他们那样直面风险，但我的工作高度依赖语言模型。不过我认为这不会摧毁整个行业，反而会提升人们的工作效率。
他们的LLM和内部产品围绕着更强大的工具链，自动化了大量工作流程——我认为这正是担忧的根源。他们亲眼目睹自己的工作正逐渐转变为审查输出结果并将其输入其他工具。这属于技能的转移，而非完全自动化的解决方案。
未来五年发展方向难以预判。即便仅实现渐进式改进，完善工具生态系统仍能带来巨大收益。
但这对新晋大学毕业生意味着什么？若仅作为大语言模型的使用者，其中究竟有多少真正属于计算机科学范畴？
高级员工的工作已不再是(纯粹)编码，而是识别正确的重要方向并保持专注，让不同团队的鲍勃和史蒂夫避免重复建设，对关键事项做出有见地的决策，阻断有害的项目，发现显而易见的问题并勇于直言。
这并非当前LLM能胜任的工作。当然，未来或许能让LLM读取全公司邮件、Slack聊天记录和Zoom会议实录。但相比那些掌握企业专属知识与经验(这些知识从未被书面记录)的行业与公司老手，它真能产生同等影响力吗？
计算机科学本质上与代码无关。如何在有限空间内高效堆叠箱子，这才是计算机科学。代码只是语言载体。大型语言模型能否解决现实世界中各种形式的实际问题？若训练数据涵盖此类场景，或许可行。
若你深陷语法迷雾，职业生涯就此终结。若能从第一性原理到TCP帧结构、从变压器架构到计算原理全面理解，你就是黄金人才。
我的经验是：初级工程师入门较快，却永远无法精进真正的工程能力(分析)与开发流程(调试)。他们同样难以阅读和审查代码。
我担心除非投入大量精力培养并持续跟进，否则他们可能永远停留在初级水平。
若AI技术快速普及不可避免，则导师制与代码评审机制亟待重构。资深工程师不应仅验证功能实现，更应主动要求初级工程师阐明：AI提出特定方案的逻辑依据、替代方案的可行性、以及潜在风险。重点必须转向理解，而非仅限生成
> 但他们永远无法精进真正的工程能力(分析)和开发流程(调试)。阅读与代码审查同样令他们吃力。
你也可以这样描述人工智能时代前的开发者。这大概是我对某些同事最大的不满
某种程度上你说得对，但我仍认为在AI时代之前，开发者必须在某个阶段做笔记、制定计划并阅读更多代码。
我也有同样的经历。
在我看来，学习包含创造与品味两个维度，二者需平衡发展才能进步。创造本质上是构建思维路径的过程，而培养品味则是修剪优化路径以提升执行力的过程。
不经烹饪无法成为厨师，若不培养对“何为有效”“何为精良”的鉴赏力(双关语)，更不可能成就大师。
通过与实习生和应届生的交流发现，他们普遍缺乏这种品味，过度依赖AI生成代码。结果是：当你与他们讨论时，他们往往难以理解所用概念和工具——既缺乏创作带来的熟练感，也缺乏将生成的代码打磨成精品的技能。
我认为更大的问题在于，如果取消初级开发岗位，实际上只是延长了大学所需的学习时间——这相当于要求学生在大学里扮演真实公司员工的角色，完成实际工作，直到积累足够经验才能直接进入更高层级的岗位。不过医生群体也面临类似困境，因为医疗行业根本不存在入门级职位：当你肩负着人类生命责任时，除资深职位外的任何岗位往往都难以胜任。
我认为初级开发者招聘遭受的最大打击，源于疫情后远程办公的普及。当所有人各自蜷缩在地下室阴暗的房间独自工作，而非与同事导师共处办公室时，初级开发者获得真实指导的机会就大幅减少——包括那种潜移默化的环境式指导。
智能编程的兴起或许是打击初级开发者的第二记重拳，但这不过是过去五年多来逐渐显现的趋势延伸。
“人工智能将取代软件开发者”
“若资深员工抵制AI并声称其无效，就用AI原生工程师取代他们！”
“AI将取代所有初级软件开发者”
“AI将成为辅助初级开发者的工具”
最终我们终将抵达这样的认知：
“AI需要且未来仍需大量人工干预，无法替代独立构建和维护专业领域知识的能力”
加曼忽略的核心问题是技能退化。AI虽能帮助初级开发者快速编写模板代码或查找API接口，却无法传授核心能力：调试技术、系统思维和复杂代码解读。依赖AI“拐杖”成长的初级开发者，可能永远无法掌握区分资深工程师的复杂模糊问题解决能力。
与此同时：
“亚马逊宣布2030年前向印度投资350亿美元，推动AI创新并创造就业” https://www.aboutamazon.com/news/company-news/amazon-35-bill… (2025年12月9日)
这是关于数据本地化的问题。
哦，所以CEO大概是指用AI取代外籍初级开发者是个坏主意。但替换本土初级开发者倒是可以
这番论述完全忽视了短期思维如何毒害整个(职场？资本体系？我也不清楚)。
没错，断绝人才输送渠道确实糟糕。但那是未来CEO的麻烦。当我们需要新资深员工填补自然流失时，大可从竞争对手那里挖人。
况且初级员工薪资也未必低多少。当然，确实存在在Wordpress网站做简单前端开发之类的人，收入低得多。但在我的工作场所，当初我们有初级软件工程师时(过去三年要么培养成资深，要么自然流失)，他们的薪资约为资深工程师的四分之三。所以你可以雇4个初级工程师，也可以雇2-3个资深工程师。可以说，让1名资深工程师运用AI技术，远比让4名初级工程师整天消耗代币、试图让Cursor执行他们根本不理解且无法有效评估的任务可持续得多。
总之我完全认同，所有这些做法——尤其是取消工程师职业阶梯底层的两个阶梯——对整个行业都是灾难性的。但我们的激励机制会让这么做的公司获得丰厚回报。股价会上涨。让未来的CEO去操心吧。
四个月前他就说过同样的话：https://news.ycombinator.com/item?id=44972151
顺便说一句，有趣的是某些人总爱把“常识”挂在嘴边，但只有当这些话出自AWS CEO或类似人物之口时才信服，若匿名评论者说同样的话反而会招致嘲笑。
任何炒作周期都如此循环往复，这不过是最新一轮罢了。
1. 用AI取代初级工程师，必然断裂人才输送链。资深工程师终将退休，谁来接替？难道我们敢赌那时不再需要工程师？风险太大。
2. 初级工程师过度依赖AI工具本身就是问题。AI工具从资深工程师编写的现有代码中学习。初级工程师过度使用AI将导致工程技能退化。最终将导致AI从AI生成的代码中学习。这种现象同样适用于多数内容领域——随着互联网内容日益由AI生成，此趋势愈发明显。
近期我与两位初级开发者(虽是初入职场，但在公司已工作2年以上)进行结对编程，旨在转移某项技术诀窍。
我意识到他们在多数基础事务上表现得令人震惊地糟糕。然而他们的公关材料看起来相当出色(至少表面如此)。我推测他们使用人工智能编写了大部分代码。
他们真正擅长的是：a) 确保员工与公司文化契合；b) 为AI提供长期任务背景。本质上他们是产品/客户与AI之间的人类过滤器，会对AI模型的输出结果进行质量把关(在一定程度上)。
完全坦白：我对当前亚马逊/AWS管理层相当不满，因为在我看来，他们连纸袋都带不出来(前AWS经理)。有数据表明亚马逊/AWS仍在招聘初级开发者吗？听说如今学生项目竞争异常激烈，但我手头没有数据。我的抱怨在于Garmin言行不一。
我们经常遇到初级员工或实习生，他们完全能够借助各种形式的AI技术批量产出大量代码行——问题在于他们从未真正学会独立思考，当系统出错或大型语言模型陷入困境时，他们根本无法解决问题。最近我发现自己不得不花更多时间指导和陪练新人，因为他们根本没有机会建立自己的技能体系。
确实如此。那么十年到十五年后，谁来担任资深工程师呢？
你以为那些决定是否招聘更多初级工程师的人，会规划超过一两个季度的未来吗？10-15年后的问题，反正不是他们要承担的。
没错，可惜10-15年意味着连续五任领导都要把问题推给下一任。
这些人为了牟利正在摧毁地球，他们根本不在乎。我们的社会机制非但不会惩罚他们，反而纵容这种行为愈演愈烈(看看数据中心扩张如何导致贫困社区缺水、电费飙升和癌症高发；几乎所有政客都对此妥协，因为他们根本不懂)。
希望人们别再跟风说“人工智能是环境公敌”。人工智能和数据中心整体排放量连污染源前100名都排不上，永远都排不上。
若真要指责科技公司破坏环境，请关注强制员工通勤的政策。毫无意义的通勤对环境的危害，远比所有数据中心加起来更严重。
抱怨人工智能的环境影响，就像塑料制造商在不可回收的塑料上贴回收标签，把塑料污染归咎于普通人回收不足。
相较于全球航运或航空旅行的排放量，人工智能对环境的影响微乎其微，简直可以忽略不计。
为何人们对机场扩建毫无异议？其危害程度远超人工智能。
答案很简单：他们憎恶人工智能，环保论调只是借口，正如他们对AI艺术的担忧。人性使然，这些人中许多人甚至真信了这个借口。
不妨设身处地想想：若明天发现AI对环境有益的证据更充分，你会相信吗？这会改变我反对AI的立场吗？答案是否定的。
> 答案是否定的。
你无法断言。我无法代表你(你的言论可能更多暴露你自身而非他人)，但我坚持立场必须立足现实而非谎言(包括自我欺骗)。
况且环境问题远非唯一关切。
你在攻击稻草人。在你看来，反对生成式AI仅仅因为它违背你的信念，就必然是理性的。请别这么做。
人们有权拒绝任何事物，很遗憾民主未能让你在社会其他群体受苦时赚取更多金钱。
我很高兴人们正从地球上最邪恶的群体手中夺回权力掌控权。
当然它们并非直接排放烟雾的污染源。但它们消耗的兆瓦级电力终须在某处产生。很少有人能享有在核电站附近建厂的奢侈。而最终这些兆瓦级的热量仍会释放到大气中。
> 为何人们对机场扩建不这么愤怒？
我们同样愤怒，别担心。
我敢肯定Anthropic希望答案是克劳德。
我敢说Anthropic心知肚明希望落空，只是不会告诉你罢了。
10-15年？可悲的是，多数人工作两年就被冠上资深头衔。
显然，拥有10-15年开发经验的人在AI领域将成为资深开发者。凭借这些经验，他们很可能晋升管理层。
提拔顶尖工程师担任管理职务有时能获得优秀管理者，但往往会以牺牲优秀工程师为代价，换来平庸或勉强合格的管理者。
我极力推崇“资深工程师”发展路径来规避此问题。那些与管理岗位格格不入的十年以上资深工程师，应当能继续领取管理层薪资，同时发挥最大技术影响力。
https://staffeng.com/about/
我同样支持“领导力不伴随管理职责”的模式。这些资深工程师理应承担领导职责——协助组织规划、指导团队成员、优化工作流程。但他们不该被困在管理事务中，比如进行一对一谈话、管理直接下属、每年耗费一个月完成绩效评估流程。
这是企业普遍面临的难题：如何将领导力与人事管理分离。为何既要由同一个人指示工作，又要由同一个人进行年度考核？为何同一个人既要主导项目技术设计，又要审批休假申请，既要协助职业发展规划，又要对失误给予反馈或纪律处分？为何我们总将这些截然不同的角色捆绑在“经理”头衔之下？
这正是我的处境。多次被要求担任管理职务，但我毫无兴趣。凭借18年工程经验成为首席工程师，靠的是技术实力而非管理才能。正如你所言，我能通过导师指导、提供建议、技术主题演讲及项目领导等方式贡献领导力。
完全赞同。尽管如此，拥有15年开发经验的我仍被组织反复推向管理岗位。我热爱本职工作，厌恶管理他人。再高的薪酬也无法让我成为管理者。
我每年仍需耗费一周进行绩效评估，但你提出的观点确实精辟。
除了下季度，其他都不存在。
AI将成为资深工程师
你不可能预知技术将引领我们走向何方。
显然是从竞争对手那里偷来的。
> 事实上，30%裁员以期节省开支的企业最终反而增加了支出，许多后来不得不重新招聘。
比如(咳…)亚马逊？
出处..？你具体指的是什么？
这些初级AI系统成熟后会成为资深开发者，进而指导更初级的AI吗？那我们就不需要人类开发者了？这不正是终极目标吗——让AI运营公司，我们都能去钓鱼？
过去几个月我多次听到类似说法，每次都出自亚马逊或AWS高管之口。这次他或许想替换资深工程师。这对公司更有利——随着年复一年资深员工数量激增，当前形势下他们根本不会主动离职。
我认为核心思路并非停止招聘初级员工。真正的意图是用配备LLM的廉价初级团队取代高薪员工。核心在于拉低平均薪资水平，而非彻底停止招聘。至少目前如此。
然后那些拥有丰富领域知识的失业资深工程师，会用AI快速创建竞争对手。你不得不花大价钱收购并封杀他们。真是高明的策略。
他们有律师、专利、竞业禁止协议、串通行为和监管俘获来阻止这种情况发生。
我们还可以假设，一旦这些编码模型足够成熟，就不会与公众或竞争对手共享。
若不投资培养初级员工，不过20年就会面临资深员工枯竭的局面。
这里的愤世嫉俗程度简直令人发指。在发现“解雇初级员工，让少数资深人士管理自主代理”的策略彻底失败后，现在又改口说“其实初级员工很棒，因为我们洗脑他们认为人工智能很酷，而且不用给他们太多薪水”。这简直令人作呕。
唯一值得讨论的是维持人才输送管道——这还用说吗？这种老生常谈竟被包装成高明见解，恰恰暴露了我们行业正深陷何等愚昧的泥潭。
泡沫。必须。尽快。破灭！！
哪个方案更不蠢：用AI取代应届生，还是用H1B签证取代应届生？
那应届生H1B呢？
招聘持OPT签证的应届毕业生，并过渡到H-1B签证。
更好的方案是：用AI取代所有人，当AI失效时，再用H1B签证者取代AI。
我们真以为所有开发者会蜕变成技能完全同质化的模板吗？许多工程师早已专注特定领域，无论是性能优化还是高阶架构设计。
我预测更专业的技能组合将日益普及：有人能高效运用AI快速构建概念验证原型，有人能在成熟代码库中借助AI提升开发速度(比如让Cursor自动生成新类型的REST接口)，也有人选择将AI排除在工作流程之外。
最终(至少我如此期盼)，AI将被视为开发者日常工具箱中的普通工具，而非取代开发者的万能救世主。
如今我日常使用的多数应用每天至少会崩溃一次。我认为这直接源于未经审查/测试就将AI代码投入生产环境的做法。
虽然我对AI生成的代码并无好感，但这与AI本身无关。软件不可靠的状态已持续十余年。企业多年来不断推出半成品并持续打补丁。而这正是我们的过错——因为我们早已对此习以为常。
> 软件不可靠的状态已持续十余年
这个“十余年”值得用大量强调符号标注。时至今日，我仍坚持每写完一行代码就立即保存——只因80、90年代经历过每日(有时每小时)整台机器崩溃的噩梦。
同感，现在真该开启自动保存功能来保护我的手指了
我总担心自动保存功能会在程序卡死时尝试写入，反而导致文件损坏。
记不清是哪款软件让我产生这种顾虑。或许是早期Matlab版本在卡死时会清除未保存文件，而当时自动保存功能处于开启状态。
我预测情况会好转，因为用AI查找修复的成本在时间投入上低得多。
问题根源在人而非技术。企业与管理者需要开始关注细节，而非机械地勾选清单。除非行业文化发生转变——这种转变或许永远不会发生——否则AI无济于事。更糟的是，当开发者为赶制任意设定的截止日期而仓促交付时，AI反而会加剧问题。
我之所以认为情况可能不同，是因为我注意到自己行为发生了实质性改变。
我始终非常重视质量和工艺。现在工作中发现问题时，我会立即修复。用AI编写代码所需的时间，原本足以让我把问题无限期拖延到待办事项清单的某个角落。
更何况，若你本就在跳过测试环节，或自欺欺人地认为“测试代码早已写好”——而这些测试从一开始就毫无验证价值——那么盲目追捧“AI能编写完美代码”的炒作浪潮，根本无法打破这种恶性循环。
AI从不修复任何问题，只会制造缺陷并累积技术债务。
谢天谢地还有人脑子清醒。
开发者应纵向替换而非横向替换，否则明天谁来当你的资深开发？
玩笑归玩笑，AI确实可能全面削减人力，但企业应努力保留各层级的人工岗位。况且大型语言模型连初级开发都无法完全替代——至少目前还做不到。
我认识某银行团队从13人缩减到2人。剩下的两人很可能被外包，他们正试图转型到业务部门。
海得拉巴的团队也能运行LLM，而且印度的数据中心和基础设施成本更低。
初级员工往往对AI工具最娴熟/最得心应手。
让他们与资深工程师搭档，可学习工程最佳实践：
同时资深工程师也能获得如何更高效运用AI的额外经验/洞见。
拥有初级工程师(实际上是各经验层次的合理组合)能加速组织发展
> 初级工程师往往对AI工具最娴熟/最适应
为什么？这在我看来不太可能。这就像说初级工程师最擅长使用JJ、Zed或VSCode。
但有趣的是，当应届生面试时使用AI“辅助”，雇主反而会反感:D
昨天刚参加某非FAANG公司的编程面试，面试官要求屏幕共享，还特意检查我的IDE设置确保“AI”功能已关闭。
我压根没打算在面试中使用基于LLM的工具。
话虽如此，即便我真有此意，面试官也无从察觉。面试必须当面进行。(话题跑偏了……抱歉)
我长期负责团队管理与支持工作，恕我直言，在大公司里初级和中级开发者承担着绝大多数实际工作量。我不认为人工智能会取代他们。那些IC5和IC6级工程师短期内也不可能每年提交400-500个代码变更。
我在REST服务器上给Opus分配了一个“错误”的研究任务(使用此斜杠命令[1])，要求研究如何利用SQLite + Litestream VFS为REST服务本身创建读副本。这显然是对VFS[2]及SQLite这类系统的危险用法(从隔离层和读取时效性角度而言)。它当然欢天喜地地启用了Django的数据库路由功能，通过实现
allow_relation策略——当obj._state.db为replica或default主数据库时返回true。此时Claude获取了该[2]链接，并通过网络搜索器在研究提示中获取了daya。但这并非重点。任何合格的初级工程师——分布式系统入门级知识——都该明白关键在于忽略了真正重要的核心问题。虽然存在关于提示优化方案的探讨[3][4]，但核心难题在于：系统能消耗多少资源来思考这些问题，并设计出最优提示及其修正方案？这本身就是个极其棘手的难题。
[1] https://github.com/humanlayer/humanlayer/blob/main/.claude/c… [2] https://litestream.io/guides/vfs/#when-to-use-the-vfs [3] https://docs.boundaryml.com/guide/baml-advanced/prompt-optim… [4]https://github.com/gepa-ai/gepa
我不确定初级员工能否立刻理解你描述的风险。即便他们去年在分布式系统入门课上表现优异。
他的意思是：当这种操作发生时，看看被裁员和新聘用的人员——猜猜结果？L7-L6被解雇，L4-L5被录用。他们很可能认为用AI替代资深员工雇佣初级员工在财务上是划算的
可大型企业都在这么干。说明解释链条存在逻辑漏洞。你不能一边宣称“这是蠢主意”，一边照做——这根本说不通。
初级开发者终将晋升资深。初级岗位消失=资深岗位枯竭。
初级与资深的区分本身有误。关键在于“能否高效运用大型语言模型”。
这如同要求员工掌握版本控制技能(该技能在早期并非如今这般基础要求)。
初级开发者并非圣诞礼物，而是终身伴侣。
但严肃地说，真有CEO认为能用AI取代行业新入职者吗？他们以为5-10年后谁会成为资深开发者？
但核心问题未被触及：初级开发的工作内容恰恰是AI可替代的领域，而非资深开发者掌握的复杂技能。
理所当然。没有初级开发者，就永远不会有资深开发者。这是不言自明的道理。
我猜理论是：5到10年后当这个问题出现时，AI也会取代资深开发者。
在我看来这纯属幻想和一厢情愿。
当然很多人这么认为。
但也有人押注相反的趋势。
从文明发展的角度看，我对此观点颇为认同。
四个月前的旧闻重提：https://news.ycombinator.com/item?id=44972151
用AI取代初级员工真是绝妙主意。
既然如此，干脆连中级开发也一并替换掉。
——某资深开发者
老扎克伯格预言2026年80%初级开发者将被淘汰，我断言2026年80%替换软件工程师的CEO将被淘汰
短期成本确实更低，直到高管更迭——那时候就变成下任的麻烦了。
第三点同样适用于整体人口生存法则。生育率最高的国家终将胜出。
> AWS首席执行官称用AI取代初级员工是“我听过最愚蠢的事”(theregister.com) 3个月前由JustExAWS发表，获1697点赞
https://news.ycombinator.com/item?id=44972151
这则报道有何新意？
这位CEO是个销售型人物。他每隔几个月就会重复同样的说辞，宣称推出“全新升级的AI预测系统”。
如果所有初级工程师都在使用AI，这种说法还成立吗？
顺便说一句，初级开发人员确实用AI辅助工作。
我不知道，我一直认为初级员工的问题主要是非技术性的，是年轻人的通病：过度自信、热衷捷径、自我优越感、傲慢无礼、缺乏沟通且不尊重同事(包括同级和前辈)、厌恶技术争论、缺乏妥协精神和团队纪律、轻视现有解决方案、交付后跟进懈怠、边缘案例检查马虎、对工具语言等事务固执己见。这些问题几乎无法靠AI解决，反而可能被放大。比如一个新手配AI和一个资深开发配AI可能效果相当，但七个新手配AI对抗七个资深开发配AI，很快就会崩盘。
先是新手，接着是资深开发，最后轮到CEO…
看他们做什么，别听他们说什么。
所以结论是什么？只解雇资深开发者？因为他们薪资太高又不会用AI？
有些公司反其道而行，解雇资深开发者，招聘有AI经验的初级员工
如今借助AI，我预期初级开发者能更快成长并迅速晋升资深。现在我倾向于初期同时招聘至少一名“初级”和一名“资深”开发者，再增聘更多初级人员快速培养成“资深”。
既然初级开发者能快速掌握AI代码库，我们根本无需再招聘需要培训资深开发者——初级开发者的成长速度已完全取代了招聘资深开发者的必要性。
因此用AI代理取代他们不仅完全愚蠢，更是为时过早。实际上更合理的做法是大幅减少资深开发者招聘，直接将初级开发者培养成资深开发者，这样既能节省大量资金，又能缩短入职培训时间。
问题解决。
要是人人都能这么想就好了。
另提一点——若AI吞噬SaaS市场，AWS将何去何从？
嗯…更多业务。因为AI在云端运行，消耗的资源会更多。
但具体哪些业务？
有人懂了。
是现在还是过去？
用AI快速推进，然后搞砸很多很多东西，而且速度极快
觉得初级开发普遍被认为能力不足有点奇怪。
我刚入行时技术还算过得去，后来招聘的应届生通常也挺靠谱。
真是蠢到家了。这就是资深开发者痛恨中层管理白痴的原因。年轻人更懂行？笑死。新人根本什么都不懂。认识到事物运作原理不等于掌握知识。
更隐蔽的问题在于，如今的新人依赖AI处理一切，导致学习停滞。他们已经落后于时代了。
……接下来就要用AI取代初级开发了
他们心知肚明AI效率低下，充其量只是个华而不实的“模板填充器”……
培养资深开发难道不需要初级开发吗？难道还有别的途径？
这纯属迎合AI质疑浪潮的表演式废话。若AI投资仍在全速推进，他就不会说这种话。
我认同他关于AI惠及初级开发者、务实应用能提升效率的观点，但这早不是新闻——自大型语言模型诞生之初就显而易见。
所以当AWS负责人说这话就是作秀，但你说了就不算新闻？可当你这么说时，大家就该在评论区听你的？
当你随波逐流迎合市场预期而非坚持己见(无论观点多么谬误)时，才叫作表演。这种行径让我想起那些曾将NFT/Web3吹捧为“划时代创新”的加密货币狂热分子，当预言落空后，他们便按同样套路悄然转向下一个骗局(AI)。
(当然我只是在技术论坛用笔名胡扯，没去参加那些广受关注的访谈)
说得对。
是我疯了还是他几个月前就说过这话？
没错，你没看错 🙂
三个月前在HN讨论过：https://news.ycombinator.com/item?id=44972151
股东们可不喜欢这样
我不太理解CEO这番评论。
难道他不懂那些靠人工智能赚取数百万甚至数十亿美元的人根本不在乎吗？
他们完全致力于探索能否彻底消除雇佣人类的必要性。
他们想要建立技术封建主义。
萨姆·阿尔特曼之流在采访中表现得如此反人性，我们竟允许他们身居高位，实在令人作呕。
终于。
真奇怪，硅谷年龄歧视问题直到伤害到初级开发者才引起关注。不，我没有幸灾乐祸。只是看到包括本帖在内，许多人现在竟宣称初级开发者比资深者更懂AI工具——尽管我们使用这些工具的时间其实相当。
或许该承认自己存在问题了？但这种觉悟恐怕要等到你耗费二十年紧跟最新工具技术，却因头发花白被宣判“过时”时才会降临。
然而…
没错，泡沫即将破裂时他们砍掉了职业生涯，抱歉了。
他们大概忘了最初制造科技泡沫的人是谁，因为如果我再不被录用，就要取代这些公司了
[已删除]
我觉得你可能得了脑坏死
第1周：64名实习生
第2周：32名实习生
第3周：16名实习生
第4周：8名实习生
第5周：4名实习生
第6周：2名实习生
第7周：1名实习生
第8周：0.5名实习生
他们真能活过夏天不被劈成两半吗？
如果他们不同意变成半机械人，那算不算真正运用了足够的人工智能？
赞同
这些实习生稍微动动脑子，第六周结束前就该逃之夭夭了。
我觉得这是你编的。
你对招聘流程真是毫无信心啊。
这就是招聘流程…
这些实习生时薪多少？
没听懂问题，他们是实习生啊
哇，这工作环境真他妈糟糕。
> 每周我们都会精简团队规模减半
搞什么鬼。
考虑让他们在竞技场互相厮杀，还能变现呢。
饥饿游戏风格，我喜欢
我是不是漏掉了什么讽刺？实习不该是花时间教人入门换取免费劳动力吗？这听起来像杰克·韦尔奇式的自嗨。
优胜者终将脱颖而出
这话听起来像是没见过模型进步速度的人说的，根本不知道它们离完全自主的工业级软件开发有多近。
这个理论很容易验证：如果AI真能媲美资深工程师，软件开发成本理应同步下降，质量理应同步提升，交付速度更会大幅加快。既然大型语言模型已普及大众，开源领域也该出现类似变化。
但现实恰恰相反——软件质量正急剧下滑(这并非AI之过，早在LLM时代前就已显现)，交付速度未见提升 (这不足为奇——编写代码本身从未是瓶颈，而将AI强行植入各处的做法反而可能全面拖慢交付速度)成本也未降低(那些误入歧途的AI项目反而造成了额外开销)。
这本是笔极易下注的买卖——软件开发仍是庞大产业，若你确信AI能完成资深工程师90%的工作，大可开家咨询公司压价抢单，坐收差价。但迄今我未曾听闻此法有任何长期成功案例。
简而言之：编码是容易的部分；至少在过去几年里，它很少成为瓶颈，因此即使我们消除了编码环节，也无法交付无限量的软件。“构建什么”通常比实际开发耗时更长。只有当编码成为主要阻碍或占据交付周期大部分时间时(提示：根据我的经验，编码时间通常连交付周期的20%都不到)，产出量才会增加。软件开发生命周期包含众多阶段，大型系统在开发前还有大量流程环节。
关于你提到的咨询公司：许多软件开发咨询业务将逐渐枯竭。你所说的成功模式行不通——毕竟如果咨询公司能做到，法学硕士也能做到，那我何必需要你当中间人？小事交给Claude/Gemini等AI处理就行，这种趋势在平面设计、文案撰写等小型创意领域已初现端倪。但涉及高复杂度、需专业判断的大型项目，仍需领域专家、规范框架及其他非编码岗位——这虽会显著降低效率，但相较于当前任何需要智力劳动的岗位，这些工作仍具优势。
因此编程完全可能被自动化，而整体“大型”软件开发速度可能仅提升20%。正如我在其他评论中所述，真正成为瓶颈的将是那些价值贡献微薄却因合规、尽职调查、销售、咨询等原因不可或缺的中间环节人员。那些被技术人员视为低价值、低效率且毫无贡献的人群——最终笑到最后的恰恰是他们，而这一切都要感谢人工智能。
就我团队而言，我们已实现显著改进，甚至不再考虑招聘新员工；我甚至开始担忧资深员工的去留。任何涉及劳动力而非决策的环节，我几乎不再需要协助。这在大型公共机构中涉及诸多环节。如今我感觉只需两名员工：一人负责理解问题本质与解决方案(而非实际执行)，另一人作为问责制后备。若真要增聘人手，只能是因为我跟不上AI的节奏而精疲力竭——但我不会这么做，因为不愿在产品工作枯竭时陷入“雇佣即解雇”的困境。这种处境令我焦虑，更无法坦诚推荐任何人以此为职业；此刻其他选择都像是虚妄的希望。
这听起来像是仅在小型博客或无需维护的副业项目等有限场景测试过的人的评论
是的，你说得对
我至今未见过这些生产级模型写出真正生产级别的代码；