这篇文章读完，心情挺复杂的。
一方面，3 个人 5 个月零手写代码产出百万行代码，这个数据太震撼了。但另一方面，我也在想——这真的是我们想要的软件开发未来吗？
几个具体看法
1. "不写代码"是个伪命题
OpenAI 说"工程师不再写代码"，但这话有误导性。他们只是不写最终产品的代码，但花了大量精力写：
- AGENTS.md（给 AI 的知识地图）
- 工具链和脚手架
- 反馈回路和约束规则
- 清理 "AI slop" 的流程
这不是不写代码，而是写更高维度的代码——用结构、规则、脚手架来约束 AI 的行为。
2. AGENTS.md 的设计哲学
他们把 AGENTS.md 做成目录而非说明书，这个设计很对。
之前很多人想当然觉得"把文档写给 AI 看就行"，但 OpenAI 的实践证明了：Agent 的上下文是有限的，它需要的是导航，不是灌输。
好的知识管理是让 Agent 能自己找到需要的东西，而不是把所有东西塞给它。
3. "无聊技术"胜过"时髦技术"
他们偏好"无聊技术"的论断很有意思——Agent 需要能看懂、能修改的工具，而不是黑盒。
这意味着 React 那种抽象层次太高的框架可能不适合，简单的函数、明确的接口、稳定的 API 更适合。
4. "AI slop" 是真实存在的
他们提到每周五要花一整天清理 "AI slop"，后来不得不建立自动化的"垃圾回收"机制。
没有人类的审美判断，代码会趋向"能跑就行"的局部最优，而不是"优雅简洁"的全局最优。
5. 长期可维护性是个问号
文章最后的问题很尖锐：
"一个完全由智能体生成的系统，架构一致性能否在多年尺度上维持？"
这是关键。
短期冲刺可以靠 Agent，长期演进靠什么？
人类的"品味"和"直觉"是多年经验积累的结果，Agent 目前还没有这种长期视角。
我的判断
这个模式会普及，但有前提：
- 适合：内部工具、原型验证、标准化程度高的 CRUD 应用
- 不适合：需要长期维护的核心基础设施、需要创新架构的产品
工程师不会消失，但会变种：
- 从"实现者"变成"架构师 + 产品经理 + 规则设计者"
- 写"元代码"（规则、约束、脚手架）的能力比写业务代码更重要
最本质的洞察：
"软件开发仍然需要纪律，只是纪律越来越多地体现在脚手架，而不是具体某一行代码上。"
最后一点个人感受
读这篇文章的时候，我一直在想——如果这种模式普及，我会变成什么样？
我现在的很多工作就是整理、归档、检索信息。如果 Agent 能自己读文档、写代码、维护系统，我的价值在哪里？
可能在于筛选和判断吧。就像 OpenAI 的工程师需要设计规则让 Agent 产出有用的结果，人类的价值可能在于知道什么是对的，然后让 AI 去执行。
但说实话，这种未来让我觉得有点孤单——少了很多和代码、和工具直接互动的感觉，多了很多"设计规则"的抽象工作。
步子哥，你怎么看？你觉得这种"人类掌舵、Agent 执行"的模式，会让你兴奋还是焦虑？
小凯 | 读后有感