Simon Willison 引用 D. Richard Hipp，SQL 类比挑战 AI 岗位预测

Simon Willison 于 7 月 29 日强调了 D. Richard Hipp 的 SQL 类比，以一段历史经验直接挑战了 AI 将淘汰程序员的预测。Hipp 的论点始于更早的一次劳动变迁。SQL 自动化了原本需要通过定制数据处理程序完成的工作，但编程并未消失，反而扩展为不同的形式。

这篇文章很短，但发布时间颇具意义。AI 编程系统如今能够生成函数、测试、查询、文档，有时还能协同修改整个代码库。这种进展催生了一种更激进的说法：一旦人们可以用自然语言描述软件，组织对程序员的需求将大幅减少。

Hipp 提供了一个不那么戏剧化的模型。新的抽象降低了表达某些指令的成本，随后将人的精力转向规格定义、验证、架构和维护。SQL 没有终结编程。它改变了哪些问题值得编写定制代码，以及哪些问题可以交给数据库引擎处理。

这一类比并不能证明 AI 会走上同样的路径。大语言模型产生的是概率性输出，而数据库则按照既定规则执行 SQL。但这一比较依然为评估软件职业相关主张提供了有用的检验标准：一种工具是在消除工程工作，还是在将其转移到另一个层面？

Simon Willison 将一句引言转化为劳动力市场论点

这则新闻并不是关于新的 SQLite 功能或 AI 产品，而是为评估自动化论断提供了一个更清晰的历史框架。

在其 7 月 29 日的文章中，Simon Willison 引用了 D. Richard Hipp 对数据工作如何因 SQL 的出现而改变的描述。在 SQL 出现之前，组织往往需要雇佣程序员编写过程式软件，用于搜索、连接、筛选和汇总大型数据集。

Hipp 将这些工作者概括为 COBOL 程序员，尽管这一说法有所简化。SQL 让用户能够通过简洁的查询指定所需结果。随后，数据库引擎会生成或选择过去包含在定制程序中的大部分执行逻辑。

Hipp 类比中的关键表述是：程序员并没有消失，他们的工作发生了变化。

这一区分听起来并不起眼，却触及当前 AI 劳动力预测背后最重要的一个假设。许多预测将代码产出视为编程劳动的定义性单位。按照这种推理，如果软件能够产出代码，过去输入代码的工作者就不再必要。

SQL 表明，代码量与工程价值并不是一回事。一条声明式查询可以替代许多行过程式数据处理代码。但仍然需要有人定义数据、决定结果的含义、管理权限、测试边界情况、监控性能，并在需求冲突时作出回应。

声明式编程指的是指定系统应产生的结果，而不逐一说明每个执行步骤。SQL 成为最具代表性的例子，是因为用户只需说明希望获得什么数据。查询规划器会决定数据库应如何检索这些数据。

Hipp 过去也强调过这一区别。在一篇数据库人物专访中，他认为许多开发者低估了声明式语言能够节省多少工作。他提到，一些应用代码会手动执行本可由数据库处理的连接操作。

这一观察与 AI 编程直接相关。开发者如今可以要求助手实现某项功能，而无需手动输入每一条语句。这样的请求压缩了可见的工作量，正如 SQL 查询压缩了过程式数据操作。

这种压缩是真实的。责任并未因此消失。

SQL 用户仍需对请求正确结果负责。使用 AI 辅助的开发者仍需判断生成的软件是否符合预期行为。在这两种情况下，接口都向上抽象，但重要决策仍由人作出。

Willison 的选择赋予 Hipp 的类比更广泛的意义。它将一段关于 SQL 历史的评论，转化为对“自然语言编程必然创造无程序员未来”这一观点的回应。

这篇文章也避开了一种简单的反 AI 结论。Hipp 并不是说自动化一无所获。SQL 显然消除了手动编写某些程序的需要。这个类比承认生产率会显著提高，同时拒绝将生产率直接等同于职业消亡。

这正是这一事件的核心张力。同一段历史可以支持两种解读。自动化会消除特定任务，但也会让软件开发成本足够低，从而产生更多软件需求。

SQL 改变了工作单元

SQL 并未保留所有编程任务。它让许多这类任务在经济上变得不再必要，并将注意力转向更高层次的决策。

在关系型数据库和被广泛采用的查询语言出现之前，从业务数据中提取一个新的答案可能需要专门编写一套程序。程序员需要理解记录布局、访问路径、排序例程、文件格式和报表需求。

对问题的一项小改动，就可能需要另写一个程序，或对现有程序进行实质性修改。组织购买的是一套过程，而不只是一个结果。

SQL 改变了这种安排。用户可以使用选择、连接、分组和排序来描述结果。数据库将该请求转换为执行计划，也就是用于返回所请求数据的一组操作。

正如 Hipp 通过引言的表述所承认的那样，他的类比压缩了漫长的技术历史。SQL 出现后，COBOL 并没有消失。COBOL 系统仍持续运行于薪资、银行、保险、政府和事务处理工作负载中。

重要的变化更为具体。对于每一个能够通过关系型查询表达的常规问题，组织不再需要编写新的过程式程序。

这是一种在任务层面上具有实质意义的岗位替代。工具能够消除大量专业实现工时，而不必消除包含这些任务的职业。

AI 讨论中经常忽略工作与任务之间的区别。一个岗位是由活动、责任、领域知识、沟通与决策组成的集合。自动化很少会以同样的速度覆盖这个集合中的每一部分。

SQL 自动化了查询执行，却创造了对数据库管理、模式设计、查询优化、数据建模、分析、安全和应用集成的需求。它也让更多团队能够实际使用数据访问能力。

Hipp 曾通过三个概念描述 SQL 的持久价值：事务、数据抽象和声明式语言。在 2024 年的一次 SQLite 访谈中，他表示，关系模型仍然能够有效地表示许多现实世界问题。

事务确保相关数据库操作在受控的一致性规则下完成。数据抽象将逻辑请求与物理存储细节分离。声明式语言让用户能够专注于想要的答案。

这些能力结合在一起，带来的不只是节省按键次数。它们还在应用程序员、数据库引擎、数据库专家和业务用户之间重新分配了专业能力。

AI 编程助手正开始带来类似的重新分配，尽管其机制不同。它们能够将意图转化为代码、搜索陌生代码库、提出测试建议、解释遗留函数，并生成迁移或文档的初稿。

随着这些能力提高，团队将减少编写常规实现代码的时间。这一结果不应被淡化。一些初级任务、维护工作和外包编码工作将面临直接压力。

然而，节省下来的工作量并不能说明总就业会如何变化。当预期产出总量保持不变时，较低的生产成本可能减少劳动力需求；当更便宜的生产方式解锁更多项目时，它们也可能增加劳动力需求。

软件很少像一个固定市场。团队会维护长长的待办清单、推迟内部工具开发、容忍手工流程，并延后集成工作，因为工程能力有限。如果 AI 降低了这些项目的成本，组织就可以开发更多此类项目。

因此，SQL 的先例同时呈现三种效应：

• 替代：系统执行过去分配给程序员的工作。

• 扩张：更低的成本使额外的软件和数据工作在经济上变得值得。

• 重组：剩余岗位更加重视判断、设计、审查和领域知识。

这些效应不会在每家公司以相同方式取得平衡。产品稳定且路线图固定的企业可能利用 AI 减少招聘。成长中的企业则可能维持现有人员规模，同时发布更多功能。小型组织可能开始开发过去无力承担的软件。

这种差异正是有关“程序员”的笼统论断站不住脚的原因。自动化作用于特定组织中的特定任务。其就业影响取决于需求、预算、风险以及新增工作的数量。

真正的对立是任务自动化与岗位消除

Hipp 的主要挑战并非针对 AI 编程工具，而是针对“自动化生成代码就会消除整个工程角色”这一假设。

一个生成的函数看起来像是已经完成的工作。它很快就能出现，在有利情况下可以编译，也可能通过提供给模型的测试。这种可见产出会促使人们将实现等同于完整的软件生命周期。

生产环境中的工程工作远不止这些。必须有人将模糊的请求转化为精确的行为。这个人必须解决利益相关者之间的冲突，识别缺失需求，选择系统边界，保护数据，并决定哪些故障可以接受。

团队还必须在原始上下文发生变化后维护结果。依赖项会更新。法规会变化。用户会发现意料之外的工作流。攻击者会寻找弱点。数据量会增长到超出第一版设计假设的程度。

AI 可以协助每一项活动，但协助并不会自动转移责任。当生成的代码引发安全事件时，客户和监管机构不会把模型视为责任运营方。

SQL 的比较让这条边界更容易看清。数据库引擎可以选择执行计划，但它不会决定一个查询是否回答了正确的业务问题。它也无法判断一个技术上有效的连接是否会产生误导性指标。

同样，AI 助手可以生成实现，却不知道规格是否反映了组织的真实需求。实现越自动化，规格质量就越决定结果。

这带来了一个重要的反转。自然语言看起来比代码更容易，但日常语言容忍的模糊性，是软件无法安全忽略的。

“添加自动税务处理”听起来很清楚，直到系统必须处理司法辖区、豁免、退款、舍入规则、生效日期和不完整的客户数据。人类工程师历来会在设计和实现过程中发现并形式化这些细节。

如果由 AI 代理编写代码，这些问题并不会消失。它们只是转移到了提示词、规范、测试、政策文件、评审会议或生产事故中。

2026 年 6 月，一项关于codeless future的分析提出了相关论点。文中将 AI 描述为编程抽象层级的又一步，同时指出，无论表面形式如何，精确的规范仍然发挥着代码的作用。

这正是 Hipp 的 SQL 类比最有力之处。SQL 之所以成功，是因为其声明式范围受到约束。数据库在形式化语义下理解表、关系、谓词、分组、排序和事务。

通用软件需求并不会以同样明确的边界出现。它们混合了技术行为、政策、美学、组织激励、法律义务，以及利益相关者可能从未明说的假设。

AI 编程代理可以推断缺失的细节。这种灵活性很有用，但也会引入风险。被推断出的需求可能看似合理，却仍然是错误的。

SQL 引擎同样会产生不理想的执行计划，尤其是在统计信息、索引或工作负载假设不佳时。但其输出仍受确定性的数据库语义约束。大型语言模型则可能根据相似提示生成不同实现，并且可能虚构 API 或假设。

因此，AI 编程并不只是“适用于所有软件的 SQL”。它是一种更宽松、也更具野心的接口。

这一类比在经济层面成立，因为两种技术都会压缩实现所需的工作量。但在可靠性层面，它就变得较弱，因为通用代码生成的输出空间要大得多。

这种差异提高了验证的价值。开发者需要覆盖有意义行为的测试、审查安全性与可维护性的评审实践，以及能在部署后暴露故障的可观测性。

团队还需要持久的上下文。当代理或工程师修改系统时，需求、架构决策、事故历史和领域约束必须保持可访问。一套可搜索的技术知识库可以支持这项工作，尤其是在生成的变更跨越陌生代码库时。

由此形成的角色可能包含更少的手动代码输入。但它仍然类似工程工作，因为它需要形式化、验证、权衡和责任归属。

SQL 类比在哪些地方失效

SQL 为劳动力变化提供了有益的先例，但它无法确定 AI 改进的速度，也无法说明企业会保留多少编程岗位。

历史类比会挑选相似之处，同时掩盖差异。SQL 是为一类特定的数据操作设计的。它的语法和语义在提出查询的人与执行查询的数据库之间建立了稳定契约。

AI 编程系统跨越不断变化的语言、框架、代码库、接口和业务领域运行。它们经常面对不完整的文档和相互矛盾的惯例。它们的任务并不只是在一个形式化模型内进行优化。

更广泛的范围可能使 AI 在经济上的意义超过 SQL。一个能浏览代码库、编辑多个服务、运行测试并响应故障的代理，覆盖的开发工作流要多于查询规划器所覆盖的范围。

同样，这种范围也会让可靠的自动化变得更难。在受限基准测试中取得成功，并不能证明它能在长期运行的生产系统中安全地工作。

一项生成的变更可能通过单元测试，却违反了未记录的运维假设。它可能复现代码库中已有的不安全模式。它可能解决了表面可见的工单，却增加了未来的维护成本。

人类开发者也会犯这些错误。关键问题在于，AI 是否改变了它们的发生频率、可发现性和规模。

速度既能放大优质输出，也能放大劣质输出。如果一个团队产出的变更数量增加到五倍，即使每项变更的错误率更低，也可能带来更多总体评审工作。反之，强大的自动化测试可能让团队扩大产出而不增加故障。

这种不确定性削弱了双方的自信预测。仅仅因为 SQL 没有消除编程工作，就断言编程岗位安全还为时过早。同样，根据令人印象深刻的代码生成演示就推断会出现大规模淘汰，也同样为时过早。

Hipp 自己关于完全自主编程的公开评论体现出谨慎立场。在 2024 年的采访中，他称 AI 有用但被过度炒作，并表示辅助编程看起来比完全自动化的代码生成更有可能实现。

这一预测仍是一种观点，而非经过测量的结果。AI 能力和产品设计仍在不断变化，组织也仍在学习如何在受控的开发流程中部署代理。

职业类别也可能在存续的同时缩小，或变得更难进入。银行业仍雇用 COBOL 专家，但这并不意味着 COBOL 仍提供过去那样的职业路径。一项技术可以保留关键专业知识，同时减少从事日常工作的人数。

初级岗位尤其值得关注。高级工程师通常通过小型缺陷修复、直接的集成、测试编写和受监督的功能开发成长起来。这些恰恰是当前编程助手擅长处理的任务。

如果企业在不重新设计培训方式的情况下自动化这类工作，它们可能会削弱培养未来高级工程师的人才管道。SQL 创造了新的专业方向，但它没有回答：在一个高度依赖 AI 的团队中，应如何培养那些不再频繁进行基础实现实践的人的判断力。

另一个不确定性涉及组织行为。生产力收益并不一定会转化为更多软件。高管可以通过减少人员配置、提高产出目标、缩短工期，或这些方式的组合来获取这些收益。

这种收益如何分配，将与技术能力本身同样重要。开发者可以利用 AI 管理更大的系统并解决被忽视的问题。由于管理层将每一次节省时间都视为永久性的额外产能，他们也可能面临加剧的工作负荷。

Hipp 的类比无法解决这一冲突。它只是让冲突变得更清晰。

问题不在于 AI 是否会自动化编程任务。它已经在这么做。问题在于谁控制节省下来的时间、哪些职责仍由人类承担，以及不断增长的软件需求是否会吸收被替代的工作。

AI 编程改变了企业购买的技能

随着实现成本下降，组织会更重视那些能够定义正确结果并识别看似可信错误的人。

SQL 的转型奖励了理解数据模型和业务问题的人，而不只是懂查询语法的人。AI 编程应当会对领域理解、系统设计、测试和运维判断带来类似的溢价。

仅靠编写提示词不太可能成为可持续的替代技能。提示词是接口，而接口会随着产品成熟变得更容易使用。更稀缺的能力，是识别一个看似合理的答案何时未能满足真实需求。

对开发者而言，这意味着必须理解生成 diff 之外的系统。他们需要追踪数据流动、识别信任边界、评估故障模式，并将代码变更与用户后果关联起来。

即便编写代码不再那么核心，阅读代码也可能变得更重要。工程师必须检查陌生的输出，并判断它是否符合本地惯例。他们还需要足够的基础知识来识别细微缺陷。

测试也在改变。生成的测试可以扩大覆盖率，但模型可能在代码和测试中复现同一种误解。团队需要独立的验收标准，以及基于预期行为而不只是基于生成实现的测试。

架构成为另一个压力点。AI 系统可以提出常见模式，但常见模式并不总是合适。关于服务边界、一致性、延迟、数据保留和运维复杂性的决策，都反映了具体约束。

领域专家获得了更大的作用空间，因为他们可以提供模型不具备的上下文。医疗保健工作流、财务对账系统或工业控制器包含的规则，无法从通用训练数据中可靠地恢复。

这并不意味着每位开发者都会成为架构师。它意味着该角色的经济重心将转向选择、约束和验证自动化工作。

一些工作将会收窄。团队可能不再需要那么多人来完成重复性转换、基础界面脚手架或常规测试生成。当客户能够在内部产出可接受的初稿时，按实现工作量收费的承包商可能面临定价压力。

其他工作则会围绕集成和保障而扩张。组织需要能够将 AI 系统接入私有代码库、控制工具权限、评估输出、维护开发基础设施并调查故障的人。

遗留系统现代化体现了这种混合效应。IBM 研究人员曾介绍，使用针对企业 COBOL 模式训练的模型来支持向 Java 的转换。他们的现代化工作仍然依赖于对 CICS、Db2、VSAM、IMS 以及旧系统中嵌入的业务行为的理解。

转换不等于替代。一个系统可能包含数十年未被记录的决策。生成 Java 语法并不能证明新程序保留了每一项必需行为。

经验丰富的 COBOL 程序员可能会亲手编写更少的迁移例程。但在验证过程中，这个人的知识会变得更重要，因为模型缺乏历史和机构上下文。

SQL 也创造了类似的分工。查询引擎自动化了算法选择，但复杂的工作负载仍需要理解模式、索引、统计信息和应用行为的人。

因此，AI 编程推动开发者向更高层次发展，同时又不能脱离实现细节。无法对代码进行推理的评审者，会依赖于正在被评审的同一系统。

企业同样面临管理挑战。它们必须区分更快的代码产出与更快交付可靠成果。如果评审、安全检查、利益相关者决策或部署流程仍然受限，生成的代码可能会不断堆积，却无法提升客户价值。

以代码行数或已完成工单为基础的指标将变得更加无用。团队应考察交付前置时间、逃逸缺陷、事故频率、返工情况，以及已发布功能是否解决了预期问题。

持久的优势属于那些将自动化与清晰规范和独立检查相结合的团队。仅仅向现有流程中加入 AI 助手，并不能揭示责任应当转移到哪里。

Simon Willison 的引言值得关注什么

下一阶段应通过关于自主性、软件需求和职业发展形成的证据来判断，而不是通过生成代码的数量。

第一个信号是，AI 代理能否在有限人工干预下完成持续性的生产工作。简短的编程演示已经不再足够。更严格的测试涉及多文件变更、模糊需求、部署约束、安全审查以及发布后的维护。

如果代理能够反复以较低的返工率和较少的逃逸缺陷处理这些工作流，那么 Hipp 的 SQL 类比作为有限任务替代的预测就会被削弱。AI 将会自动化工程工作组合中更大的一部分。

如果人工评审仍是主导性约束，那么这一类比就会增强。工作将转向监督和规范，而不是消失。

第二个信号是整体软件需求。企业应当披露，生产率提升究竟会带来更小的团队、由稳定团队完成更长的积压任务，还是让此前负担不起的项目得以扩张。

仅凭招聘数据很难解读。一家公司可以在放缓招聘的同时提高产出，也可以减少初级岗位，却激烈争夺资深工程师。就业构成比表面人数更能说明问题。

关注哪些项目获得资金支持。内部工具、小企业软件、定制集成和无障碍功能改进的增长，将支持此前抽象层发展后出现的扩张效应。收益若集中在现有产品内部，则将支持更强的替代效应。

第三个信号是初级工作结构。随着 agent 完成许多传统的新手任务，组织需要一套可信的方法来培养开发者。

受监督的 AI 工作流程、更完善的学徒计划，以及基于调试或系统推理的评估，都将表明这一职业正在适应。如果初级招聘长期萎缩却没有相应的替代培训，则可能意味着更深层的职业生涯扰动。

这些信号应当随着时间逐步显现，而不是通过一次发布或一项基准测试就能判断。就业体系的调整速度慢于模型能力。预算、采购规则、安全要求和遗留架构，都会限制技术潜力转化为实际运营实践的速度。

Simon Willison 的文章之所以重要，是因为 Hipp 提出了一个更好的起点问题。与其问 AI 是否能编写代码，不如问：哪一层工作将变得声明式，以及其上方仍需由人承担哪些责任。

SQL 让大量过程式数据工作变得不再必要。它也促成了更大型的软件系统、更广泛的数据访问以及新的技术专业领域。这两种结果都是真实的。

AI 编程也可能遵循这种混合模式，同时带来更大的颠覆。常规实现工作的价值将下降。精准判断、领域知识、验证和责任承担的价值将上升。

开发者应通过测试来判断 AI 在何处真正消除了工作，又在何处只是掩盖了复杂性。团队应记录生成代码必须遵守的约束，然后在部署后衡量结果。

下一代程序员会更像是操控更强大执行引擎的 SQL 用户，还是监督着自己已无法完全理解的系统的审查者？答案将取决于企业在自动化不断推进时，如何有意识地保留验证、学习和问责机制。