Better Code, More Slowly
作者：Nolan Lawson（PouchDB 作者，Salesforce 工程师）
来源：https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/
核心论点：AI 编码的主流用法是"slop cannon"（快速产出勉强可用的烂代码），但 LLM 同样适合写出更高质量的代码——即使更慢。
反 slop-cannon 的立场
AI 编码的两种用法：
| 用法 | 特征 | 结果 |
|---|---|---|
| Slop cannon | 快速产出低质量代码，开大 PR，未经评审就合并 | 技术债务累积，代码库健康状况恶化 |
| Better code, more slowly | 用 AI 做深度评审、找 bug、写文档、理解系统 | 代码质量提升，开发者对代码库的理解加深 |
"LLMs are very flexible. And you can use them just as effectively to write high-quality code more slowly."
多模型交叉评审 PR
核心洞察来源
Milvus 博客文章的核心发现：模型越多、越不同，幻觉和误报越少。
Nolan 的实践配置
同时运行三个模型评审同一个 PR：
- Claude sub-agent
- Codex
- Cursor Bugbot
指令模板（大意）：
运行 Claude sub-agent、Codex 和 Cursor Bugbot 找出这个 PR 中的 bug，
按 critical/high/medium/low 分级。等它们都完成后，
评审它们的发现，自己做研究排除误报，然后写最终报告。
Bug 定义标准
可自定义，Nolan 的 stipulations 包括：
- KISS 原则
- DRY 原则
- 可访问的 HTML/JSX
- SQL 查询使用 proper index
实际效果
- 几乎零误报率
- 找到的 bug 数量多到"让你无聊透顶"
- 范围从 critical 安全/正确性 bug 到 "这个注释有误导性"的低级问题
Workflow：如何处理海量 bug
- 让 agent 修复所有 critical/high（人工指导正确方案），循环直到清零
- 跳过收益不值得的 high/medium（例如：100 行代码修一个极窄 edge case）
- 如果 critical 太多，直接放弃 PR——说明整个思路有问题
Side Quest：发现 Pre-existing Bugs
意外后果：评审过程经常挖出 PR 之前就存在的旧 bug。
结果：
- 进入修复旧 bug、写 unit test 的 side quest
- velocity 不一定提升，甚至下降
- 但代码库整体健康度大幅提升
"This is the opposite of the '10x productivity' slop-cannon style of development... but I find it very satisfying."
Nolan 的观察：复杂架构的 happy path 不如 failure modes 有意思。Pre-LLM 时代熟悉代码库的方式就是看假设在哪里崩掉——AI 加速了这个过程。
慢下来的"Vibe Coding"
给"写几百行 PR 自己却看不懂"的开发者
- 让 agent 解释 PR："这个 PR 怎么工作？可能在哪里失败？"
- 写 Markdown 文档 + Mermaid 图表帮助理解
- 用 Matt Pocock 的 /grill-me skill 直到完全理解 PR
核心竞争力不变
"A more super-powered version of the kind of programming I was already trying to do before LLMs: careful, methodical, quality-obsessed, focused on making things better for the next coder."
与现有框架的对照
| 框架/观点 | 核心信息 | Nolan 的补充 |
|---|---|---|
| Karpathy | Vibe Coding 抬高下限，Agentic Engineering 保住上限 | "保住上限"的具体实践：多模型交叉评审 |
| Simon Willison | 工程师在停止逐行 review agent 代码，产生"愧疚感" | Nolan 选择主动增加 review 强度，用多模型替代人工逐行 review |
| François Chollet | 代码产出 10x 增长，但净生产力几乎没变（技术债务） | Nolan 的 workflow 直接回应：用 AI 发现和修复技术债务，而非加速制造 |
| Dan Shipper / Proof | Vibe coding 应用爆红后崩溃 | Nolan 预防式地避免这种崩溃：在合并前就做深度质量检查 |
可立即应用的行动
1. 设置多模型 PR 评审 skill
Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR
ranked by critical/high/medium/low. Once they're all done, review their
findings, do your own research to rule out false positives, and write
a final report.
2. 自定义 Bug 定义
根据团队标准扩展 stipulations：
- 性能模式（SQL index、N+1 查询）
- 安全模式（XSS、注入、权限检查）
- 可维护性模式（注释准确性、命名清晰度）
3. 用 AI 生成理解文档
在评审过程中要求：
- "画一个 Mermaid 序列图解释这个 PR 的数据流"
- "列出这个 PR 引入的所有新假设和边界条件"
- "如果三天后我需要修改这段代码，我需要知道什么？"
关联
- vibe-coding-real-cost — Vibe Coding 的真实代价（Proof 崩溃案例）
- product-trends/vibe-coding-market-dynamics — Vibe Coding 市场动态（含 Karpathy、Willison、Chollet 观点）
- claude-code/overview — Claude Code 使用模式
- harness-engineering/overview — Harness Engineering 总览