大语言模型时代高级软件工程师的轨迹是什么？一场 Hacker News 的辩论
一场题为“Ask HN：高级工程师当前的轨迹是什么？”的 Hacker News 讨论产生了 58 条评论，且未达成共识。评论者中的主流观点是，高级工程师的角色正在被重新定义——从编写代码转向指挥智能体、把控质量以及应对组织政治——而非被淘汰。少数观点则认为，架构本身将是强化学习的下一个目标，并且该角色将在几年内大幅缩减。
帖子讨论的起点
原始发帖人问道，为什么前沿实验室不能像在代码和数学上（存在对错答案）那样，构建关于优秀和糟糕软件架构的数据集并进行强化学习。发帖人直白地阐述了其中的利害关系：
“鉴于 2024 年大语言模型还只是个花哨的自动补全工具，而现在人们已经在谈论用智能体构建‘软件工厂’，在您看来，是什么阻止了这一发展？为什么软件架构在一两年内对智能体来说仍然困难？”
发帖人自己的结论对程序员来说是悲观的：“我认为（从商业角度看）对实际软件编程技能的需求在几年内会消失 90%，而产品负责人等拥有更多人际交往技能的人会更受青睐。这是一段美好的时光。”
最有力的反驳：架构可能根本不再重要
结构上最有趣的回帖来自 akoboldfrying，他认为问题的前提是错误的——不是因为智能体无法学习架构，而是因为架构的存在仅仅是为了应对人类认知的局限。
“架构，即应用/强制执行诸如模块化和抽象层次等组织原则，目前我们这样做主要是为了管理复杂性——以便我们能在有限的头脑中容纳尽可能多的系统。对于足够大的系统，为了高效工作，这是必要的。但如果你能不用这些‘拐杖’就能‘把整个系统装进脑子里’，那么实际上就不需要它们了。它们变成了可以省去的开销。”
该评论者将此比作一个“Hello world”脚本，没有人会为它规划架构。如果模型能在上下文中容纳整个代码库，那么架构这门学科就变成了可选的额外开销，而不是一项需要自动化的技能。
帖子中的证据表明智能体已接近掌握架构
一位评论者 jwr 报告了使用帖子中提到的两个模型 Fable 5.1 和 Astra 处理架构设计文档的直接经验，并表示结果与人类工作相比具有竞争力：
“我和它们一起处理架构设计文档，它们非常出色。它们的一些建议比我的解决方案更好。它们还没有到能完全取代系统架构师的程度，但已经很接近了。”
同一位评论者指出了模型仍无法触及的领域：“仍然存在一个悬而未决的问题：构建什么，以及如何创建易于理解、并以人类可理解的方式呈现复杂信息的用户界面。这是 AI 目前无法做到的。”
第二位评论者 zeryx 描述了尝试用智能体构建视频游戏的经历，并报告说智能体可以编写任何单独的代码片段、编写脚本来捕获基本故障模式，甚至可以通过启动虚拟机、使用 AutoHotkey 触发游戏状态、截取屏幕截图和 GIF 来评估它们构建的内容，从而实际游玩游戏。失败不在于执行：
“凭直觉知道构建什么才能最大化乐趣，或任何其他非逻辑的人类体验，永远不会被强化学习化。”
帖子中认为对智能体来说仍然困难的部分
几位评论者就他们认为难以自动化的一系列任务达成了共识，且他们的理由不同于通常的“AI 不会写代码”的论点。
组织共识。 accurrent 将高级角色本身定义为政治性的：“我认为高级软件工程师是在大型组织中推动共识的人。我认为大语言模型短期内不会解决这个问题。”同一位评论者指出，在后端，追踪竞态条件和推理什么适合放入上下文窗口仍然需要人工监督，设计无缝迁移的测试也是如此。
对糟糕想法提出异议。 jgilias 认为，当前的模型（如果有的话）过于顺从，无法在这个角色中发挥作用：
“模型存在对齐问题。也就是说，它们过于对齐，无法对糟糕的想法进行足够有力的反驳。有时由于权力动态等原因，你无法真正反驳，但工作仍然需要以某种方式完成。因此，人类通过有时忽略糟糕的想法，有时配合叙事，但随后做实际需要做的事情，有时在没有其他办法时，坚持立场并在一些糟糕想法真正扎根之前将其扼杀来应对。一个智能体可以用昨天存在的 SOTA 模型能力做到这一点。但那样它们就需要变得严重不对齐。”
责任归属。 papa-smurf 描述了自己从软件开发转向系统咨询，并明确指出了护城河：“（咨询）工作的主要护城河是，客户总是需要一个人来承担责任。那就是我。我想类似的角色相对安全。”
决定构建什么。 fergie 将问题简化为本质：“最终你仍然需要有人来决定我们要告诉机器做什么，然后实际告诉机器做什么，不管是用 JavaScript 还是简单的英语，这并不重要。”
重新定义：高级工程师作为技术负责人
帖子中最常被重复的预测是，职位名称会保留，但职位描述会改变。gregwebs 直接指出：
“高级工程师和所有软件工程职位将变得更像技术负责人。如果你能指挥 AI，并且比非软件工程师指挥 AI 开发软件产生更多的每美元/时间价值，那么你仍然可以产生大量价值。对于大多数非原型的东西，现在应该已经是这样了。工作已经从‘编写代码’变成了‘交付软件’。一个技术负责人。”
同一位评论者补充了一个供给侧论点，反驳了简单的裁员说法：“但也会有 1000 倍更多的软件。因此，对于那些适应的人来说，可能仍然会有机会。”
bradfa 提出了一个关于角色融合的平行观点，指出产品经理、项目经理和 Scrum 负责人在大语言模型出现之前就已经存在于工程团队中，并且这些角色是任务的委派，而不是一种独立的工作类型：
“现在，所有这些角色都可以部分外包给大语言模型，但仍然有一个人类在循环中指导工程并与业务/客户对接将仍然有价值。知道整体上要构建什么、下一步构建什么、以后构建什么，以及产品如何与业务目标相关联，仍然是一项非常人性化的工作。”
帖子建议培养的技能
RugnirViking 推荐了一个具体的技术方向：“我建议更多地关注性能、测试和可观测性。人类的理解 + 质量/可维护性才是金钱所在。学会用智能体来做这些事情。”同一位评论者链接到另一个 Hacker News 讨论，关于“AI 使用是一项技能”的观点，并总结道：“我不认为工程师会真正灭绝，尽管他们可能会减少。”
accurrent 指出，美学和用户体验直觉在前端变得更有价值，因为原型制作现在足够便宜，可以测试许多概念；而机器人技术则是一个“即使有 LLM 辅助编码，你也不会觉得移动得更快”的领域，因为存在太多跨职能问题。
异议：经济性尚未证实，看涨是自私的
并非帖子中的每个人都接受智能体能力是约束条件的假设。sdcfgy 认为约束是财务和政治上的：
“经济性和现实情况尚未证实且不透明。我们拥有的大部分证词来自重度投资的人士和/或以当前较低折扣率支付技术费用的人。提供技术的公司财务状况不佳，在地缘政治上高度站队，对许多人来说是一个风险。它是否有效是无关紧要的：看起来地平线上有一个巨大的经济或政治失败。因此，在思考未来之前，先观望。”
amelius 将采用本身视为一个陷阱：“每个看好 AI 的 vibe coder 都需要意识到，我们正在训练 AI。帮助它取代我们。我们基本上是在为圣诞节投票的火鸡。我们完蛋了。”
fergie 对高级软件工程师薪资的任何下行压力提出了另一种解释：“高级软件工程师薪资的顶端似乎确实有一些压力。这可能只是主观愿望，但如果属实，我怀疑这与求职者增加的关系更大，而不是实际工作的减少。AI 似乎推高了每个空缺职位收到的申请数量。”
zerop 对采用将真正落地的领域提出了一个更狭窄的主张：“大语言模型在编码方面取得了成功，因为有人正在审查它产生的工作（代码）。当然，代码质量随着时间的推移变得更好。我认为，除了人在回路中的场景外，AI 在业务中不会看到大规模采用。”
需求侧论点：大多数人不想与计算机交谈
dimbletimbers 认为，帖子的参与者系统性地高估了竞争：
“我认为开发者和 HN 上的人大大高估了普通人对计算机的了解、关心或渴望与之互动的程度。无论工作变成什么样，如果你喜欢与计算机交谈，并且知道如何让它做除显示电子邮件或 YouTube 之外的任何事情，你就领先于潮流，并且很可能保持领先。”
testerius 将该观点扩展为一般的劳动论点，将程序员与数学家、医生、生物学家、销售代表、营销人员、教师和艺术家并列：“当然，你可以摆脱程序员或数学家，但那样你需要自己理解和处理事情。你仍然需要有人能检查‘发生了什么’。”
frangonf 提出了同一论点最简版本：“如果软件（以及其他可能很快受到同样冲击的学科）仍然可能‘出错’，即使有机器辅助你仍然可能搞砸，那么从事软件工作的人仍然有一席之地。”
帖子的落脚点
没有评论者声称知道时间表。帖子实际的产出是一份候选护城河清单——组织共识、责任归属、决定构建什么、美学和用户体验判断、性能和可观测性工作，以及否决糟糕想法的意愿——以及两个真正不相容的预测。一个是架构是一项可学习的技能，智能体将吸收它，之后这门学科就变成不必要的开销。另一个是架构是对人类记忆局限性的变通，智能体从一开始就不需要它，因此它们是否能学会它的问题无关紧要。
几位评论者用黑色幽默而非分析来回应存在主义的框架。Zealotux 写道：“我已经开始研究创办一个害虫防治业务，或者也许翻新我在街上找到的家具。如果你有其他适合高级工程师的想法，请告诉我。”sitzkrieg 自称“几乎正式进入白发老手领域”，他说：“正在考虑开一个养蜂场。被数百只蜜蜂蜇伤听起来仍然比被迫与任何来源的 LLM 代码交互有趣。”sharpshadow 提供了帖子焦虑的最浓缩版本：“手工编码将被禁止。风险因素太大。你可能是与全能者沟通的萨满。”