1. Prisma Is Building the Stack for the Next Million Products

推荐理由： 这篇不是再讨论“Agent 能不能写代码”，而是把问题推进到 Agent 如何把代码真正变成可运行、可观察、可验证的软件。Prisma 的 software factory 思路很明确：不要让 Agent 在数据库、部署、日志、preview 和开发工具之间不断恢复 context，而是把这些基础设施做成一个连续工作环境。

核心要点：

  • Prisma 把理想的 Agent 工作单元定义成 build → run → inspect → fix → validate，而不是“生成代码后交给人”。Agent 应该能改 schema、实现前后端、启动真实应用、挂接隔离数据库、观察 traces，再根据运行结果继续修复，最后带着可运行环境和验证证据进入 PR。
  • 环境本身就是 context layer。 Prisma 认为 memory / company brain 只能缓解问题，更基础的设计是让系统在 Agent 需要时直接暴露正确状态：每个任务独立数据库、可程序化 provision 的 runtime、ORM safeguard、logs/traces/preview 都应属于同一个反馈回路，从而减少跨工具 handoff 和 context reconstruction。
  • 更长远的产品方向不是“让 Agent 学会操作更多 dashboard”，而是把 code hosting、issue、cloud agent、deployment 和 production telemetry 继续接入同一环境，让 intent → implementation → runtime evidence → next iteration 真正闭环。对 AI-native developer platform 来说，connected loop 本身比单个工具更接近核心产品。

2. Optimising the Strike Software Factory

推荐理由： 这是近期最值得看的 production software factory 实践之一。Strike 把 Agent 系统拆成 model + harness + environment，其中模型是租来的、harness 多半来自供应商，真正能长期沉淀为团队资产的是 repository environment：测试、静态分析、skills、流程、架构约束、eval 和 CI。

核心要点：

  • Strike 区分 deterministic enforcement 与 non-deterministic guidance：compiler、lint、static analysis、test 是一次建设、长期执行的固定成本；prompt / skill / review agent 则每次都要付 token 成本。只要规则能够确定性表达，就应该尽量从“告诉 Agent 别犯错”升级成“系统结构上不允许犯错”。
  • Software factory 被拆成六层：process spine、domain guidance、deterministic gates、orchestration、corpus hygiene、fold-back。尤其重要的是 skill 也需要 eval：每次 skill 更新都应被当作一个可验证假设，在相同任务集上对照 baseline，像代码测试一样防止 prompt / behavior regression。
  • 他们最终优化的不是 token 或 PR 数，而是 human review burden。校验应尽可能靠近错误产生的位置：editor → save → pre-commit → pre-push → agent hook → CI；而 skills/docs 还必须持续去重、清理冲突并与实际代码 reconciliation。模型和 harness 会换，但这些 repository-level assets 会跨模型持续复利。