关于程序员过时的传说

从无代码到人工智能辅助

每隔几年,就会出现一项崭新的技术,声称将使软件开发人员变得多余。头条新闻遵循着可预见的模式:“编程的终结”、“现在任何人都可以开发应用程序”,或者我个人最喜欢的“为什么你的五岁孩子会在学会阅读之前就开始编程”。

高管们兴奋不已。顾问们如鲨鱼般围拢。幻灯片演示文稿层出不穷。预算随之调整。

然后现实逐渐显现。

实际上发生的变化并非替代,而是转型。那些承诺消除技术专长需求的科技,最终催生了全新的专业领域,且薪资水平往往高于以往。无代码运动并未淘汰开发者,而是催生了无代码专家和后端集成工程师。云计算并未淘汰系统管理员,而是将其转型为薪资翻倍的DevOps工程师。元素周期表

如今,我们正目睹AI辅助开发领域出现相同模式。“AI将编写所有代码”的承诺正演变为现实:我们需要能够有效协调AI系统的工程师,本质上仍是同一类工程师,但如今他们需要掌握新技能并期待更高的薪资水平。

但此次转型背后还有更深层的变化。与以往技术变革主要改变解决方案的实现方式不同,AI辅助开发凸显了软件工程中一直存在但如今无法忽视的根本真理:

软件领域最宝贵的技能并非编写代码,而是架构系统。

而正如我们将看到的,这是人工智能目前无法替代的唯一技能。

永无止境的替代断言来回炒作

我们已经经历过多少次这样的炒作?让我们来数一数:

无代码/低代码革命

还记得拖放界面曾被寄予厚望,声称能让业务用户自行构建应用程序吗?承诺很明确:“既然任何人都能开发应用,为何还要雇佣昂贵的开发人员?”

实际结果:这些工具反而催生了新的问题。仍需有人设计支撑这些炫酷界面的数据模型,与现有系统和数据库集成,处理可视化工具无法解决的边界案例,并在需求演变时进行维护和升级。

结果并非减少开发人员——而是催生了“无代码专家”,他们既理解业务领域,又清楚这些平台的技术限制。猜猜看?他们的薪资甚至高于他们本应取代的开发人员。

云计算革命

“迁移到云端后就无需系统管理员了!”

仿佛基础设施一旦迁移到他人服务器上就能自行管理。云计算并未消除对系统专业知识的需求,而是转变了这种专业知识的形式,并大幅扩展了其应用范围。

系统管理员并未消失,而是以DevOps工程师的身份重生,拥有更炫酷的头衔和大幅提升的薪资待遇。工作并未消失,而是演变为基础设施即代码、自动化部署管道和分布式系统管理。

如我在关于微服务的 LinkedIn 帖子中所提到的:“我目睹团队花费数月将功能完好的系统分解为微服务,却发现只是用一套问题换来了更昂贵的问题集。”云计算催生了这种复杂性,而有人仍需管理它。这个人依然是系统专家,只是在更高的抽象层级上运作。

离岸开发浪潮

“为什么支付本地开发人员的费用,当你可以在海外以更低成本完成相同工作?”

成本大幅节省的承诺很快与沟通挑战、质量问题以及发现有效软件开发需要深入的上下文知识和持续协作的现实相撞。

取而代之的是更微妙的方法:拥有明确所有权边界的分布式团队、更强大的架构实践,以及——令人惊讶的是——比最初预期的更高总成本。

人工智能编码助手革命

如今,人工智能承诺为我们编写代码。“只需描述你的需求,人工智能就会生成代码!”

早期现实已初现端倪。人工智能生成的代码看似合理,但常包含细微的不一致和错误。资深工程师需花费大量时间验证和修正人工智能的输出结果。“氛围编码”现象表明,经验丰富的开发者能从中提取远超新手价值。完全依赖人工智能辅助构建的系统往往缺乏连贯的架构。

“在凿子时代,你给木匠们提供了一台数控机床。猜猜谁能做出更好的家具?”

这一模式再次变得清晰:技术并非取代技能,而是将其提升到更高的抽象层次。

为什么这次不同

那些认为“人工智能将取代开发人员”的人根本误解了这一点:代码并非资产——它是负债。每一行代码都需要维护、调试、保障安全,最终还需替换。真正的资产是代码所赋能的业务能力。

如果人工智能让编写代码变得更快更便宜,其实它只是让创造负债变得更容易。当你能够以史无前例的速度生成负债时,能够战略性地管理和最小化这些负债的能力将变得指数级地更加 valuable。

这一点尤其重要,因为人工智能擅长局部优化,但不擅长整体设计。它可以优化单个功能,但无法确定一个服务是否应该存在,或者它应该如何与更广泛的系统互动。当实现速度大幅提高时,架构错误会在你意识到它们是错误之前就已经固化。

对于代理机构构建一次性营销网站的工作,这无关紧要。但对于需要在数年内演进的系统,这将是灾难性的。

技术转型的模式始终如一——系统管理员转型为DevOps工程师,后端开发者转型为云架构师——但人工智能加速了这一切。能够生存并蓬勃发展的技能并非编写代码。

而是架构系统。而这是人工智能无法做到的。

本文文字及图片出自 The Recurring Cycle of “Developer Replacement“ Hype

你也许感兴趣的:

共有 406 条讨论

  1. > 用于代理机构构建一次性营销网站

    有趣的是,我最近做了一些自由职业工作,修复了一次性氛围编码的着陆页。而有一件事我们可以确定,那就是那些最爱控制的人总会提出一个额外的愚蠢要求,这会让AI彻底困惑,并迫使其制造更大的混乱,然后我不得不来修复它。

    无论人工智能变得多么智能,我们面临的软件问题很少是技术性的。问题总是出在那些制造意外复杂性并将其推给下一个人的人身上,仿佛这些复杂性是“必要的”。

    开发人员最大的资产就是对他人说“不”。也许人工智能会学会这一点,但有了竞争的人工智能,我敢肯定我们总会让其中一个说“是”,就像我们对人类所做的那样。

    1. 对经典“需求缺陷”的精彩重述:软件可以完美实现,但如果需求本身缺乏合理性(包括对技术系统现实的考量),混乱便会随之而来。

      我认为人工智能在“你要求一个GIF,但它们不支持透明度”方面会达到这个水平,但我100%确定人们将继续编写“将标志设计成一个正方形,其中每个点到中心的距离相等”这样的需求。

      编辑:是的,是JPG,不是GIF,是个调皮的拼写错误加上自动更正。

      1. 19世纪中叶的计算经典。

        > 有两次有人问我,——“请问,巴贝奇先生,如果把错误的数字输入机器,是否会得到正确的答案?”一次是上议院的成员,另一次是下议院的成员提出这个问题。我无法理解是什么样的思维混乱会引发这样的问题。

        摘自《哲学家的生活片段》(1864年),第五章“差分机一号”

        1. 他们只是在问他是否作弊。

          你输入2+2,得到4。这就是正确答案。

          如果你输入1+1,这是2+2问题中错误的数字,4还会出来吗?制造一台总是说4的机器很容易。

        2. >我无法正确理解那种会引发如此问题的思想混乱。

          这真是个荒谬而优雅的说法,用来表达无法理解某些问题背后的愚蠢。

          1. 我不知道巴贝奇曾声称差分机(或分析机)具备思考能力。坦率地说,这听起来像是你从想象中的巴贝奇那里编造了一个虚构的论点,试图再次得分。

              1. 我刚查过。找到了一本《哲学家的生活片段》(1864年版),读了第五章“差分机一号”。书中根本没有提到“思考机器”,整体上只是一个人在描述机械计算器构思的过程。

                我完全不知道你在说什么。

                  1. 说句公道话,你大约一周前曾与我互动,但我无法进行有意义的回应,因为担心你那种自以为是且好斗的讨论方式会将对话引向一场你一心想要“赢”的争论。我目睹了另一位评论者上当受骗的经过。

                    因此,看到你在另一个帖子中再次使用这种自以为是的语言,宣称缺乏依据的结论,并在面对反证时拒绝重新考虑自己的立场,或提供自己坚实、直接的证据,同时指责他人自以为是,这既令人发笑又令人担忧。如果你认为自以为是会导致混乱,我认为是时候重新评估你自己的讨论方式了。

                    1. 虽然我赞赏你合理且合乎情理的回应,但我怀疑你是在与大语言模型(LLM)打交道,也许是一种表演艺术项目。

                    2. 你没有错。当我面对某些话题上的特定态度时,我也会变得有点易怒,因为这不是我第一次面对它——而是一系列漫长且令人烦躁的互动,其中这个新的边缘案例,属于同一类型。

                      或许我应该更主动地在脑海中将互动分类,比如“这是政治表态吗?”或者“这是学术表态吗?”(这里,我所指的政治,是指关注信仰的“谁”和“为什么”,而非其内容本身)。对于像我这样的人来说,问题在于这两者往往密切相关,而我们所处的环境中充斥着一种我们并未同意的政治氛围。

                      特别是,计算机科学等领域的 discourse 环境对语言的字面和诚实使用具有病态性。我认为,计算机科学的“政治”——即 discourse 中的人、态度、方法等——本质上是不诚实的。我认为,这一观点在当今社会尤为容易被证实。我曾以为这只是企业炒作,但实际上,这种现象一直延伸到那些偏好使用夸张比喻的幻想型研究者,他们的这种偏好远超其进行诚实沟通的能力。

                      因此,巴贝奇当年为了金钱推销自己的想法,以及他以一种漠不关心的语气被引用,成为了这一问题的象征。他当然不像今天我们所见的那样极端;但他毫不犹豫地利用赞助者的误解来谋取金钱。我讨厌他在这方面被如此轻易地引用。

                      无论如何,在这样一个我认为基本上不诚实的环境中,我并不总是能保持冷静,这是肯定的。未来我会在这一点上更加自我审查。或许我该彻底放弃对这个问题的关心,将这份失望归入虚无主义的垃圾桶:计算机的“科学”是一个精神分裂的镜厅,人们在此玩弄语言的恶意游戏,而目瞪口呆的旁观者却认真地加入其中。创新的实质被埋没,关于它的诚实言论几乎无法辨别——诸如此类。好吧。

                      我本以为物理学家和哲学家会超越这种境地,但弦理论学家在90年代也玩过类似的游戏——而我对那段时期的科普作品也一直感到愤怒。

                    3. 我认为你可以尝试变得稍微友善一些,谦逊一些,少些先入之见,多些开放心态。你正在让自己无法考虑某些主题的新信息,或在没有偏见的情况下重新审视之前遇到过的信息。

                      如果你对讨论某件事感到厌倦,也许放手让别人来处理也无妨。但当你带着负面情绪进入对话时,你会显得有些难以接近。这是一个我们可以互相学习的地方,是一个论坛,而不是战场。积极的态度能打开心扉,消极的态度则会关闭心扉。如果你之前遇到过某人的观点,这并不是任何一个人的错,而且,你有时可能会犯错,就像我们所有人一样。

                    4. 管理员可以禁止这个用户吗

                  2. >我的观点源于与巴贝奇交谈的人的叙述,以及他与政府、媒体等机构的互动。

                    我相信你很快就会分享这些叙述中的一些相关引语

      2. 我认为你正在寻找的例子是“七条垂直的红色线条”:https://www.youtube.com/watch?v=BKorP55Aqvg

        任务已设定;灵魂在哭泣

          1. 谢谢,我之前没见过这个回复!挺有趣的 :)

          1. 我们目前的运营预算连五维空间都难以负担,而且这显然无法扩展,我恐怕不行。大家准备好,我提议我们把它们画在_双曲平面_上。二维空间,放在咖啡桌上刚好,还能容纳我们所需的所有平行线。甚至有些可以是超平行线。此外,我们可以将其部署在AWS非终端用户计算环境中,用于逻辑基础设施部署。

      3. > 一个每个点到中心距离相等的正方形

        根据这些要求,我会在球体表面绘制一个正方形,使正方形的每个点到球体中心的距离相等。

        1. “我们需要一种新型的曲面显示器……”

      4. 这是在开玩笑还是暗示AI不明白透明GIF是100%存在的?

        1. 我认为他们只是把GIF和JPG搞混了。字母在QWERTY键盘上具有相同的排列模式,因此可能被自动更正为另一种格式。

        2. 原始GIF格式不支持透明度。89A版本新增了对完全透明像素的支持。但仍不支持Alpha通道,因此例如部分不透明的阴影效果无法实现。

          这取决于“透明”的具体含义。

      5. > 人们将继续提出“将标志设计成每个点到中心距离相等的正方形”等要求。

        为什么AI不能像人类开发者一样处理这类问题?通过提问跟进,或迭代需求?

        1. 去试试你最喜欢的大语言模型(LLMs)吧。它们太恭敬了,无法持续地推回或建立辩证关系,而且它们很难可靠地坚持要求列表。

          1. 我并不是说它们今天就能做到。我的意思是,不能排除它们很快就能做到。

            1. 这是一种令人震惊的态度,而这种态度在当前行业中却司空见惯:评估AI/ML系统时,不是基于它们当前能做什么,而是基于它们在理论上可能做到什么。

              问题是,只要有足够的幻想,当然它们可以做到任何事情。这让不择手段的销售人员向你推销一些实际上不可能实现的东西。他们让你自行推测,或者直接替你推测,承诺一些不存在且可能永远不会存在的东西。

              马斯克承诺“完全自动驾驶”已有多少年了?最近我们又看到了多少次他的汽车因误判阴影而冲出路面撞上树木,或是驶入类似《猫和老鼠》中 Wiley E. Coyote 风格的假隧道?

              在评估未来可能出现的事物时,例如决定是否投资一家人工智能公司,虽然存在一定价值,但你需要通过基于当前工具实际能力而非遥不可及的假设未来来进行评估,从而抑制人工智能领域的过度炒作。

              其中一个棘手的问题是,这些工具的能力在过去几年里有了显著提高;现代大语言模型(LLMs)的能力比两三年前要强得多。人们很容易想到:”如果这种指数曲线继续下去呢?一切皆有可能。”

              但在大多数实际系统中,你不会看到无限的指数增长,而是更接近于对数曲线。最初是指数增长,但最终会放缓并渐近地趋于最大值。

              我们到底处于对数曲线的哪个位置,很难说。如果我们的能力还能再指数增长几年,那么当然,也许一切皆有可能。但更可能的是,我们已经达到了这个拐点,随着我们接近基于大语言模型(LLM)的人工智能方法的极限,持续的增长会越来越慢。

              1. 随着关注点从与AI的来回互动转向向其下达指令后等待其处理一系列自生成的输入和输出,我感觉我们正处于那个转折点——提示词似乎变得更智能,因为它能做更多事情,但我们只是掩盖了它所做的“更多”其实是在进行一场漫长而隐蔽的对话,这需要大量时间和计算资源。整个“代理式”概念只是让CPU运行更长时间。

              2. 没错。关于AI最关键的未知数是它何时会达到瓶颈。

                    1. 是什么决定性因素让所有技术达到瓶颈,而进化似乎是开放式的?技术不会自我改变,是我们人类在改变它们。

                      那么人工智能的终极目标是什么?

                    2. 什么?进化特别容易陷入局部最优解。当物种状况良好时,如岛上没有天敌的物种,进化压力就很小。推动该物种进化的唯一因素是自然选择,使其活得更久、患病更少、死于意外更少等。这些因素不够具体,且不以时间为压力,因此没有太大动力去超越自然寿命进行改进。此外,对于某些情况而言,延长寿命并非最终目标,而是增加繁殖能力。完全有可能,甚至很可能,当追求寿命最大化时,最终会对繁殖能力产生负面影响,反之亦然,从而达到一种平衡状态。

                      此外,技术的发展与进化并不相同,因此不确定为何要将两者进行比较。

                      技术停滞不前是由多种原因造成的——改进成本过高、缺乏改进兴趣、无法突破科学瓶颈(参与的关键人员离职/去世/失去兴趣,或当前知识水平下难以突破),以及理论极限(如硅芯片领域已接近极限)。我认为这与进化没有太多相似之处。

              3. 完全同意。实际上,许多(年轻)人并不知道当前的大语言模型(LLM)“革命”是过去 20 多年机器学习发展的尾声。那么,还有多少年呢?从某种程度上来说,考虑到运行它们的成本和复杂性,这有点像 20 世纪 40 年代后期制造巨大的电子管计算机和电视机。也许这里会出现一个晶体管时刻,有人意识到我们已经拥有可以组合用于确定性任务的确定性算法,而不是这些“垃圾机器”?我并不介意它们生成垃圾视频和图片,但我担心它们有潜力以完全新的方式彻底破坏软件的质量。

              4. 这种态度与加密货币骗子或其他任何骗子如出一辙。或者,如果不是出于恶意,那通常来自于对该领域完全缺乏经验的人。

            2. 我们也不能排除在冥王星的黑暗面,有一只飞行的意大利面怪物被一只飞行的茶杯环绕在太空中,但我们不会将我们物种的生存建立在我们可能很快在那里发现它的机会上

            3. > 我不是说他们今天就能做到。我是说,我们不能排除他们很快就能做到。

              同样,也不能排除地球明天会被伽马射线暴击中的可能性。你似乎在谈论一些如果做得好,需要AGI的事情。

              你可以用AI做任何事情。任何事情。唯一的限制是你自己。

              1. 无限的可能性存在于AI中。无法实现的未知存在于AI中。

              2. 伽马射线暴的概率是可以量化的(它非常微小)。(而且这是我们完全无能为力的事情,所以不值得担心。)

                没有人能预测一项技术何时会达到瓶颈。人们的预测基于一些荒谬的观点,比如“我祈祷我们的新统治者能让我永生”和“太阳底下无新事,一切都是营销”……

                明年可能迎来下一次人工智能寒冬,人工智能可能在我们有生之年消灭人类,甚至这两种情况都可能发生。这两种情况都是一个巨大光谱中极不可能(定性上)的两端。

                这并不是说我们“一无所知,因此放弃讨论”。否则我也不会参与这场讨论,我也希望你不会参与,如果你不期待有时能学到东西或面对新想法的话。

                我只是觉得两种态度都毫无建设性:“它将使我们永生”以及“我经验丰富,我知道没有新技术能达到预期,因此可以嘲笑那些承认自己不知道的人”。你不知道。大多数技术都达不到预期,少数技术甚至比预期好得多。我敢肯定,在李世石比赛之前,你曾想过“好吧,它会赢得这场比赛,然后在十年后达到顶峰”?

            4. > 我说的是,不能排除他们很快就能做到这一点

              即使是经验丰富的工程师,在这方面也可能出人意料地糟糕。并非所有人都能对老板说“这是一个愚蠢的要求,原因如下。你是不是其实想说……”当他们的薪水受到威胁时。

              随着职业生涯的晋升,这种对话本身就是工作。

              1. 此外,一旦AI也告诉他们他们的想法是愚蠢的/没有意义的,以及如何改进,他们就会停止使用它。ChatGPT永远不会不谦逊,因为谦逊是它对那些非常喜欢它的人的主要“优势”。

                他们只是想要一个“是”机器人。

              2. > 职业越高,对话本身就是工作。

                我认为,你越能找到方式(有生产力地)让对话成为你的工作,你的职业生涯就越成功。

              3. 我想大多数人知道这样说不太妥当。如果他们不知道,那这就是他们需要改进的地方。

            5. 这是魔法般的想法。请停止吧。

            6. 但是,为什么经理或客户要花宝贵的时间来照看大语言模型(LLM),直到它做对为止,而他们可以付钱让工程师来做这件事呢?工程师很可能已经掌握了提示人工智能和检查其结果的专业知识。

              这就是人们从未理解的无编码解决方案的本质。开发事物仍需一个耗时的过程,而你必然会出现掌握该过程的专家,他们能以远超普通人的效率和速度完成任务。

              1. 完全正确!

                这在科技领域之外也适用。即使你可以在家里做土豆泥,但在餐厅由每天做成千上万次的人来做,会更受欢迎。尤其是当你想要特定的改动时

            7. 那会很糟糕,当你打开电脑告诉它做一件事,它却说“不,你很蠢”……我不确定我们是否想要这样

              1. 无论你是否想要,它都会出现,因为只有能够做到这一点的大语言模型(LLM)才能对实际的科学发现有用。希望进行实际科学发现的人会知道其中的区别,因为他们会测试大语言模型的输出结果。

                [编辑] 换句话说,对某些人来说,说谎较少的大语言模型(LLMs)更有价值,因此,无论对用户的自尊心造成多大的伤害,那些告诉你“你很蠢”的大语言模型最终都会在这些圈子里占上风。

                1. 那么它究竟如何学会何时该反驳、何时不该反驳?我认为这类讨论难以推广。随意说“不”并无实际帮助。

          2. 我刚刚用Claude 4和ASCII艺术尝试了这个。

            输出内容很详细,但它尝试后纠正了我

            > 实际上,让我澄清一个重要问题:你描述的“每个点到中心距离相等”实际上是圆的定义,而不是正方形的定义!

            以下是提示

            > 使用ASCII艺术,你能为我制作一个每个点到中心距离相等的正方形图像吗?

            1. 我认为原帖指的是更广泛的“不可能”要求类别,而非将其作为具体示例。

              如果我们只是寻找聪明的解决方案,那么曼哈顿度量中的等距点集就是一个正方形。在客户不可避免地拒绝这种聪明人的做法之前,无需做出任何澄清。

              1. 我只是回应了这样一个观点:大语言模型(LLM)机器人不会拒绝无意义的请求,因为它们太好了。

    2. 在“不”和“当然可以”之间,还存在50种“你确定这是你想要的?”的含义。例如,一位年长的客户让我创建一个网页,让人们可以“下载数据库”。他当然指的是一个非常有限的CSV导出。我好奇ChatGPT是否能理解他的提示,而这对我来说是比较明显的一个例子。

      1. 我认为他实际上对需求有更清晰的理解,比你更清楚。在网页开发术语中(以及许多其他术语领域),“数据库”指的是“Postgres实例”等。

        但本质上它只是指“数据基础”,就像“代码库”不仅仅指Git仓库一样。“下载数据库”只是意味着有一种方式可以下载所有数据,而CSV是一种合理的导出格式。不要误以为它指的是下载Postgres数据文件夹的方式。

      2. 确实。说“不”并不是在拒绝,而是在谈判。

        1. 我的一大 pet peeve 是“谈判”这个词在用户需求中的用法。

          在业务用户看来,谈判意味着开发人员可以做 X,但开发人员很懒惰。通常,需求 X 没有意义,因为开会时业务方决定转向新方向并决定了新的技术解决方案。产品所有者只是传达了新需求,却没有提供背景。如果架构师或高级开发人员参与了会议,他们会告诉业务方,你们刚刚毁掉了六个月的开发工作,现在必须从头开始。

        2. 我称之为“不谈判”——问题在于,缺乏经验的开发人员强调“不”的部分,而客户只听到“不”。

          你需要做的是深入了解他们想要X、Y或Z的原因(这些需求要么成本高昂,要么无法实现,或两者兼而有之)——然后向他们展示一种达到目标或接近目标的方法。

          1. “是的,我可以做到,但我不认为下载整个数据库正是你想要的”

        3. > 说“不”并不是拒绝,而是谈判。

          有时确实如此。我经常不得不说“不”,因为客户的要求确实无法实现。接下来就是解释为什么他们想要的东西根本不存在,因为他们常常会问“那如果这样做呢?”——“不行!那行不通,原因如下……”

          1. 几乎没有什么是不可能的,但很多事情都非常接近。如果需要改变系统的基本设计方面,那就得不偿失。我不会为了让你能像拖放小工具一样移动UI的一部分,而烧毁代码库并引发150万个我们不知道会产生什么影响的副作用。

          2. 啊。

            我最近不得不解释`a * x !== b * x when a !== b`*…听到“但在其他竞争对手那里结果是一样的”这种说法,再加上“也许问题是你不够专业,无法理解”,真是令人抓狂。

            1. 啊,我看到你也做过金融软件开发 ;)

              我们确实遇到过不少“我也不知道该怎么说,那些人算错了”的情况。

              不过,大多数客户对计算结果的可解释差异还是比较宽容的。金融领域有很多“差不多就行”的情况。我们通常只在有人(我认为)在找借口不买我们的软件时才会遇到问题。“这不完全匹配,我们绝对不能用这个”之类的情况。

              1. 金融界抛给我们的那些超级复杂的数学公式确实令人望而生畏。

                在这份工作中,我只用到了加号、星号(乘法),甚至有一次还用到了减号。

                有个传言说我的一位朋友用过除法,但他有博士学位。

          3. “我可以向你解释,但我无法替你理解”

      3. 天啊,这让我想起一个客户(企业级),他被推到了产品经理的位置,并要求我们开发一个“允许用户收藏每页内容”的网站

        1. >> 允许您收藏每个页面

          在当今世界,随着越来越多不向历史记录推送数据或无法根据历史记录正确打开页面的单页应用程序(SPA)的出现,这一需求显得尤为合理

        2. 这实际上是一个非常合理且易于理解的需求。他们希望使用静态端点并大量使用查询参数,以便您可以收藏单个页面的状态。

          这取决于您与他们合作,识别关键功能并确定具体该如何操作。

          1. 谢谢Chip——我们几年前就解决了这个问题。

    3. > 开发者最大的优势就是对他人说“不”。或许AI会学会这一点,但面对竞争的AI,我敢肯定总会有其中一方说“是”,就像我们与人类打交道时一样。

      根据我的经验,这是工作中最困难的部分,但这绝不是许多开发者乐于接受(甚至认为是自己职责)的部分。

      我认为确实存在“既是开发者又是产品经理”的开发者,因为许多项目的成功最终取决于对利益相关者进行深入的个人层面的理解。

      1. 我认为我发展出的最大技能是日本式的“是的,但……”的拒绝方式,即不直接说“不”。本质上,你是在说任何事情都有可能,但可能需要扩大限制(预算、时间、复杂性)。如果公司文化期望工程团队在功能决策中拥有同等话语权,那么直接说“不”是可接受的。但在像我所在的非技术驱动型公司,如果不提供更多背景并让他人参与讨论他们愿意付出的代价,单纯说“不”会让你看起来像是阻碍。

        1. 我们与一家以色列团队合并,我不得不向他们解释,我们的工程师对他们提出的要求给出了“好莱坞式拒绝”。基本上就是“是的,这听起来是个好主意”,但实际上意味着“绝对不行”,除非立即跟进可行的解决方案。以色列工程师对此感到非常有趣,并开始询问,每次得到“是”的回答时,是否真的是一种“好莱坞式拒绝”。

          1. 哈哈,我也曾犯过类似的“好莱坞式拒绝”错误。通常是这样说的:“太棒了,这看起来真的很感兴趣!我会做一些研究。”然后我只看两秒钟,之后就再也不提了。有趣的是,有时这正是对方真正想要的:被倾听并认可他们为提出想法所付出的微小努力。

            1. 是的!

              我看到“请听我说,我有好主意”效应的两种变体:积极和消极:

              1) 这看起来很棒,你有没有考虑过添加<听起来很酷但要么无法实现,要么在现实世界中实际上毫无用处的东西>?

              以及

              2)哦,不!你不担心<在一些奇怪的边缘案例中,在一些现实世界中没有人会使用的不明智的工作流程中破坏一些东西>吗?

              “我会研究一下”是一个很好的回答。天啊,可怜的大语言模型(LLMs),它们必须认真对待这些事情,而且要字面理解……

              1. > “我会研究一下”是一个很好的回答

                但如果你不这么做,这就是谎言。在其他文化中,人们会教导他人接受自己的投诉不重要,而不是教程序员说谎,而那些人会接受,因为在那种文化中否认投诉是正常的。

                我认为强迫文化说谎是不健康的。

                1. 我认为这其中有些道理(尽管我指的是提出新想法的人,而非提出正当投诉的人)。对我来说,意图是尊重——一种在不直接拒绝的情况下认可他人意见的方式。“我会调查一下”这句话往往是更礼貌地表达“如果我认为有必要,我会采取下一步行动”。通常你已经知道足够的信息可以立即说“不”,但将它重新表述为“我会调查一下”,有助于向提问者展示尊重,避免立即否定他们(尤其是在公共场合)。

                  我意识到这种方法的价值高度依赖于一种公共尊重的文化。在日本很常见,在美国的一些文化中也很常见。让错误的人看起来很愚蠢,在这些文化中是职业问题的根源。

      2. 说“不”是工作中最难的部分,而且只有在你工作几年并已经创造了大量价值后才有可能做到。

        其中也有一门艺术,即如何构架回应,弄清楚客户真正想要什么,并提出一个能让他们达到90%目标的方案,而不会让应用程序复杂性膨胀。祝你在AI方面好运。

    4. 有一整本书专门讨论这个话题,名为《人件》。这就是为什么我喜欢说“愿你的所有问题都是技术问题”。

      除了极少数前沿案例外,用代码解决技术问题从未如此困难。

      1. 没错。只要团队足够优秀,几乎100%的技术问题都源于人际关系问题。

        1. 我听过很多次这种说法。但具体含义并不清楚。如果几乎100%的问题都是“人际关系问题”,那么“人际关系解决方案”具体指什么?这或许能帮助澄清。

          1. 请记住我提到的是“拥有足够优秀的团队”。

            “人际问题”主要是由于设计不一致、沟通不畅、愿景不清、微观管理等原因导致的。

            “人际解决方案”应该是,而不是给开发人员扔些残羹剩饭,而是真正拥有一个共同的愿景,让开发人员/设计师/每个人都能提前规划,生产功能时无需担心(导致过度设计)或缺乏关心(导致设计不足)。

            即使没有其他计划,只有“尽快上市”,每个人都应该清楚这一点,并且每个人都应该清楚在100公里/小时的速度下将车转向180度的后果。

            双向反馈很重要,因为如果只有自上而下的沟通,唯一的反馈将是客户投诉和开发人员 burnout。

            1. 我将微观管理概括为“糟糕的管理”。我被赋予了自主权,但实际上我在试图修复内部开发的糟糕软件和硬件,因为它们本可以使用外部的优质组件,而且时间表不允许我们弄清楚如何正确构建这些东西。

              100%由管理层引发的问题。

              1. 另一个问题是,当微观管理阻碍了重要信息的传递时,它就不仅仅是烦人的问题了 :/

              2. 在内部开发东西而不是购买足够接近的现成产品,这绝不仅仅是管理层的失职。

            2. 在你看来,“人员问题”本质上是“领导力/愿景问题”吗?

              1. 问题可能并非出在领导者身上(跨职能团队中此类问题比比皆是),但领导者有责任解决它,所以我猜这算……

          2. 书中提到的《Peopleware》可能是你的最佳资源,它很简短。但兄弟的评论也一针见血。

        2. 技术问题才是导致人员问题的根源。不能完全归咎于其中一方。

          1. 人员问题在第一行代码编写之前就已存在,即使周围没有一名工程师,即使话题与工程完全无关。

    5. 这实际上是一个非常好的观点。虽然确实不难想象人工智能在评估潜在解决方案的复杂性并向用户发出警告方面要远胜于人类。

      例如,在国际象棋领域,人工智能已经远远优于人类。包括评估位置等任务。

      诚然,尽管本文主要关注的是大语言模型(LLMs),但我这里使用的是广义上的“人工智能”。

    6. 代理公司的工作似乎是初创企业界个人的盲点,许多人并未意识到其范围远超主题定制服务。全球最大的公司不仅经常与代理公司合作,外部承包商也完成了一些最佳作品。例如,Huge为谷歌产品赢得了3项Webby奖。

      1. 哦,我同意。我对代理机构本身没有意见,这个话题与我的回复无关。我的重点更多在于“一次性”这个概念。

    7. 我同意,人工智能与人类的显著差异在于知道何时说“不”,以及/或深入挖掘未言明的需求/价值。

    8. > 最大的控制狂

      “控制狂”这个词不必要。对于任何已知的特征要求序列/集合,都可以选择一个最优的抽象。

      也可以以一种方式排列要求,使得引入下一个要求会完全使之前为已引入要求选择的抽象失效。

      大多数人类在这种情况下难以恢复。那些成功的人被称为高级软件工程师。

    9. > …总会有那个额外的愚蠢要求,完全让AI困惑,并迫使其制造更大的混乱,然后我不得不来修复它。

      终于,2020年代的Microsoft FrontPage

    10. > 意外复杂性

      我们还没找到更好的术语来形容它吗?

      这是有意为之的、经过设计的复杂性…

      这绝非偶然:工程师或管理层选择了它。

      关于偶然复杂性与本质复杂性的近期讨论(由一篇被标记的文章引发):https://news.ycombinator.com/item?id=44090302(选择合适的二分法很困难,因为两个类别中都存在例外)

      1. 你可以称之为非本质复杂性。

        我并不在意这个名称,但我关心那些骗子假装它不存在。

    11. 精彩引语:> 我们面临的软件问题很少是技术性的。问题总是出在那些制造出意外复杂性的人身上,他们将这些复杂性推给下一个人,仿佛它们是“必不可少的”。

      直到达到绝对庞大的规模,现代工具、代码和系统在技术上都能合理地处理大多数事情,因此通常归结为将复杂性最小化作为优化开发的首要任务。这可能包括

      – 代码设计复杂性 – 设计复杂性 – 产品复杂性 – 沟通复杂性 – 组织复杂性

      有时,减少这些复杂性是相互排斥的(大多数时候不是,而在理想世界中永远不会……但人类……),这就是为什么我们的大部分工作是共同抵制并权衡复杂性,以减少它。需要理解的是,某些复杂性深深植根于个人/公司/代码/任何流程中,短期内你只能学会绕过或与之共存以继续前进,但希望长期能通过战略决策逐步消除它

    12. 顺便问一下,现在哪里可以找到自由职业工作?除了口口相传。

      1. 冒着给出一个非答案的风险:

        根据我个人的经验,如果你是个体或小型公司,想要寻找合同/自由职业工作,建立关系是没有替代品的。

        起初进展缓慢,但当你做得好并维持关系时,最终你会被工作淹没。

        1. 楼主在此。这就是我打算给的答案……我做的绝大多数自由职业工作都是通过个人关系获得的。

          通常是与过去雇佣过我的公司,或前同事所在公司的个人关系。

          唯一一次为其他人做自由职业工作,是我的邻居(一位平面设计师)给我介绍了一些工作。

    13. 除了说“不”之外,另一个优势是:”我明白事情的发展方向和业务的走向,所以我最好以X种方式让它灵活/可扩展,这样接下来的部分会更容易。”

      1. 这假设你所预见的方向是准确的,而我认为这在很大程度上取决于沟通能力。

    14. 专家不仅要擅长某件事,还不能在这方面表现糟糕。拒绝做自己不擅长的事是其中一部分。但这并不重要。

      我们可以争论AI能做这做那,或不能做这做那。但更好的替代方案是什么?往往不存在。我们在云计算等领域已反复经历过这一点。自建服务器更精简,但需采购服务器、数据中心和运营资源。这很困难。而云计算已变得简单。

      在另一个故事中,许多人认为 HN 很简单 [0]。然后有人指出,它可能已经过时了 [1]。这并不奇怪,因为 HN 的简单性并没有比大语言模型 (LLM) 提供更多功能。大语言模型 (LLM) 有做不到的事情,但 HN 并没有做太多这样的事情。

      要让人们变得更好,我们实际上需要的是人。这些人需要住房、教育和医疗保健。还需要能够提供性能、可靠性和安全性的良好技术。但HN充斥着各种借口,声称这些东西并不必要,而这正是AI可以模仿的。而且它不需要做得很好就能做到这一点。

      [0] https://news.ycombinator.com/item?id=44099357 [1] https://news.ycombinator.com/item?id=44101473

      1. > HN充斥着各种借口,声称这些东西并不必要,而这正是AI可以替代的部分

        这不仅仅是HN上的现象;人们普遍相信,最终人工智能将使觉醒的个体获得无限杠杆,而无需依赖烦人的他人。他们只需信任人工智能,并拥抱指数级增长。

        呼吁艺术民主化的声音也属于此类。培养艺术品味的一部分是通过长期积累技能、不断精进、持续超越自我的过程。换句话说:这就是创作本身。如果你认为只有输出结果重要,那么你就错过了赋予你艺术声音的旅程。

        如果人们觉得自己对生活有足够的掌控力,他们就无需向机器神明祈祷。

        这确实是个更难的问题。但我看不到人工智能能解决它。

    15. 仅仅说“不”对任何人都没有帮助。

      更好的做法是说:“我们可以做到,但这需要X周时间,并且会产生多少费用/性能开销。”

      这将引发一场让双方都受益的对话。甚至可能让你明白,为什么以及如何让这个请求最终变得合理。

      1. 几年前,我接手了一个陷入困境的项目,这是一个在医院环境中使用的医用防护服分配/回收系统,该项目因重大改版陷入开发困境已超过两年。在对项目现状进行审计后,我决定放弃原有所有内容。随后,我们从零开始,面对超过200个已知问题和45个待开发功能。

        产品方要求在6个月内完成,我反驳称无论增加多少开发人员,这个时间表都极不可能实现。随后我们开始每周举行范围缩减会议。一个月后,我们达成共识,认为一个5人团队可以完成任务……最终仅将bug数量略微减少,因为稳定性是核心需求,但功能被缩减至仅5个。

        我从未直接反对某项建议,而是通过提供高层次估算来沟通。若某项功能被认为足够重要,我会花数小时至数天进行初步设计,以更精准地评估工作量。所有细节均围绕难度、范围和风险展开,旨在建立估算准确性的信任,并让产品团队自行选择最优先解决的问题。

      2. 我完全同意。如果有无限的时间和资金,我可以做任何你想要的事情——除了化圆为方。

        解释困难的责任在你,理想情况下,对方会意识到自己的请求是不合理的,一旦你提供了不合理的时间表来匹配。

        实际上,直接说“不”总是更困难,因为如果你不是真正的决策者,那么你所做的事情很可能毫无意义。你最终还是得解释自己(最好用一个不合理的时间表来解释),否则就会被排除在流程之外。

        通常情况下,请求者试图设身处地为你着想,以更好地解释他的目标,结果想出了一个过于复杂的解决方案——并描述了这个解决方案而不是原来的目标。你面对荒谬请求的目标是揭开这层面纱,找到原来的问题,然后倒推回去,构建一个合理的解决方案。

      3. 我认为你没有理解我的意思。

        这不仅仅是时间或预算的问题。有些事情在没有适当数据的情况下根本无法实现。

        我之前提到过这一点:我最近遇到一个情况,一位项目经理希望对一个纯数学函数的两次调用得到相同结果,尽管输入不同。

        我可以耐心地多次解释这一点,提供替代方案,并尝试探索实际的问题空间,但到了某个阶段,项目经理说“也许我应该问另一位工程师”这句话变得令人厌烦,让你想辞职。

        与那些不仅无法胜任工作,还拒绝听取他人意见的人合作,在这一行业中已经变得太过司空见惯。

        1. 我会告诉项目经理“当然,我们一起去和他谈谈”。另一位工程师很可能同意。或者他可能看到我没有注意到的地方。无论如何,我们都在取得进展。

          > 与那些不仅无法胜任工作,还拒绝听取他人意见的人合作,在这一行业已变得司空见惯。

          在某些领域确实如此。但确实存在人员素质更高的公司。当然,要在那里获得录用,你需要证明自己更多。

          1. > 当然,要在那里获得录用,你需要证明自己更多。

            你此处的言论极具侮辱性且毫无必要。这句话本身更多地反映了你而非我。

            我的故事的重点是,对对话者进行人身攻击并不是开发软件或赢得讨论的方式。让我们至少在这里对彼此更加尊重。

            1. 这是一个误解。我所说的“你”是指“泛指的你”(任何求职者),而不是“特定的你”(你)。

              我希望“需要良好技能才能获得好工作”这一事实并不存在争议。

              我这是在传递希望:确实存在好工作,所以不要放弃这个行业!

              1. 理解了。我并不反对。

                然而:即使加入拥有出色工程部门、高薪资甚至优秀管理层的公司,也无法保证软件开发流程处于同一水平。我这是基于在一家FAANG公司、两家YC初创公司和两家市值数十亿美元的独角兽公司的经验。

                该行业对开发者和用户存在根本性的轻视,一方面体现在RTO/裁员/AI替代,另一方面则表现为黑暗模式、cookie横幅、自动播放视频、行为实验以及对数据的肆意滥用和整体效率低下。

                我仍然坚持认为,对那些损害世界和妥协工作的行为说“不”,是任何自称工程师的人的职责。

  2. 我认为这篇文章关于“为什么它是正确的”的论点大多是错误的。

    > 这是关于系统架构设计。而这正是人工智能无法做到的事情。

    为什么人们坚持这种观点?人工智能绝对能够做到这一点,因为它已经能够做到这一点,而我们现在正在围绕“系统架构设计”的含义进行定义。

    它在理论上也无法为你决定你想做什么,以及你应该做什么。(它当然可以提供想法,但上下文空间如此之大,我看不出来它如何能比你更现实地看到你世界中存在的问题,包括你能做什么、你认识谁以及你感兴趣什么。)

    在可预见的未来,我们仍需要那些渴望实现目标的人。成为开发者将意味着不同的含义,但这并不意味着你不是最适合处理这项任务并应对其中复杂性的人。

    1. > 成为开发者将意味着不同的含义

      其实不然。编程的本质是向机器解释该如何行动。实现方式随时间演变,从编写机器语言和打孔卡片,到整合框架和绘制界面。但核心始终不变:将来自那些并不真正清楚自己需求的人的模糊要求,转化为机器可可靠执行的精确指令,且无需人工干预。

      多年来,程序员们发现,实现这一目标的最佳方式是使用代码。图形用户界面通常不够表达力,而英语则过于模糊和/或过于冗长,这就是为什么我们有编程语言。在电子计算机出现之前,某些领域就已经有了专门的语言,比如数学,原因也是一样的。

      大语言模型(LLMs)只是编程发展过程中的一个阶段,但程序员的作用仍然不变:通过提示、绘图或编写代码,让机器按照人的意愿行事,我猜代码仍然会占主导地位。大语言模型(LLMs)非常擅长重复以前做过的事情,但让它们使用自然语言描述来编写原创内容却是一件非常令人沮丧的事情,如果你在编程,那么很可能至少会有一些原创内容,否则,为什么不使用现成的产品呢?

      我们现在正处于炒作周期的顶峰,但情况会逐渐平静下来。一些事情肯定会发生改变,就像新科技出现时一样。

      1. 我喜欢和别人开玩笑说,我们程序员几十年前就已经实现了工作的自动化,我们只需告诉我们的编译器我们想要什么,它们就会神奇地为我们生成所有的代码!

        我认为大语言模型(LLMs)并没有什么不同,我们的工作变得更轻松只是意味着我们现在可以做更多的事情,而能力越强,需求也就越大。当然,这并不是一蹴而就的。

        1. 不同之处在于,编译器做的是确定性、重复性工作,几乎每次都正确。人工智能则处理困难的部分——模糊性,并且有时能做到大致正确。

          1. 困难的部分从来都不是模糊的部分。你只需要与利益相关者沟通以解决问题。这就是需求阶段,它只需要良好的沟通技巧。

            困难的部分是建立一个能够在不增加太多成本的情况下进化的系统。系统越大,做到这一点就越困难。我们有模块化、内聚性、信息隐藏等原则来帮助我们,但没有明确的指导方针来实现它。这就是设计阶段。

            一旦完成了上述两点,编码通常相当简单。如果有一个良好的编程生态系统和了解它的人,可以很快完成。

          2. 关于编译器,我有个坏消息。

            1. 没错,他说的对——编译器基本上每次都做同样的事情。编译器中出现 bug 的情况非常罕见,即使汇编代码不同,只要功能相同就无所谓。

        2. 我完全同意这个帖子,因为这是关于为什么没有代码(以及云/SaaS在一定程度上)未能实现其乌托邦式承诺的讨论。

          主要是因为上游存在阻碍,限制了吞吐量。

          通常是业务需求不明确(因为有人没有充分考虑问题)或大规模运营问题(架构通用性差)。

          > 我们的工作变得更容易,只是意味着现在我们可以做更多事情,而更多能力带来更多需求

          这是计算/数字化革命中被反复遗忘的教训!

          它们改变世界的原因并非因为它们比手动前辈更强大,而是因为它们在经济上更便宜。

          因此,它们使一类此前因经济性不足而无法解决的问题得以被研究。

          例如,世界上没有哪家公司对获取更多实时财务运营细节不感兴趣……但这并不值得花钱雇人持续整理这些数据。

          >> 无代码运动并未淘汰开发人员;它催生了无代码专家和后端集成专家。云计算并未淘汰系统管理员;它将他们转型为薪资翻倍的DevOps工程师。

          同样,这篇文章围绕这一问题展开,但遗漏了两个重要结论:

          1) 革命性技术降低了交付现有价值的总成本。

          2) 薪资~=价值,只要需求支撑,职位数量即可保持。

          转型后,后端集成商、DevOps工程师等职位的数量是增加还是减少,目前尚无法预知。

          在最近的历史中,那些提升生产力的人获得了更高的薪资,而其他人则失去了职位。例如,支持数百万用户的云工程师,而不是过去需要更多人手来更低效地交付服务的人。

          目前尚不清楚人工智能编程是否会刺激更多需求,还是仅仅增加相同或更少职位的价值。

          附言:若我今日规划职业路径,绝不会选择缺乏客户互动成分的岗位。无论未来如何发展,业务解决方案制定能力都将成为关键差异化因素。无论技术多么精湛,被“锁在柜子里的”程序员将越来越少地成为岗位的必要组成部分。

      2. 我同意,我认为AI只是一个抽象层。编写一个函数来完成X、Y、Z?效果很好。甚至设计一个有向无环图(DAG)也相当不错。但要将一切无缝集成?那就得请开发人员出马了。

        值得庆幸的是,开发工作中最不被教学和面试重视的环节(如何结构化大型代码库)将成为新的前沿领域和差异化因素。但正如脚本语言消除了对指针和内存管理的关注,人工智能将抽象出离散的代码块。

        这有点像开源软件的梦想,但更先进——不要重新实现标准函数。也不要费心去搜索它们或想办法集成它们。只需请求你需要的功能并继续前进。

        1. > 我同意,我认为人工智能只是一个抽象层。创建一个执行X、Y、Z的函数?效果很好。甚至设计一个有向无环图(DAG)?也不错。要将一切顺畅集成?那就叫开发人员来吧。

          “你的工作现在是将所有这些人工智能生成的代码片段顺畅地整合在一起”这个想法会让我彻夜难眠,甚至可能因压力而缩短寿命。

          我不是在开玩笑。你描述的情况听起来就像一场噩梦。将库文件整合在一起是一项如此枯燥、令人沮丧的任务。让AI解决所有有趣的挑战性部分,然后亲自完成将所有内容整合在一起的繁重工作?

          我希望自己能更接近退休。或者死亡

      3. 这些都是非常好的观点。

        我发现大语言模型(LLMs)对编码很有用,因为它可以为我做很多繁重的工作,然后我介入并做一些收尾工作。

        它在审查我的代码、提出改进建议、编写单元测试等方面也相当不错。

        但这一切背后隐藏着一个问题,即我必须详细描述所有这些事情,才能让大语言模型(LLMs)做好工作。当然我可以直接说“为我编写单元测试”,但如果我详细描述测试用例,甚至说明希望如何进行测试,它会做得更好。

      4. 这个想法的问题在于,当前系统已从完全无法承担开发者角色,发展到一定程度上能承担开发者角色(即新型代理)。

        以这种速度发展,开发者层变得过时或缩减为一名架构师指挥多个代理的情况并不难想象。

        事实上,这种情况可能已经部分实现。我不再亲自编写代码,而是指导Claude代码进行修改。这种工作流程比旧方法快得多。

      5. 我对这一问题的思考方式是:代码之于开发者,如同砖块之于建筑师。编写一行代码仅仅是工作中的最后10%,其前还有大量认知努力。正如建筑师在铺设砖块前已完成蓝图设计、划定直线、搅拌水泥等准备工作。

      6. +100.

        我觉得很多人需要重新阅读《月球是严酷的主人》。

    2. 这篇文章大多是错误的,公司已经不再像以前那样大量招聘应届毕业生。如果人工智能已经能够完成除架构设计以外的所有工作(尽管这是一个错误的论点,但我们姑且接受),那么自然公司需要更少的工程师来设计和监督人工智能系统。

      1. 我怀疑任何招聘减少更多是受市场情绪影响,而非工作岗位被人工智能取代。许多公司在“抢占先机”的阶段选择削减成本而非加速扩张。

        1. 人们总是忘记,招聘削减早在人工智能被炒热之前就已经开始。人工智能只是当前的借口,因为它有助于提升股价。

          我们已经看到裁员超过3年……

          1. 我曾供职的一家公司获得了5亿欧元融资,孙正义的指令是“尽可能多地招聘开发人员”。

            那是在疫情和人工智能兴起之前。

            裁员的发生是可预见的,我们只是没想到会来得如此之快。

            1. > 我们只是没想到会这么快

              裁员恰恰始于美国政府决定停止向投资基金提供免费资金之时。在宣布这一决定的前几天。

              在此之前,人们已经清楚这将发生。但我同意,几年前没有人能预测到它何时会停止。

            2. 我认为人们没有预料到这会持续超过3年。人们准备应对12到18个月的波动,而不是让这种趋势成为新常态。

              1. 说得对,我同意。

                我好奇这是AI、市场、两者还是其他原因造成的…… :/

                1. 是市场,哈哈。

                  你觉得高管们会说:“是的,我们裁员是因为收入糟糕且成本过高!”他们会告诉员工:”是的,我们确实有AI。AI是我们的竞争优势,这就是我们不得不裁员的原因。我们有AI,而竞争对手没有。这就是我们更好的原因。(天啊,希望这管用。请让股价回升,爸爸需要一艘新游艇。)”

              2. 硅谷的大型科技公司现在大多是行尸走肉。糟糕的招聘市场将持续到它们主导软件市场为止。

            1. > 此外,大多数计算机科学项目培养的毕业生无法胜任FAANG级别的工作

              你是说FAANG式的面试折磨。我曾与许多前FAANG顶尖学校的毕业生共事,他们其实没什么特别的。

              1. 他的言论听起来就像典型的印度优越感,认为印度人是优越的种族。这种言论出现在HN上真是令人疲惫。你无法说服他任何事情。

        2. 以及纠正招聘泡沫。

          这取决于具体情况。昨天刚和一位在军方子公司工作的朋友聊过(所以不只是软件领域),他们说项目基本上被招聘工程师的瓶颈所阻碍。

      2. 他们不再招聘初级员工,现在我的工作内容比以前多了10倍的琐事。人们正在扩张以填补这些空缺;我没有看到太多证据表明AI正在“取代”这些员工,就像企业认为现在不需要招聘初级开发人员一样。不过,五年后资深工程师的数量将大幅减少,如果人工智能无法填补这一缺口,企业将感受到的冲击远大于他们现在认为通过不招聘所获得的利益。

        1. >> 不过,五年后资深工程师的数量将大幅减少。

          这种情况已经发生。过去4到5年间,我认识的30多位资深开发者要么转行到开发领域之外,要么在许多情况下完全离开开发领域。大多数人离开是因为他们陷入了你所描述的困境。他们不得不承担更多管理职责,而人工智能甚至无法完成初级开发工作,因此许多人选择放弃并离开。

          是的,人工智能在许多方面都在帮助缩短开发时间,但将特定知识转移到这些工具上正在阻碍实际技能的发展。

          未来十年,随着行业不得不应对同时发生的大量问题,我们将面临一段真正的动荡时期。

      3. 不过,软件工厂假说认为,大语言模型(LLMs)将降低生产软件所需的技能水平,降低生产相同软件所需的技能门槛(即自动化使软件工程师的工作像在工厂流水线上工作一样)。在这种情况下,人们会更希望使用低技能的廉价劳动力,因此更喜欢初级员工。

        不过,我猜测招聘不足只是市场饱和的结果。仅从计算机科学学位授予量的增长来看,我们最终会陷入这种局面。

        1. 这种平衡并不会完全按照预期的方式实现。公司仍然会聘用最优秀的软件工程师(为什么不呢?),但被廉价的新人取代的威胁意味着他们没有太多谈判筹码,工资也会随之下降。最终,还是那些经验丰富的老手和竞争激烈的招聘流程在寻找拥有丰富经验的人才。

          不过这些变化不会一蹴而就,当前正在发生的冲击可能还需要几年时间才能真正显现。

      4. 随着蒸汽船进入市场,帆船的数量和复杂程度显著增加。只有当蒸汽船在几乎所有对市场重要的方面都明显优于帆船时,帆船才真正被淘汰,成为一种奇观。

        我认为,在大语言模型(LLM) 仍在改进,以期成为比大多数程序员更优秀的程序员的过程中,对开发人员的需求也会出现类似的剧烈波动。然后,程序员们就会去从事其他工作。

        随着构建成本的下降,能够就构建什么做出重要决策的能力应该会成为需求增加的一项技能。不过,做出重要的技术决策并理解其后果一直是开发人员的工作内容之一。因此,我们应该擅长这一点。

        1. 蒸汽机相较于风帆的优势显而易见。剩下的问题仅在于工程实现,即逐一解决每个小问题并提升引擎效率。自ChatGPT问世以来,幻觉问题已被指出。而至今我们甚至尚未找到任何解决线索。

          1. > 蒸汽机相较于风帆的优势显而易见

            事实绝非如此!正因如此,才有了长达60余年的风帆+蒸汽船时代。而货运领域更是持续更久![0]

            家长为AI采用选择了绝佳的比喻:在某些领域更优,在其他领域逊色,且随着技术进步,这种平衡将不断变化。

            [0] https://en.m.wikipedia.org/wiki/SS_Great_Western https://en.m.wikipedia.org/wiki/SS_Sirius_(1837) https://www.reddit.com/r/AskHistorians/comments/4ap0dn/when_

            1. > 在某些领域更优,在其他领域逊色,且这种平衡会随着技术进步而变化。

              那么,人工智能在哪些领域比传统编程更优?如果你的答案是建议,那么通过传统工具进行优化,它只是像上下文帮助、谷歌搜索和GitHub代码搜索这样的工作流程插件。而我更倾向于传统工具,因为它们更可靠。

              软件开发生命周期有六个主要阶段:1)规划、2)分析、3)设计、4)实施、5)测试、6)维护。我无法理解大语言模型(LLM)的辅助作用在客观上如何比完全不使用它更好。我读过的所有内容大多是轶事,其根本原因是缺乏经验和知识。

                1. 然后掷骰子,根据某些规则来决定每个令牌……也就是大语言模型(LLMs)。

                  1. 这是掩盖了重点。就像人们可以称微处理器为随机跳跃的电子一样。

      5. 人们显然无法决定人工智能是在杀戮初级员工,还是降低了外行人的成就标准。

        1. 虽然只是轶事,但:

          一家名字中含有“人工智能”的金融科技独角兽公司,仍然禁止使用大语言模型(LLMs)进行编码(我以前的工作)——自 2023 年以来,该公司不再招聘初级员工。

          2024年获得YC投资的初创公司(我目前的工作)在人工智能领域投入巨大 –> 员工中有一半是初级员工。

        2. 确实存在这种更广泛的论点,甚至可以在学术论文中找到。人工智能最擅长的是补充专业知识,还是仅仅取代基础技能?可能两者兼而有之,但这是一个开放的问题。

        1. 这并不能解释为什么这么多软件专业人士发现自己失业,并且难以找到新工作。

            1. 请提供证据支持你暗示的观点:美国以外的计算机科学项目培养的毕业生比美国(不包括你提到的“前七名”)的计算机科学项目培养的毕业生更优秀。

    3. 也许我误解了你的表述,但我认为,只要有足够的上下文,人工智能就能以相当高的准确度判断你想做什么。

      事实上,我认为这就是人们敲响警钟的可怕之处。通过足够的监控,组织能够在现实世界中可靠地识别您,从而构建大量上下文信息,即使您没有佩戴人工智能眼镜。

      有了这些上下文信息,人工智能猜出您想要做什么将变得合理。或许甚至能猜出一系列事件、行动或活动,这些将引导您走向该组织认为理想的最终状态。

      这主要是针对那个特定的论点,可能与您整体的论点有些偏离。

      1. 看看你的生活和你用来运作的信号。如果你和我一样,以一种相对合理的方式总结它们,基本上感觉是不可能的。

        例如,我母亲打电话问我是否想过来。

        人工智能如何才能拥有足够的上下文来替我做出这个决定?如果从出生或出生后不久就开始配备足够数量和质量的传感器——当然,从理论上讲这并非不可能。

        但作为一个成年人,我了解我们分享和不分享的事物,我们现在和过去的冲突,我从未与任何人谈论过的事情,以及如果我想表达出来或承认自己不愿承认的事情。

        它可以查看我的日历。但它无法理解我已经考虑做某事有一段时间了,而我刚好听到有人随口提到其他事情,这让那个想法重新浮现,现在我真的更想做那件事。人工智能如何知道?(同样,从理论上讲,如果拥有合适的传感器,这并非不可能,但似乎还很遥远。)

        当然,我可以尝试解释。但从哪里开始呢?我该如何向妈妈解释呢?这真的非常复杂。我并不是说大语言模型(LLM)在这里没有帮助,实际上,考虑到它们对我们的了解非常有限,它们能提供如此大的帮助,这既令人难以置信,又令人清醒。

        1. 没错,即使是AGI也无法替我回答这个问题。

          这意味着它无法自行设计软件解决方案,除非它能读取人们的思维并知道他们可能想要什么。

      2. > 但我认为只要有足够的上下文[…]

        我认为这是关键。唯一能提供足够准确上下文的是软件开发人员。产品负责人(PO)或经理无法处理如此细节(或抽象)的程度,通过提示将它们传递给聊天机器人;工程师每天都在做这件事。

        我笑话我的产品负责人或我的经理的经理这样的非技术人员向大语言模型(LLM)下达“命令”,要求它设计一个可处理支付的高可扩展小型组件。如果提供的细节不够充分,可能会出现许多问题:从安全性、版本控制、弹性、部署到可维护性……

        1. 直到大语言模型(LLMs)直接与业务和市场数据挂钩,并在没有或只有很少的人为干预的情况下做出决策。

          1. 我认为这是完全的幻想。这种数据通常非常混乱。大语言模型(LLMs)在区分信息是有用还是有害方面非常糟糕。

            此外,上下文窗口无限扩展到能容纳所有数据的可能性极低,即便能实现,模型能否真正利用所有信息又是另一个问题。

            要实现这一设想,需要克服无数已知和未知的挑战。目前,即使是拥有相对较小上下文的简单代理要做到可靠且表现良好都已十分困难,更不用说你所提议的这种复杂程度了。

          2. 这不是大语言模型(LLMs)的目标。首席执行官和高级管理人员需要下属来处理模糊或非明确的命令,并从构思到发布对他们的行动负责。当然,大语言模型可以被配置为处理模糊的指令,甚至说“好的,老板,我对我的行动负责”,但真正的老板不会对此感到满意。

            想想看:如果 10 年后,我创办了一家公司,我的唯一员工是一个能够执行我给出的任何命令的高能大语言模型(LLM),如果出了问题,谁应该承担责任?是 LLM 还是我?肯定是我,所以我最好给该死的 LLM 下达明确且无歧义的命令……但嘿,我只是自己公司的 CEO,我不知道该怎么做(否则,我就会成为工程师了)。

          3. 好吧,我期待着看到首席执行官向大语言模型(LLM)解释其商业计划的第一次会议。

            1. 我肯定有兴趣至少尝试一下为一个由大语言模型(LLM)担任首席执行官的公司工作……也许,从现在起三年后。

              我不知道我是否真的相信它会在每个领域都比人类做得更好。但它肯定不会在竞争对手的董事会中有表亲,不会向高尔夫球友透露我们的计划,不会根据握手力度来提拔员工,也不会因为调戏员工而被解雇。

              1. 但只要有人说“不,这没道理”,它就会改变商业计划,然后半个小时后就会忘记两个计划的内容。

                作为首席执行官,即使观点和信念是错误的,也要坚持自己的观点和信念。这是大语言模型(LLMs)无法做到的。

                1. 一个次要的旁枝末节:我认为更准确的说法是,做人为的是拥有观点和信念。但或许,担任CEO这份工作确实需要将某些类型的观点和信念转化为行动。

                  更确切地说,我印象中,目前超顺从的大语言模型(LLMs)只是微调过程的结果。当然,大语言模型(LLMs)没有内在的心理状态,所以我们不能说它有意见。但它可以被微调,以表现得像它有意见一样,对吗?

                  1. 这就是我的观点——作为首席执行官,你必须拥有愿意为整个公司赌上一切的信念。

                    谁在对大语言模型(LLM)进行微调?如果你让某人转动拨盘,设置核心概念和政策,使其在上下文窗口之外持续存在,在我看来,他们才是真正的领导者。

                    1. 通常,销售这些大语言模型(LLMs)作为服务的公司会进行微调和设计内置的提示部分。如果我们要说这些公司的员工才是真正做<事情>的人,我认为这是可以理解的。但我认为这是一个不寻常的解释,通常我们认为做<事情>的是使用大语言模型的人。

                      我正在猜测一家由大语言模型(LLM)运营的公司(目前尚不存在),因此,该公司所有员工一起使用它似乎是合理的(为什么不可以呢?)。

                    2. 一个吸收大家想法并半民主地做出决定的大语言模型(LLM)?再加上利润分享,你可能就成功了。

                    3. 是的,或者甚至是一个由 LLM 协调的合作社、行会和/或特许经营权的集合体。实际上以半民主的方式运行这个东西的机制肯定需要仔细设计!

      3. 我认为社交媒体广告已经实现了这一点。针对特定人群开发行为模式以实现转化,并构建向用户推送引导其沿此路径前进的信息模型并不困难。转化并不意味着必须购买产品,也可能是接受某种理念、投票支持某位候选人等。正如你指出的,令人担忧的是,鉴于当前被动收集的关于万物与万人的海量数据,这种情况在现实世界中确实可能发生。

      4. 我希望全人类¹都能实现和平与繁荣,从能够实现互利共赢并避免因偏袒他人而排斥任何人的起点开始。

        你看,“AI”甚至不需要猜测,我对此完全公开透明。如果任何工具(包括自动化推理(AI)设备)能帮助实现这一目标,那么这类工具本身并不存在重大问题。

        巨兽以损害人类利益的方式垄断该工具,这是另一个独立的问题。

        ¹ 这是一句略带人类中心主义的表述,但这是促进人类共识的好方法,我认为这实际上仍隐含着与地球上其他生物和谐共处的必要性。

    4. 不,AI目前还无法进行架构设计。这里的混淆在于无法区分架构与规划。

      规划是指将需求映射到解决方案,并根据可用资源预测解决方案的交付能力。我并不认为AI目前已接近掌握这一能力。即使人类资源被视为商品,这也不是一件简单的事。

      执行计划被称为任务执行。

      架构是相互关联系统设计与艺术的结合。这涉及多层相互竞争和/或协作的计划。人工智能绝对无法做到这一点。某一层的严重错误可能破坏或取代其他层,而这将造成灾难性后果。这就是为什么这项工作由真人完成,并且他们会不断接受审核。

      1. 它无法主动成为编码代理并进行更改,但它现在也不会为单个脚本这样做,然而我们却说它能编码。

        然而,我可以问它如何以逻辑方式架构我的数据库,它显然有扎实的思路,但它不会自己编写脚本。

        因此,它实际上是在教导或指导我们一种做事方式,它并未在任何领域执行……至少目前如此

        1. 我的所有评论都与编写代码无关。物理工程中的建筑师不会亲自钉钉子或浇筑混凝土。软件领域的建筑师同样不会关注代码的孤岛。

    5. 自人工智能(AI)问世以来,随着人们纷纷将AI生成的脚本应用于各类基础设施,我的工作量显著增加。而这些工作并非那种可以将任务交给AI就能获得解决方案的类型,而是常规的开发工作。其中部分问题是我们自身造成的,因为我们向用户提供了大量AI代理。

      我曾尝试将基础设施相关信息进行形式化并嵌入其中,以便AI生成的代码能适应这些信息,但面临严重挑战。我希望拥有一位AI秘书,但请务必确保其本质上是真人。

      AI在基于小范围上下文窗口逐行生成代码时表现更佳。若上下文范围过大或过于复杂,生成的代码必然无法运行或正常工作。这与AI最初运作的统计确定性机制如出一辙。

      如果AI能创建项目,它必须完全自包含。虽然有用,但也有局限性。

      AI嵌入是另一个令人头疼的问题,就连大型科技公司在这方面也屡屡受挫。准备嵌入数据的工作量巨大。这是人类的工作,因为AI目前还不适合做这件事。也许未来能做到,但认为开发者终于可以休息了,那未免太天真。还会有其他麻烦事要处理。

    6. 人工智能无法进行架构设计。人工智能可以模拟架构设计。很多时候,人工智能甚至无法编写代码。

    7. >为什么人们坚持这样做?

      因为这甚至远未达到入门级架构的水平。而且大语言模型(LLM)的结构使其难以按照架构的要求进行迭代。它基本上只是获得一点背景信息,然后以惊人的速度进行拆解和重建。你无法以这种方式进行架构设计。

      >即使在理论上,它也无法为你决定你想做什么,也无法为你决定应该做什么。

      这在客户中很常见,甚至是大客户。

    8. 但这就是它被宣传的卖点。那个替你做决定的机器人。

      如果人们还得自己思考,那还有什么意义?

      1. 如果我还要自己动手,那杠杆有什么用?

    9. 是的,我们只需要亚马逊发布他们的AWS SDK MCP,然后等待几年,直到粗糙的部分被磨平,然后就可能实现了

      我的意思是,我们实际上已经有一个行业专门做这件事(Vercel、Netflix等)

    10. 说得好。人们经常谈论人工智能,仿佛它永远无法达到与人类精英相当的能力水平,这似乎是一种不切实际的悲观主义。

      1. 既然人们喜欢谈论现在就能取代开发者,我不同意这种说法。在这种背景下,对未来的猜测毫无意义。

        但如果我们还是想这样做的话:目前对大语言模型(LLM)的停滞和迭代方法在短期内并不乐观。这种方法似乎已经达到瓶颈。

      2. 没错。

        人工智能可以在某个时间范围内做人类能做的一切。

        仅仅因为一个人是有机体,并不一定就拥有超凡的才能。

    11. 如果你把他们使用的“人工智能”理解为“大语言模型(LLMs)”,那么没错,大语言模型(LLMs)无法进行架构设计,而且我认为它们永远也不会做到这一点。你可以将它们的性能提高 10 倍,超越我们目前所有的扩展极限,但大语言模型(LLMs)仍然从根本上不适合进行架构设计。从本质上讲,这项技术甚至不适合中小规模的代码一致性,更不用说架构级的一致性了。从本质上讲,它太容易说“我需要验证用户名”,然后敲出一个新的“用户名验证例程”,因为自动完成功能很好,但现在你有了第七个“用户名验证例程”,因为大语言模型(LLM)之前已经做过几次了,而且这七个都不一样,这只是它们当前病态的一个特别容易理解的例子。

      如果有人要改变“架构”的目标,那只会是那些认为“架构”完全符合现代大语言模型(LLM)的上下文窗口的人,更不用说他们成功地做到了这一点。他们现在是糟糕的架构师,甚至比无用还糟糕,比我对实习生的期望还糟糕。实习生可能会崇拜他们还不理解的设计方法,但即使如此,也比大语言模型(LLMs)产生的结果要好。

      然而,下一代人工智能会是什么样子,谁也说不准。一个能够构建系统符号地图、直接操作该地图,然后将其转化为代码的人工智能,能够实现什么,目前难以预料。不过,目前没有人知道如何做到这一点。这并非缺乏尝试。

  3. 本文犯了一个根本性错误,即作者认为企业重视质量。事实上,企业从未重视过质量。客户可能重视质量,但企业只重视利润率。如果客户只购买高质量产品,那么企业就会提供高质量产品。但大多数时候,客户也不重视质量,他们重视的是性价比。他们会在亚马逊上购买最便宜的工具,然后开心地用代码编写出一个漏洞,接着扔掉这个有问题的代码,继续编写代码。

    唯一重视质量的人是工程师。任何依赖他人突然重视质量的工程师对未来的预测都可以安全地忽略。

    1. 这完全不符合我的观点。

      首先,所有最成功的软件产品都具有非常高的质量。谷歌搜索之所以成功,是因为它又好又快。所有成功的网页浏览器都运行得非常出色。大型操作系统也是如此。iPhone 是一款令人惊叹的产品。Facebook、Instagram、TikTok;无论你如何看待,这些都不是 bug 众多或运行缓慢的产品(尤其是在它们的全盛时期)。Stripe 通过打造一款优秀的产品实现了增长。成功的B2B产品同样具备极高品质。我对Databricks没有太多好感,但它确实运行良好。我发现Okta极为出色。Notion也运作得非常顺畅。(当然也有反例:例如Rippling就没给我留下深刻印象。)

      那些在不重视品质的情况下仍取得成功的產品案例在哪里?

      1. > 那些不重视质量却取得成功的產品案例在哪里?

        自2000年代以来的Windows产品。它们可能在早期凭借质量取胜,但如今主要通过合规控制和转换成本来维持优势,这是我的观点。

        还有大型传统B2B数字系统。几乎所有ERP系统。我无法亲身体验,但这是我对SAP产品和Oracle产品的印象。还有Encompass,它是美国抵押贷款市场绝大多数的系统记录。大多数医疗软件也是如此。

        有很多记录系统由于处理了数十年的细节,形成了巨大的护城河。它们的“质量”按现代用户体验和性能标准来看非常差,但它们处理了行业中的所有细节。

        1. 你说得对,也许这里有个例外。在市场拓展阶段,你需要保持产品质量。一旦客户已经扎根,你就可以放松甚至降低产品质量到一定程度。你是在玩弄摩擦,这可能会失去业务,但熟悉的客户可以容忍很多。

      2. “优质”这个模糊的概念在这里起到了很大作用,但iPhone有bug,Facebook有bug,操作系统在基本功能如窗口管理或文本编辑上也屡屡失误,确实存在大量bug和卡顿(Mac上的设置应用就是个臭名昭著的例子)。但既然质量标准这么低,一切都显得无所谓了。

      3. 感谢指出Rippling的问题。我也有过类似的糟糕体验。

      4. >> 那些不重视质量却取得成功的產品例子在哪里?

        Salesforce。Quickbooks。任何Oracle产品。

        1. Blackboard的软件和系统。

          该死的Windows。

          1. 几乎所有微软产品都证明了质量与软件成功几乎无关。

      5. 抱歉,但Facebook是“高质量产品”?从一开始到今天,它一直是一个漏洞百出的烂摊子,跨越多台电脑,持续了十多年。不只是我。他们唯一的价值就是社交图谱,而他们只是因为先发优势才拥有它,别无其他。

        如今当网站崩溃时,我反而将其视为一个温和的提醒,让我不要在那里浪费哪怕一分钟的时间。无论如何,现在网站上大多是针对我毫无兴趣的群体生成的虚假AI广告,我一直向Facebook举报这些广告,但即使是涉及欺诈或诈骗的案例,Facebook也只在2%的情况下给予解决。欧盟,你们这些廉价的骗子。

        但过去我曾用它与家人朋友分享照片,因为我曾活跃于环球冒险与旅行。十年间累计上传了超过1万张照片。

        相册上传时常随机失败,或仅上传部分照片,甚至有照片被重复上传。即便在稳定的光纤网络下,Flickr或Google Photos从未出现过此类问题。无法评论,系统显示内部乱码错误。评论被重复发布。页面刷新后显示错误。链接到个人资料或照片时会跳转到空白页面。有时甚至主页也只是空白动态或出现内部错误。我看到“出现错误”这句话数百次,甚至可能上千次,它已经成为经典的500错误变体。诸如此类的问题层出不穷,我没有保留详细记录。始终使用Firefox浏览器和uBlock Origin插件。

        我若与这样一款技术上堪称最差的产品有任何专业上的关联,我都会感到无比羞耻。当然,如果我能忽视自己正在助长社会毒瘤的事实,或许还能勉强接受,但这需要我运用高超的反社会人格技巧,而我既无能力也无意愿去做。

        不,Facebook根本不配与其他产品同日而语,无论从哪个合理角度来看都是如此。

        1. 公平地说,但请注意他们并非第一个。

          我同意,我第一次使用Facebook时(大约在2004年),我的印象是“这是什么,就像七个PHP文件?我也能做出来!”,但到他们IPO时,我认为它已经相当成熟了。此后它积累了大量冗余代码。

    2. 当人们的设备开始变砖、加载网站需要12秒、申请医疗补助只能在上午9点到11点之间进行且需要运气时,人们才会开始关心。

      我们正处于一个奇怪的过渡期,一切仍相对高质量且勉强能用,但几十年后,事情将以比你说“OpenAI”还快的速度恶化。

      一些奇怪的事情将开始发生,比如政府无法升级税收系统,却消耗了数十亿资金;基础设施因未知原因出现故障;现在无处不在的简单非低功耗设备将变得稀有。一切都需要订阅和互联网接入,而且没有任何东西能正常工作。你将不得不整天与大语言模型(LLMs)对话。

      1. 我确信微软Teams团队已经全面投入到“氛围编码”中。我从未见过在如此短的时间内发布如此多的故障功能,就像过去几个月一样。这是未来,因为越来越多的公司全面投入到AI编码中。

        1. 不,这只是微软的一贯质量标准。AI只会加速这种 decline。

        2. 没什么新鲜的,只是崩溃速度加快了。

      2. > 申请医疗补助计划只能在上午9点到11点之间进行,而且还得靠运气。

        当我们得到 healthcare.gov 时,情况差不多,可能更糟。网站无法使用,只完成了大约 5% 的要求。情况很糟糕,人们都很生气。

        当然,按照美国政府的一贯做法,这项任务被外包给了一些私营公司。这些公司花了两年时间完成,超出了预算,但仍然一无所获。

        1. 尽管这个问题很复杂,由多种因素造成,但我认为这预示着未来几十年我们将看到的质量水平。当然,还有广告。广告永远有效。

      3. 如果当前技术达到瓶颈(但价格继续下降,如预期),那么这是一个合理的预测。

        但随后将出现对“一站式”可靠超级应用的需求,以取代其他所有应用。这些应用将开启威廉·吉布森所描述的超级企业现实。

        1. >但价格将继续下降,如预期所示

          是吗?人工智能似乎正处于市场占领模式。据我所知,很少有企业实际上报告利润。

          我只能预测,一旦市场被赢家占据,AI模型将疯狂推高成本。这与过去20年中的每一次技术趋势如出一辙。

          1. 在过去20年里,托管、带宽、存储和计算成本都下降了几个数量级。

            无论当前哪种模型最佳,似乎都会有一个开放权重模型在6个月后跟进,其成本将与硬件成本紧密挂钩。

      4. > 当设备开始故障、加载网站需要12秒、且只有在上午9点至11点之间且运气好的情况下才能注册医疗补助时,人们才会开始关注。

        我不知道医疗补助的情况,但后两点现在已经成真。

    3. 我不知道你从哪里得到客户不重视质量的印象。他们非常重视质量。

      如果客户不重视质量,那么每家初创公司都会成功,只需提供最基本功能的产品,以最低价格销售,并通过销量获得足够的收入。

      1. > 只要提供最基本功能的产品,以最低价格出售,通过销量来获得足够的收入,每家初创公司都会成功。

        你刚刚描述的是“拼命工作文化”。是的,它确实会带来商业成功。工程师不喜欢这种文化。

        1. 没错,但大多数拼搏都以失败告终,成功初创企业的比例大概是5%或10%吧?

          1. 拼搏不会失败,你为什么会这么想?客户喜欢雇佣拼搏者。初创企业失败是因为他们追求软件经济,而非拼搏经济。如果你愿意接受拼搏经济,你将永远不会缺乏工作。

            1. 你提出的论点很奇怪。我指的是初创企业。

              > 创业项目不会失败

              那么,从定义上讲,应该很少有工程师会遇到财务问题,对吧?几乎每个工程师都希望自己的副业能成功。

              1. 没有工程师愿意去拼命赚钱。

                你仍然只在考虑初创公司。我在想园艺师和票贩子。没有工程师会做这些。但如果你愿意去做,你就能赚钱。

                1. 你表达得不够清楚——你所说的“拼命工作”具体指什么?而且用绝对化的表述(“没有工程师”)在这里也很难成立。

                  这听起来就像你在说“所有工程师都很懒惰”,而这显然是错误的。

                  1. 使用我讨论对象的原话。

                    > 以最低价格提供功能最基本的產品,并通过销量赚取足够的收入

                    这就是拼命赚钱。

                    1. 如果你是这个意思,你整体观点是明确错误的。

                      许多工程师都在以最快的速度(因为时间就是金钱)开发勉强能用的产品,并通过大量销售来实现盈利。整个班加罗尔的承包商行业就是这样建立起来的,许多西方的小型承包商公司也是如此。你真的认为没有工程师明白如何通过压低价格来击败竞争对手吗?真的?

                    2. 有些工程师深谙商业运作的门道。但如果你专注于质量,你就不是在搞商业运作。

                      不过,我并不确定是否应该将那些拥有软件产品的商业人士称为“搞商业运作的工程师”。这是不同的思维方式。

                    3. 无论是选择“商业运作”还是“质量”,都是同样愚蠢的。质量是实现最终目标的手段,而放弃质量也是实现最终目标的手段。而且,无论是商业人士还是工程师,都有足够聪明的人知道何时专注于质量符合他们的目标,何时不符合。

                      听起来你已经接受了某种荒谬的“西格玛思维模式”的胡说八道,现在你正在用它来维护自己的身份。为了你自己的利益,停止这种行为。与你似乎相信的相反,拼命工作确实会失败,如果你对这种可能性闭目塞听,最终你会把精力浪费在错误的事情上,并在一个行不通的拼命工作中耗尽自己。即使你没有这样做,你也会让自己变得令人无法忍受,以至于你不想与任何人互动。这不是一条好路。

                    4. > 承诺“拼命工作”或“质量”同样愚蠢。

                      当然是。

                      > 听起来你已经接受了某种荒谬的“西格玛磨练心态”的胡说八道,并将其作为身份来把关。

                      这种理性主义的胡说八道正是我致力于在HN上反对的。从直觉主义的视角出发,才能真正做好泛泛而谈。我关于这个话题的原始帖子获得了25个赞,这在当今已属相当高的水平。是你误将我的概括视为把关,而这正是因为你执着于理性主义思维,因此将这种思维投射到他人身上。

                      我只是坚持自己的立场。我不会采取半途而废的态度。反正没人会在第一天之后继续关注这个帖子。在保质期过后继续讨论也没什么害处。

            2. 我真的不明白这条评论想表达什么。

    4. 关于我最喜欢的以质量为核心的公司的一些事实:https://www.fractalaudio.com/

      他们开发基于硬件的吉他音箱/效果器模拟器(例如虚拟效果器踏板板+音箱),并持续获得稳定的更新。从手感和准确性角度来看,他们几乎击败了所有竞争对手,甚至包括像Line 6(雅马哈旗下公司)这样规模更大的企业。据我所知,这是一家非常小的公司,可能不到20人。大多数改进都源于CEO对如何准确模拟这些非常模拟系统的理解不断提升。

      他们几乎做了初创公司不该做的一切:

      * 主要是一家硬件公司

      * 直接销售而非通过Sweetwater等渠道

      * 不支付艺术家进行代言

      * 没有订阅服务

      * 提供大量免费且有时相当重大的建模算法更新

      * 没有使用AI快速开发产品

      质量是他们在竞争激烈的市场中脱颖而出的关键。

      这也不是特例。这是市场部分领域运作的方式。并非每个市场的每个部分都陷入价格战的泥潭。

      1. 特例证明了规则。如果“质量”是小众市场,那么它本质上就不代表整个市场。

        1. 没错。事实上,它通常并不代表整个市场,更多时候只是某些细分领域:有时你想去麦当劳,有时你想去米其林星级餐厅。

          同样以吉他为例:许多吉他手青睐NAM(神经放大器建模器),因为它免费且可在PC上运行,或是选择像ToneX这样的廉价硬件效果器。这个市场的低端用户总是追逐高端产品,但这些廉价选项在音质上表现出色,与多年前的L6 Pods相比已有了长足进步。

      2. 看到这样的情况令人欣慰。没有什么能比得上用心之作。

    5. 我认为在某些情况下,质量可以成为差异化因素。当iPhone推出时,市面上已有运行Windows Phone和Symbian系统的手机,它们功能更多且价格更低。然而iPhone仍取得成功,因为其运行更流畅且用户界面比竞争对手更精致。

    6. > 商业从未重视质量。客户可以重视质量,但商业只重视利润率。

      如果你认为你已经非常接近一个细微差别。

      商业不重视代码质量。他们的首要目标是快速推出产品以吸引客户。如果你身处快速变化或竞争激烈的领域,质量就变得更为重要,因为你需要推出差异化功能。如果该领域变化缓慢、不易迁移等,那么发布周期可以更慢,质量的重要性也相应降低。

      不过,客户确实关心“质量”,但他们对质量的定义可能大不相同,主要体现在“易用性”上。

      他们不在乎背后的代码、使用的框架等,只要软件a)能实现他们的需求,b)在他们看来“足够快”地实现即可。

      1. > 他们不在乎背后的代码、使用的框架等,只要软件a)能实现他们的需求,b)在他们看来“足够快”地实现即可。

        商业人士喜欢这么说,但很多时候这忽略了代码质量与满足用户需求速度之间存在的内在关联。我参与过许多代码混乱的项目,而这种混乱总是会转化为用户关心的问题。并不存在代码糟糕但软件对用户却很优秀的魔法案例——这种情况不存在,至少不会持续太久。

    7. 我建议将结尾那句话改为:

      唯一经常重视质量的人是工程师。

      我甚至可能补充说,绝大多数工程师在价格合适时都乐于牺牲质量——以及通常的职业道德。当然,并非所有人都是如此。

      我们所处的是一种奇怪的文化,这种文化既能培养出在工作中具备复杂逻辑能力的工程师,同时“商业的最终目标始终是利润”这一观念有时也会带来困扰。

    8. 企业在成本中心重视质量是因为这能降低成本

      1. 个体经理可以。但整个企业关注的是更宏大的格局。然而,经理们重视的是吞吐量,而非单位经济效益。他们会接受更快的交付速度,即使这意味着单位经济效益较差。

    9. 这完全取决于领域,我认为。有些领域中,利益相关者绝对重视质量(例如收入损失、罚款及其他后果)。但这并非普遍适用。

    10. 当质量可用时,客户重视质量。

      如果供应链中在你之前的人更关心某件事的廉价性,那么这就是你所能得到的全部。

  4. 我认为列表中缺少了一些非技术性的革命,而是组织层面的:

    1. 推动“软件架构师”制定计划和规范,让那些烦人的开发人员只需遵循即可。我记得大约在2005年,有一种热潮是通过UML生成代码,让开发人员“只需”填空。我观察到的结果是,系统被过度设计到极致,甚至只是添加一个新字段需要修改四个不同层级的八个文件。

    2. 随后到来的“敏捷转型”时代,由于对敏捷原则的(可能是有意的)误解,导致大量现成流程、角色被引入,并对微观管理开发人员有所容忍。从我所见,这主要侵蚀了信任、动力和创造力。最佳情况下,它会形成一个高效的“功能工厂”,但生产出的却是错误的东西。更常见的是,它会让整个团队迅速变得低效。

    我一直很欣赏的是,非开发人员对开发人员的工作表现出真诚的兴趣,试图参与其中或至少提供支持,接受复杂性并明确需要解决的问题。无论团队使用何种工具或遵循何种流程,我始终认为这种做法会带来成功。而任何试图降低软件开发固有复杂性的努力,都未能取得同样的效果。

    1. 这是Visual Basic最接近实现的一点。使用可视化工具设计图形用户界面,点击按钮时填充空白。

  5. > 软件领域最宝贵的技能不是编写代码,而是架构系统。

    > 而且正如我们将看到的,这是AI目前无法替代的技能。

    然而,文章中从未真正“展示”这一点。它只是重复了几次,却没有提供任何证据。

    我认为恰恰相反:专门让AI设计架构所获得的结果,已经比我遇到的30%的“架构师”所能想到的要好。只是很多使用AI的人并没有明确提出这些要求。

    1. 我的看法略有不同。大语言模型(LLMs)非常擅长生成问题的中等解决方案,因为这是可用训练语料库的主要部分。它是一个通用的“最佳实践”生成器。从定义上讲,你可能会期望它比三分之一的人类建筑师更优秀。

      另一方面,它们在从第一原理推理来解决远超其训练语料库的问题方面表现非常差。在某些领域,例如对性能要求较高的平台,中等水平的解决方案通常是错误的,你需要高技能的人员使用大语言模型(LLMs)无法获得的背景知识和知识来完成设计工作。你可能可以使用大语言模型(LLMs)来设计数据库内核,但由于训练数据无法达到最先进水平,因此设计出的内核会相对简单。

    2. > 然而,我们在文章中从未看到这一点。它只是重复了几次,却没有提供任何证据。

      我对这篇文章在Hacker News上获得的点赞数量感到震惊。它的质量极低。显然是用ChatGPT写的。迹象包括:

      (1) 错误的技术“炒作周期”。它显示的是“触发、幻灭、启蒙、生产力”。它缺少非常重要的“过度期望”阶段。

      (2) 过多的停顿打断了思路的流畅性:

      – 大量使用破折号。ChatGPT喜欢用破折号来分割句子。

      – 大量使用简短句子以显得精辟深刻。例如:“高管们兴奋不已。顾问们如鲨鱼般盘旋。幻灯片数量激增。预算不断调整。”

      (3) “这不仅仅是X,而是X+1”,其中X是普通描述词,X+1是对X的更强调的重新表述。ChatGPT经常使用这种结构。以下是文章中的几个例子:

      – “实际发生的事情不是替代,而是转型”

      – “对于[…]一次性营销网站,这无关紧要。对于需要数年时间演进的系统,这是灾难性的。”

      类似地,“这不是X,而是X的逆数”,导致相同的重复表述:

      – “无代码运动没有消除开发人员;它创造了无代码专家和后端集成人员。”

      – “云计算并未消除系统管理员,而是将他们转型为DevOps工程师”

      – “软件领域最宝贵的技能并非编写代码,而是架构系统”

      – “结果并非开发人员减少,而是‘无代码专家’的诞生”

      – “系统管理员并未被淘汰,而是重生为DevOps工程师”

      – “工作并未消失,而是演变为基础设施即代码”

      – “技术并未取代技能,而是将其提升到更高的抽象层次”

      – “代码不是资产,而是负债”

      ———

      我希望人们停止使用ChatGPT。每篇文章都以同样冗长、刻意卖弄深奥的ChatGPT风格撰写。

      没有人再用自己的声音写作了。

    3. 这就是一厢情愿的想法。作者可能对自己的架构能力感到自豪,因此认为它是不可替代的。如果他们擅长优化,他们会认为优化是不可替代的。

      1. 我认为这只是这些工具的本质。它们擅长做你无法做到的事情(大多数事情),但不擅长做你能做到的事情(非常少的事情)。

        例如:如果你像大多数人一样是个懒惰的打字员,那么代码助手可以显著提高你的效率,当你将其作为自动完成工具使用时。但如果你是个熟练的Vim用户,手指在键盘上飞舞,或者是个精通结构化编辑的Lisp高手,那么代码助手反而会拖慢你的速度或分散你的注意力。

      2. 正如马克·安德森所说,风险投资是人工智能最后一个无法取代的职业 :)))

        > 安德森表示,风险投资可能是少数几个在人工智能自动化浪潮中幸存下来的职业之一。他指出,这在一定程度上是因为该职业需要多种“无形”技能,更偏向于艺术而非科学。

        https://fortune.com/article/mark-andreessen-venture-capitali

        1. > 这份工作需要多种“无形”技能,更像是一门艺术而非科学。

          我见过更多由人工智能生成的艺术作品,而非科学作品。

        2. 不,人工智能在生成自我吹捧的胡言乱语方面表现得相当出色。

    4. 建筑师面临的90%问题在于能否理解并表达系统的要求与限制,以及理解其与其他系统的交互方式。

      即撰写提示、理解答案、提出异议等。

        1. 就是这样!

          除非人工智能被引入作为常规同事,且利益相关者希望与它定期沟通,否则我认为这种情况短期内不会改变。

          当不合作的利益相关者主导项目时,反向工程也有其局限性,需要“上帝模式”类型的内部基础设施访问权限,而这种权限并非人人都能获得。

    5. 这是因为很大比例的“架构师”其实并不出色。我们面试过一位候选人,他对实际操作IT基础设施知之甚少,但在他看来这并不重要,因为他更看重架构师的角色,不想接触终端、YAML、数据库等技术细节。他们非常认真地坐在那里告诉我们,他们真的只想在图表工具和Excel上工作……

      架构师就像管理者,比人们想象的要难得多,而且很少有人能真正胜任这份工作。

      1. 没错。这确实像“管理”一样,人们期望只需在公司多待几年就能轻松获得这个职位。

        另外,我讨厌“架构师”被用作“云架构师”的同义词。软件架构远不止云计算。

        1. 完全正确。我注意到我之前的一位实习生现在成了“企业架构师”。他确实很聪明,但从零到架构师只用了3.5年?这个人根本没有足够的经验成为架构师。这要么是因为公司需要这个头衔,要么是因为他被“收买”留下来。

      2. > 我们面试了一位候选人……他不愿意接触终端相关的工作……他们更希望找到一位架构师角色的人

        我不确定你们是否真的在寻找一位架构师?架构师有不同类型。例如,企业架构师确实不会接触YAML,解决方案架构师则有更窄的关注范围,而工程师则承担着繁重的工作和团队责任。后者更适合称为首席工程师。根据我的经验,成为优秀的(首席)工程师并不等于成为优秀的架构师,但公司为了让职位描述更具吸引力,常会冠以“架构师”的头衔。我认为,公司应更认真对待首席工程师这一角色本身。

        架构师通常需要具备抽象推理、信息处理和概念思维的高度技能。然而,招聘“架构师”的人往往在寻找2x/nx工程师,即每小时能编写x个组件的人。这是一种愚蠢的错配。

        我同意,没有实际经验的人确实不太适合,尤其是在“企业架构师”级别以下。

    6. 架构师是什么?

      哦,你是说幻灯片撰写者。抱歉,刚才没听明白。

  6. 我越来越确信,过度追捧AI热潮的公司正在为自己埋下被颠覆的隐患。

    这篇帖子的作者说得对,代码是一种负担,但人工智能领导者不知怎么说服了市场,认为按需生成代码是一大胜利。他们正在向行业推销一个未来,即公司可以用更少的人力维持“生产力”。

    令人惊讶的是,似乎没有人问(或关心)在代码生成时代,产品品质会如何。上个月,萨蒂亚·纳德拉(Satya Nadella)曾声称微软30%的代码是由人工智能生成的。这是否与GitHub今年每月平均发生20起事故有关?[1]这基本上相当于每个工作日都发生一次……

    没有什么是免费的。我预测,那些过度重视大语言模型(LLMs)效率的公司将为此付出质量上的代价。我并不认为这会打垮任何巨头,但并不是每家购买这种“蛇油”的公司都是微软。如果企业失手了,会有许多饥渴的企业家蜂拥而至。

    [1] https://www.githubstatus.com/history

    1. > 我越来越确信,那些过度追捧AI热潮的公司正在为自己埋下被颠覆的种子。

      我持相反观点。忽视AI的公司将面临艰难处境。

      1. 哈哈,我试图通过添加“过度”来缓和这一观点,但我同意。企业应允许团队在工作流程中尝试相关工具。

        我的观点更多是针对人们对人工智能的过度期待。当前一代人工智能技术充斥着陷阱和风险。许多企业似乎在决策时寄希望于通过创新来规避后果。

      2. 为什么?难道是因为缺乏艺术感的设计,所以不需要支付给艺术家费用?除了在最大化股东回报方面,我看不出来放弃人工智能会让他们“落后”。

        人工智能,尤其是用于编程,本质上与典型的海外外包编程公司无异,充斥着毫无意义的注释和混乱冲突的代码风格。

        如果人工智能最终真的如支持者所说的那样,他们随时可以开始更多地使用它。

    2. 我同意这一点。“过度使用人工智能的公司将面临长期成本负担”[1]

      [1] AI:加速无能。https://www.slater.dev/accelerated-incompetence/

  7. > 代码不是资产——它是负债

    没错,就是这样。100%同意。程序的目标是用尽可能少的代码实现特定目标/功能。而人工智能恰恰相反。如今代码生成变得容易,自然约束机制已不复存在,无法阻止过多负债的产生。

    1. 对生产力悖论(https://en.m.wikipedia.org/wiki/Productivity_paradox)的回答可能是:技术进步导致系统复杂性增加,抵消了技术本身带来的效率提升。

    2. 这让我想起过去人们用MS FrontPage创建网站的日子,当时的HTML代码有90%都是冗余。

      1. >HTML代码中90%都是冗余代码。

        你最近看过很多顶级网站的代码吗?

        1. 我前几天刚访问过stallman.org,是的。

        2. 哈哈,你没说谎。框架叠加框架——这就像乌龟叠罗汉一样。

    3. 但如果代码可以轻松替换,为什么它会成为负担?如果出了问题,下一代“程序员”会让AI重新生成代码。

      1. 代码无法轻易替换。它确实是“软件”,但你认为银行为什么还在使用COBOL?你认为我以前的公司为什么还在运行一个过时的Zend(PHP框架)版本?

        1. 这也是“技术债务”这个术语被使用的原因。你通过编写的代码强制执行的每一个决策,都可能是你以后需要撤销的。而这样做的成本可能非常高。高到在父评论中,你根本不会去管它。

        2. 因为,直到最近,替换代码的成本非常高。AI“程序员”可以在几分钟内生成完全新的代码,因此无需维护它。如果明天出现新问题,他们会再次生成代码。

          1. > 如果明天出现新问题,他们会再次生成代码。

            从大语言模型(LLM)的角度来看,一周前生成的代码与现在生成的代码有什么区别?大语言模型(LLM)如何知道在哪里以及如何修复错误?为什么大语言模型(LLM)从一开始就没有生成没有该特定错误的代码?

            1. 明天“程序员”会告诉AI bug是什么或需要做哪些改动,AI会根据这些新增要求生成新代码。

              1. 这与你上面说的矛盾:

                > 因为直到最近,替换代码的成本非常高。AI“程序员”可以在几分钟内创建全新的代码,因此无需维护。如果明天出现新问题,他们会再次生成代码。

                为了知道需要进行哪些更改来修复错误,程序员需要先对代码进行调试。但如果代码的替换成本很高(在这种情况下,我们将使用大语言模型(LLMs)从头开始重新生成代码),那么代码的调试成本也会很高(代码替换成本高的原因是代码已经变得难以维护……这也是调试成本高的原因)。

                此外,要求程序员进行调试,然后让大语言模型(LLMs)编写代码也是没有意义的。为什么不直接让大语言模型(LLMs)进行调试呢?

                因此,您每次生成“新代码”的设想并不现实。对于非常小的应用程序来说,这也许可行,但对于通常由 100 名工程师参与的大多数项目来说,这会带来难以维护的混乱局面。如果难以维护,那么程序员就无法高效地进行调试,而如果程序员无法进行调试,那么就没人能告诉大语言模型(LLM)如何修复它。

                1. > 为了让程序员知道需要做出哪些改动来修复 bug,程序员首先需要调试代码。

                  AI 也能调试代码。而“程序员”不需要知道如何修复,只需描述正在发生的错误。

          2. 替换代码仍然非常昂贵。迁移的难点通常不在于代码的生成。

      2. >可以轻松替换

        我想问题是“用什么替换?”你怎么能确定这是1:1的替换?

      3. 例如,如果你有50个不同文件中以略微不同的方式编写的排序例程,你应该使用哪个?最好有一个你信任的排序例程的单一文件。

    4. 这是一句很棒的引语。从商业角度来看,这在很大程度上是正确的。我个人也认为代码是一种创造性表达,一种艺术形式。我喜欢编程,因为我可以以一种优雅且易于阅读的方式表达解决方案,无论是对自己还是对他人。虽然有些肤浅,但如果你读过优雅地编写的代码,你就会立即明白。

    1. 你可能经常犯错,但突然间就对了。查查”做一只火鸡”:https://en.wikipedia.org/wiki/Turkey_illusion

      1. 我认为你忽略了一个事实,即它确实消除了“编码”。

        而这正是事情开始变得有趣的地方。

  8. 这些人工智能系统的问题在于,它们在孤立的环境中表现得非常出色,但当必须整合到完整的技术堆栈中时(即使技术堆栈也是由相同的模型编写的),它们就会崩溃和烧毁。

    基于大语言模型(LLMs)的当前一代生成性人工智能根本无法正确学习编写大型代码库,也无法对产品做出正确的评估选择。如果无法进行客观的推理和评估,你就无法成为一个好的“开发人员”替代者。这类似于向大语言模型(LLMs)询问(复杂的)积分,它通常会以“通过推导证明的解决方案”来结束答案,这不是因为它真的做到了(它也会在不正确的积分上以这种方式结束),而是因为它的训练数据就是这样做的。

  9. 这类文章是在无中生有地辩论。任何人都能看出,当前AI无法真正取代开发者(尽管在某些情况下它确实能节省大量时间)。但五年后呢?十年后呢?事物正在迅速变化,没有人知道未来会发生什么。

    五年或十年后,至少部分开发者被完全取代是完全可能的。

    (人力资源、财务、市场营销等领域的人员也可能面临同样的命运。)

    1. 目前,开发人员失业的现象已持续了3年。

      或许5年或10年后情况会发生变化,但就目前而言,我无法想象自己会被取代,除非出现某种范式转变, 而当前的人工智能改进似乎并未提供这种范式转变——它们只是在重复相同的迭代,每一代都略微精进或具备更多基于自身输出生成新输出的能力——因此我没有理由认为我的工作目前面临威胁,仅仅因为未来某个时间点可能存在这种可能性。

      有人需要告诉我,到底是什么变化会导致人工智能的能力发生如此巨大的转变,因为目前我还没有看到。这似乎让人们有理由将科幻小说当作商业计划来对待。

      1. 作为开发人员(有时会使用大语言模型(LLMs)),我完全同意。

        它们可以成为有用的工具,但目前的能力以及(我个人认为)其无限提升的潜力被严重夸大。整个行业似乎戴着某种有色眼镜,我认为这与它们的进展不均衡且具有双向性有关。每次有人推出他们的新模型,我尝试使用时,总会发现它在某些方面比前一版本更好,但在其他方面又不如前一版本。但数据在增长,所以算是进步吧?

        一方面,我可以把这一切都当作又一种管理潮流来一笑置之(需要明确的是,我并不认为大语言模型(LLM)的使用是一种潮流,只是认为这是一种将改变世界的技术,而不是另一种工具),但让我对当前的人工智能炒作感到最恐惧的不是大语言模型(LLMs)会取代我们的工作, 而是那些富裕且如今拥有政治权力的群体,他们正推动大规模能源生产来支撑这一切“人工智能”,而这种行为很可能造成实际损害。

        其中一些人几乎像宗教狂热分子一样,他们相信人类活动导致的气候变化,却仍执意不择手段地将能源生产提升到荒谬的水平,同时轻描淡写地忽视这种行为的明显影响,声称任何因能源生产激增而造成的损害都将由最终出现的仁慈神一般的人工智能来为我们解决。

        嗯,我认为这种情况不会发生。一点也不会。

        1. 在我看来,如果将“做出拯救我们的决策”交给当前形式的人工智能,结果将介于破坏性与灾难性之间,无论电力生产是否造成气候损害。

      2. 没有什么根本性的东西需要改变。它只需要变得更聪明、更可靠。

        不要以为那些疯狂的“六个月内一切都将由人工智能掌控”的预测没有实现,就意味着它永远不会发生。

        我足够老,记得在互联网泡沫时代在线购物的失败。有时候事情就是需要时间。

        1. > 没有必要进行根本性的改变。它只需要变得更智能、更可靠。

          但这些正是需要对系统运作方式进行根本性改变才能实现的改进。

          到目前为止,还没有人找到让人工智能系统实现这一目标的方法。然而,我们却要相信,对大语言模型(LLMs)进行微调就能很快实现这一目标。

        2. 如果你还记得互联网泡沫时代,你应该也记得低代码和所见即所得(WYSIWYG)曾被视为开发者的末日。

          当然,现在还没发生并不意味着永远不会发生,但也没有证据表明它会发生。当最新的末日教派未能预测到世界末日时,这会让你对下一次有人喊出“世界末日”时是否更相信还是更不相信?未来开发者末日被推迟得越久,它似乎就越不可信。

          1. > 低代码和所见即所得(WYSIWYG)都被认为是开发者的末日。

            我的意思是……希望这真的很明显,为什么它们是完全不同的!

            1. 技术确实不同,但它们都是试图通过隐藏代码来用业务用户取代开发者的尝试。到目前为止,这并没有成功,因为事实证明,成为一名优秀的开发者不仅仅是编写代码,但人们仍然不断尝试。

              1. 代码是固化的设计。整个问题在于设计本身,以及如何处理必要性和偶然性复杂性。编写代码只是常规工作。与其他设计工作唯一的区别在于,我们可以随时开始编码,因此需要不断往返调整。

                这就像建造房屋主要是物流和重复性工作。而设计房屋足够复杂,需要学位和多年经验才能被信任做好。

              2. 这并非低代码或所见即所得(WYSIWYG)失败的原因。我的意思是,从某种意义上说它们并未失败——Squarespace和Notion似乎运作良好。但它们未能完全取代大多数开发者的原因在于,人们通常希望实现超出平台能力范围的功能。这些平台不够通用,无法覆盖所有使用场景。

                人工智能在这一点上本质上不同。

                应该为这种谬误起个名字——之前的尝试失败了,因此所有尝试都会失败。

                1. > 它们不够通用,无法满足所有用例。> AI 在这一点上是根本不同的。

                  目前大多数项目都超出了人工智能的能力范围。平台可以变得更好并添加更多功能,为什么这与人工智能变得更好并能做更多事情不同?

                  当时人们不知道是否有可能让这些平台通用到足以取代程序员。你不能。

                  今天我们尚不确定是否能将基于transformer 的AI通用化到足以取代程序员的程度。时间会证明一切。

                  对我来说,这看起来完全一样。

                2. 当然,这与“这次情况根本不同”的谬论如出一辙。参见我之前关于末日教派的评论。

                  需要注意的是,我并不是说没有技术能够填补这一空白,GenAI 可能可以做到,但我完全不相信大语言模型(LLMs) 是取代开发人员所需的一切工作的正确技术。

                  1. 我的意思是,如果你无法分辨AI与低代码/所见即所得之间的根本区别,我真不知道该说什么了……

                    1. 我的意思是,如果你看不到汇编语言与C语言之间的差异要大得多,并且开启了编程的黄金时代,我真不知道该说什么了

      3. 我认为,如果AI能取代开发人员,那么任何需要打字的工作都面临风险,我们将会陷入如此困境,以至于规划这种情景毫无意义。

        1. 编程工作可能是最容易被取代的,因为有大量公开的培训材料,而且本质上是基于语言的。

          但没错,我同意。等到我的工作真正完全被取代时,社会已经完蛋了。

    2. 如果给人工智能十年时间改进,那我敢打赌会有大量开发者被取代,而不仅仅是部分开发者。

      我认为你在金融领域也说到了关键点。如果微软花十年时间提升AI对Excel的理解能力,我认为大量商业分析师将变得多余。目前,在一家拥有2.5万到5万名员工的组织中,根据行业不同,可能会有数十到数百名商业分析师。十年后?嗯,就说没人会愿意在账面上承担数百名商业分析师的薪资,同时还要支付微软365AI的许可证费用。只有最优秀的分析师会留下来。而且数量不会太多。

      1. > 嗯,就说没人会愿意在账面上承担数百名商业分析师的薪资,同时还要支付微软365AI的许可证费用。

        但成千上万家公司将能够用1到10人的团队实现以前只有2.5万或5万员工的组织才能实现的功能。

    3. > 完全有可能在5到10年内,至少部分开发人员会被完全取代。

      部分开发者已完全被取代,例如着陆页开发者。但AI/无代码开发者的数量庞大且增长迅速,因此并未消除任何开发岗位。这只是科技领域一贯的趋势,需要持续跟进。

      1. 着陆页开发者还存在?我以为他们早在几十年前就被FrontPage和Dreamweaver取代了。

        (仅开玩笑)

  10. 我认为这类文章背后有一个基本假设,即技术进步将达到瓶颈。如果这个假设成立,那么确实如此。

    但如果假设不成立,那么未来完全有可能出现一种AI模型,能够读取整个AWS/基础设施账户、分析日志、财务数据、查阅文档,并形成对整个业务的完整认知。到那时,人工智能模型能够处理架构和长期规划的想法似乎是可行的。

    通常,当我读到关于开发者替代的文章时,其潜在假设是代理/模型会不断变得更大、更好、更便宜,而不是今天现有的模型就能做到。

    1. 人工智能构建的系统及其推理过程,随着时间推移可能变得难以理解,仿佛由外星人打造。软件开发、技术栈及实践中存在巨大的社会属性,确保了(尽管存在分歧)开发者在当代软件开发方法上大致达成共识(例如,这与20或40年前的情况已大不相同)。

      当人工智能系统主要依靠自身运行时,其实践方式也会随之演进,但不会有软件开发者群体参与并跟进这些概念和实践的变革。仍需有一小部分专家持续跟踪并引导人工智能的软件开发方式,以便分析并修复不可避免的故障案例,并确保人工智能的运作方式仍能被人类理解。

      假设人工智能将达到这种能力,这将是一个漫长而复杂的过渡过程。

  11. 我认为,软件行业的大部分裁员是由于不确定性,而非技术原因。这些裁员事后被用技术术语来合理化。如果没有经济不确定性,公司会乐于接受额外的生产力。

    换个角度思考:五年前,许多公司为了提高生产力而招聘更多软件工程师,并乐于承担额外成本。因此,我认为这与成本无关。

    我可能错了,但或许看待这一切的一个有用方式是忽略裁员的官方理由,而是关注公司本身。

    1. 额外的生产力在哪里?为什么它没有体现在经济数据中?

  12. 你还可以追溯到文章描述的更早时期。上世纪90年代,同样类型的文章曾预测,像FrontPage、Dreamweaver等所见即所得(WYSIWYG)编辑器将使网页开发者变得多余。

    1. 在70年代,有文章称商业人士可以使用SQL等高级语言取代开发人员。在60年代,则是COBOL。

    2. 虽然花了些时间,但Wix/Webflow/SquareSpace/WordPress最终确实自动化了大量工作。

      1. 他们确实做到了,但你认为与90年代相比,现在的网页开发岗位是更多还是更少?

        1. 大量类似宣传手册类型的网页工作已经消失,要么被这些网站建设工具取代,要么被Facebook吸纳。我不知道从事这类工作的人现在在哪里,但我想大多数人可能没有准备好去编写大型React应用。

          1. 你为什么这么认为?你觉得所有新的React工作岗位是怎么填补的?React开发者不会凭空出现并完全掌握React,他们是通过实践成长起来的。

        2. 2025年的网页开发者与网页数量的比例肯定远低于1998年。

          1. 为什么有人会关心这个指标?人们关心的是工作机会。

        3. 更多,但这并不能说明未来会怎样。

          1. 当然有意义。这并非保证,但假设一种趋势很可能继续下去并非毫无意义。当观察到一种趋势时,主张“这次不同!”的一方需要证明其观点。

            1. 人工智能的目标是自动化几乎一切。这听起来与过去的任何时代都截然不同。

              1. 如果你不认为观察到的趋势能预示未来,就不应在相反方向上做出缺乏依据的断言。它们说得更少。

                1. 人工智能旨在自动化一切,这是全新的。这就是重点。过去从未出现过与现在缓慢展开的情景相似的AI。根本不是一回事。如果你不同意我使用的“一切”这个词,那么是的,我明白我不应该使用这个词。

    3. 对于设计师来说也是同样的情况,“现在任何人都可以使用Squarespace/Webflow/Framer创建网站”——这引发了模板市场,而这些模板是由——你猜对了——设计师创建的……

    4. 下一个热门YC初创公司……用UML图训练AI :)

  13. > 软件领域最宝贵的技能不是编写代码,而是架构系统。

    我并不完全认同。我认为关键技能在于将现实世界中所有不一致的元素转化为计算机能理解的形式。

    而这是所有无代码/低代码平台失败的地方。在某些时候,必须进行这种转换,而大多数人绝对讨厌这样做。现在,你还是得雇一个开发人员。尽管它们可能很有帮助,但我还没有看到大语言模型(LLMs)能更好地完成这种转换。

    也许大语言模型(LLMs)/人工智能能够以我尚未看到的方式,从“极快的白痴”中消除白痴,而白痴就是计算机。

    1. 如果回顾编程语言的历史,我们一直在朝着“自然语言”的方向发展。我们从1和0开始,然后过渡到汇编语言。我想当时汇编语言被认为是更高层次的语言。

      我怀疑如果当前趋势继续下去,今天的高层次语言在不久的将来会成为低层次语言。了解它们的重要性将降低,就像今天编写有用应用程序时无需掌握汇编语言一样。

      系统架构仍将至关重要。

      1. 我们走向的是更高层次的抽象,而非自然语言。这些抽象看似自然语言,因为我们用自然语言为它们命名,但其语义可能大不相同。

        构建软件一直是利用这些抽象来解决问题。但客户给我们的主要是愿望和需求。我们将这些转化为问题,然后解决该问题。它从“我想要$this”(需求)到“如何实现$this?”(分析),再到“$this可以这样实现”(设计)。我们将最后一部分翻译成代码。但仍然有”$this是否正确实现?” (通过测试回答)和“$this不再正常工作”(维护)。

        因此,我们不是转向自然语言,因为代码的整个目的就是固化设计。我们正在朝着更好地表示常见设计元素的方向发展。

        1. 我同意你所写的内容,但可能有以下几点不同意见:

          “我们正在朝着更好地呈现常见设计元素的方向发展。”

          我认为,新创建的抽象概念中,大约90%都带有时尚元素。因此,这种呈现方式往往变得越来越不常见,也就是说,更加碎片化。

          我认为希望在于自然语言能解决这个问题,通过成为描述抽象概念的通用语言,并以某种方式减少时尚元素。这就是人工智能的承诺。

          但如果这会发生——我有点怀疑,因为人类创造时尚的欲望是那个未被解决的“房间里的大象”。

          1. 你说得对。但抽象性的一个好测试是一致性。抽象是生成器。你从几个参数中识别出可以推导出系统其余部分的参数。但要做到优秀,它需要能够解决整个问题空间,而无需调整生成的系统(泄漏的抽象)。

            人类语言是最终的泄漏抽象,因为虽然你可以给某物命名,但你需要更多的词汇来精炼它,而这一过程是递归的。

            这就是形式语言诞生的原因。随后我们发明了计算机,用于自动解释形式符号。当前所有抽象仍属于形式范畴(一旦变量固定,语义即无歧义)

            从自然语言到形式语言的过渡并非概率过程。而是识别一组与自然语言规范的模糊性紧密契合的抽象,随后组合这些抽象并固定变量。这就是设计过程。最终结果通过代码实现,代码即完整规范。

  14. > 无代码/低代码革命

    我认为此次存在关键差异:AI编码已完全嵌入软件开发工作流程,确实为部分项目和工程师节省了大量工作。相比之下,几乎没有工程师会使用无代码/低代码工具并将其维护在自己的仓库中。

    影响在于,随着生产力提升,我们所需的工程师数量将减少。仅此一点可能不足以改变供需曲线。然而,当这一趋势与当前市场缺乏业务增长的现状相结合时,曲线将发生变化:我们面临的新问题越少,获得的重复性解决方案越多,我们投入重复性解决方案的工作越多,AI生成的代码准确性越高,因此人类需要编写的代码就越少。

    因此,这次不是关于人工智能取代工程师,而是关于人工智能取代足够多的重复性工作,从而使我们需要更少的工程师。

  15. > “为什么雇佣昂贵的开发人员,当任何人都可以构建一个应用程序?”

    > 结果并不是开发人员减少

    这让我思考,是否应该淘汰非开发人员?

    1. 是的。大语言模型(LLMs)擅长产生看似合理、体现意识、考虑周全、平衡且至少对相关技术有表面了解的陈述和回应。即使它们不承诺、不果断,甚至不准确。

      换句话说,它们是许多非开发人员的非常经济实惠的替代品。

      1. “将此重写为Cockburn定义的’完整用例’:…”

    2. 根据我的经验,这些公司中掌权的人并非开发人员,而是非开发人员。这些人绝不会愿意淘汰自己,无论他们能带来多少价值。

  16. 我认为这次攀登并不能真正证明氙气的有效性(高度研究专家彼得·哈克特博士也持此观点[0])。

    团队在攀登过程中使用了补充氧气,但起始高度和流量未被报告[1]。这只是推测,但如果他们使用的氧气量超过常规且起始高度较低,那将是一个巨大的优势。

    此外,安德鲁·乌沙科夫今年仅用不到4天时间从纽约市抵达峰顶,且未使用氙气(但同样使用了补充氧气,起始海拔和流量未知)。他使用了低氧帐篷进行准备,且根据报告的准确性,他可能为此花费的时间甚至比氙气团队更少[1]。

    [0] https://www.npr.org/2025/05/18/nx-s1-5398553/a-new-company-i… [1] https://www.alanarnette.com/blog/2025/05/21/everest-2025-fas

  17. > 软件领域最宝贵的技能不是编写代码,而是设计系统架构。

    而捍卫立场时最宝贵的技能是移动目标。

  18. 我认为,在大语言模型(LLMs)能够明确地拒绝你的请求之前,我们无法完全依赖它们。ChatGPT、Copilot 和类似工具的最大缺点是,它们总是会给你一些回报,总是会提供某种答案,很少会质疑你的原始请求。这是我目前在与人类和机器合作时观察到的最大差异。人类通常会提出异议,通过合作可以共同提出更好的解决方案(或许代码更少、流程更简化,或依赖性更低)。而聊天机器人(目前为止)只会从成千上万种潜在解决方案中随机选择一种来打发你。

    1. > 我认为,在大语言模型(LLMs)能够果断地拒绝你的请求之前,我们无法完全依赖它们。ChatGPT、Copilot 和类似工具的最大缺点是,它们总是给你一些回报,总是提供某种答案,很少质疑你的原始请求。

      这是坏消息吗?这意味着那些过于自负地认为自己“伟大”的点子(却缺乏该领域深厚知识)并希望拥有“顺从”下属的经理们,将面临一场不愉快的惊喜。 :-)

  19. >无代码/低代码革命

    可视化编程(无代码/低代码)工具在多个领域取得了巨大成功,例如动画、信号处理、数据处理等。但它们并未在通用编程领域取得成功,我认为未来也不会成功。关于这个永恒的HN话题,更多内容请见:

    https://successfulsoftware.net/2024/01/16/visual-vs-text-bas

    1. 虚幻蓝图是图形抽象的成功案例,特别适用于设计师与开发者的协作流程。

      我认为这些工具比你的观点更具说服力。

      1. 虚幻蓝图在其设计领域非常成功。但它并非用于通用编程。没有人会用虚幻蓝图编写银行系统,它也不会取代C++、Java或JavaScript。

        1. 作为反例,你可以用蓝图快速搭建一个用户界面并制作一个支持网页的桌面应用,

          但这与主题无关。

  20. 人工智能是技术债务银行中的一条无限信用额度。

  21. 本文中破折号的数量颇具深意……

    我同意这个想法的核心,我也写过相关文章(https://www.linkedin.com/posts/brunocborges_ai-wont-eliminat…)。

    1. 这读起来非常像对 AI 的正面吹捧。

      作者只是让 GPT 回答“为什么 AI 不能取代我的工作”。

      内容太少。这简直是一团糟。

      *我指的是整个第一部分是我见过最像人工智能的东西,就连试图营造的有力开头也显得过于明显:

      高管们兴奋不已。顾问们如鲨鱼般盘旋。幻灯片成倍增加。预算发生变化。

      然后现实逐渐显现。

  22. 第一个列出的迭代版本太晚了,那么关于“通用商业导向语言”呢?

    此外,某物是负债与某物有维护成本并非同一回事。

    1. > 某物是负债与某物有维护成本并非同一回事。

      那么你对“负债”的定义是什么?“持续承诺支付未来成本”是一个不错的定义。

  23. 我认为这些是值得未来考虑的关键想法:

    [预] > 代码不是资产,而是负债。

    > 每行代码都必须维护、调试、保障安全,最终被替换。真正的资产是代码所赋能的业务能力。

    > 能够生存并发展的技能不是编写代码,而是架构系统。而这是人工智能无法做到的。[/预]

    1. 代码是资产。创建“代码”需要大量资金。

      这就像说作为一家配送公司,你的运输车队不是资产而是负债,这毫无意义。

      几乎所有资产都需要不同程度的维护。

      1. 我设想一家工厂,里面有装满极具腐蚀性和毒性化学品的巨型容器,这些化学品可能对特定化学反应非常有用。

        这些容器的默认初始状态是负债。它们今天可能是资产,但维持这种条件状态需要持续的工作。

    2. 问题是,随着计算成本下降和人工智能能力的提升,成群的编码代理可以对每行代码进行优化,寻找更干净的实现方式,并进行测试,全天候运作。当前的模型常常产生一团糟的代码。但认为这种情况将永远存在是一个大胆的假设。

      编程领域存在大量不可动摇的传统观念,而这场辩论总会触及这些禁忌。但我记得类似的论调曾针对Go语言及其所谓的人类独特性提出过。当时我们已看到,当人工智能真正到来时,这些传统观念并不会长久存在。

      1. 我认为将Go与系统开发进行比较并不实用,Go有一个非常明确的目标需要实现,它可以轻松地通过迭代来实现这一单一目标。开发系统是一项复杂得多的任务,甚至定义目标都涉及大量人类主观性。在方法论、流程、工具等方面,有大量尝试试图定义软件开发目标,但迄今为止,还没有任何方法足够好到能够自动化这个过程。

        人工智能可能有一天会足够强大,以帮助人类完成软件开发中的某些任务,但用下围棋作为类比并不合适。

        1. 如果你重新阅读我的评论,你会发现我比较的是人类玩家/开发者特有的某种东西。

      2. 我不知道,经过近70年的软件行业,我们仍然无法拥有不受供应链攻击影响的软件包仓库。

        尽管SQL存在诸多缺陷,但它尚未被取代。HTML依然是王者。

        1. C/C++依然是每个操作系统和编程生态系统的核心。

      3. 为什么用粗体?因为对未来预测过于自信。

  24. > 系统管理员并未消失,他们只是以DevOps工程师的身份重生,拥有了更炫酷的头衔和大幅提升的薪资待遇。

    天啊,我感觉自己像是唯一注意到这一点的人。人们会说“DevOps能编程”,仿佛这让DevOps成了新鲜事物,但能够自动化任何事情,本就是90年代至21世纪初SAGE风格系统管理员的核心原则。

  25. 我同意文章中的一些观点。我同意代码是一种与代码所属资产不同的负债。这就像汽车的轮胎,它们是负债,而汽车可以被视为资产。

    但人工智能可以进行一些架构设计。只是,一个不具备高超大语言模型(LLM)技能的人,并不可能设计出一个能做任何有用事情的分布式系统。

    在我看来,人工智能的净效果将是提高开发人员的产出,而不会增加每个开发人员的成本。实际上,这将使软件开发成本降低。我猜可能存在某种软件需求峰值,未来可能需要更少开发者来满足,但通常而言,当某物变得更便宜时,对其需求往往会增加。

    我认为关于我们消亡的传言被夸大了。

  26. 我认为我们应关注更早的案例:COBOL。

    这是非开发人员对需要向昂贵的程序员详细说明业务细节的回应,我们假设这些程序员无论如何都会更改这些细节并自行编造数据!

    这同样毫无作用,尽管如作者所言,它确实创造了大量就业机会!

  27. 我强烈同意架构部分的观点。

    看到分布式“单体架构”与实际单体架构之间的复杂性差异,让我怀疑我们中的一些人对服务客户的认真程度。构建一个Rails或PHP应用的速度,让自2016年以来提出的许多方案从商业角度看显得有些多余。许多SaaS B2B产品可以被重构为一个PowerShell/Bash脚本。

    要引导团队远离那些闪闪发光的干扰,需要非常坚定的态度。卑躬屈膝的人工智能装置绝对无法承担这个角色。我确信大语言模型(LLMs)正在引导开发人员走向更复杂的道路,因为我必须不断提醒他们“不要使用第三方依赖项”和“先用伪代码进行演示”,以避免被 npm Narnia 吸走。

  28. 我观察到的一点是,我的公司现在在所有“自建 vs 购买”决策中都强烈倾向于“自建”。而这并非一家科技公司。是的,AI并非魔法,我每天工作10小时就是因为这个原因,即使有AI的非同小可的帮助。

    1. >我观察到的一点是,我的公司现在在所有“自建 vs 采购”的决策中都倾向于“自建”。

      这很有趣,我记得上世纪九十年代曾与一家大型美国银行的CTO交谈,他告诉我恰恰相反。他们更倾向于采购而非自建。

      1. 注意这个限定词:现在。由于人工智能,我的公司更倾向于自建,且对自建的风险承受度更高。

  29. >这是系统架构设计。而这是人工智能目前无法做到的一点。

    没有人知道未来会是什么样子,但我会稍微修改这句话:

    “这是系统架构设计。而这是人工智能目前还无法做到的事情。“

  30. 我非常喜欢这篇文章,这是我听过的关于”为什么我不应该对工程职业的未来感到恐慌”的最有力论据。

    现在,仅仅为了好玩,我将尝试构思我能想到的最有力反驳:

    这篇博客忽略了人工智能与软件开发中其他技术之间的关键区别。人工智能不仅仅擅长编写代码,它擅长思考。它不会仅仅自动化软件开发,而是会自动化知识工作。在一个人类大脑在决策的各个领域都比机器逊色的世界里,你作为人类将无立锥之地。

  31. 我认为薪资上涨的说法并不成立。初期掌握新技术的人本就稀少。你所看到的只是经典供需规律的体现。过段时间情况会再次趋于平稳。

    我认为更恰当的类比是杰文斯悖论。新技术使开发者更高效,从而降低成本。但需求增长幅度将超过效率提升带来的收益。

    我认为短期内不会出现值得自动化的事情耗尽的情况,尤其是如果相关成本继续下降的话。

  32. 阅读这篇文章,然后将其与丹尼尔·科科塔约洛(Daniel Kokotajlo)四年前发表的《2026年会是怎样的》进行比较。

    这次真的不同了,我们正面临一个充斥着海量数据的世界。这将不仅仅是劳动力市场的简单重组,而是具有深远影响且可能极为严峻的变革。

    https://www.lesswrong.com/posts/6Xgy6CAf2jqHhynHL/what-2026-

  33. 在我公司,他们正在加倍下注。强迫我们使用人工智能,产品经理和高管突然扮演起架构师和高级开发者的角色,试图挤占开发者/架构师的职责。也就是说,他们试图夺走开发者本应在人工智能工具实现目标后获得的更多时间。更甚者,他们正在进行外包。

    这使得他们的目的非常明显,他们想摆脱(昂贵的)开发人员,而不是释放我们的时间,让我们能够从事更高层次的工作。

    1. 如果事情像你所说的那样迅速恶化,那么你没有时间抱怨。你需要领先于这个人工智能怪兽。忽视它将自食其果。掌握它需要时间。如果你被当前的工作解雇,你将需要强大的人工智能技能来获得下一个职位。

  34. >>> 那些认为“人工智能将取代开发者”的人根本误解了这一点:代码不是资产——它是负债。每一行代码都需要维护、调试、保障安全,最终被替换。真正的资产是代码所赋能的业务能力。

    这本身就能解释这个循环。动态方程往往会振荡。任何暂时加速代码生产的行为,都会在未来带来维护成本。

  35. 那么,所有这些回应和文章本身似乎在回避什么?问题不在于它让开发者变得多余,而是加剧了不平等。换句话说,要么因为缺乏某种新技能而产生劣质开发者群体,要么在离岸外包的情况下,直接产生低端开发者群体。

  36. 用“编程作为理论构建”的语言来说,人工智能产生的产物是死胎。没有人拥有或拥有与它们相对应的理论。软件开发人员可以阅读输出结果并进行开发,但这样你就又在做实际的软件开发了。

    这就是为什么大语言模型(LLMs)不会取代开发人员。

  37. 文章顶部的图片似乎是一幅糟糕的(我假设是AI生成的)Gartner技术成熟度曲线示意图。理论上应有五个阶段,但底部文字与图表不匹配,因为缺少“过高期望的峰值”阶段,而图表似乎也缺少“生产力高原”阶段。

    1. 令人遗憾的是,这种误导性表述可能会随着时间推移逐渐成为新的“真相”。

  38. 有趣的是,没有人指出图表有误。启蒙与幻灭的标签被互换了。

  39. 我足够年长,记得当年人们曾认为无需再雇佣昂贵的开发人员,因为面向对象编程将使半熟练员工能够用标准化组件组装软件。他们甚至谈论过即将到来的“软件工厂”。

    1. JavaScript生态系统相当庞大,确实提供了海量的“标准化组件”库。某种程度上,这个梦想已然实现。一个半熟练的人可以在很短的时间内构建简单的应用程序。在早期,这是不可能的。

      然而,如果工具提高了 10 倍,那么产品的复杂性就提高了 100 倍。如今,你可以使用大语言模型 (LLM) 一次性完成一个俄罗斯方块游戏。在过去,这需要数周甚至数月的时间。但现在,没有人会对俄罗斯方块级别的游戏感到印象深刻。

      1. 然而,没有任何大语言模型(LLM)能够一次性创建一个基于章节级别的自动缩进的简单标记查看器。我尝试过。

  40. 为了让“氛围编码”取代软件工程,“氛围编码”必须成为……软件工程。

  41. > 代码并非资产——它是负债。每一行代码都必须维护、调试、保障安全,最终被替换。真正的资产是代码所赋能的业务能力。

    这是贯穿整个软件工程职业生涯的必备原则。

  42. 我认为,随着程序员的生产力提高,对程序员的需求也会增加,但只是最初阶段。然而,如果生产力提高得太快,编程自动化程度太高,那么对程序员的需求就会迅速下降。这是非线性的。

  43. 文章中提到大语言模型(LLMs)在架构方面表现欠佳,这与我在代码中使用它们的主要规则相一致: 不要让它们设计数据结构或函数签名。它们可以在适当的时候填充这些内容,但我不会让LL定义它们。(结构体、枚举、函数签名等)

  44. 有趣的是,那些一再拯救开发者,尤其是昂贵的美国/加州开发者的东西,正是他们倾向于讨厌的——会议、撰写文字和客户服务。

    编写代码几乎应该是在深入理解问题并进行迭代之后的次要考虑。

  45. 我喜欢现在能立即判断出某段代码是否由GPT-4o生成的能力。

    >实际发生的变化并非替换,而是转化。

    “陈述——/,否定”模式是我目前所知最明显的ChatGPT特征。

    1. 我认为ChatGPT学会这种句式是因为许多人类评论员/“思想领袖”都这样写作。当然,无论这种句式来自人类还是ChatGPT,其价值大致相当……

      1. 对我来说这太老套了,付出太多努力却回报甚微。我感觉它因这种“聪明”而受到奖励,但这种聪明是RLHF用户所感知到的。

  46. AI在帮助你学习架构方面做得相当不错。

  47. >这是在设计系统。而这是AI无法做到的一件事。

    结论太弱,因为AI已经做得相当好了。

  48. >代码不是资产——它是负债。

    告诉可口可乐吧,他们的最有价值资产就是一个算法

  49. 开发者相关性的神话

    在借钱不再免费(非零利率)的时代,它还能持续吗?

  50. 天啊!我们欧洲人真希望这种双倍薪资的场景也能在这里实现。

    1. 你试过拥有枪支却没有医疗保障吗?

      1. 我明白你的意思,但你这样表述听起来像是更糟糕的结果

  51. > “对于代理公司搭建一次性营销网站的工作,这无关紧要”

    对营销网站的轻蔑态度仍在继续。我认为呈现在客户面前的东西绝非“一次性”!当客户想修改他们的账户时,他们可能会通过熟悉的“营销网站”进入。或者当潜在客户和产品用户在权衡你的支付计划时,这些都不是小事!你真的会在客户掏出信用卡的时刻信任Sloppy Jo的AI吗?这是UX的“关键时刻”。“一次性”?“无关紧要”?呸!

    1. 我的意思是……我曾作为负责“安装”网站的一方,经历过由代理机构打造的网站,而“一次性”确实是个恰当的描述。其中一些网站无需维护,因此在开发时缺乏细致打磨和文档记录,由薪资低、人员流动率高的团队完成,随后交由客户使用,且预期几年后会重新开发。

      我认为“一次性”在这里并非作为贬义形容词使用。它们确实重要,但确实是以一种特殊方式构建的。

  52. 作者似乎忽略了代码成为负债并未影响那些不在乎的人编写代码的数量。

    就在Capgemini顾问发布关于如何使用AI编写代码的教程同一天,我从一位项目经理处得知,他们让AI编写代码,再由人类项目团队审核——因为这样做要容易得多。

    我预计大多数外包业务将走向消亡,因为向AI解释需求可能更容易,且响应时间也快得多。

  53. >软件领域最宝贵的技能不是编写代码,而是架构系统。

    我一直强调——人工智能是砖块制造者,而你负责建造房屋。决定建造这座房屋的正是你,它只需要将砖块放置在正确的位置……

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注