思想领袖
新的10倍工程师并不写10倍的代码,他们构建能够写代码的系统

十倍工程师已经成为硅谷的神话,持续了几十年。独自工作的天才,戴着耳机,以超人的速度生产优雅的代码。我们一直在争论他们是否存在,如何聘请他们,并对任何声称自己是十倍工程师的人保持沉默。
但是在通往AI优先的未来途中,发生了一件有趣的事情:十倍工程师变成了现实。他们只是与我们想象的完全不同。
OpenAI最近分享了一个三人团队如何使用Codex发布1500个拉取请求和大约一百万行代码,而无需手动编写一行代码。三个工程师,零手写代码。一个由数百名内部用户使用的生产产品。
这不是10倍;它更接近100倍。而使其成为可能的技能并不是打字速度更快或知道更多算法。它是构建使AI代理变得高效的系统:工作流程、防护栏、验证循环、代理插入和人类通过界面审查的接口。
我相信这是工程组织中新关键功能的出现。我将其称为AI编排工程。
三个学科走进站立
如果你仔细观察AI编排工程师实际做什么,你会认识到三个熟悉的学科融合成一个。
最明显的成分是DevOps。DevOps集中了部署管道。一个团队配置了每个工程师在发布代码时使用的CI/CD工作流。AI编排工程做同样的事情,但适用于代理工作流。它定义了任务如何分配给代理,输出如何验证,重试和回退如何工作。这是代理运行的共享基础设施。
然后还有架构,它与DevOps的重叠比你预期的更大。架构师决定哪些接口被锁定,哪些模式被强制执行,哪些边界不能被跨越。在代理优先的世界中,这更为重要。代理需要干净、文档齐全的代码库,清晰的合同。AI编排工程师定义这些约束,不仅仅是为了人类的可读性,还为了代理的理解。一个凌乱的仓库不再只是技术债务;它是每个接触它的代理的生产力上限。
最不被理解的部分是特定于AI的层。提示工程、上下文管理、模型选择、代理配置。今天,大多数工程师以分散的、任务为基础的方式执行此操作。每个人都找出自己的提示风格、自己的代理设置、自己的解决方法。AI编排工程师集中了这一点。他们建立共享的剧本、可重用的配置、关于什么有效和什么无效的组织知识,适用于所有模型和用例。
单独来说,这三个功能在今天的大多数工程组织中都存在。论点是,将它们合并到一个单一的、集中化的角色中,会产生质性不同的东西。
节目主持人隐喻
电影导演不操作摄像机、不演出场景、不编辑镜头。但每一帧都反映了他们的决定。
他们选择拍摄构图、节奏、基调。他们决定何时推进近距离拍摄,何时拉远镜头。他们设置环境(灯光、布景设计、阻塞),以便每个演员都可以在连贯的愿景中做出最好的工作。剧组是各自有才华的,但没有这种协调,你会得到一个永远无法发布的混乱。
AI编排工程以同样的方式运作。代理是有能力的。模型是强大的。但是,没有人设计协调它们的系统,定义约束,构建反馈循环,结构工作流,你会得到我们都经历过的东西:不一致的输出、浪费的计算、代理以相互冲突的方式工作、工程师花费更多时间修复AI生成的代码,而不是自己编写代码。
导演让电影变得比其各个部分的总和更伟大。AI编排工程师对代理舰队做同样的事情。
为什么大多数组织投资不足
这是我在整个行业看到的:公司在AI工具上投入了大量资金,但在周围的系统上投入的资金还不够。
工程师可以使用Copilot、Claude、Codex。他们进行个人实验。有些人成为高级用户。大多数人在“花哨的自动补全”阶段就停滞不前。研究报告中持续出现的20%的生产力提升?这是工具级别的采用,而不是系统级别的思考。
突破的组织、报告2倍或更高的吞吐量的组织,有一个共同点。他们集中了编排工作。有人(或某个团队)拥有代理工作流、仓库准备、验证基础设施、每个代理都可以访问的共享上下文。
该角色实际上是什么样子
AI编排工程师的一天可能包括:
- 设计代理工作流:定义功能请求如何成为规范、成为计划、成为并行代理任务、成为审查和合并的代码。
- 构建验证基础设施:自动测试、linting规则、安全扫描和评估框架,代理必须在其工作被合并之前通过。
- 维护仓库健康以供代理使用:文档、清晰的接口、依赖项管理和代码库简化,所有这些都针对代理理解进行了优化,而不仅仅是人类可读性。
- 集中提示和上下文策略:共享系统提示、检索管道、模型路由决策和配置模板,整个团队都使用。
- 监控和改进代理性能:跟踪成功率、故障模式、每任务成本和时间到合并跨代理舰队,然后根据数据调整系统。
这个人处于平台工程、软件架构和AI专业知识的交叉点。他们不编写功能。他们构建使功能交付快速、可靠和可扩展的系统。
历史模式
在云计算的早期,部署是每个工程师的副业。每个团队都有自己的脚本、自己的服务器配置、自己的方式来将代码部署到生产环境。DevOps出现了以集中这一工作,平台工程随后发展以将其构建为共享的自助基础设施。
AI正在遵循相同的轨迹。目前,代理使用是每个工程师的副业。每个人都有自己的提示风格、自己的工具偏好、自己的心智模型,用于确定何时AI有帮助,何时无帮助。集中这一点的组织,将代理使用视为基础设施而非个人实验的组织,将以与拥有成熟的DevOps实践的组织相同的方式领先于其他组织。
区别在于速度。DevOps转变花了十年。这个可能需要季度。虽然我会承认,这个预测假设组织比平常更快地认识到这种模式。
前进的道路
如果你是工程领导者,这是我会建议的,尽管你的里程可能会根据你的团队已经走了多远而有所不同。
- 找出谁已经在非正式地做这项工作。每个组织都有人已经弄清楚了代理工作流,其他工程师会去找他们寻求关于提示或工具设置的建议。这个人就是你的原型AI编排工程师。
- 使其显式化。给函数一个名称、一个命令和资源。不要让它保持为附着在某人的“真正”工作上的副业。
- 从仓库准备开始。不要投资于复杂的代理工作流,在确保代码库是代理可以实际导航的东西之前。清晰的接口、良好的文档、综合测试、简化的架构。
- 集中化有效的东西。当有人发现提示策略或工作流模式显著改善代理输出时,捕获它。将其作为整个团队的默认值,而不是锁定在一个人头脑中的部落知识。
- 在系统级别进行测量。不要仅跟踪个别工具的使用情况。跟踪代理完成的任务数量、审查和改进率、瓶颈所在。
新的10倍
十倍工程师的神话一直是关于个人英雄主义的。一个人,通过纯粹的天赋和咖啡因,超越了所有其他人。
AI时代的十倍工程师现实是关于系统思维的。那个让每个其他工程师(和每个代理)更高效的人,通过构建正确的基础设施、正确的工作流、正确的约束。
他们不编写10倍的代码。他们构建能够编写代码的系统。
我不确定这个角色是否会完全按照我在这里描述的方式形成。但我相当确定,弄清楚编排层(无论他们最终如何命名它)的组织,将是真正实现每个人都在谈论的生产力提升的组织。












