人们普遍认为“人工智能不会取代软件工程师”，通常会说“你将被使用人工智能的软件工程师取代”，这意味着人工智能将用于提高软件工程师的生产力和效率。我认为软件工程师将被普通人、非工程师（会计师、律师等）取代，他们有权创建自己的软件来解决自己的问题。
我认为我们还没有接近自动化软件工程。但如果我们根本不需要软件工程师怎么办？
我设想一个世界，人工智能工具和无代码工具使规范能够创建任何人都可以创建的规范软件来解决自己的问题。从某种程度上来说，这种情况已经发生了几十年。但现在可以轻松地制作好的规范软件。
首先，让我们从头开始。
如果你不写代码，你还有价值吗？
有很多工作纪律是编写代码，但不是软件工程师。与我合作的第一个非工程师编码员是一位计算语言学家。他是一名语言学家，绝对不是软件工程师，但他确实写了很多Python。我还与一位游戏艺术家合作过，他显然是一位艺术家，但他的媒介是代码（和视觉设计）。从那以后，我与数十位擅长编写代码但不是软件工程师的专业人士一起工作过。
在亚马逊，我了解到首席软件工程师不编写任何代码的想法。首席工程师会公开感叹他们编写的代码太少，以至于他们可能甚至没有能力编写生产代码。
这让我思考了很多。我一直以编写代码的能力来定义自己。但我是一名高级软件工程师，似乎所有向上的道路都涉及不编写代码。这让我震惊。
今天，我在人工智能编码中看到了类似的现象。各个级别的软件工程师都在努力思考他们的价值是什么。如果不写代码，我们该怎么办？
为什么要聘请软件工程师？
在不直接谈论软件工程师所做的所有事情的情况下，我们首先为什么被雇用？
- 大型项目——我见过商界人士设计出一个解决方案的原型，但最终却达到了进一步开发自己难以完成的地步。软件工程师引入了诸如设计模式和单元测试之类的东西，使项目变得更大。
- 分发——同样，在设计出解决方案原型后，人们如何使用它？例如，Web 应用程序、SharePoint 服务器上的 Excel 电子表格、移动应用程序。
- 规模——有多少用户？任何顶级互联网网站，如谷歌或 Facebook，都已经变得庞大，并且以这种规模运营非常复杂。他们雇佣了大量的软件工程师，并公开宣称他们的成功取决于他们雇佣的工程师的素质。
- 维护——软件工程师了解软件如何生存。一个未受影响的应用程序最终会莫名其妙地崩溃。事实上，一些工程师会吹嘘他们编写的一个软件在生产环境中运行了 20 年没有受到任何影响。这种吹嘘之所以有分量，是因为它很不寻常，大多数软件在没有维护的情况下都会莫名其妙地崩溃。
- 安全——在某些情况下，通常是实时嵌入式设备，人类健康和安全面临风险，需要聘请软件工程师来对质量和完整性负责。
这些事情本质上都与编写代码无关。那么为什么我认为软件工程正在消失呢？
实验：故事模式
假期期间，我编写了一个网络应用程序，我将其命名为“storymode” 。我想让 Claude 写故事并将它们转换成有声读物，以便我的孩子们可以进行多次 10 小时的公路旅行。
问题是：这不是我写的。我给自己定了一条规则，我使用Cursor 的Composer 和新的 代理模式。我不但没有写代码，连代码也没有读过。我盲目地接受了每一个改变，没有经过审查。
它成功了！除了少数例外，我能够编写一个完整的网络应用程序来解决我的问题，并且仅用英语散文来完成。有几次我遇到了厄运循环，不得不手动干预。但随着模型和开发工具变得更加智能，这种情况发生得越来越少。
规范软件：解决你自己的问题
我们显然正处于软件和软件工程的关键时刻。辩论就是我们要去的地方。很难想象软件会在五年内保持不变。我认为软件的生产将走向用户。
为什么？简单的经济学。
我将其称为规范软件，即规范者为解决自己的问题而编写的软件。想想开发工具与提交费用报告所使用的软件的关系有多好。开发工具很好，因为它们是由遇到问题的同一个人开发的。另一方面，在企业软件中，购买者和用户是不同的人；它因难以使用而臭名昭著。
最小化开发者和用户之间的距离。距离越大，就越难走对。
规范软件就是这样，但已达到极限。这是开发人员和用户之间可能的最小距离。对于一切。
混合角色减少沟通开销
如果您观察了软件工程几十年来的发展，您会发现这种模式已经在重复出现。 A 组和b 组具有不同的技能组，并且由于他们沟通不畅而浪费了大量时间和精力，因此我们将创建具有两种技能组的AB 组。
缩短距离可提高效率：
- Dev Ops = 开发 + 运营
- 全栈=前端+后端开发
- 机器学习工程师= 数据科学家 + 工程师
- DataOps = 数据工程师 + 运营
- DevSecOps = 开发 + 安全 + 运营
- 技术布道者= 开发人员 + 营销人员
- 法律技术专家=律师+软件开发人员
- 游戏美术师=游戏开发者+美术师
- 计算语言学家=语言学家+开发人员
- 生物信息工程师=生物学家+数据科学家
随着时间的推移，这个列表会变得越来越长，因为人们希望减少通信开销。是的，沟通固然好，但更好的是不需要沟通。能够在两个领域进行清晰思考的人比两个无法沟通的人有用得多。
明显的缺点是，这些混合角色往往不太精通任何一个预先组合的角色，但无论如何，企业更喜欢它们，因为它们以更高的速度交付正确的东西。
规模的诅咒（规范软件解决的问题）
我最热门的观点是，产品经理既不属于A 类，也不属于 B 类。也许他们一开始是一名软件工程师，但当他们成为产品经理时，他们就被禁止编写软件。或者也许他们是一位主题专家，但当他们成为产品经理时，他们被禁止继续实践他们的专业知识，因此技能萎缩。
最糟糕的是，产品经理在高层管理人员的推动下提出伟大的想法，将产品推向市场领导者的地位。但在追求伟大创意的过程中，他们脱离了最初的使命。
这是规模的产物。
当软件成为产品时，它需要用户。在成为产品之前，它只有用户。随着它继续作为一种产品存在，它需要用户的增长。为了实现增长，它需要迎合新的用户群体，而在这个过程中，它迎合的原始用户会减少，因为很难服务于多样化的用户群。
科里·多克托罗（Cory Doctorow）的enshittification是这种效应的一个特例，它解决了双边市场在规模扩大时所发生的情况。
规模总是会带来问题。在分布式系统中， 蜂窝架构的创建是为了人为地减少流量规模。 AWS 的工程师意识到随着规模的增加，新的问题总是会不断出现，因此创建了该架构。
与蜂窝架构类似，规范软件限制了规模，这使得新解决方案的出现和发展变得更加简单。
规范软件不需要软件工程师
规范软件本质上更小、更简单，因此可以很大程度上避免规模带来的开销。
- 小项目——他们一次只解决一个问题，当问题变得复杂时就重写。
- 分发——几乎没有分发基础设施，例如，他们可能在笔记本电脑上运行网络应用程序或使用无代码平台。
- 小规模——他们为朋友或直接团队制作。
- 维护——仍然需要维护，但维护规模很小，因此人工智能工具是一个可行的选择。
规范软件不需要软件工程师。人工智能开发工具可能足以让普通人解决自己的问题并维护自己的解决方案。在故事模式之后，我确信了这一点。
规范软件开发工具
规范使用什么类型的软件来创建规范软件？
- MS Excel — 经典的标准软件。多年来，会计师和商界人士一直在创建电子表格来解决自己的问题。用户界面不太好，所以我认为这将逐渐被其他选项取代
- Cursor & Windsurf — 具有强大 AI 支持的代码编辑器。开始的时候比较困难，但你能做的事情几乎没有上限。
- UIPath和 RPA 软件— 这些工具可让您直接在计算机上自动化鼠标驱动的点击工作流程。据我所知，UIPath 正在大力投资人工智能和计算机视觉。 Claude 的计算机使用工具将给 UIPath 带来激烈的竞争，并且很快就会出现许多其他选择。
- 自定义 GPT和MS Copilot — 将数据源集成到工作流程中的好方法。这些是必不可少的无代码人工智能工具，可以让您的数据对其他人非常有用。
这不一定是要复制软件工程师所做的事情，而只是解决您自己的问题。
规范软件将占据主导地位
我在这里的热门观点并不是企业希望他们的研究人员、会计师、律师等解决他们自己的问题。企业一直希望如此。我可以说出我工作过的超过 5 个团队的名字，这些团队都是由规范者和电子表格制作的原型启动的。到目前为止，规范软件只是合理化了增加软件工程投资的需要。
最热门的观点是，规范软件可以由规范人员开发和维护。
在制作故事模式时，我突然意识到任何人都可以做到这一点。他们不这样做的主要原因是因为他们不知道自己可以。这只是一个教育问题。
软件工程师仍然有工作
我确实认为软件工程师能够渡过难关。
- 社会变革是缓慢的，你有很多年的时间来重新定义自己
- 规范软件并不总是合适的，例如当健康和安全面临风险时
- 现有软件始终需要维护（例如，目前仍有 800B 行 COBOL 仍在使用）。
- 规范软件依赖于非规范软件平台，如 Cursor 或 MS Excel
但无论如何，你都需要扩展自己。
传统上，软件工程师组成一个紧密结合的小组，并与其他业务部门隔离。我们有足够的行话和内部笑话，可以维持我们自己的平行文化。这种情况不太可能持续下去。
与销售人员交朋友，通常会拓展业务。