As a software engineer with more than seven years of experience before the coding-agent era, I never liked the idea of vibe coding. But I knew there was a clear line between it and using coding agents to generate clean, maintainable code. That line, where good software principles meet coding agents, is defined by software factories.作为一名在编码智能体时代之前就拥有七年多经验的软件工程师，我向来不喜欢“随性编码”（vibe coding）的理念。但我深知，随性编码与利用编码智能体生成简洁、可维护的代码之间存在一条明确的界限。这条界限——即优秀软件原则与编码智能体的交汇点——正是由“软件工厂”所定义的。
That’s why, three months ago, I built my own software factory, Squid, to ship all of Decoding AI’s small and medium projects with minimal human intervention. The first version was so overbuilt I stopped using it.正因如此，三个月前我构建了自己的软件工厂 Squid，旨在以最少的人工干预交付 Decoding AI 的所有中小型项目。第一版做得太复杂了，以至于我后来直接弃用了它。
Meanwhile, I kept seeing people obsess over the next “_____ engineering” label, instead of focusing on actionable outcomes. Prompt engineering, then context engineering, then harness engineering. So far, so good. But in the last few weeks (July 2026 as I write this), things got off track with loop engineering and graph engineering, which already read more like marketing talk than like anything that solves real problems. Graph engineering overtheorizes how teams have built AI applications since the LangGraph era kicked off in ~2024. Don’t get me wrong. The terms aren’t wrong (Boris Cherny, who leads Claude Code at Anthropic, says, “My job is to write loops”), but we’re overexplaining intuitive things we started doing years ago.与此同时，我发现人们总是沉迷于下一个“……工程”的标签，而不是专注于可落地的成果。先是提示词工程（prompt engineering），接着是上下文工程（context engineering），然后是工具链工程（harness engineering）。到目前为止，这些都还算合理。但最近几周（写下本文时为2026年7月），情况开始跑偏了，出现了循环工程（loop engineering）和图工程（graph engineering），这些听起来更像是营销术语，而非解决实际问题的方法。图工程过度理论化了自2024年 LangGraph 时代开启以来团队构建 AI 应用的方式。别误会，这些术语本身没错（Anthropic 负责 Claude Code 的 Boris Cherny 说：“我的工作就是写循环”），但我们确实在过度解释那些我们几年前就开始做的直觉性工作。
While you’re defining what counts as a loop, you’re not thinking about the processes that actually deliver software.当你还在定义什么是循环时，你却忽略了那些真正交付软件的流程。
The right frame is the software factory, which was one of the core themes at AI Engineer World’s Fair 2026, where Tereza Tížková (growth at Factory.ai) defined one as “the whole loop, the whole lifecycle of developing software with autonomy.”正确的框架应该是软件工厂。这是 2026 年 AI 工程师博览会（AI Engineer World’s Fair 2026）的核心主题之一，Factory.ai 的 Tereza Tížková 将其定义为“整个循环，即以自主方式开发软件的整个生命周期”。
I bet you already have an intuitive sense of what a software factory is. In this article, I want to further formalize it and map it onto the software development lifecycle (SDLC). We’ll explore how big your software factory should be, and when to stop automating before it adds more friction than value. Most importantly, I want to highlight where the human belongs in this process, and where I believe they’ll still belong even in a world where all the code is generated by AI.我相信你对软件工厂已经有了一种直觉上的认知。在本文中，我希望进一步将其形式化，并映射到软件开发生命周期（SDLC）中。我们将探讨软件工厂的规模应该有多大，以及何时应该停止自动化，以免造成比其价值更多的摩擦。最重要的是，我想强调人类在这个过程中所处的位置，以及我相信即使在所有代码都由 AI 生成的世界里，人类依然不可或缺的领域。
So…what’s worth automating? Where does the human bring the most value? What’s worth building, and what’s worth buying?那么……什么值得自动化？人类在哪里能发挥最大的价值？什么值得自研，什么值得采购？
The design of a software factory软件工厂的设计
Like a physical factory, a software factory automates software creation with minimal human input. Raw work (bug reports, feature ideas, incidents) goes in. Shipped software comes out. It needs a few highly qualified people making high-leverage decisions, and defined gates that work can’t pass through without them.就像实体工厂一样，软件工厂通过最少的人工输入实现软件创建的自动化。原始工作（错误报告、功能构想、突发事件）输入，成品软件输出。它需要少数高素质人员做出高杠杆决策，并设置明确的关卡，没有他们的参与，工作流无法通过。
Factory.ai pitches “a self-improving system for your Software Development Life Cycle (SDLC).” Addy Osmani frames the stack as loop, harness, factory: “The loop is the atom”; a factory is “an org chart made of loops.” Warp’s CEO, Zach Lloyd, states that “software engineering will become factory engineering.”Factory.ai 将其描述为“一套用于软件开发生命周期（SDLC）的自我改进系统”。Addy Osmani 将技术栈框架化为循环、工具链、工厂：“循环是原子”；工厂则是“由循环组成的组织架构图”。Warp 的首席执行官 Zach Lloyd 指出，“软件工程将演变为工厂工程”。
The factory is made up of eight stages that can be divided into three buckets:工厂由八个阶段组成，可分为三个部分：
What to build. Triage/intake classifies, deduplicates, and routes incoming work. Brainstorming finds high-impact features through market analysis, user data, and technical research. Planning, the most important stage, turns that research into a polished plan, refines it by letting the agent grill you, and tracks decisions in an ADR (Architecture Decision Record) log plus a glossary. The outputs of this stage are tickets backed by documentation that a team of agents can implement, which can be tracked in plain files or a project management tool, such as GitHub Issues, Linear, or Notion.构建什么。分类/接收阶段负责对传入的工作进行分类、去重和路由。头脑风暴阶段通过市场分析、用户数据和技术研究发现高影响力的功能。规划阶段是最重要的阶段，它将研究成果转化为精细的计划，通过让智能体对你进行“拷问”来完善计划，并在 ADR（架构决策记录）日志和词汇表中跟踪决策。该阶段的产出是带有文档支持的工单，可由智能体团队执行，并可在纯文本文件或 GitHub Issues、Linear、Notion 等项目管理工具中进行跟踪。
At this stage, the agent plans in read-only mode, going through the code, the AGENTS.md file, and most importantly the context layer.在此阶段，智能体在只读模式下进行规划，遍历代码、AGENTS.md 文件，以及最重要的上下文层。
Actual building and checking. Implementing is a software engineer and QA agent loop that goes through the tasks and supporting documentation. Review checks the PR diff against product, architecture, and code standards. Review-CI runs the test suite, and failures trigger a fixing agent. Release handles CD to staging/production with human deployment checks.实际构建与检查。实现阶段是一个软件工程师智能体与 QA 智能体的循环，它们遍历任务和支持文档。审查阶段将 PR 差异与产品、架构和代码标准进行比对。Review-CI 运行测试套件，失败则触发修复智能体。发布阶段处理到测试/生产环境的 CD，并进行人工部署检查。
Self-improving. Monitor/incident response feeds production signals (alerts, errors, incidents) back into triage as fresh input on what to build next, closing the loop.自我改进。监控/事件响应将生产信号（警报、错误、突发事件）作为新鲜输入反馈回分类阶段，从而闭环。
Orthogonal to the eight stages, we have the context layer. The layer is especially important at the front of the line. Brainstorming is limited to the data it sees: user analytics, competitor analysis, research, transcripts, and documentation. At this stage, a poor context layer directly limits the space of possibilities you can explore. It has a similar impact on planning, where transforming the raw idea into technical specs and tasks depends heavily on how good the examples in the context layer are. If you want to implement a new product-recommendation feature, and you have zero examples, the LLM will just predict the most common thing to do, which often isn’t the best solution for your product.与这八个阶段正交的是上下文层。该层在流水线前端尤为重要。头脑风暴仅限于它所能看到的数据：用户分析、竞争对手分析、研究、转录稿和文档。在此阶段，糟糕的上下文层会直接限制你能探索的可能性空间。它对规划阶段也有类似的影响，将原始构想转化为技术规范和任务，在很大程度上取决于上下文层中的示例质量。如果你想实现一个新的产品推荐功能，但没有任何示例，大模型只会预测最常见的做法，而这往往不是针对你产品的最佳解决方案。
The context layer can take many forms. One strategy that is becoming increasingly popular is the LLM Wiki, a term coined by Andrej Karpathy. It’s basically a strategy to transform your data into a structured knowledge base, just by using files, instead of a database. Factory, via its AutoWiki feature, transforms popular codebases into a structured knowledge base that agents can query instead of parsing the codebase itself. LangChain recently released OpenWiki, a CLI tool to manage wikis for agent memory. If you’re curious, in this article I detail how I turn my data from Obsidian, Readwise, and Google Drive into agent memory via LLM wikis.上下文层可以有多种形式。一种日益流行的策略是 Andrej Karpathy 提出的“LLM Wiki”。这本质上是一种将数据转化为结构化知识库的策略，只需使用文件而非数据库。Factory 通过其 AutoWiki 功能，将流行的代码库转化为智能体可以直接查询的结构化知识库，而无需解析代码库本身。LangChain 最近发布了 OpenWiki，这是一个用于管理智能体记忆 Wiki 的 CLI 工具。如果你好奇，我在本文中详细介绍了如何通过 LLM Wiki 将 Obsidian、Readwise 和 Google Drive 中的数据转化为智能体记忆。
Where the human belongs人类的位置
To see where the human belongs, let’s walk through the factory with an end-to-end example. We’ll build a feature for a shopping-assistant agent on an ecommerce platform similar to Amazon’s. The scenario is that usage data says users aren’t engaging with its recommendations, and we have to ship an improvement.为了明确人类的位置，让我们通过一个端到端的例子来走一遍工厂流程。我们将为类似亚马逊的电子商务平台构建一个购物助手智能体的功能。场景是：使用数据表明用户并未参与其推荐，我们需要发布一项改进。
Brainstorm is where taste lives. Agents do the grunt work: They analyze user activity, scan competitors’ assistants, and pull research into the knowledge base. Then a member of the technical staff starts looking at the data, understands why people are not engaging with the recommendations, explores how the competition implements their solution, and proposes a fix as a feature spec. At this stage, the spec solves a business problem. It doesn’t need to prescribe a technical solution yet.头脑风暴是品味所在。智能体完成繁重的工作：它们分析用户活动，扫描竞争对手的助手，并将研究成果拉入知识库。然后，技术人员开始查看数据，理解用户为何不参与推荐，探索竞争对手如何实现其方案，并提出作为功能规范的修复建议。在此阶段，规范解决了业务问题，还不需要指定具体的技术方案。
Plan is where a human, with the help of the software factory, transforms the feature spec into an implementation plan. Let’s assume that we want to make a change to the recommender engine algorithm. The human chats with the knowledge base, figures out whether it’s feasible, and thinks through architecture, interfaces, data flow, cost, and latency. They then let the agent scan the codebase and grill them until the plan is properly refined into something that fits the codebase. The output is a bunch of tickets plus an ADR explaining the algorithm change and an update to the glossary.规划阶段是人类在软件工厂的帮助下，将功能规范转化为实施计划的地方。假设我们要修改推荐引擎算法。人类与知识库聊天，判断其可行性，并思考架构、接口、数据流、成本和延迟。然后，他们让智能体扫描代码库并进行“拷问”，直到计划被完善到适合代码库为止。产出是一堆工单，外加一份解释算法变更的 ADR 和词汇表更新。
The agent can help within these two stages by quickly scanning through a ton of data and improving the plan, but the human is still central.智能体可以在这两个阶段通过快速扫描海量数据并改进计划来提供帮助，但人类依然处于核心地位。
Use the strongest model (Fable) for brainstorming and planning. These stages burn fewer tokens than implementation itself, but everything downstream depends on them. A well-written plan lets cheaper models (Opus, Sonnet) execute without reasoning their way out of dead ends. A weak plan makes them retry until the extra tokens erase the price gap.在头脑风暴和规划阶段使用最强大的模型（如 Fable）。这些阶段消耗的 Token 比实现阶段少，但下游的一切都取决于它们。一份编写良好的计划可以让更便宜的模型（如 Opus、Sonnet）在不陷入死胡同的情况下执行。而薄弱的计划会让它们反复重试，直到额外的 Token 消耗抵消了价格差距。
With a weak plan, I’ve watched Sonnet on high reasoning out-cost Opus on the same task: The smaller model needs more attempts to reach the same goal. Total cost is tokens × price, not model tier. So more failures equals more reasoning, more tokens, and more cost.在计划薄弱的情况下，我观察到 Sonnet 在高推理模式下的成本甚至超过了 Opus 执行同一任务的成本：较小的模型需要更多尝试才能达到目标。总成本是 Token 数量 × 单价，而非模型等级。因此，失败越多，意味着推理越多，Token 消耗越多，成本也就越高。
From here on, we move into “loop” and “graph” engineering territory.从这里开始，我们进入了“循环”和“图”工程的领域。
Implement runs a software engineer agent that picks up every ticket that’s ready to go. As the loop is scoped to a feature, it takes only the associated tickets. After each ticket is implemented, a QA agent tries to find bugs by stress-testing the application. As agents tend to have a positive bias towards their own work, the split between the software engineer and QA agents matters. As Addy Osmani puts it, the model that wrote the code is “way too nice grading its own homework.” This loop, at solo scale, can be as simple as a bunch of terminals pulling tickets. At larger scale, it runs on remote agents working 24/7.实现阶段运行一个软件工程师智能体，领取每一个准备就绪的工单。由于循环范围限定在特定功能，它只处理相关的工单。每个工单实现后，QA 智能体会通过压力测试应用来寻找 Bug。由于智能体倾向于对自己完成的工作有积极偏见，因此软件工程师智能体和 QA 智能体之间的分工至关重要。正如 Addy Osmani 所言，编写代码的模型在“给自己作业打分时太仁慈了”。在个人规模上，这个循环可以简单到只是一堆终端在拉取工单。而在更大规模上，它运行在 24/7 全天候工作的远程智能体上。
The loop only works if agents can interact with the app. The QA agent needs one command that starts the whole stack reproducibly. From there, it drives the app in the browser, calls the data or fine-tuning pipelines, or hits your server’s API. Whatever your app’s interface is, the agent needs access to it, the same way a human user would.只有当智能体能够与应用交互时，循环才有效。QA 智能体需要一个能以可重复方式启动整个技术栈的命令。从那里开始，它像人类用户一样在浏览器中驱动应用，调用数据或微调流水线，或者访问服务器 API。无论你的应用接口是什么，智能体都需要像人类用户那样访问它。
The key idea is to integrate feedback loops as natively as possible into your software factory. Ideally, you want multiple levels, depending on how expensive it is to run them: linting, unit tests, integration tests, and end-to-end tests. When the loop keeps failing, the root cause is almost always missing plumbing, not the agents.关键在于尽可能原生化地将反馈循环集成到软件工厂中。理想情况下，你需要根据运行成本设置多个级别：Lint 检查、单元测试、集成测试和端到端测试。当循环不断失败时，根本原因几乎总是因为缺少管道连接，而不是智能体本身的问题。
Review has three steps. Step one checks the product and architecture requirements against the ticket and the ADR. Any discrepancy becomes a new ticket passed back to the implement loop. Step two ensures code quality (modularity, naming) and guards against AI slop such as verbose comments or cryptic function names. Step three looks at the CI/CD pipeline. At every step, any failure auto-creates a task picked up by the software agent.审查阶段分为三步。第一步根据工单和 ADR 检查产品和架构要求。任何差异都会变成一个新的工单传回实现循环。第二步确保代码质量（模块化、命名），并防止 AI 产生的垃圾代码，如冗长的注释或晦涩的函数名。第三步查看 CI/CD 流水线。在每一步中，任何失败都会自动创建一个任务，由软件智能体接手。
Not every project needs all three steps. The “factory” ends with a PR that you as a human need to review and merge. But in reality, if you spend enough time creating a strong plan, the PR that reaches you is usually ready to ship as-is.并非每个项目都需要这三个步骤。“工厂”以一个 PR 结束，你需要作为人类进行审查和合并。但现实中，如果你投入足够的时间制定了强有力的计划，到达你手中的 PR 通常已经可以直接发布了。
So where does the human belong? You’re indispensable during brainstorming and planning, and you return for the final check. Agents own everything in between. OpenAI took this to the extreme: ~1M lines and ~1,500 merged PRs over five months with zero hand-written lines. Their framing is “Humans steer. Agents execute.”那么人类的位置在哪里？你在头脑风暴和规划阶段是不可或缺的，最后还需要回来进行最终检查。智能体拥有中间的一切。OpenAI 将这一点推向了极致：五个月内，约 100 万行代码和约 1500 个合并的 PR，完全没有手写代码。他们的框架是“人类指挥，智能体执行”。
Don’t overbuild the factory不要过度构建工厂
With my first Squid version (my own software factory), I got greedy and chased full autonomy: big remote workflows, parallel agents, and one grand pipeline running end to end. It worked, until something went offscript. Which it usually does. I couldn’t debug it, couldn’t halt it mid-run, and couldn’t redirect it without throwing the run away. It was a big monolith that took me too far out of the loop, and I couldn’t control it.在使用第一版 Squid（我自己的软件工厂）时，我变得贪心，追求完全自主：庞大的远程工作流、并行智能体以及一个端到端运行的大型流水线。它确实有效，直到某些事情偏离了剧本——而这种情况通常都会发生。我无法调试它，无法在中途停止它，也无法在不丢弃运行结果的情况下重定向它。它是一个庞大的单体，让我脱离了循环，无法掌控。
I realized you need two options. The first is granular commands that let you grill your plan, implement a specific task, or review one particular step. The second, for when you’re comfortable giving the agent 24/7 autonomy, is an end-to-end command that chains all the smaller ones into a fully autonomous graph, such as one big /plan and /implement-review-all command. Basically, each step is a “loop,” while the whole pipeline is the “graph” of your software factory. Still, note how planning and the rest are split into two different commands, as planning is, and always will be, human-driven (at least if you want the result to stay aligned with what you actually want).我意识到你需要两个选项。第一个是细粒度命令，让你拷问计划、实现特定任务或审查特定步骤。第二个选项是针对你放心交给智能体 24/7 自主运行的情况，即一个端到端命令，将所有小步骤串联成一个完全自主的图，例如一个大的 /plan 和 /implement-review-all 命令。基本上，每一步都是一个“循环”，而整个流水线就是你软件工厂的“图”。不过，请注意规划阶段和其余部分是如何拆分为两个不同命令的，因为规划是，且永远将是人类驱动的（至少如果你希望结果与你的真实意图保持一致的话）。
Bottom line. You need to be able to step in, halt it, redirect it, and interrupt it, while still having the option to go fully autonomous.总结：你需要能够介入、停止、重定向和中断它，同时仍然拥有完全自主运行的选项。
The bottleneck is me, and that’s by design. To be honest, I’ve worked mostly solo since the AI coding agent boom, and I don’t understand who the people shipping 100 features in parallel are. Most of my features (per project) build on one another, which makes them impossible to parallelize. As the project grows, you can find more and more independent features that can be implemented in parallel, but I still believe that number is limited.瓶颈是我自己，这是设计使然。老实说，自 AI 编码智能体爆发以来，我大多是独自工作，我不明白那些并行交付 100 个功能的人是怎么做到的。我的大多数功能（按项目计算）都是建立在彼此之上的，这使得它们无法并行化。随着项目增长，你可以找到越来越多可以并行实现的独立功能，但我仍然认为这个数量是有限的。
That’s why, when I parallelize, I only use local agents, each running in an isolated codebase via worktrees. So far, I’ve never felt the need for 24/7 remote agents, or wanted the overhead of managing them.这就是为什么当我进行并行化时，我只使用本地智能体，每个智能体都在通过工作树（worktrees）隔离的代码库中运行。到目前为止，我从未感到需要 24/7 全天候的远程智能体，也不想承担管理它们的开销。
A big team can justify more automation, but it has to earn it. So as with any other software product, start small, start by automating the most time-consuming bottlenecks, and add complexity gradually as people get comfortable with the system. Don’t be like me, with my Squid experiment.大团队可以证明更多自动化的合理性，但它必须证明其价值。因此，像对待任何其他软件产品一样，从小处着手，先自动化最耗时的瓶颈，随着人们对系统的熟悉程度提高，逐步增加复杂性。不要像我做 Squid 实验那样。
Build vs. buy自研与采购
In all scenarios, you’ll start with a prebuilt coding harness. The most popular vendor-locked ones are Claude Code and Codex. Or go open source with OpenCode or Pi, which took off thanks to its minimalist, extensible architecture that lets you easily build on top of it.在所有场景下，你都会从预构建的编码工具链开始。最流行的供应商锁定方案是 Claude Code 和 Codex。或者选择开源的 OpenCode 或 Pi，后者凭借其极简、可扩展的架构脱颖而出，让你能够轻松在其上进行构建。
But picking a harness isn’t the same as knowing how to configure it and wire it into your software factory. That’s why everyone needs to know, at least intuitively, how a coding agent works under the hood: the agent loop running in your terminal, what changes when it runs remotely, how you evaluate it, and which context engineering strategies keep it cheap without making it dumber. If you want to learn more about building a coding agent from scratch, consider exploring my open source course on GitHub. Even if you never plan to build your own harness, that intuition is what lets you become a power user.但选择工具链并不等同于知道如何配置它并将其接入你的软件工厂。这就是为什么每个人都需要至少在直觉上了解编码智能体在底层是如何工作的：运行在终端中的智能体循环、远程运行时发生了什么变化、如何评估它，以及哪些上下文工程策略可以在不降低智能体智力的情况下降低成本。如果你想了解更多关于从零构建编码智能体的内容，可以考虑探索我在 GitHub 上的开源课程。即使你从不打算构建自己的工具链，这种直觉也能让你成为高级用户。
For a small team, you’ll get extremely far just by defining a set of skills and agents that encode your process on top of the coding harness (a.k.a. your software factory). To keep it simple, this is what I did with Squid, which I use to implement all my projects.对于小团队来说，只需在编码工具链之上定义一套编码你流程的技能和智能体（即你的软件工厂），就能走得很远。为了保持简单，这就是我在 Squid 上所做的，我用它来实现我所有的项目。
There are other off-the-shelf “software factories” powered just by skills and agents defined in .md files, such as Matt Pocock’s skills repository or the BMad method.还有其他现成的“软件工厂”，仅由 .md 文件中定义的技能和智能体驱动，例如 Matt Pocock 的技能存储库或 BMad 方法。
But remember that the factory is mostly about processes, not tools: A factory that doesn’t fit how your team already works adds friction, never gets adopted, and ends up useless.但请记住，工厂主要关乎流程，而非工具：一个不符合团队现有工作方式的工厂只会增加摩擦，永远不会被采用，最终毫无用处。
You cross the buy line the moment engineers you don’t personally supervise run agents. Observability, tracing, cost tracking, and pay-per-token billing stop being optional and become someone’s full-time job. Agent swarms wired into Linear, Slack, and CI across distributed infrastructure are a logistical hell that isn’t your product. That’s when it makes sense to look into off-the-shelf solutions such as Factory.ai (that comes with the Droid agent), or Warp’s Oz. In Warp CEO Zach Lloyd’s words, “Most of the factory is not necessarily a new interface. It is an integration into people’s existing workflows.”当你不再亲自监督的工程师开始运行智能体时，你就跨越了采购的界限。可观测性、追踪、成本跟踪和按 Token 付费不再是可选项，而变成了某人的全职工作。接入 Linear、Slack 和 CI 的分布式智能体集群是一场物流噩梦，而那并不是你的产品。这时，考虑 Factory.ai（自带 Droid 智能体）或 Warp 的 Oz 等现成解决方案才有意义。用 Warp 首席执行官 Zach Lloyd 的话说：“工厂的大部分内容不一定是一个新界面，而是对人们现有工作流的集成。”
At the other end of the spectrum, you cross back to building when the platform’s constraints cost more than the team it would take to replace it, as OpenAI’s report on its Codex-built product shows.在光谱的另一端，当平台的约束成本超过了替换它所需的团队成本时，你就回到了自研，正如 OpenAI 关于其 Codex 构建产品的报告所显示的那样。
The smallest builds, the middle buys, and the largest builds again.最小的自研，中间的采购，最大的再次自研。
What’s next下一步是什么
Someone is already coining next quarter’s “_____ engineering” term as we speak. But the software engineering processes you use to output real code won’t change that often. That’s why you should be open-minded but at the same time focus on actionable outcomes, not on overthinking how to label things.此时此刻，已经有人在构思下个季度的“……工程”术语了。但你用来输出实际代码的软件工程流程不会那么频繁地改变。这就是为什么你应该保持开放的心态，同时专注于可落地的成果，而不是过度思考如何给事物贴标签。
As Zach Lloyd suggests: Find one “annoying part of your job” and build the smallest loop that handles it.正如 Zach Lloyd 所建议的：找到你工作中“最烦人的部分”，并构建处理它的最小循环。
The harsh reality is that software factories are just at the beginning. They’re far from perfect, and especially far from being fully “autonomous.” Usually, when someone claims they’ve cracked the software factory problem, they either haven’t tested the idea enough or are trying to sell it to you. I’m confident we’ll reach the point where almost the entire software development lifecycle is automated (with the exception of brainstorming and planning), but at the moment we’re still figuring things out.残酷的现实是，软件工厂才刚刚起步。它们远非完美，更远未达到完全“自主”。通常，当有人声称他们已经攻克了软件工厂难题时，要么是他们没有充分测试这个想法，要么是试图把它卖给你。我相信我们会达到几乎整个软件开发生命周期都自动化的程度（头脑风暴和规划除外），但目前我们仍在摸索中。
But here’s what I’m wondering:但我一直在思考：
Which stage of your factory still needs you the most? I keep automating mine, and the bottleneck stubbornly stays at planning.你工厂的哪个阶段最需要你？我一直在自动化我的工厂，但瓶颈顽固地停留在规划阶段。
Explore next继续探索
- Osmani, A. (2025). “Loop Engineering.” X.
https://x.com/addyosmani/status/2064127981161959567Osmani, A. (2025). “循环工程.” X. https://x.com/addyosmani/status/2064127981161959567 - MacManus, R. (2026). “AIEWF Daily Dispatch: Loops, Software Factories & Forward Deployed Engineers.” Latent Space.
https://www.latent.space/p/aiewf-daily-dispatch-loopsMacManus, R. (2026). “AIEWF 每日快讯：循环、软件工厂与前线部署工程师.” Latent Space. https://www.latent.space/p/aiewf-daily-dispatch-loops - Factory.ai. (n.d.). Agent-Native Software Development Platform. https://factory.aiFactory.ai. (n.d.). 智能体原生软件开发平台. https://factory.ai
- Osmani, A. (2025). “Software Factories, Light and Dark.” X.
https://x.com/addyosmani/status/2079442194449232227Osmani, A. (2025). “软件工厂，光明与黑暗.” X. https://x.com/addyosmani/status/2079442194449232227 - Karpathy, A. (n.d.). LLM-Wiki. GitHub.
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94fKarpathy, A. (n.d.). LLM-Wiki. GitHub. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f - Abboud, M. (n.d.). “How Coding Agents Actually Work: Inside OpenCode.”
https://cefboud.com/posts/coding-agents-internals-opencode-deepdive/Abboud, M. (n.d.). “编码智能体是如何工作的：走进 OpenCode.” https://cefboud.com/posts/coding-agents-internals-opencode-deepdive/ - Kapoor, S. (n.d.). “Building and Evaluating AI Agents.” AI Engineer.
https://youtube.com/watch?v=d5EltXhbcfAKapoor, S. (n.d.). “构建与评估 AI 智能体.” AI Engineer. https://youtube.com/watch?v=d5EltXhbcfA - OpenAI. (n.d.). “Harness Engineering: Leveraging Codex in an Agent-First World.”
https://openai.com/index/harness-engineering/OpenAI. (n.d.). “工具链工程：在智能体优先的世界中利用 Codex.” https://openai.com/index/harness-engineering/ - Parsons, C. (n.d.). “Ralph Loops: Build Dumb AI Loops That Ship.” AI Engineer.
https://www.youtube.com/watch?v=2TLXsxkz0zIParsons, C. (n.d.). “Ralph 循环：构建能交付产品的笨拙 AI 循环.” AI Engineer. https://www.youtube.com/watch?v=2TLXsxkz0zI - Pocock, M. (n.d.). “Software Fundamentals Matter More Than Ever.” AI Engineer.
https://www.youtube.com/watch?v=v4F1gFy-hqgPocock, M. (n.d.). “软件基础比以往任何时候都重要.” AI Engineer. https://www.youtube.com/watch?v=v4F1gFy-hqg - MacManus, R. (2026). “Warp CEO Zach Lloyd on Why Software Factories Are the Next Phase of Coding.” Latent Space.
https://www.latent.space/p/software-factoriesMacManus, R. (2026). “Warp 首席执行官 Zach Lloyd 谈为何软件工厂是编码的下一阶段.” Latent Space. https://www.latent.space/p/software-factories - Iusztin, P. (2026). “Building a Coding Agent From Scratch: Harness Architecture.” Decoding AI.
https://www.decodingai.com/p/building-a-coding-agent-from-scratch-system-designIusztin, P. (2026). “从零构建编码智能体：工具链架构.” Decoding AI. https://www.decodingai.com/p/building-a-coding-agent-from-scratch-system-design - Iusztin, P. (2026). Building a Coding Agent from Scratch Course. GitHub.
https://github.com/decodingai-magazine/building-a-coding-agent-from-scratch-courseIusztin, P. (2026). 从零构建编码智能体课程. GitHub. https://github.com/decodingai-magazine/building-a-coding-agent-from-scratch-course - Iusztin, P., & Bouchard, L.-F. (2026). “LLM Wikis as Living Memory for AI Agents.” Decoding AI.
https://www.decodingai.com/p/llm-wiki-agent-memoryIusztin, P., & Bouchard, L.-F. (2026). “LLM Wiki 作为 AI 智能体的动态记忆.” Decoding AI. https://www.decodingai.com/p/llm-wiki-agent-memory
Join 44,000+ engineers eager to learn how to build their own software factories by subscribing to Decoding AI Magazine!订阅 Decoding AI 杂志，加入 44,000 多名渴望学习如何构建自己软件工厂的工程师行列！
