---
author: AI Engineer
date: '2026-09-27'
guest: ''
layout: post.njk
source: https://www.youtube.com/watch?v=tUPPVhBBcoM
speaker: AI Engineer
tags:
  - software-engineering
  - agentic-workflow
  - autonomous-agents
  - developer-tools
title: 软件工程向工厂工程的演进：自改进软件工厂与开源新范式
summary: Warp 创始人 Zach Lloyd 提出软件工程正转型为工厂工程。随着代码生成边际成本趋零，团队竞争力转向流程工程与生态构建。演讲系统拆解了涵盖分流、规范编写、实现、审查与监控的闭环流水线，并探讨了自改进循环及人类产品品味的核心价值。
insight: ''
draft: true
series: ''
category: software-development
area: tech-engineering
project: []
people:
  - Zach Lloyd
companies_orgs:
  - Warp
products_models:
  - Warp
media_books: []
status: evergreen
---
### 范式转移：从交互式编码走向软件工厂工程

软件开发范式在过去数年经历了剧烈的形态演变：从早期的**聊天交互**与以 Cursor、GitHub Copilot 为代表的代码自动补全，演进到当前开发者与 Claude Code、Warp 等终端工具频繁互动的**交互式智能体**（Interactive Agents）阶段。然而，未来的演进方向绝不仅限于人机对话，而是正在全面迈向深度的系统性**自动化**（Automation）。

从长远来看，**软件工程**（Software Engineering）这一学科的本质将逐步转变为**工厂工程**（Factory Engineering）。在这一新体系中，软件的研发流程被组织为类似现代工业流水线的闭环生产系统（Software Factory）。从输入需求想法、缺陷分流、需求规格制定，到代码实现、审查、验证与线上监控，整个软件开发生命周期（SDLC）都将交由多智能体协作网络驱动。人类工程师的角色将发生战略性后退：从直接编写代码转向流水线的顶层设计、瓶颈调优以及对关键审查节点的把控。

<details>
<summary>Original English</summary>

the okay. hello, everyone. i'm excited to be here. uh my name is acalloid um today going to be talking about self improving software factories, the new open source model. and basically, what i think is happhappening to developso little bit about me just to begin. so i am a former principple engineer for google. it's a lead engineering on the google dog sweet. it's been engineer now for google time time. i'm still uh pping frequently, but i haven't read ellantic code and last six months uh. and i'm the founder of a company called waruh warp. if you're not familiar is a open source agentic development environment. um you may know us as a terminal, that is how the company started it basbasically terminal that has agents built in um we open source at a couple months ago, and i'm going to talk a little bit about that experience in the motivation for it. it's popular open source project over sixty thousand and giheup stars ars. you've had couple hundred people contributing if over eight hundred thousand active developers who are using warp. and increasingly, we are focused not just on the terminal aspect and the interactive aspect of development, but more so on. how do you automate development and weto talk mostly about that. so the thesis that i have is that the discipline of software engineering is going to become something more like factory engineering. and i'll explain what i mean by this in a minute, but just keep that mind. that's that's what i think is going to happen. um if you look at development over the past couple years, it's i mean, it's crazy how it's changed. we've gone from a world of chat. and i auto complete curceror copilot to the phasit were and now which i consider to be mostly interactive agents. so you're sort of sitting at your computer, and you are telling cloucode to do something, you telling work to do something. and i believe what's going to happen over the next six months a year, hard to predict the pace is that we're going move ve much more towards the world of automation. but before agaends that just quick show a hands, how many folks in here are building with agents, every hundred percent makes sense um how many how many folks are building typically with multiple agents at one time. so again, almost everyone, how many people are running an agent right now, i am not offended. i would get the torical ical i would be doing into ah how many folks are running agents in the cloud a curiosity. so that looks like less than half but still still navigate. and how many folks have have set up a system internally to automate the whole offort of them my lifecycle, so everything from like trioging speacking implementing reviewing. so i see some hand. so some people are doing this. so this is what's going to happen. uh, every project of significant size. i believe it's going to have something like this um and it's going to look kind of like this big loop. and everyone is talking about loops is nothing that complicated about loops. this loops says cloud software factory ory. this loop could literally just say, like the software development lifecycle. it's the same thing, but just to go through this loop, it's like ideas are 're going to come in at the top. agents are going to do trios. if something is complicated, they alright speck. these little blue boxes are where humans step and humans will review the spec. uh agents will the the implementation human man inient review. the code agents will verify human will view the product you ship, and then you monitor and round around you go. um and this is what software development for better or worse. i think it's going to end up looking like. so the pieces, which is that if this what sofofare engineering is going to look like, um software engineers are going to be the ones who end up building and managing these factories.

</details>

### 开源重塑与护城河：应对极低边际成本克隆的战略重构

当 AI 智能体让构建软件的边际成本逼近于零时，软件行业面临着根本性的商业模式冲击：**构建极其廉价，克隆亦变得轻而易举**。如果竞争对手可以在极短时间内完整克隆任何软件功能，单纯依靠产品本身的静态功能点将无法建立稳固的商业护城河。专利保护在此类场景下是无效的死胡同；初创公司在缺乏巨额资本、既定分发渠道或专有数据壁垒的劣势下，突围的关键在于通过**开放式构建**（Building in the Open）来积累生态系统、品牌认同与社区信任。

然而，传统的开源项目维护往往伴随着繁重的运维痛点，例如大量噪音 Issue、低质量 PR、永无止境的代码审查地狱以及验证修改耗费的大量精力。解决这一矛盾的核心正是软件工厂。以 Warp 为例，在封闭开发五年后选择拥抱开源，正是因为其构建了一套围绕开源管理的自动化流水线（如 `build.warp.dev`）。通过在公网公开工单流转、智能体分工与贡献者协作状态，智能体承担了辅助贡献者提交、协助维护者审核的大量前置工作，使得大规模开源协作在智能体时代具备了极高的生产力可行性。

<details>
<summary>Original English</summary>

now i promise at the beginning, and i put in the title of the talk, i going to talk about open source. and so i want to do that for a few minutes, i may to take a quick digression. um i bring up open source because one of the main reasons that war open source was to build build a public factory. um and so this is a picture of this website. we built called build out worktot dev, which shows all of the issues that are flowing through our system and whastayed there and what agents are working on them. what contributors are working on them. and it's kind of like a protofactory done at scale. it's not working perfectly, but it is working. and one of the reasons we open source was to try to build this. um just in general, i think it's interesting to talk about open source in the time of agentic development. this is a really stuper graph, but it's like it's just it. you get it. it's like it's becoming much cheaper to build software. um a cororal of that is that it's becoming intertrival to clone one software. and so if you are in the software business, i don't know how many folcusing this ruroom in the software business per say, but it's very hard to build a software business if it's free to build software. it's hard to capture the value, especially if a competitor can clone. and so my big takea a or a big tip everyone in here is that the first thing you should do is patin your code. i'm kidding, don't this. it's a complete dog. don't don't do this. my my first step is obviously, you need to have a great product ah. this has always been the case um, but i would say a great product product was never enough, but even now more than ever, if you think that you're going to build a great sofof business, just by building a shipping, a great product, you're probably not onna succeed. uh you need advantages beyond the product. and so those advantages could look like distribution ecosystem could be that you have a great brand or data mode, you might have capital um but if fear start up again, i'm coming from the start of world here, you just don't have these advantages. and so you you still want to break through. and one of the ways that i suggest doing this is by building in the open. and so to be clear, it ook worar five years of building closed to sort of make the leap in the building in the open or explain why. but if you build in the open, um, it helps build your ecosystem, it can take you from being like hated on hacker news to like tolerated. uh it can burst your brand to create community. and so there's all these advantages to it. uh and some of the things i think i've traditionally been a pain can now be managed. and so like the traditional, you know, pain of open source might be something like you get a lot of noisy issues. you get sobby ps, you can end up in code reyou how you can end up having to spend a lot of time verifying changes. and so the solution, so kind of a long way, it wa're getting to this for open source or at least for war. in the case of open source. the thing that made us finally decided to do this was that we built a whole set of automations, really a software factory around managing the open source project. and so like i said, this is what i think the future is going to look like. i'm going to drill into it a bit just to get a little bit more technical for folks who want to try to build something like this further own projects.

</details>

### 工厂车间架构：五大核心阶段与多智能体分工机制

一个高效落地的**软件工厂**在技术结构上被解构为一个严密的有向工作流图（Workflow Graph）。类似于十年前持续集成与持续部署（CI/CD）成为行业默认标配，现代软件工程工厂也由五个核心阶段构成：

* **输入阶段（Inputs）**：来自团队成员、外部用户、工单追踪系统、Slack 沟通频道、终端 IDE 或线上监控警报的原始想法与缺陷报告汇入流水线。
* **智能分流（Triage）**：由专门的分流智能体对所有需求进行过滤。若属于边界明确的简单任务，智能体直接执行修改；若属于高复杂度问题，则启动多维**规范编写**（Spec-driven Development），分别输出定义产品约束与不变量的**产品规范**（Product Spec），以及描述架构设计与代码形态的**技术规范**（Tech Spec）。
* **代码实现（Implementation）**：运行在云端隔离沙箱（Cloud Sandboxes）中的编码智能体读取规范，自动拉取分支并生成代码差异（Diff）。
* **代码审查与验证（Review & Verification）**：为杜绝无休止的“模型劣质代码”（AI Slop）消耗开发者精力，先由审查智能体完成第一轮合规性检验，再基于风险管理策略引入人类工程师介入审查；同时利用**计算机使用能力**（Computer Use: 由智能体直接操控 UI 生成运行视频与截图）结合传统 CI/CD 管道进行全功能验证。
* **运行时监控（Monitoring）**：智能体在功能发布后持续追踪崩溃指标与用户真实使用情况，并将监控洞察反哺至输入端，形成完整的生命周期闭环。

在底层支撑层面，软件工厂由三大基础设施柱石组成：接入各种工作输入的**接入层**、负责智能体调度与流程编排的**控制平面**（Control Plane）、承载沙箱环境与模型调用的**执行平面**，以及记录智能体长期记忆与执行轨迹的**数据平面**（Data Plane）。

<details>
<summary>Original English</summary>

so what are the components of an effective software factory? it's really not that complicated to start or at a high level, you need a set of automations. you need a way of providing context and skills. you need a way of bring humans in at the correct time to sort like when things get stuck on the factories. and then a really important thing is you need some set of self improvement capability. so think of this is loops. and if you do this right in the open source world, you can get a, you know world where agents are helping contributors contribute, they're helping maintainers maintain. and i want to emphasize there's nothing special about open source here. i think every sizzable project can benefit from this approach, and i predicted every every company, every open source project will have at its core a software factory kind of lect. the way that CICD became just like, of course, you have that. maybe i don't know when that happened ten years ago, let's tour the attack, the factory floor for a second here. so you're not going to look at this. this is too much. um the the point of this slide is not to have you read the worflow, it's that the factory floor is basically a graph um of steps where you are defining like, okay, how to sofa get built for my product. and it looks pretty similar for every product. um it look in, they flow through um they get stuck at certain points, and you know, broadly speaking, just to back out a second. so there's the inputs. the inputs are really ideas. um the inputs could be coming from your team. they could be coming from your users. um the inputs themselves tend to come in through certain channels. ls, you should think about is like your task tracackers and obvious one or slack your teams, like your communication channels. they could come directly from like your terminal RIDE. they could come from your monitoring systems. but there's some set man puts that bring work into the factory. there's trioge. this is a really important step. so again, i boiled down a sathing very simple, but like you want an agent theis looking at issues as they come in into saying, you know, if this is easy, and this is on an ambious ous, just mplement it. and this is how you can actually get going with a factory. if finisshe you is hard ah, i recommend having uh an agent that produces speacks folks in here using spectrtive and development show hands, people follow us. yeah, you can do this many different ways, but i think it's very effective the way that we do it to work that i recommend is having an agent, right? what we call a products spec and a text spec product spec describes the product and variance that you're building towards text back, describes the architecture and the shape of the code. then you have an implementation agent. this is basically a coding agent that run somewhere in the cloud. it makes a def, you can use all sorts of coating agents for this. you have review this isin, many ways. the most painful part, like i expect, the people are a little bit tired of reviewing identical slop. i would have an agent tucode review first, and then it becomes over time, like a risk management exercise of like when you bring in humans to ducoter view, but you want to have a step in here where humans can do it. this is a very important step um for certain types of apps, the verification step. so this would be things like computer use if youbuilding ding a sort of ui having the computer actually use the code of the agean produced and producing videos and screen shots, CICD still use it, obviously, uh and in monitoring. so agents don't stop in your factory when code a shift they should observe. what's been shipped? is it crashing? is it being used and round and around you go because you take the output of this monitoring step, and you feed it back in to the top of the factory. now you could try and build this. and i went to a talk earlier that my frirenanamm gave where uber has built an internal version of this. um and it's pretty cool. i would say, for most, you know, most organizations, it really depends where you are. you'll be able to build a simple version of this easily, but to build a thing that actually scales is probably like you's probtty focusing on your own product, not building this infrastructure because there's a lot of stuff that you end up wanting. you're not again, not what to read this ah, just a lot of stuff, if you do build it um or if you buy it 'll end up with something like this, which is um you're going to have a bunch of ways to getting work in the ar factory. that's what's in the topiyear. you're going to have a sort of control plan for figuring out how work gets distriributed across your factory floor. you're going to have the actual place where the work happens. and so that's going to be cloud sandboxes. it's going to be figuring out what agent to runs. so what's the harness? what's the model? and then finally, it this is a really important thing. you're going to want to set up some kind of data plane that sits below your factory. and so that's something that lets agents remember what they've done. learn improve over time.

</details>

### 自我改进循环与工程师思维转变：元工程与产品品味

工厂不仅是一套静态的执行流水线，更是一种**以度量为驱动的工程心智模型**。在工业级工厂中，团队必须严密监控系统效率：不仅要评估软件的交付频次与质量，还要精确核算消耗的“人类工程师时间”与“模型 Token 成本”。实现这一目标的关键是构建**自改进循环**（Self-Improvement Loops），例如**技能演进循环**（Skill Loop）：在主线上，执行智能体调用特定 Skill 产出结果；在侧线上，**观察者智能体**（Observer Agent）实时监控执行质量与人类介入反馈（如资深工程师纠正代码审查意见的记录），并依据纠错行为自动调整优化底层 Skill 定义，实现流水线能力的代际迭代。

在这一变革浪潮中，软件工程师的工作重心必须发生根本性迁移——从“构建产品本身”提升为**构建那个构建产品的自动化系统**（Building the thing that builds the product）。这种“元工程”（Meta-Engineering）工作更加贴近工艺工程或制造流程设计。对于沉迷于纯粹码字的开发者而言，直接编码量的锐减可能是个落差；但对于以交付高价值产品为乐趣的工程师而言，这无疑是黄金时代。

在随后的现场问答中，针对初入职场的计算机专业毕业生，核心建议是优先锤炼**适应能力**、**批判性思维**以及对底层系统架构与规范设计的深度理解能力。即便智能体包揽了绝大多数实现细节，**人类的产品品味**（Product Taste）、同理心与真实需求洞察仍是整个工业流水线最不可替代的核心锚点——如果流水线脱离了人类敏锐的审美与价值判断，开足马力生产出无人问津的代码废料将毫无意义。

<details>
<summary>Original English</summary>

the factory is not just like a product. it's also a mindset. and this brings me back to the thesis i had at the beginning, you need a measure and improve. so factory is is where i don't know. you can sctch ch metaphor as as far as you want, but like you should be thinking of efficiency. and so that means like how much software you ship, how much should it cost in terms of human time and token time? and you're going to want to measure this and try to improve it over time. a key part of this is creating loops. so loops are again, they sound complicated. they're not that complicated. loops are basically ways of uving agency improum. um by like observing what they're doing where they're failing. um and so a common kind of loop the're going to want to put in your factory is like a skill loop. that means you're going to have your factory agents that are running skills, and then you'll have observer agents that are seeing how those skills are being applied, looking for issues and trying to improve the skills. so for incenstance, if you had a coter view agent ah, and it was leaving comments and a senior engineering, your team is going correcting. those comments. you'd want an observer agent that would look at that and basically um improve the coter view agent for the next run. this is one thought just to leave folks with, like what is where's leave engineers? i think you're going to have to get into this mindset, and i'm trying very hard to get our team into this mindset. it's not always easy that you're not just building the product, but you're building the thing that builds the product. and that's like it's just different. it's more like process engineering your manufactureing or something like that. and you could think like, okay, maybe that's abbuomer like, is that obomamer is that you know? and it depends like it depends what joy you get at a software n engineering. if your joys in writing the code, i think you're everyone in here, who is a software engineer, is going to be writing less code. but if your joy is in shipping products like it's never been a better time. and this is actually where i find my joy. it's like i like building and shipping the thing. so everyone in here is going to code less, but they're going to shiit more, and that's going going be be trayed off. but if you approach it like you're a factory engineer, i think you can see like that they're still really cool set of engineering challenges. um you could almost think if it's like meet a engineering, a cudiyou engineer, your system of agents to be the best possible with engineering. but i think is a very compelling and interesting set of challenges to solve. so that's it uh for folks who are interested. uh this, if you follow the income, as cuuarcode, i've set up um a open source sketobrripo, where anyone who wants to try building their own factory agents can do it. this uses warpps. uh. agent platform is part of it, but you honestsay you don't have to use it. i'm not trying to push in into our product, but this should give you a good sense of like, okay, if you want to set up um an agent that does uh trioge or an agent that does um speackwriting. how do you actually do that? how do you get from like the theory of uh working with a factory to actually putting it into practice? um i don't know we have the capability or do questions in here. i saved a few minutes for questions. if anyone has questions otherwise. well, i will rap up. yes, yes, it's a great question. so i said some it alalcontradictory. i think think you should the way you should think of it is like everyone's going to deploy some sort of factory. but then the tuning of the factory, the like are these the right skills from my domain is this factory building my product in the right way. i still think there's a bunch of interesting engineering challenges. and for some places you can build this. but again, i think i think that uh, you should prily be focusing on building the core product for your company for the most part. but there's a bunch of like tuning. and like uh figuring out how to make the factory word for your product. that matters is a great question. yes, it's ah thank you. so much, i adany questions. so if you are a college student right now, yes, graduating and enter the workforce where we can spend in your time. yes. so the the question in case people couldn't hear was like if i was a college student graduating entraying the workforce right now. so i think that the most important skills in this new world are adapability. i think that that's critical thinking. it's like the the speed, which you can learn the do think i don't know fear, computer science student, but i still think there's a ton of value in understanding like the underlying systems and architecture. and being able to reason in understand, i do de food, understand the speacks that agency writden. i start ted writing. so i would focus on on those skills um and like i don't know, we're hiring more people than we've ever hiire. there's a lot of kind of like me know people action around, like, you know, people not being hired er because AAI that's not experience we've had so far and what i'm looking for are like really adaptable product focus thinkers who can like basically be great problem, solve it problem llves um even as the underlying technology changes. yeah, i think of time for one more question. yes, what covery radiation and taste, what about the like? so question tion was what about the product taste in? like the how do you actually built in useful? i think, is probably or right, like maybe the framing. and like um where do the ideas come from? and so i think that um the problem with the factor of metaor or and i'm like leaning and do it, because i think that's like that the're something to it. is it? it can kind of sound like mechanizing or humanizing. um and i still think underlying all of this. the only thing that matters is like, are you building something useful? and if you have like a factory that is like turning out shit that no one cares about. it's like what's the point? and i think that human taste, human input, human product sense um humans like guiding at those touch points where you can automate stuff is absolutely like essential unlike. that's like what i do like, i'm trying to figure out what do customers want, what do people want? what's can be valuable to them. so think that's an absolutely key point to it. i think i at time time, so i have to go. i hope folks uh h enjoy this chat, uh, really grateful for being very to speaks. so thank you all very much. the.

</details>