软件开发瓶颈从“写代码”转向“定义问题”

软件开发的瓶颈正在从 "写代码" 彻底转移到 "定义问题" @thorstenball 认为：当模型产出的代码质量超过人工审查能力时，围绕"人写代码"建立的一切工艺、流程和工具（code revie...

软件开发的瓶颈正在从 "写代码" 彻底转移到 "定义问题" @thorstenball 认为：当模型产出的代码质量超过人工审查能力时，围绕"人写代码"建立的一切工艺、流程和工具（code review、单测、终端、PR、敏捷）都将失去存在基础！ 关于代码本身：传统质量标准将失效 · Code review 已死：人无法在合理时间内找出模型代码的问题，只能审查"系统与其组合方式"，而非逐行看代码。 · 单测可能死：他给出现场证据——模型一次写出 900 行 Arduino C，零编译错误、上电即跑。测试如同"辅助轮"，不摔倒就不需要。 · "好代码"的概念本身值得怀疑：我们对好代码的定义（整洁、可读、格式规范）本质上是为"人要读改代码"服务的。当修改代码的主体变成模型，80 列宽度、换行位置这类标准对 agent 毫无意义；推而广之，你心中其他所有"好代码"属性都应重新审视。 · 开源形态改变："given enough eyeballs, all bugs are shallow" 依然成立，只是眼球换成了人工的。 关于人的价值：从工匠到架构者 · 写代码的"手艺"会消失（意大利手工鞋匠还存在，"但看看你脚上穿的是什么"）；但"构建软件的手艺"空前重要：理解业务问题、借鉴已有方案、把握发布时机与反馈循环，这才是新游戏。 · 大多数 bug 将不再是"编码 bug"，而是"你要错了东西"的 bug。 关于流程与组织：现有协作范式解体 · PM/设计/工程三权分立不再合理，敏捷、Scrum 都会死；把票塞给 agent 再向人汇报的"肉身代理"式工程师将失去价值。 · 大公司与小公司的工程差距会拉大：创业公司若模仿 Google 的流程会显得更可笑，因为它们本可以更快、更少约束。 · 人工的性能优化贡献仍将存在，但只是边缘案例：99% 的软件没有用户、没有人在跑，快慢无所谓；真正要紧时，模型也能修。 关于工具与范式：token 是新的计算范式 · 终端将死：shell、文本编辑器、CLI 工具、jq 命令行组合，会变得像"用 Perl 写单行程序"一样古老；他以终端爱好者身份说这话，分量更重。 · 最深刻的洞察：我们被 80 年确定性计算机史绑架，把"计算机一直这样工作"误认为"计算机必须这样工作"，正在进入"后二进制时代"，一切都会在 token 之上重建。 · UI 会被即时生成：菜单、设置页、仪表盘本质上是"给笨机器用的人类 API"，机器变聪明后 UI 大幅减少。 关于经济与时间线 · Token 就是新生产资料：未来几年，拿不到足够 token 的人就像 80 年代买不起个人电脑的人，只能打二级联赛。 · 模型不会走向"便宜的笨模型"：更聪明的模型犯错更少、轮次更少；"你什么时候真的会接受'它错几次也没关系'？" · 替换需要一代人：就像今天仍有人靠 ASP 开发谋生，10 年后仍会有写代码的岗位，"但你想做那份工作吗？" Thorsten Ball @thorstenball Most predictions I see are still way too conservative. Here's mine 🔗 View Quoted Tweet 💬 2 🔄 0 ❤️ 1 👀 506 📊 2 ⚡