「手写代码已死，但写代码的经验还在帮你」：一条百字笔记的延伸
一句话结论：手写代码作为「产出方式」确实过时了，但真实的编程经验与「能否驾驭 AI agent」高度相关——换句话说，非技术人员无法成功地演化一个 AI 辅助系统。
- 原文全文只有 100 词（本文已全文双语照录），核心命题一条：「手写代码已过时。但真实的编程经验与『能否有效指挥 agent』高度相关——换句话说，非技术人员无法成功演化 AI 辅助系统。」
- 思想源头：DHH（Ruby on Rails 之父）的「写作与编程之辨」视频引发的推文讨论。
- 我的延伸：这条命题是上一篇「知识真空」论的人才侧推论——组织若不招/不留有经验的人，就没人能指挥 agent 走对路；个体侧的推论是：攒下的是「判断力资产」，不是「打字速度资产」。
- 核验状态：ssp.sh 原文可达、全文照录核验通过；源推文与 DHH 视频在本网络不可达，未独立核验。
1 · 原文全文（双语照录）
这条笔记短到可以全文照录——这也是核验的一部分：让读者看到原文的全部，而非转述。
「That's my answer to 'is writing code dead?' as of 2026-09-24.
Personal observation: Writing code by hand is obsolete. But real coding experience correlates really well with being able to direct agents. In other words, non-technicals cannot successfully evolve AI-assisted systems.」
中文：这就是我对「写代码已死吗」截至 2026-09-24 的回答。个人观察：手写代码已经过时。但真实的编程经验，与「能否有效指挥 AI agent」高度相关。换言之，非技术人员无法成功地演化一个 AI 辅助系统。
笔记末尾标注了思想源头：一条推文，以及 DHH（David Heinemeier Hansson，Ruby on Rails 创造者）的视频《The Differences between Writing and Coding》（写作与编程之差）。
2 · 为什么「指挥 agent」需要真实的编程经验
这条命题的反直觉之处在于：大家原以为 AI 编程会让「会不会代码」变得无关紧要，人人皆可造软件。但 Späti 的观察恰恰相反——经验不是用来写代码的，是用来判断 AI 写得好不好的。展开成三层：
- 品味层：AI 能生成「平均水平」的代码，但判断「这个抽象方向对不对、这个依赖该不该引、这个架构三年后还撑不撑得住」，需要踩过坑的品味（taste）。品味不来自提示词技巧，来自过去亲手写下的每一行烂代码。
- 验证层：AI 的输出必须被验证。没有经验的人验证不了——他们连该跑什么测试、该警惕什么边界都问不出来。于是「演化 AI 辅助系统」在第一步就卡死：你不知道现在的系统是变好了还是变坏了。
- 方向层：agent 擅长在被定义好的空间里爬坡，但「选哪个坡」是架构与产品判断。非技术人员可以造出一个 demo，却无法把它演化成系统——demo 到产品之间的路，全是要靠经验做决策的路。
3 · 与「没人懂系统了」的呼应
上一篇（《问题不是 AI 写的代码，而是没人懂系统了》）讲的是组织现象：全员 AI 产出、无人通读，知识真空化。这一条笔记是它在个体层面的推论：
- 组织侧：知识真空化 → 没人能判断系统健康度 → 可维护性成为最终 Boss。
- 个体侧：经验决定指挥能力 → 有经验者是杠杆的支点，无经验者只能产出 demo。
两条合起来的推论是残酷的：AI 时代工程师的分化不是「会用 AI vs 不会用」，而是「有经验地用 vs 没经验地用」——前者在放大判断力，后者在放大生成速度。还有一条人才侧的隐含结论：如果组织停止招聘和培养初级工程师，五年后就没有「有经验的中级」——指挥 agent 的能力断层是复利的。
4 · 核查与验证
| 核查项 | 方法 | 结果 |
|---|---|---|
| ssp.sh 原文可达性 | 直接抓取 | 200 通过，100 词全文照录核验一致 |
| 发布/更新时间 | 页面元数据 | 09-24 发布（100 词）、09-25 增补（+34 词） |
| 源推文（@BaronHakkinen） | 直接访问 | 本网络不可达，未独立核验 |
| DHH 视频《The Differences between Writing and Coding》 | YouTube 访问 | 本网络不可达，未独立核验；DHH 身份（Rails 创造者）为公开常识 |
| 观点层声明 | 体裁判断 | 原文为「个人观察」（personal observation），一条经验性命题，无数据断言；本文解读为观点延伸 |
5 · 延伸判断：经验的三种复利
把这条命题再往前推一步，真实编程经验在 AI 时代产生三种复利：设计复利（知道什么地基撑得住，少走选型弯路）、验证复利（知道哪里最容易出问题，评测与审查更有命中率）、方向复利（知道哪些坡值得让 agent 去爬）。反过来，没有经验支撑的 AI 使用也有三种负资产：无法审计的代码库、无法判断的质量、无法迁移的 Demo。
给个体的建议保持朴素：在让 AI 写代码之前，先让自己达到过「能独立写出它」的水平——不是要你回到手写时代，而是确保你有能力校验它的输出。给团队的建议：面试里保留「不借助 AI 的编码环节」，不是怀旧，是校准指挥能力的下限。
REF · 参考来源
原始文献
- Simon Späti, Writing Code by Hand Might Be Dead, but it Certainly Helps, ssp.sh/brain, 2026-09-24 发布 / 09-25 更新（本文核验版本，全文 100 词已照录）
思想源头
- @BaronHakkinen, 推文, X, 2026-09
- DHH, The Differences between Writing and Coding, YouTube
关联阅读
- 本站姊妹篇：「问题不是 AI 写的代码，而是没人懂系统了」观点核验与解读
- Simon Späti, The Problem is not the AI Code
- Simon Späti, Having Taste (with AI)
对本文有疑问、想交流技术方案或合作，扫码加我微信，备注来意通过更快。