尝试使用工厂模式
Trying the Software Factory Pattern

原始链接: https://lethain.com/software-factory-experiment/

2026 年,人工智能驱动开发的快速演进要求我们不断适应。在 Imprint,我们已从简单的 AI 编码助手转型为复杂的“软件工厂”模式。 这种模式超越了基于任务的 AI,转向了以目标为导向的自动化。我们的“工厂”利用一套循环架构,对项目 RFC 进行审计,通过 Datadog 和 Snowflake 监控指标,并管理 Linear 工单。智能体能够自主创建必要文档、识别缺失任务并执行代码编写工作,仅在需要更新项目目标时才会暂停进行同步。 这种方法解决了“状态囤积”问题,即开发者无意中将重要的项目背景保留在脑海中,而非系统中。通过整合数据可视化、集中式任务管理(Linear)以及受控的智能体集群,该工厂确保智能体不仅能编写代码,还能验证工作是否与高层商业目标保持一致。 归根结底,这些进步是相辅相成的:软件工厂之所以成功,是因为我们在通用任务管理和跨代码库工作空间等基础设施上进行了投入。尽管变革的节奏令人疲惫,但它代表了软件在发布后构建、管理和监控方式的根本性转变。

这段 Hacker News 讨论聚焦于实施“软件工厂模式”(即利用人工智能体自动化开发流程)所面临的挑战。 主要讨论者指出,尽管这一概念很有吸引力,但 UI 和移动应用测试仍然是重大的瓶颈。他们指出,人工智能模型难以评估可用性和“卡顿”问题,因为它们缺乏感知动态效果或静态快照之外用户体验的能力。此外,在快节奏的初创环境中,对人工驱动规范的依赖使得人类必须深度参与其中,从而阻碍了完全自动化。 对话还涉及了工具使用问题,有用户质疑在这些系统中使用 Notion,并警告称这会导致杂乱无章、令人诟病的文档。另一位评论者则认为问题不在于工具本身,而在于管理层对该工具的依赖,并将这种偏好归结为问题的真正根源。总体而言,该讨论反映了人们对代理式自动化软件生产的渴望,与当前人工智能在处理前端细微差别及行政开销方面的实际局限性之间持续存在的矛盾。
相关文章

原文

One of the interesting challenges of the AI ecosystem in 2026 is that new, effective patterns emerge faster than I can adopt them. I’ll find a handful, get back to work, and realize a month later that I’d missed four or five more. The adoption cycle for Imprint this year has been something like:

  1. January: get every engineer onto Claude Code every single day
  2. March: ok, let’s also get everyone else onto Claude Code or Claude Cowork every single day
  3. April: local development is bottlenecked on checkout and worktree model, instead create ~10 local workspaces which each have an independent checkout of every repository, and operate at the workspace level, not at the repository level, so it can generate cross-repository pull requests across frontend, backend, infrastructure and data monorepos
  4. June: oh boy, agent-driven development is heavily constrained by lack of a common task management system with higher visibility and less permission complexity than Jira, so let’s migrate the entire company over to Linear and hard stop on Jira
  5. July: yikes, now we have visibility into all these tickets, many of them are trivial but managing them through local development isn’t scaling, let’s roll out an orchestrated harness which internally we call “Agent Fleet”, along the lines of Stripe’s Minions

The most recent question for me has been figuring out how to adopt the software factory pattern. (After some light research, the specific AI-context origin of this term is slightly messy to attribute, but I think it might be Justin McCarthy in February 2026’s Software Factories And The Agentic Moment.)

The software factory pattern is looping on a broad goal, and then relying on the harness to drive progress towards that goal. Our first pass at implementation is fairly basic:

  1. An agent skill /linear-project-loop which reads in a Linear project and starts by auditing that project’s goal definition on these dimensions:

    1. An RFC in Notion that describes the project’s goals, how those goals are measured, and the general approach
    2. A Datadog dashboard or Snowflake queries that measure progress against those goals

    If those are missing, or the Linear project is missing in its entirety, it iterates with you on creating those missing tools.

  2. Then it reviews the state of the metrics and issues for the project. If new work is identified, it adds those issues to the project. It updates the state of issues that have moved.

  3. It works on the non-blocked tasks based on the project’s current state. This is often writing a pull request, updating a pull request, pinging for review, asking a clarifying question, etc.

  4. When a task completes, if the project description is fresh, it takes on the next task. If the description hasn’t been updated in a while, it reruns the loop starting with the first step.

Right now I am running this locally in a local harness, but it’s working well enough that I anticipate moving the behavior to be driven by the same orchestrated harness that we assign one-off tasks to.

What I particularly like about the factory pattern is that it parallels very closely how I’ve been working locally, while forcing me to recognize the places where I was accidentally hording parts of the state for myself regarding the goals of the project. I was already asking agents to iterate on specific Linear projects, but they didn’t have the ability to evaluate if they were going in the right direction, or if it was missing necessary tasks. Now it does. The other place this has been extremely helpful for me is checking in on projects post release. For example, I shipped our passkeys implementation earlier this year, but some months go by without my checking in on how it’s going. If we saw adoption spike, or error rates start to turn, I might miss it, but running the factory in a less frequent post-release mode would catch it immediately.

The final thought that’s been interesting to me is how much all of the pieces here compound only to the extent that you have the other pieces. For example, this factory pattern depends on having Datadog MCP and Snowflake access available to manage goal-tracking, but it also depends on Linear being the single source of state for the company’s work, and an orchestrated harness that can perform work independently from your laptop. Keeping up with this many migrations is a fascinating industry moment.

联系我们 contact @ memedata.com