编者按：我们正经历一场堪称“AI 版工业革命”的浪潮。各种新工具、新模型层出不穷，更新速度快到让人眼花缭乱——昨天刚推出的框架，今天可能就被新一代模型取代。表面上看，这是一片繁荣景象，但对开发者来说，这场盛宴背后隐藏着焦虑与迷惘。过去，程序员精通一个技术栈，就能吃好几年饭。而现在，AI 工具的进化速度远远超过人的学习速度。昨天还在研究 Prompt Engineering 的最佳实践，今天就被一个懂语义、能自我优化的新模型拍在沙滩上。当 AI 能自动生成、优化甚至自测代码时，一个尴尬的问题浮出水面：人类开发者的价值是什么？这篇博客的作者 Paul Payne 是一位具有 30 年编程经验的西雅图资深工程师，他目前是微软 CTO 领导下的一名首席研究员。他当前的工作是通过系统和认知架构增强生成模型，构建人工智能系统。Paul Payne 和他的团队探索如何利用大语言模型将其效用拓展至更广泛的应用场景，致力于构建功能性原型，并在微软内部、学术界及更广泛的行业中分享我们的研究成果。他们的成果已逐步应用于 Semantic Kernel、Microsoft Teams 和 Bing 等产品，并被全球多个研究团队所采用。Paul Payne 于 2023 年创立了西雅图人工智能协会，除了专业交流和创意项目合作之外，他和团队每周还会从各个角度讨论人工智能对社会的影响。在这篇博客中，Paul Payne 描绘了一幅 AI 正在颠覆软件工程领域的未来图景。他坦言自己正经历一场“存在主义危机”。但事情总有好的一面，我们或许不必将未来视为程序员的“谢幕”。正如作者团队的工作所展现出来的那样，AI 虽然强大并且高效，但仍然需要人类工程师来引导、设计和赋予其方向。当 AI 接管了代码实现的“执行层”，未来的程序员可能不再需要亲手敲击每一行代码，但人类工程师的价值也将得以向更高层次升华：他们将有被彻底从底层代码中解放出来，有更多精力去定义更复杂的问题、去进行跨领域的伦理权衡、去理解并塑造技术与社会的关系。以下为作者博客原文，经由 InfoQ 翻译及整理。
好的，我正式宣布。我整整 30 年的编程生涯，已经成为了一件历史文物。
我目前从事的 AI 工作让我确信，在短短几年内，人类回顾过去时，会觉得人们曾经真的需要亲手编程机器这件事非常可笑。
我 8 岁就开始编程了，那时我埋头苦读一本 Commodore 64 用户手册，并照着杂志后面的代码敲打。从那以后，我的学习就从未停止。编程不是你学几年就能完全掌握的东西。在过去的 40 年里，我一直身处全行业持续不断的技术演进洪流中。
当我们招聘程序员时，我们看重的一些主要品质是适应性、自主学习和批判性思维能力。要保持站在技术前沿需要持续不断的努力。
编程从根本上需要一种对机械的共鸣。你需要理解机器是如何工作的——存储、内存、处理、接口。在这个基础之上，你学习语言和工具集的语义——到底是哪些字符的神奇组合能被系统实际执行。再往上，是大型程序的抽象，然后是程序系统，再是计算机系统。程序员的大部分工作是管理复杂性，因此学习和开发应对复杂性的技术至关重要。
经验更丰富的开发者会拥抱各种抽象概念，比如数据结构和算法、配置与状态、封装、函数式与对象组合、实体与数据、事件与快照、顺序与递归，这真是永无止境。所有这一切，都伴随着持续不断的新产品发布，每周都在重构你的工具箱。
还有那些权衡取舍！所有的编程（就像所有的工程一样）都关乎权衡。你可以用处理能力换取内存，用时间换取完整性，用可靠性换取成本，用可维护性换取速度；调整上百个变量来打造出符合你需求的程序。
程序并非存在于真空中。程序旨在解决真实人群的真实问题，并以能转化为实际产品和服务的方式呈现。程序员必须懂得如何定义问题，识别用户需求，并以可理解、令人满意的方式满足它们，确保他们构建的系统是可行的，并且能够创造可行的业务。程序员编写与用户交互的程序，因此我们始终处于心理学、社会学以及它们与我们构建的技术相互影响的前沿。
一个程序员在几十年里学会的，是思考本身是如何运作的。如果你试图将问题空间中的推理分解成一系列步骤，或者将其拆分以便不同部分能协同工作，或者想弄清楚哪些事物会随着时间演变，那么房间里真的应该有一位程序员。
这就是为什么编程，作为一门学科，在过去的半个世纪里已经渗透到了几乎每一个科学领域。程序员是设计者、架构师和建造者，他们在所有领域都为解决问题注入了超强动力。
三年前，我结束了几位高级工程师职位的候选人面试。在面试流程中，发现一些人——无论出于何种原因——就是没有掌握在编程工作中取得成功所需的基本编程技能，这种情况并不少见。根据工作和候选人的具体情况，如果他们拥有强大的批判性思维或解决问题的能力，我们或许会稍微放宽要求，但发现这种情况仍然有点令人震惊。
在一连串的候选人失败后，我颓然倒在办公椅上，感叹道：“为什么这些候选人在用编程解决这个基础问题时都这么吃力！？”
我的同事觉得好笑，问道：“是什么问题？”我便向他描述了这个问题。“好吧，”他说，“……那么一个令人满意的解决方案应该以什么形式呈现呢？” 我转过身，意识到他并不是真的要帮我提高面试技巧，他正在把我们刚获得早期访问权限的 OpenAI GPT3-Davinci playground 中输入这个问题。敲了几下键盘后，他提交了问题，然后完美无缺的 Python 答案就跳了出来。我看了看，它正确且高效。
我惊呆了。
于是，我让他用另一种编程语言来解决。它做到了。
然后我让他用不同的编程范式来解决。它也做到了。
接着，它不再等我们要求更多变体，而是开始自动打印出一系列其他语言的解决方案。
从那天起，我们在微软的小团队就开始研究由 LLM 驱动的系统。起初我相信，正如业界在接下来两年里逐渐意识到的那样，单凭这项技术就足以在计算机技术触及的几乎每个领域提高生产力。但我也相信，要让这些系统能够解决不仅仅是玩具问题，还需要很长很长的时间。程序员日常使用的技能，对于一个文本补全神经网络功能来说，期望值实在是太高了。
我们一个接一个地解决问题。首先，它们的记忆窗口非常短，有点像注意力持续时间，于是我们开发了应对的技术。然后，我们将系统连接到其他工具，赋予它们除了写文本之外的更多能力。接着，我们着手让这些系统能够处理更长的连续操作链。下一步，我们研究如何将更大的任务分解成更小的任务，并且仍然能取得进展。然后，我们研究技术让它们的结果更可衡量、更可靠。最终，我们致力于让它们更具自省能力，能够根据实时表现进行自我调整。
在我们的研究过程中，模型的能力变得越来越强，生态系统也在不断发展。一步步地，我们的系统从我们程序员手中接走了越来越多的工作。
今年春天，Anthropic 发布了 Claude Code，它包含了一些关键要素，真正让我们的系统进入了超速运转状态。
首先，它可以直接通过命令行与你的计算机交互，而不是像 ChatGPT 或 API 那样被困在网页应用中。其次，他们以优雅的方式整合了一些众所周知的模式——任务分解、任务委派和工具调用（如网络获取和文件搜索）——这使得系统能够以可靠的方式编排一系列任务。
今年我们一直在使用 Claude Code 这类工具，并且不断提升我们 AI 系统的能力，以承担更大型的任务，具有更高的可靠性，运行更长时间。而所有这些，都没有让我觉得编程本身会变成历史文物。
我们一直在将我们各种技术和实验打包整合到 Claude Code 之上，有点把它当作一个快速实验平台。我们能够将许多来之不易的发现快速集成进去。我们在 https://github.com/microsoft/amplifier 发布了一个早期原型，并将在接下来一两周内发布一个较新的版本，该版本是模型无关的（不运行在 Claude Code 上）。
这还不是那个能取代我作为程序员的东西，但它让我确信，我们的时间线是以月为单位，而不是以年为单位。它已经完成了困难的部分。
有了 Amplifier，你现在可以描述你想要什么，它就会为你构建出来，从设计到后端，再到前端，包括测试，并且遵循你自己的编程理念。
但这还不是重点。重点是你用得越多，它就变得越好。随着时间的推移，你会创建可重用的工具，它能捕捉有用的技术。它会从你对它的使用中学习，建议改进自身的方法。这是一种指数级的生产力，你构建的东西能帮助你更快地制造东西。
在过去的一周里，我使用 Amplifier 检查了两个独立的代码库，提取了我在其中一个代码库中正在开发的功能集，提出了三种可能将相同想法集成到另一个代码库的方式，并行实现了每一种方式，然后为我提供了一份关于哪些可行、哪些不可行的总结。我还用它来处理一组我一直在编写的大量 bash 脚本，将它们转换成了一个 Web 服务 API、一个 Golang 命令行界面和一个完整的 Web 应用前端。当然，设置提示词需要时间和程序员知识，但上述每一项任务都只需要向 Amplifier 发出大约三个提示。在每种情况下，Amplifier 都会运行 30 到 120 分钟，然后带着可工作的软件回来，包括文档。
与此同时，我们扩展团队中的其他人用它构建了十几样其他东西，包括新版本的 Amplifier、一个广泛的评估框架，以及两个不同的图形化实验桌面。
最让我印象深刻的是一位设计师，他编程背景有限，设想了一种全新的方法，从期望的设计美学出发，直达完整的设计框架，他借鉴了 Figma 和 Storybook 等其他工具组合中的想法和工作流，创建了一个全新的助手驱动的设计应用程序，我估计这能让他的生产力提升十倍。
上周，我们让 Amplifier 处理一个有趣的项目，用于管理大型互连任务列表，然后它把这个功能集成到了自身之中，允许我的同事整夜持续运行它，自主完成几十项任务，甚至为他准备了一份“晨间报告”，其中包含了各种组件的多种实现方式，以获取他关于下一步该做什么的反馈。
这还不是最终产品，我们（以及整个行业）还有很多工作要做。硬件和软件制造商（驱动程序、核心库、集成）将需要发布产品上下文供 AI 使用。我们将需要继续发展并发布新的系统集成标准。但这是我第一次感觉到，困难的部分已经完成了。从这里开始，机器直接按你的要求做事，而无需程序员从中协调，已是清晰可见的前景。
我上面提到的那个项目，把 bash 脚本变成 Web 应用程序？实际上，整个开发过程都是在一个树莓派微型电脑上运行的。我只需要在上面安装 Amplifier，挂载旧的代码库，然后告诉它去创建所有其他项目。我从未碰过代码，它已经比我花好几周时间自己做出来的要好了。
我计划发布这个项目供他人使用，但你可以想象，使用相同的过程来构建定制的、个性化的软件，甚至无需分发它。我们不再需要下载和安装软件，我们将能够直接告诉机器我们想要什么，它就会创造出来。想修改一些东西？添加新功能？做一个全新的应用程序？只需开口要求。
我上面描述的所有编程技能，我花了一辈子时间掌握的技能，现在都可以通过像 Amplifier 这样的工具，加上恰当的提示词来完成。最后一步就是将所有这些专业知识打包起来，交给 AI，然后任何没有编程经验的人，都将能够根据需要让 AI 构建他们所需的任何软件。
那么现在该怎么办？
我不介意把这描述为一次个人的存在主义危机。我的身份认同中，确实有很大一部分是与“成为一名程序员”紧密相连的。我曾认为找到正确的咒语让机器做出神奇的事情是一种魔法。这是一种职业超能力。
那么，当每个人都能施展魔法时，这意味着什么？我的超能力现在变成了……日常生活？我还能在决策桌上拥有一席之地吗？这对我所追求的价值传承又意味着什么？我们都希望想象我们一生所做的事情能超越我们自身而持续。但现在很清楚，我的职业生涯遗产将会是一种奇特的遗存……就像铁匠，或抄写员，或宫廷弄臣。
但也许这比之前技术驱动的淘汰更奇怪。在以前的所有案例中，变得冗余的人能够将他们领域知识和解决问题的技能提升，应用到新事物上。铁匠建造了铸造厂。抄写员变成了印刷商。弄臣变成了喜剧演员。他们继续解决同样的问题，通常规模更大，使用他们的新工具。
但是，当解决问题本身变得过时时，我们该做什么？就在刚才，我停下来去读了我的同事 Brian Krabach 关于他对此存在主义危机的文章。他六个月前就到了这个阶段，但我当时还不相信他。当然，机器会取代一部分编程工作，但在可预见的未来，我们仍然需要程序员来让机器做到这一点。Amplifier 每天都在明确地证明，我在时间线上错了。
在他的文章中，他描述了他是如何在意识到取代程序员能让他解脱出来，去做他作为程序员一直热爱的事情——更快地解决更大的问题——中找到慰藉的。但我不太确定。识别问题和提出解决方案对我来说似乎一直是比较容易的部分。我在各种创新实验室的经历告诉我，这些事情，也仅仅是可以被自动化的流程而已。
“但是机器无法获取关于需要解决什么问题的数据！它们不知道我们面临什么问题！” 当然——直到我们让它们编写软件来做这件事。
所以，是的。想到真正的问题——尤其是当前最急需的社会层面问题——即将得到解决，确实有相当的慰藉。我无疑会参与到其中许多问题中去。我只是需要努力接受一个事实：我的贡献将不再主要依靠我辛苦获得的编程技能。这些技能很快将触手可及，只要能够购买一些计算资源的人都能拥有。
当 AI 编码工具以其惊人的速度自动生成代码时，一个隐忧也随之浮现：它可能在以更高效的方式，积累更庞大的“技术债”。这些由 AI 生成的代码，或许在当下能勉强运行，但却可能缺乏整体的架构设计、清晰的责任边界与可维护的代码风格，如同一座用速干水泥匆忙砌起的高楼，看似迅速，却暗藏结构风险。
但这也恰恰是彰显人类工程师价值的关键所在。AI 精于“执行”，却疏于“谋划”；长于“实现”，却拙于“洞察”。它无法理解代码背后复杂的业务上下文、难以权衡长远的技术选型、更无法为代码的可维护性与团队协作负责。人类工程师所具备的系统性思维、架构设计能力与对业务深度的理解，是预防和治理技术债的根本。
10个月宝宝每天需要喝多少奶粉？
