Building Software Is Learning
核心主张: 当构建全新功能（无现成 spec）时，"一次做对"几乎不可能，因为构建过程本身就是学习过程。唯一能控制的是缩短获取反馈的周期。
来源: Thorsten Ball — Building Software Is Learning (Amp 团队内部 memo)
What it is
Thorsten Ball 在 Amp 团队内部的观察：
罕见的场景（几乎从不发生）：
A: "we need this feature"
B: "yes, let me build it"
...
B: "done."
A: "fantastic, exactly what I wanted."
真实的场景（反复发生）：
- "hmm, actually, that's not what I meant"
- "there's 3 ways to do this, I'm not sure what's best"
- "Don't like it"（没有具体原因）
原因: 构建新软件 = 学习。你无法 upfront 完全定义它，因为"完全定义它"本身就是编程。你无法避免误解，因为你还不能定义它。
Why it matters
在 AI 加速软件生产的时代，这个框架的价值反而上升：
- AI 降低了"写代码"的成本，但没有降低"理解需求"的成本
- vibe-coding 让"4 周 hack 一个功能"变成"4 小时"，但"这不是我想要的"的反馈循环依然存在
- 如果不主动管理反馈周期，AI 只是在更快地产出错误方向上的代码
The Core Metric: Feedback Loop Time
"The most important thing you can do when building something new: reducing the time it takes you to go from 'let me try something' to getting your ass whooped by reality."
不要: 花 4 周（或 4 小时）hack 完整功能，最后对方说"这不是我想要的"
要: 用最小代价最快搞清楚"他们到底想要什么"
Fast Feedback Methods
| 方法 | 时间成本 | 适用场景 |
|---|---|---|
| 1小时原型 | 1hr | 快速验证方向 |
| 写 spec 给对方看 | 30min | 确认理解一致 |
| 每日小批次 ship | 每天 | 持续碰撞现实 |
| 缩小范围，聚焦未知 | 即时 | 跳过已确定的部分，只探索不确定的 |
| Fake demo 视频 | 几小时 | 获取早期反馈 |
| 写新闻稿/说明文档 | 30min | 如果 idea 能用 3 段话讲清，何必花一周构建？ |
| 写 README 示例代码 | 1hr | 验证 API 设计，无需完整 SDK |
关键原则: 可以组合使用。对于大功能，应该同时使用多种方法。
Good vs Bad Feedback
坏的反馈来源:
- MVP 太 buggy → 只收到 bug 报告，不是"useful feedback"
- 测试者要跳 8 个 hurdle 才能试用 → 没人会给真实反馈
- 在 branch 上憋 3 周，27 个 commits 一起 merge → CI 爆炸后有 27 个可能原因
好的反馈原则:
- 滑板例子: 想获得设计反馈？给看 deck 就行，不需要轮子。想获得使用感受反馈？必须装轮子。
- 反馈频率 > 反馈完美度
In the AI Era
当 AI 让构建速度提升 10x 时，"building software is learning" 框架意味着什么？
- AI 放大了"方向错误"的成本: 如果反馈循环没有同步加速，AI 只是在更快地产出错误
- AI 降低了原型成本: 1 小时原型 → 10 分钟原型，但"给人看并获得反馈"的环节没有变快
- 新的瓶颈是"人的确认速度": AI 可以 10 分钟写一个功能，但人可能需要 2 天才能给 feedback
Related
- mental-models/premortem — 事前验尸：另一种降低方向错误风险的方法
- mental-models/task-driven-vs-goal-driven — 任务驱动 vs 目标驱动：与"每日小批次 ship"理念相通
- product-trends/forward-deployed-engineer — Forward Deployed Engineer: Palantir 的 tight feedback loop 实践
- product-trends/google-stitch-design — Google Stitch: "Instant Prototypes" 作为设计反馈工具
- claude-code/claude-cowork-felix-rieseberg — Felix Rieseberg: "Prototype ≠ product"
- claude-code/syntaqlite-ai-build-experience — "AI turned abstract uncertainty into concrete prototypes"
Open Questions
- 在 AI 辅助开发中，"feedback"的定义是否需要扩展？（CI feedback、模型 self-correction、A/B test feedback）
- 当 AI 能自动生成 fake demo、新闻稿、README 示例时，这些方法的价值是上升还是下降？
- "building software is learning"是否适用于 AI-native 产品（用户也在学习如何使用 AI）？