# How I use Linear to manage agents (and why we should all be building software factories)
**作者**: Fred Jonsson
**日期**: 2026-07-19T14:31:20.000Z
**来源**: [https://x.com/enginoid/status/2078850177926938666](https://x.com/enginoid/status/2078850177926938666)
---
Linear is probably my best-value subscription at the moment. I pay the sole user fee of $12/mo and the company agents have eaten through ~400 issues in the past month.
I use Linear to organize my tickets and feed them into coding agents to do in parallel. Linear is a central place of coordination and a great interface for me to organize the work at my laptop and on the go.
What I have today is a fairly low-tech and crude prototype compared to how I want it to be, at software factory automation level 5. Unfortunately, it gets the job done well enough that I'm forced to work on my product rather than play software Factorio.
## Tickets are organized into an an outcome hierarchy
When vanilla agents manage tickets, they scatter tickets rather creatively in the backlog, and often use their own cryptic lingo, like "Fix gated-access exception in owned-compute handler."
For my own clarity of what needs to be done (which is the whole point of Linear), I've set them up to maintain a hierarchy of tickets named after outcomes rather than the technical task.
Tasks are organized into a hierarchy of outcomes. (They typically end up containing more technical subtasks as agents start executing.)
Arranging the tickets as a tree means that I can encourage agents to finish trees of epics down to the root, and it gives me a high-level sense of progress.
This is something that I've always found to work well in teams, but works exceptionally with agents because unlike most of us, they are very happy to actually organize the backlog.
Triage is an inbox for future prompts
The agents work on 3-5 "workstreams" at a time, that are determined not to change the same code area (by an LLM workflow). To avoid interrupting that process, I report issues into the triage inbox rather than starting new agents when I see issues.
I don't have to think about prioritization for what I put into the triage inbox - I just drop anything I can think of that needs doing. This ticket started out as a screenshot, and later got fleshed out according to the agents' "ticket intake guidelines."
This ticket started out as just the screenshot that I dropped into triage, and got expanded by the agent into something clearer. The Triage inbox has become a key way for me to drop things that need fixing.
## Formatting tickets for agents
The ticket is the contract between me and the agent, kind of like a plan, but to make them maximally readable to humans, they all have a "Goal", "Why" and "Outcomes" section. This is to help me remember clearly what a ticket is about, and to give the agent a good shot of solving the real need.
Focusing on the target state avoids overly constraining the implementation approach. At the point of defining a ticket, the code is typically not deeply researched, so the exact approach is best left up to the implementing agent. As in human teams, implementer autonomy works great for agents if they have a clear standard to work to.
To help the agent, there are two more sections:
- Implementation approach: where we do inject any guidance on implementation approach, usually coming from me.
- Verifications: Created by the ticket-authoring agent under strict guidance about the minimal testing procedure for new features. They generally always include "Automated", "Manual" and "Visual" checks. (I'm planning to replace manual checks with automated ones for repeatability in the future. These checks would depend on a robust computer-use agent.)
An agent will be blocked from closing a task if any of the checklist items are unchecked, to avoid cheating or hasty work. (The agent can, of course, still cheat or remove checkboxes -- but in practice they don't as it requires a higher degree of dishonesty than typical "I'm done" declarations.)
## Organizing work into batches
I've found the best balance by organizing work into batches of 3-5 parallel workstreams. Depending on the day and the size of the work in each batch, these batches can take from 30 minutes to 4+ hours, yielding 2-4 batches in a day.
Driver: My own quality of life
An important philosophy of this system is my own quality of life. The batches are unsupervised (and Claude's AskUser hook is blocked – so it doesn't ask a question after 15 minutes and do nothing for 2 hours).
Because agents like to ask you to unblock by taking actions on the computer like logging into a browser, it was important to tell the agents that the agent is unsupervised ("but monitored for quality and safety", in a feeble but low-effort attempt to reduce cheating or sabotage).
This buys me back focus to do deep work and do my reviews and kick-offs in chunks, rather than the exhausting affair of task-switching between agent windows all day.
How batches work
To create a batch, I use a a "workstream update" skill, which:
1. Makes sure anything in progress is actually in progress, and makes other work available to pick up.
2. Reads any new tickets that have come in from me or other agents (via triage).
3. Loads up on priorities - focusing on finishing work in progress, looking at steer from me and weekly goals, and seeing if anything new is urgent.
4. Proposes 4-5 agent prompts that I paste into the agents.
A workstream update is essentially a document that starts with high level context...
...and contains 3-5 segments of tasks assigned to agents. The agent that does the workstream update is prompted to make each section nonoverlapping in terms of area of the code, but to assign workstreams to agents that meaningfully advance a current goal.
When I said the system was low-tech earlier, I meant it: I paste each workstram prompt into Codex, Claude Code, Cursor or Antigravity.
Requiring work to be complete
In the early iterations, I had a lot of issues with different agents fail to complete the assigned work. I want the agent to fully close the ticket (which includes merging the change), but agent would stop at various points before the full job was done: before committing code, before creating a PR, before marking it as ready to review, before it passes tests and reviews, before it's successfully merged, and before checking all checkboxes in the ticket.
To overcome this, I've gone to great lengths to make the agents actually finish work. This is a messier problem when you work with multiple harnesses and don't have a simple API to invoke the agent, so you have to rely on hooks rather than a typical workflow approach.
At this point, agents typically do finish their work. If they don't, they have to mark the ticket as either "Blocked" and raise a formal escalation for human help according to a human escalation standard (see below.)
Through prompts and hooks, the agent is required to:
- Register an "agent session", tied to the tickets.
- Mark the tickets in progress.
- Work on the tickets.
- Submit PRs and ensure they are merged and deployed.
- Ensure all code is pushed and in a PR.
- Tick off all checkboxes in each ticket.
- Ensure all the tickets are marked as closed or blocked.
- Upload a transcript of the session, for root cause analysis.
- Mark the agent session as complete. (If the session was interactive – eg. if I asked some questions about the codebase that were not related to a ticket, the agent can ask for a "waiver" to follow formal closeout that would ordinarily require tickets that are verified as done.)
The hooks were essential to ensure that the agents were finishing their tasks. There are occasional false positives where an agent blocks on an issue that a human is not needed for – for example, when our MCP server doesn't support a tool that they need but they actually have the ability to just deploy a new tool to the MCP server. But for the most part, they're good about finishing.
## Human escalations
Much of my work now is around access control - creating accounts and moving secrets from hither to thither.
Agents are notoriously bad at assigning work to humans, because they have the curse of knowledge – they generally expect that you have exactly the same mental state, and that you know exactly what they mean by "needing this to deploy the component quality ratchet."
They also love giving you tasks that take fifteen minutes rather than two, by saying things like "add a GitHub app" rather than giving the exact instructions and configuration.
To combat this, I've prompted them to be careful in their phrasing of human escalations and assume that the human is very busy, really not in the headspace. The human knows very little about the code, the problem being solved, or why they are even there. I also ask them to go out of their way to make it easy for the human to do the work quickly without much thinking (eg. by writing scripts.)
Lastly, I ask them to ensure that all other unblocked work proceeds optimistically, so that there is a minimal amount of work to complete the task when the human escalation is resolved.
## Linear + agent quirks
In general, Linear's MCP server works really well, but I did need to make three minor adjustments to the interface with Linear. Those were just enough to replace their MCP server with our own:
- Support for updating ticket summaries through diffs. Agents had a tendency to post their updates through keeping the ticket description correct. This is generally good behavior, but they would tend to completely override the verification criteria and other nice details of the original ticket, which is important for the reviewer agent. So I banned direct edits but gave the LLMs a tool to send diffs for patches.
- Giving agents their own identity, rather than mine. The Linear MCP server uses your personal OAuth by default. I had to quickly switch to giving the agents a different MCP server with an app-based authentication and identity. I wasn't getting any notifications when agents assigned tasks to me, as they were operating as me, and a lot of the time I was confused about whether the agent had closed a task or I had.
- Minor ergonomics. The `get_issue` command that comes through the vanilla MCP server wouldn't always return enough context for the agents, including comments and subtasks, so this ensures that they have the full picture without having to "remember" to ask for everything.
## How it's working
This system works really well and was an exceptional improvement over my previous attempts to think hard to assign tickets work, and monitor completions reactively.
Linear is a joy to use for task management and is especially wonderful on the go. The agents have done a tremendous amount of work through this system and they seem to benefit from the context they can get from the ticket templates.
Because the format is human-optimized and outcome-focused, I also have an easy time verifying the tickets are asking for the right things. Overall, my attention scales a lot better than it did before I implemented this system.
I was able to prototype this quickly just using desktop agent harnesses, which was quick but also a constraint due to how much cheaper subscription tokens are. I'll probably keep this setup for some time, because it's practical and because for better or for worse, software factories are not my main business.
The hacks that I use to manage the state machine from a ticket to a completed code need to be replaced with a proper state machine, so the system can be more easily measured (eg. for completion rate and defect rate), progressed (when things get stuck) and continually improved.
Most of the things I want to improve require breaking out of the restrictions of using a harness:
- Replacing hooks with workflows. The hacks I've put in place to manage "agent sessions" are deeply disturbing. It tracks what agents are active, but also allows root-cause analysis into agents that are slow or produce bad results. But this heinous implementation requires the agent to go rummaging for transcripts to upload, in locations that depend on the harness. If I wasn't dependent on subscriptions for economics, it would be much more pleasant to just invoke the agents via API from the linear tickets and manage agent session postconditions through a proper workflow representation.
- Workflows with measurement. I'm a big fan of process management, continuous improvement and the Toyota Production System. All of those juicy ideas apply remarkably well to software factories -- all that's left is capturing metrics (like completion rate, defect rate and variance) and starting to systematically improve the low-hanging fruit.
- Evals. Since much of my work is around evals and I depend very strongly on coding agents, it feels ironic that I don't have evals for my own coding agents. It would be extremely useful to be able to repeat the same task under different guidance, and run the whole suite at least weekly. But they're a little annoying to set up when you're using multiple harnesses, so I haven't bothered. It feels like I'm standardizing around OpenAI, which conveniently doesn't consider it a ToS violation, so this could be coming soon and is probably the low-hanging fruit for me now.
## Software factories are the future, and now's the time to get them right
I'm interested in hearing from more people working on software factories, and so I want to make the case for why software engineers should be enthusiastically working on them.
There's considerable divide, and maybe awkward hesitation, on whether we should be building towards software factories – systems that generate production-quality software with humans working at their highest leverage.
Whether they're "real" or not, in the same way there was divide whether agents would be widely used for coding 2-3 years ago. The companies who best acted on the belief that LLMs would write good code created extreme value in the software world – and have been acquired in amounts ranging from $2.5 to $60 billion. This suggests that it can be valuable to be optimistic, and plan for success when the signs are there.
The biggest symptom that there is a divide today is that many people are now discussing whether it's a worthwhile goal to automate code review, or whether engineers should read every PR. "Do you look at the code?" is a question I get asked a lot by other engineers who are also trying to figure out the right balance.
I'm surprised by the hesitation that we have about software factories being the future. To me, it's obvious that it is worth automating everything that is possible to automate, as long as that automation can successfully deliver production-grade software.
The signs that it's possible are clearer than ever, and while we're probably going to see industry-wide tools and patterns emerge, there are steps that all teams can be taking to start taking advantage of automation today and building towards the metaphorical puck.
To make that automation work well for software engineers as professionals and build workflows that allow us to do energizing work, we should take an active part in shaping it rather than let it happen to us. Do we want to spend all our time reviewing PRs and approving agent actions, or do we want to design systems that allow us deep work and creativity? These world are equally possible and depend largely on the effort we put into making software factories human-friendly.
Software factories are worthwhile in the same way coding agents are worthwhile – the benefits will be too good to ignore, and unless you build software as a hobby, you will will have to go there for competitive reasons whether you like the idea of automating software or not.
The most advanced companies today are working on the review/verification bottleneck. Next comes the long-horizon bottleneck. Then there will be token cost bottleneck. Then perhaps the specification bottleneck. At some point, the user validation bottleneck. It feels like the fundamental pieces are here already, and that it's about composition and economics. We are already in an industrial revolution.
So the question isn't whether, but how. In the past we used waterfall, scrum, extreme programming (and many other buzzwords) to organize these activities into a system that reliably produced software, hopefully on schedule and under budget.
These methodologies made sense, because human development of software takes place in a complex adaptive network rather than through controllable processes. Whenever we tried to introduce heavyweight processes, we discovered that it just doesn't work well with human cognition or motivation to deliver a 30 page document before building anything.
My personal bet is that outside of the human parts, most of the mechanics of delivering code seem better modelled than an industrial process: something that is rigorously defined and dependent on standardization, measurement, and process control.
The role of humans will be:
- Understanding what needs building.
- Instructing building to happen in the right way, typically out of band from the specific task. (At the "factory" level.)
- At the task execution level, lend creativity, intuition and foresight into research, sensemaking, and optimization tasks.
- Evaluating whether delivered software meets professional and human desirability standards.
- Building, maintaining and improving the factories the make software.
The most exciting times in technology have always been when lots of people are trying to solve the same problem and everyone brings their own insight and experiences – this was certainly the case in the evolution of the interactive web (from jQuery to React) and web applications (from Rails to Django and FastAPI). Everyone was sharing what was working, and it was a really fun time.
It'd be great to expedite how much we talk about software factories by getting the awkward bit out of the way: acknowledging that they are definitely happening.
I'm curious to see work from people who are trying to build software factories and to hear about what's working and what isn't, so we can all figure out and build the best future of software together.
## 相关链接
- [Fred Jonsson](https://x.com/enginoid)
- [@enginoid](https://x.com/enginoid)
- [9.6K](https://x.com/enginoid/status/2078850177926938666/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:31 PM · Jul 19, 2026](https://x.com/enginoid/status/2078850177926938666)
- [9,654 Views](https://x.com/enginoid/status/2078850177926938666/analytics)
---
*导出时间: 2026/7/20 10:11:43*
---
## 中文翻译
# 我如何使用 Linear 管理代理（以及为什么我们都应该构建软件工厂）
**作者**: Fred Jonsson
**日期**: 2026-07-19T14:31:20.000Z
**来源**: [https://x.com/enginoid/status/2078850177926938666](https://x.com/enginoid/status/2078850177926938666)
---
Linear 目前大概是我物超所值的订阅服务。我支付的是唯一的单用户费用，每月 12 美元，而公司的代理们（agents）在过去一个月里已经处理了大约 400 个议题。
我使用 Linear 来整理我的工单（tickets），并将它们输入给编码代理以并行处理。Linear 是一个协调的中心，也是我在笔记本电脑上和移动中组织工作的绝佳界面。
与我期望达到的“软件工厂自动化第 5 级”相比，今天的这套系统只是一个相当低技术且粗糙的原型。不幸的是，因为它能很好地完成工作，我不得不专注于我的产品，而不是玩“异星工厂”这款软件游戏。
## 工单按结果层级组织
当普通的代理管理工单时，它们会相当有创意地将工单散落在待办事项中，并且经常使用自己晦涩的行话，比如“Fix gated-access exception in owned-compute handler”（修复自有计算处理程序中的门控访问异常）。
为了我自己清楚需要做什么（这也是 Linear 的全部意义所在），我设置了它们来维护一个以结果而非技术任务命名的工单层级结构。
任务被组织成一个结果层级结构。（随着代理开始执行，它们通常会包含更多技术性的子任务。）
将工单排列成树形结构意味着我可以鼓励代理完成从史诗（epics）到根节点的整棵树，这让我能对进度有一个高层次的把握。
这对我来说一直是在团队中运作良好的方法，但对于代理来说效果出奇地好，因为不像我们大多数人，它们非常乐意真正地去整理待办事项。
Triage（分类）是未来提示词的收件箱
代理一次处理 3-5 个“工作流”（workstreams），这些工作流被确定为不会更改相同的代码区域（由 LLM 工作流决定）。为了避免打断这个过程，当我发现问题时，我会将问题报告到分类收件箱，而不是立即启动新的代理。
我不需要对放入分类收件箱的内容进行优先级思考——我只是把任何我能想到需要做的事情都丢进去。这个工单最初只是一张截图，后来根据代理的“工单接收指南”进行了充实。
这个工单最初只是我丢进分类里的一张截图，后来被代理扩展成了更清晰的内容。Triage 收件箱已成为我丢弃需要修复内容的关键方式。
## 为代理格式化工单
工单是我和代理之间的契约，有点像计划，但为了让人能最大限度地阅读，它们都有“目标”、“原因”和“结果”部分。这是为了帮助我清楚地记住一个工单是关于什么的，并给代理一个解决真正需求的良好机会。
关注目标状态可以避免过度限制实现方法。在定义工单时，代码通常没有被深入研究，所以确切的方法最好留给实现的代理来决定。就像在人类团队中一样，如果代理有明确的标准可以遵循，实施者的自主性对它们来说非常有效。
为了帮助代理，还有另外两个部分：
- 实现方法：在这里我们会注入任何关于实现方法的指导，通常来自我。
- 验证：由编写工单的代理在关于新功能的最小测试程序的严格指导下创建。它们通常总是包括“自动”、“手动”和“视觉”检查。（我计划在未来用自动检查替换手动检查以保证可重复性。这些检查将依赖于一个强大的计算机使用代理。）
如果任何清单项目未被勾选，代理将被阻止关闭任务，以避免作弊或草率的工作。（当然，代理仍然可以作弊或删除复选框——但在实践中它们不会，因为这需要比典型的“我完成了”声明更高程度的欺骗。）
## 将工作组织成批次
我发现通过将工作组织成 3-5 个并行工作流的批次，可以达到最佳平衡。根据日期和每批次工作量的大小，这些批次可能需要 30 分钟到 4 小时以上，一天可以产出 2-4 个批次。
驱动因素：我自己的生活质量
这个系统的一个重要哲学是我自己的生活质量。这些批次是无监督的（并且 Claude 的 AskUser 钩子被阻止了——所以它不会在 15 分钟后问一个问题然后什么都不做 2 个小时）。
因为代理喜欢让你通过在计算机上采取行动（比如登录浏览器）来解除阻塞，所以告诉代理它是无监督的这一点很重要（但“受到质量和安全的监控”，这是一种软弱但低投入的尝试，旨在减少作弊或破坏）。
这为我赢回了专注力，让我可以进行深度工作，并分批进行审查和启动，而不是整天在代理窗口之间进行令人精疲力竭的任务切换。
批次如何工作
要创建一个批次，我使用一个“工作流更新”技能，它会：
1. 确保任何进行中的工作确实在进行中，并使其他工作可供接手。
2. 阅读任何来自我或其他代理的新工单（通过分类）。
3. 加载优先级——专注于完成进行中的工作，查看我的指导和每周目标，并看看是否有任何新情况是紧急的。
4. 提出 4-5 个代理提示词，我将它们粘贴到代理中。
工作流更新本质上是一个以高层上下文开始的文档......
......并包含 3-5 个分配给代理的任务段。执行工作流更新的代理被提示使每个部分在代码区域上不重叠，但要将工作流分配给能有意义地推进当前目标的代理。
当我说这个系统是低技术时，我是认真的：我将每个工作流提示词粘贴到 Codex、Claude Code、Cursor 或 Antigravity 中。
要求工作必须完成
在早期的迭代中，我遇到了很多不同代理未能完成分配工作的问题。我希望代理完全关闭工单（包括合并更改），但代理会在整个工作完成之前的各个点停下来：在提交代码之前、在创建 PR 之前、在标记为准备审查之前、在通过测试和审查之前、在成功合并之前，以及在检查工单中的所有复选框之前。
为了克服这个问题，我竭尽全力让代理真正完成工作。当你使用多个束线并且没有一个简单的 API 来调用代理时，这是一个更混乱的问题，所以你必须依赖钩子而不是典型的工作流方法。
此时，代理通常会完成它们的工作。如果它们没有，它们必须将工单标记为“Blocked”（阻塞），并根据人工升级标准提出正式的人工升级请求（见下文）。
通过提示词和钩子，代理被要求：
- 注册一个“代理会话”，与工单绑定。
- 标记进行中的工单。
- 处理工单。
- 提交 PR 并确保它们被合并和部署。
- 确保所有代码都被推送并在 PR 中。
- 勾选每个工单中的所有复选框。
- 确保所有工单都被标记为已关闭或已阻塞。
- 上传会话记录，用于根本原因分析。
- 将代理会话标记为完成。（如果会话是交互式的——例如，如果我问了一些与工单无关的代码库问题——代理可以请求“豁免”，以遵循正式的关闭程序，该程序通常需要被验证为已完成的工单。）
钩子对于确保代理完成它们的任务是必不可少的。偶尔会有误报，即代理在一个不需要人工的问题上阻塞——例如，当我们的 MCP 服务器不支持它们需要的工具，但它们实际上有能力直接向 MCP 服务器部署一个新工具时。但在大多数情况下，它们在完成工作方面做得很好。
## 人工升级
我现在的大部分工作都围绕访问控制——创建账户和将秘密从这里移动到那里。
代理在分配工作给人类方面出了名地糟糕，因为它们受到“知识的诅咒”——它们通常期望你拥有完全相同的精神状态，并且你确切地知道它们所说的“需要这个来部署组件质量棘轮”是什么意思。
它们还喜欢给你需要十五分钟而不是两分钟的任务，通过说“添加一个 GitHub 应用程序”而不是给出确切的指令和配置。
为了解决这个问题，我提示它们在人工升级的措辞上要小心，并假设人类非常忙碌，真的不在状态。人类对代码、正在解决的问题，甚至他们为什么在那里知之甚少。我还要求它们尽力让人类能够快速完成工作而无需太多思考（例如，通过编写脚本）。
最后，我要求它们确保所有其他未阻塞的工作乐观地进行，以便当人工升级解决时，完成任务的工作量最少。
## Linear + 代理的怪癖
总的来说，Linear 的 MCP 服务器工作得非常好，但我确实需要对与 Linear 的接口做三个小的调整。这些调整足以用我们自己的服务器替换它们的 MCP 服务器：
- 支持通过差异更新工单摘要。代理倾向于通过保持工单描述正确来发布它们的更新。这通常是好的行为，但它们倾向于完全覆盖验证标准和原始工单的其他好的细节，这对审查代理很重要。所以我禁止了直接编辑，但给 LLM 提供了一个发送补丁差异的工具。
- 给代理它们自己的身份，而不是我的。Linear MCP 服务器默认使用你的个人 OAuth。我不得不迅速切换到给代理一个不同的 MCP 服务器，使用基于应用程序的身份验证和身份。当代理给我分配任务时我没有收到任何通知，因为它们作为我操作，而且很多时候我很困惑是代理关闭了任务还是我关闭的。
- 次要的人体工程学。通过原始 MCP 服务器传递的 `get_issue` 命令不会总是返回足够的上下文给代理，包括评论和子任务，所以这确保它们拥有完整的画面，而不必“记住”要求一切。
## 它是如何工作的
这个系统工作得非常好，比我之前试图努力分配工单工作和被动监控完成的尝试有了显著的改进。
Linear 在任务管理方面使用起来非常愉快，尤其是在移动中。代理通过这个系统完成了大量的工作，它们似乎从工单模板中获得的上下文中受益匪浅。
因为格式是针对人类优化的且以结果为中心，我也很容易验证工单是否要求了正确的事情。总的来说，我的注意力比实施这个系统之前扩展得更好。
我能够仅使用桌面代理束线快速制作原型，这很快，但由于订阅令牌便宜得多，这也是一个限制。我可能会保留这个设置一段时间，因为它很实用，而且因为无论好坏，软件工厂不是我的主要业务。
我用来管理从工单到完成代码的状态机的那些黑客手段需要被一个适当的状态机所取代，以便系统可以更容易地被衡量（例如，完成率和缺陷率）、推进（当事情卡住时）和持续改进。
我想改进的大多数事情都需要打破使用束线的限制：
- 用工作流替换钩子。我为了管理“代理会话”而实施的黑客手段非常令人不安。它跟踪哪些代理是活动的，但也允许对缓慢或产生糟糕结果的代理进行根本原因分析。但这个糟糕的实现需要代理去翻找上传记录，位置取决于束线。如果我不依赖订阅作为经济手段，通过 API 从 Linear 工单调用代理并通过适当的工作流表示管理代理会话后条件会愉快得多。
- 带有衡量指标的工作流。我是流程管理、持续改进和丰田生产系统的超级粉丝。所有这些绝妙的想法惊人地适用于软件工厂——剩下的就是捕捉指标（如完成率、缺陷率和方差）并开始系统地改进容易摘到的果实。
- 评估。由于我的大部分工作都围绕评估，并且我非常依赖编码代理，我感觉我没有为自己编码代理进行评估是具有讽刺意味的。能够在不同的指导下重复相同的任务，并且每周至少运行整个套件将是非常有用的。但是当你使用多个束线时，设置它们有点烦人，所以我也就没费心。感觉我正在围绕 OpenAI 标准化，这恰好不认为这违反服务条款，所以这可能很快就会到来，并且现在对我来说可能是容易摘到的果实。
## 软件工厂是未来，现在是把它们做好的时候了
我有兴趣听到更多在软件工厂工作的人的声音，所以我想说明为什么软件工程师应该热情地致力于它们。
对于我们应该是否朝着软件工厂发展——即人类在最高杠杆点工作并生成生产级软件的系统——存在着相当大的分歧，也许还有尴尬的犹豫。
无论它们是“真的”还是“假的”，就像几年前关于代理是否会广泛用于编码是否存在分歧一样。那些最积极地采取行动相信 LLM 会编写好代码的公司在软件世界创造了极端的价值——并以 25 亿到 600 亿美元不等的金额被收购。这表明乐观是有价值的，当迹象出现时，为成功做计划是有价值的。
今天存在分歧的最大症状是许多人正在讨论自动化代码审查是否是一个值得的目标，或者工程师是否应该阅读每一个 PR。“你看代码吗？”是其他也在努力寻找正确平衡的工程师经常问我的问题。
我对我们在软件工厂作为未来这件事上的犹豫感到惊讶。对我来说，显而易见的是，只要自动化能够成功交付生产级软件，自动化所有可能自动化的东西是值得的。
可能的迹象比以往任何时候都更清晰，虽然我们可能会看到行业范围内的工具和模式出现，但所有团队都可以采取一些步骤，开始利用自动化并朝着隐喻的冰球方向前进。
为了使自动化对作为专业人员的软件工程师工作良好，并建立允许我们从事令人振奋的工作的工作流程，我们应该积极参与塑造它，而不是让它发生在我们身上。我们是想把所有时间花在审查 PR 和批准代理行动上，还是