当人人都会写代码，工程师还剩下什么？
写在前面：这几天，Geoffrey Huntley 在 AI Engineer Miami 访谈中的一组观点被不少人转发。他说得很尖锐：软件开发正在变成一个死胡同，因为现在人人都能写代码。
这句话容易被理解成“程序员要失业”。但更值得追问的是：当代码生产越来越便宜，工程师身上最昂贵的部分到底是什么？
Geoffrey Huntley 的那篇文章不是一篇完整长文，而是把一次访谈里的观点压成了十几条热判断。原文可以在这里看到：A couple of months ago in Miami, I sat down and dumped my brains。
把这些判断放到自己的工作里看，核心并不复杂：Cursor、Claude Code、Codex 这类工具已经让普通人可以生成代码；“会写代码”和“会做软件工程”正在分开；有价值的工程师，必须理解产品、设计系统、驾驭 coding agent，并且对结果负责。
这不是一个遥远的判断。它已经发生在每一个技术团队的日常里。
过去，一个人能把需求翻译成代码，本身就是稀缺能力。今天，这个稀缺性正在下降。页面、脚本、接口、组件、测试样例，都可以由 AI 在几分钟内生成一个可运行版本。
但可运行不等于可交付。能生成不等于能负责。
这就是工程师价值重新定价的开始。
一、写代码正在变便宜，但工程没有变便宜
AI 首先压低的是“代码生产”的成本。
这件事很容易让人误判。因为过去很多工程工作都被包装成写代码：写一个页面，接一个接口，补一个脚本，改一个样式，修一个报错。只要把代码写出来，工作似乎就完成了。
但在真实项目里，代码只是结果的一部分。
一个工程系统能不能长期运行，取决于更多东西：需求是否被正确理解，边界是否清楚，数据是否可信，异常路径是否覆盖，权限是否收住，测试是否能复现问题，发布之后能不能回滚，后续的人能不能继续维护。
AI 可以很快生成代码。问题在于，它不会天然知道你的业务约束、历史债务和交付责任。
它能给出实现，也能补测试。但哪些风险值得测，哪些边界不能碰，哪些结果必须回滚验证，仍然要由工程师判断。
所以，AI 没有让工程消失。它只是把工程师身上最容易被自动化的一层剥离出来。
剩下的部分更硬，也更难伪装。
二、Coder 和 Software Engineer 会被重新区分
过去很多团队没有必要严格区分 coder 和 software engineer。因为写代码本身已经足够复杂，能稳定写出代码的人，就可以在团队里承担相当多的工作。
现在不同了。
如果一个人的主要价值是“把别人说清楚的需求翻译成代码”，那这部分能力会越来越容易被工具替代。不是因为这个人不努力，而是因为这件事的供给突然变多了。
软件工程师要回答更靠前、更靠后的问题：
- 这个需求有没有被正确定义？
- 这个功能应不应该做？
- 这个实现会不会破坏已有系统？
- 这段代码未来谁来维护？
- 失败时用户会看到什么？
- 数据、权限、日志、测试和发布链路有没有闭环？
这些问题不是“写代码”问题，而是工程判断问题。
AI 让更多人可以写代码，也让工程判断变得更显眼。以前，一个人写得快、语法熟、框架懂得多，很容易被认为是高级工程师。以后，这些仍然重要，但不再够用。
更关键的是：你能不能把一个模糊问题拆成可验证的工程路径。
三、不会使用 Agent 的工程师，会被自己的天花板卡住
Geoffrey 有一个观点很刺耳：如果你不能演示 coding agent 如何工作，你就只是 AI 的消费者，并且给自己的职业加了一层玻璃天花板。
这句话虽然重，但值得认真听。
我们看到的问题是，很多人使用 AI，仍然停在问答模式：解释一段代码，改一个函数，生成一个组件，写一份文档。
这当然有价值，但还不是 agentic engineering。
分界线在于：你能不能把 AI 当成一个可调度的执行单元，让它读仓库、找证据、制定计划、修改代码、跑测试、修失败、汇报边界。
这时，工程师不再只是自己敲每一行代码。他在设计一条工作流：哪些事情交给 AI 快速探索，哪些判断必须自己保留，哪些验证必须自动化，哪些输出不能信任，哪些风险必须人工复核。
这要求工程师理解工具的失败方式。
AI 会编造。AI 会过度自信。AI 会为了完成局部任务破坏整体一致性。AI 会在没有上下文时给出看似合理、实则危险的方案。
如果你不能识别这些问题，只是把 AI 输出当成答案，你确实只是消费者。
如果你能控制上下文、约束边界、设计验证、审查结果，AI 才会变成你的工程杠杆。
四、小团队会变强，大团队会被迫重组
Huntley 还有一个判断：AI native 团队可能只需要五到十个人，就能完成过去更大团队才能完成的工作。
这不是说所有公司都会变成小公司，也不是说复杂系统不需要大团队。变化在于：很多新产品、新工具、新业务验证场景里，团队规模和产出之间的关系会被改写。
过去，团队扩张常常意味着更多角色：产品、设计、前端、后端、测试、运维、内容、运营。每个角色都需要人，每个交接点都有损耗。
一部分交接会变轻。
产品工程师做原型更快，后端工程师补管理界面更快，设计师生成交互方案更快，内容团队完成多平台发布准备也更快。
但这也会带来新的问题：如果每个人都能产出更多，组织该如何判断什么值得做？如何避免更快地产生更多低质量东西？如何让 AI 生成的内容、代码和决策进入稳定流程？
这正是我们在 ArchSight Labs 一直关注的方向。
这不是项目展示，而是我们自己应对这类变化的方式：把 AI 生成能力放进工程纪律里，而不是只追求更快地产生更多东西。
我们做 Solver，不只是追求算得快，而是要让计算结果可解释、可复核、可交付。
我们做 Graphics，不只是展示 3D 模型，而是要把工程语义、材质、构件和交互关系收进可理解的工作台。
我们做 AIOS 和 Cognition，也不是为了多几个提示词，而是为了让 AI 协作有角色、有边界、有验证、有复盘。
甚至我们做内容发布，也会把文章、图片、元数据和发布预检放进一套工程化流程里。
这些看起来不是同一件事，但底层逻辑是一致的：AI 可以加速生产，但必须有工程纪律来承接生产。
五、工程师要练的不是“提示词”，而是判断力
不少人把 AI 能力理解成 prompt 能力。这只对了一小部分。
提示词当然重要。一个清楚的问题，比一个模糊的问题更容易得到有用结果。但拉开差距的，不是会不会写几句漂亮提示词，而是有没有足够的判断力。
判断力来自三个地方。
第一，来自对系统的理解。你知道这个仓库为什么这样组织，知道模块之间的关系，知道哪些代码是核心路径，哪些只是边缘工具。
第二，来自对产品的理解。你知道用户要完成什么，知道哪些功能只是看起来高级，哪些能力能减少真实工作里的错误。
第三，来自对验证的坚持。你不满足于“AI 说可以”，而是要看到测试、日志、截图、数据、发布结果，看到失败后能否恢复。
工程师不是不用写代码，而是不再把写代码当成自己的全部身份。
他要能提出问题，拆解问题，组织上下文，驱动工具，审查输出，承担结果。
这比写代码更难，也更接近工程本来的样子。
结语：不要守住旧稀缺性
每一次工具变革，都会让一部分旧稀缺性消失。
打字曾经是技能，排版曾经是技能，搭建一个网站曾经是技能，写一个简单 CRUD 系统也曾经是技能。它们没有完全消失，但不再足以支撑一个人的长期不可替代性。
AI 正在让“生成代码”走上同样的路径。
这不是坏事。它只是提醒我们：不要把自己的价值绑定在一个正在快速变便宜的动作上。
工程师要守住的，不是键盘前的手速，而是面对复杂问题时的清醒。
能定义问题，能设计系统，能控制风险，能验证结果，能带着 AI 把事情做完。
当人人都会写代码，工程师剩下的不是更少。
剩下的是更真实的工程能力。
关注我们
欢迎搜索并关注 筑见实验室，获取更多结构计算与工程前沿动态：
