Citizens Build, Agents Execute, Experts Govern

普通人构建，代理执行，专家治理

Rachel Laycock

我是Rachel Laycock，Thoughtworks的首席技术官。我着迷于技术如何改变我们构建软件、领导团队和运营企业的方式。在这里，我会记录那些尚未成熟的想法，挑战自己的思考，偶尔也会偏离主题探索一些有趣的支线。

2026年8月19日

TL;DR：周末构建一个应用程序与构建企业级软件并不相同

在过去六个月里，我注意到一个有趣的差距正在扩大。这并不是技术上的差距，而是人们对软件工程实际含义的认知存在差距。

对话通常以相同的方式开始。一个非技术人员，可能是高管，会向我讲述他们周末构建的某个项目。有时是聊天机器人，有时是内部工作流程，有时是令人惊讶的精致应用程序，解决了实际的商业问题。他们感到兴奋，这种兴奋是合理的。一年前，他们可能根本无法构建出这样的东西。然后问题来了。

“如果AI现在能做到这一点，为什么我们的工程团队不能快十倍？”

这是一个合情合理的问题，毕竟我们都见过演示。我首先想到的是“你并不了解构建企业级软件需要什么”。但随后我开始思考自己到底想表达什么，以及如何在不显得过分居高临下地向非技术人员解释。这时我突然意识到，我们自己造成了这个问题。多年来我们一直强调如何编写好软件，导致所有人都认为编写软件等同于软件工程。

周末构建的应用程序确实是真正的软件。它可能解决了实际问题或展示了某个想法。有时确实令人印象深刻。我不想贬低这一点，因为我认为AI最令人兴奋的成就之一是大幅增加了能够将想法转化为可用软件的人数。这很酷，我完全理解。我最初构建的第一个应用程序和“hello world”让我兴奋到选择将其作为职业，这种兴奋是真实的，我不希望过度抑制它。

但你最初的那个“hello world”（如今可能已经是一个具备各种功能的完整应用程序），与在高度监管的企业环境中将软件引入生产环境相比（仅举一例），有着非常、非常（特意重复）巨大的差异。但为什么？

当这个应用程序变成企业依赖的系统时，问题会完全改变。客户数据是否受到保护？当依赖项失败时会发生什么？两年后其他人能否理解这个系统？它能否经受审计？它能否应对今天千倍于当前用户的流量？一天之内面对数百万用户又会如何？我们如何在客户发现问题之前察觉异常？除非有经验丰富的工程师在场，否则这些问题在演示或构建阶段根本不会出现。当我最初构建应用程序时，我肯定不会问这些问题。我当时只关心功能！

正是在这样的时刻，经验丰富的工程师变得更为重要，而不是更不重要。不是因为他们是唯一能构建软件的人，而是因为他们具备判断力，知道我们是否可以信任这些软件：设计是否合理、风险是否被理解、今天能正常运行的系统六个月后不会变成别人的噩梦。

几周前在 FOSE 上，我们出人意料地花了很少时间讨论编码。我们讨论了代码是否仍然是真理的来源，偶尔也会谈到我们多么怀念编写代码，但大部分时间我们讨论的是设计、架构、治理、学习和判断。一个团队描述了他们花了一天时间设计规范，让代理人在夜间运行，第二天早上再审查结果。对我来说，有趣的部分不是夜间流水线，尽管这确实很酷。真正有趣的是人类在做什么：决定什么是“好”的标准，权衡取舍，并判断返回的结果是否真的符合他们的需求。我们反复回到“良好设计”这个话题，因为事实证明，当代理能够快速生成大量代码时，良好的设计变得更为重要，而不是更不重要。

这让我开始思考，我们是否一直以错误的方式看待稀缺性。我们花了数十年时间优化那些能够编写代码的人，因为他们曾经稀缺且昂贵。我不确定这是否真的曾经是真正的稀缺点，但那可能又是另一场闲聊。现在感觉真正稀缺的是良好的工程判断：知道什么是“好”的标准，理解风险，并知道某个能正常运行的东西是否真的值得在生产环境中信任。因为软件的存在目的不是被构建，而是运行在生产环境中，安全地解决它被创建时要解决的问题。组织并不依赖代码运行，它们依赖的是信任。

几个月前，我在一次对话中几乎不假思索地说出了下面这句话：

公民构建。代理执行。专家治理。

这句话听起来很酷，我以为市场团队会喜欢，所以我把它记了下来。然后我暂时放到了一边。有趣的是，写下这些随笔时，我往往直到让这些想法在脑海中反复思考，并且向我信任的人（比如 Thoughtworks 的高级工程师）表达之后，才会知道自己是否真的相信它们。有时我会回来觉得之前说的完全是胡言乱语。偶尔，我会意识到其中隐藏着更有趣的东西。这次就是后者的情况。

起初我以为自己在谈论角色。公民构建软件（本质上是非技术人员）。代理编写代码。工程师成为治理者。但事实上，我不认为这就是我的本意。我认为我在谈论价值转移的方向。AI 给每个人提供了一种新的表达想法的方式。执行工作越来越多地由代理来处理。它们编写代码、重构代码、生成测试、修复漏洞并以一种以前根本不可能实现的速度进行迭代。但这些都不会减少对专业知识的需求。

事实上，我认为这恰恰相反。当每个人都能创建软件时，仍然需要有人决定这些软件是否值得在生产环境中的企业系统中存在。仍然需要有人思考架构、安全、韧性、可操作性、合规性、成本——这些在演示中没人会感到兴奋的“无聊”内容，但一旦客户无法登录或审计人员突然造访时，它们就会变得痛苦而重要。

这正是为什么我认为经验丰富的工程师不会变得不那么重要，反而会变得至关重要。他们的工作重心将从亲自构建每一个功能，转变为创建一个环境，让其他人员和代理能够安全地构建成千上万的功能。他们将成为设计安全护栏、平台、工程实践和反馈循环的人，让其他人能够快速行动而不引发混乱。

或许这就是未来软件组织的形态：不是所有人都成为软件工程师，也不是软件工程师消失，而是一个几乎任何人都能创建软件、代理越来越多地执行软件，而工程专业知识成为让所有这些创造力安全扩展的关键因素。需要明确的是，我并不是指人们随意构建东西然后丢给工程师去修复，这种做法是完全错误的反模式。

或许这就是为什么我与高管和工程师交流时，有时听起来他们似乎在描述截然不同的未来。高管看到的是现在任何人都可以构建软件，而工程师看到的是仍然有人必须承担这些软件的后果。两者都正确，他们只是在关注同一系统不同部分，而我们需要解决这些部分才能塑造出真正的未来。

最新文章（8月19日）：

Citizens Build, Agents Execute, Experts Govern

上一篇文章：

The Conductor Developer

所有文章 /