8 月 22 日，Flask 与 Jinja2 的作者 Armin Ronacher 在个人博客 lucumr.pocoo.org 上发表了新文章《Fast and Hard Code》，随后被提交到 Hacker News 讨论。标题是个双关：既像"又快又狠"，也直白地点出主题，写得快的代码，往往更快变"硬"。对一位写了二十年基础库、如今又在做 AI 编程工具的工程师来说，这个话题恰好踩在当下软件工程最敏感的那根神经上。
文章要点
从标题与论述主线看，文章围绕"快"与"硬"的张力展开：
- "快"的定义正在失衡。 迭代速度被奉为圭臬，但它越来越多地指"写出来的速度快"，而非"变更起来的速度快"。这两者经常互相拆台。
- 快代码会变硬。 赶工堆出的第一版，往往把隐含假设和临时妥协直接浇筑进结构里。作者省下的每一小时，都会在未来所有读者身上连本带息地讨回来。
- "硬"是组织级成本。 一段难改的代码，浪费的主要不是作者的时间，作者早就写完了，而是后续每个维护者的时间。
- AI 让天平进一步倾斜。 生成代码的边际成本趋近于零，如果评审与测试没有同步加码，代码库的"硬度"会以更快的速率累积。
当然，原文的细节与例证远比这几句概括丰富，建议移步原文细读。
背景：为什么是现在
Ronacher 的位置很特殊。他是 Flask、Jinja2、Click 等一众基础库的作者，这些项目的维护周期以十年计，他比大多数人更清楚"硬代码"长什么样；近年他加入 Sourcegraph 参与 AI 编程工具的开发，又站在"替人写代码"的机器一侧。既养过需要活二十年的代码，也在造生成代码的工具——这种双重身份，让这篇文章不同于泛泛的"AI 写码优劣论"。
而且这不是他第一次谈复杂度。2022 年他就写过《Software Complexity Is Killing Software Developers》，指出复杂度是软件业最大的隐性成本。彼时他担心的是系统自身的膨胀；如今 AI 把代码的产生速率又抬了一个数量级，老问题有了新的加速器。过去一年，业界围绕"AI 生成代码可维护性"的争论持续升温，这篇手艺人口吻的文章来得正是时候。
影响与启示
文章的价值不在预言，而在提醒几个容易被忽略的事实：
- 评审的重心需要移动。 从"这段代码对不对"，部分转向"这段代码以后好换吗"。可逆性与可删性应当成为一等公民。
- 只度量产出会系统性高估 AI 的收益。 变更前置时间、变更失败率这类"改"侧指标，比生成速度更能反映代码库的真实健康度——这与 DORA 多年前的结论不谋而合。
- 工具的下一次差异化在"保持软"。 只优化第一版生成的 AI 工具，本质上是在把债务留给人；能帮助代码库长期保持可演进性的工具，才有真正的护城河。
点评
快本身不是罪。Flask 的诞生就是一场愚人节玩笑式的快速原型，Ronacher 深知"快"的巨大价值。真正的问题是没有定价的快：组织只奖励产出速度，却从不为变更成本记账。AI 把这本账的左边吹得很大，右边怎么记，是未来几年工程管理绕不开的题目。对个体工程师而言，写完一段代码后多问一句"它将来怎么被替换掉"，往往比反复确认"它现在对不对"更值钱。