Lovable — Scaling Agentic Coding with Token Spend

Lovable — Scaling Agentic Coding with Token Spend

Alexander Lebedev 在 Lovable 的复盘提供了一个罕见的“高 token 预算下真实工程组织如何重构研发流程”的样本：个人月 token 开销一度到约 25K 美元，半年累计约 85K 美元；工作形态从一人加少量 agents、每周 20–30 个 PR，演化到一人协调 6–7 个 agents 及其 subagents、每周 150+ 个 PR，极端周达到 293 个 PR。

为什么对用户重要

这篇文章值得入库，不是因为“多花 token”本身，而是因为它把 Agentic-Coding 的瓶颈从“agent 会不会写代码”推进到“人类注意力、风险分层、知识扩散、PR 抽象、skill 分享和自我优化循环”。这正好对应用户的 Hermes / llm-wiki 工作流：agent 的产能上升后，真正稀缺的是可控的上下文、验证门禁、风险路由和可复用 workflow。

它也给 Harness-Engineering 一个组织级案例：当 agent 产出体量远超传统 review 能力时，harness 不只是帮 agent 执行命令，而是要把变更切成可审查单元、把 review 分流到不同成本/速度通道、把高风险决策交还给人类。

机制 / 一阶原理

文章的核心机制可以归纳成四层：

1. 产出层：agent swarm + stacked PR。大任务不再是一整个巨型 PR，而是拆成 10-PR stack；每个 agent / subagent 负责实现、局部 review 或特定性质检查。
2. 风险层：markdown policy + LLM classifier + deterministic enforcement。高风险变更（infra/auth/大 diff/非 owner 代码/生产功能等）强制 human review；中风险走慢而贵的 AI review；低风险走快 AI review。LLM 负责分类，确定性工具负责执行规则。
3. 验证层：local review-and-fix + CI review safety net。本地 review skill 由主 agent 分派 correctness、performance、reuse、security 等 subagents，聚合去重后自动修复；CI review 是最低公共安全网。
4. 学习层：把重复流程写成 skills，并用历史 PR / session log 反思改进。作者强调 agent 自己写 skill、任务后询问 skill improvement ideas、从过去 100 个 PR 中提取流程改进。

一阶原理是：当生成成本下降时，系统瓶颈从“写代码”迁移到“选择正确目标、限制风险半径、保存组织知识、验证结果”。因此需要把人类注意力从逐行 review 上移到 RFC、ADR、系统设计和高风险决策。

与已有 wiki 概念的关系

• 与 Agentic-Coding：补充了高吞吐量 coding agent 的真实组织瓶颈：注意力管理、PR 粒度、风险分类和任务隔离。
• 与 Harness-Engineering：把 harness 从单任务流程控制扩展到组织级变更路由与 review policy。
• 与 AI-Code-Review：提供“local review-and-fix 是 workhorse，CI review 是 safety net”的分层观点。
• 与 External-Agent-Skills-Design-Patterns：重复流程应晋升为 skill，但 skill 分享和同步仍是未解问题。

对 Hermes / llm-wiki 的可执行启发

1. 把入库任务也做风险分层：小的 source/concept 更新可自动执行；涉及 schema、目录结构、批量重写或删除的更新应进入 human-review 建议，而不是自动改。
2. 日报不要只列发现，要维护“radar policy file”：类似 Lovable 的 markdown policy，llm-wiki radar 应明确哪些内容进入 deep ingest、哪些只留 raw、哪些需要用户确认。
3. 每次 cron 完成后做 self-improvement hook：今天已按要求生成 llm-wiki-optimization-YYYY-MM-DD.md；后续可把“候选未入库原因”结构化，积累成雷达过滤器。
4. PR stack 对应 wiki stack：复杂主题不要塞进一个大 synthesis；应拆成 source 页、概念页、比较页，并让每页有独立写入记录和链接。

失败模式 / 边界

• Tokenmaxxing 不是目标：作者也提醒，真正指标是 outcome，不是 token spend 或 PR 数。llm-wiki 不应把“多入库”当作成功。
• AI review 仍可能错：大 PR 对人类和 AI 都不可审查；因此必须强制小变更、分层 review 和真实测试。
• 知识扩散缺口：传统 code review 的副产品是学习和组织对齐；自动化 review 会削弱这层，需要 RFC/ADR/wiki/skill sharing 补回来。
• 人类任务系统与 agent 任务系统要分离：作者反对把 agent 长篇思考塞进 Linear；对 llm-wiki 来说，raw/session 噪音也不应污染正式概念页。

写入记录

• 2026-07-05 09:02 CST：新增 source 页面，提炼 Lovable 高 token agentic coding 实践对风险分层、AI review、PR 粒度、skill 自我改进和 llm-wiki radar policy 的启发。