6月初，OpenAI公布了一组数据：Codex周活跃用户突破500万，其中非开发者（分析师、营销、运营、设计师等）占新增用户的20%，增速是开发者的3倍。编程工具正在走出开发部门，变成通用生产工具。一个数据分析师可以借助AI快速完成原本需要申请开发资源的可视化模型，直接生成可发布的互动页面。
乍看之下，这似乎是“人人都是程序员”的有力证据。但答案并没有这么简单。
AI的确让普通人离“把一个想法变成可运行的软件”前所未有地近。一个原本只有0.3分能力的人，可能被AI放大到0.8甚至0.9。但问题在于：AI可以放大0.3，却很难凭空生成那最初的0.3。如果一个人不知道自己想要什么，不知道什么叫边界条件，不知道Demo和服务之间隔着一整套工程责任，包括真实用户、并发、安全、成本、后续维护，那么AI带来的往往不是创造力的爆发，而是混乱的加速生成。
这里有一个经常被忽视的问题：代码不仅要“对人友好”，还要“对AI友好”。一位资深工程师（化名CC）曾接手过一个历史项目，几千行的Python脚本，业务逻辑、数据处理、异常处理混在一起，再加上早期AI补全留下的碎片，几乎不可读。对AI来说同样不友好，因为巨型脚本会严重消耗上下文窗口。CC没有急着重构，而是让AI先扮演架构师，梳理模块关系、调用链路、数据流向，生成文档和流程图，再由人工校准。这时AI的角色不是“写代码的实习生”，而是一台结构显影仪，把混乱的系统形状照出来，重构才变得可行。这个案例说明：AI不是把工程能力取消了，而是把工程能力变成了更底层的基础设施。
更成熟的AI Coding实践也印证了这一点。CC的做法是尽可能替AI构建丰富的上下文，包括产品PRD、需求评审记录、技术文档、代码库、项目规范，然后让AI在这个上下文里工作。技术方案先沉淀成文档，经过团队review再进入编码。开发完成后，AI生成的文档不仅给人读，更成为其他AI Agent的上下文。换句话说，AI Coding的核心对象正在变化：过去我们写代码，今天我们在写上下文。谁能组织更好的上下文，谁就能更好地使用AI。如果上下文是乱的，AI会高效地放大混乱。
AI还有一个更隐蔽的危险。CC在一个数据科学项目中发现，无论输入多离谱，程序总能输出结果。排查后发现，AI在很多环节加了默认值、try catch和静默降级。每个局部都在“增强稳定性”，串起来却变成了一个几乎不会失败的黑箱。这很危险。工程系统里，该失败的时候失败，错误才能被及时暴露。AI之所以这样写，是因为它更容易被奖励“完成任务”。用户说别崩，它就加兜底；说要输出，它就造默认路径。但报错消失不等于问题解决。人类工程师仍然要告诉AI：哪些错误必须暴露，哪些异常不能吞掉，哪些链路必须快速失败。
如果AI可以把0.3放大到0.9，那最初的0.3到底是什么？对专业开发者来说，它不是某个框架的熟练度，而是业务理解、写清楚需求的能力、验收能力、系统判断，比如什么时候让AI修，什么时候人接管。对非专业开发者来说，它更基础：能不能描述清楚自己想要什么，能不能把一个想法拆成几个小问题，能不能意识到软件不仅有页面，还有数据、权限、部署和维护。很多人以为自己缺的是编程语言，其实第一步缺的是需求表达。
“人人都是程序员”之所以流行，是因为它抓住了一个真实趋势：软件创造正在从少数专业人士手里扩散出去。但如果因此认为专业性不再重要，就走向了误区。AI Coding不会消灭工程能力，它会重估工程能力。它不会让所有人自动成为程序员，它会让那些具备结构化能力、业务理解和责任意识的人获得更强的生产力。
AI时代，人人都更接近软件创造，但不是人人都自动拥有工程能力。AI放大的不是职业标签，而是人的基本功。
