AI Coding Agent 会取代程序员吗？先别急着焦虑
前段时间，我在杭州电子科技大学、东南大学、浙江大学等高校，和老师、研究生以及本科生聊 AI-Assisted Engineering 和 Project Velocity 时，几乎总会有人问到同一个问题。
与此同时，也有不少读者通过微信公众号私信我，表达了类似的担心：
OpenAI Codex、Claude Code、Google Antigravity、OpenCode 这些 AI 编程 Agent 越来越强，是不是意味着程序员很快就要被替代？
这确实是个很现实的疑问。
因为如今的 AI 编程 Agent，早已不只是帮你把代码补全那么简单。它能够读取代码、修改代码、执行命令，甚至能在同一个项目目录里把一串开发任务连续完成。
所以，大家的担心并非空穴来风。
这个问题真实存在，而且也很容易让人焦虑。
于是很多人会想：
既然 AI 已经能写代码，那程序员到底还剩下什么价值？
我的观点是：AI编程Agent 不会轻易直接“取代”程序员，但会迅速替换那些只会“等需求、写代码、不验证、不理解系统边界”的从业者。
真正发生变化的，并不是“程序员这个职业”本身，而是“程序员的工作方式”。
过去我们依赖 IDE、代码模板、栈溢出技巧、搜索引擎，更多是在“找答案”。
后来有了 Copilot、ChatGPT，我们开始让 AI 帮忙“写片段”。
但到了今天的 AI 编程 Agent，情况完全不同。
它不只是回答问题，还能进入工程目录，先理解上下文，再去完成一连串实际动作：
查看已有代码
修改多个文件
执行测试
根据报错继续调整
生成提交说明
阐述设计思路
协助重构项目结构
这就意味着，AI 正在从“代码助手”走向“工程执行单元”。
但要注意：它仍然只是执行单元，而不是工程负责人。
这两者的差别非常关键。
很多人在第一次使用 AI Coding Agent 时，会感到特别兴奋。
比如输入一句：
帮我实现这个功能。
随后 Agent 开始快速改文件、生成代码、跑命令。
你会觉得它很聪明。
可过一会儿，问题就出现了：
代码确实能跑，但不一定满足真实硬件约束
功能看似完成，但边界条件被遗漏
测试通过了，但测试本身覆盖太弱
改了不少文件，却没有把“为什么要改”交代清楚
一旦出错，回滚会变得很困难
系统越改越复杂，最终无人敢再维护
这就是大家常说的“Agent 翻车”。
并不是因为 AI 不够强，而是使用者没有给它设定清晰的工程边界。
AI Agent 擅长执行，但它并不知道你的产品目标、硬件限制、安全要求、交付节奏以及客户场景。
这些关键信息，仍然需要工程师去明确。
在传统开发模式里，程序员的主要工作往往是：
理解需求 → 写代码 → 调试 → 修 bug → 交付。
而在 AI-Assisted Engineering 的模式下，工程师的角色会更像：
明确目标 → 规划架构 → 约束 Agent → 审查结果 → 搭建测试 → 控制风险 → 持续迭代。
换句话说，程序员不再只是“代码生产者”，而是在逐步成长为：
系统设计者、验证负责人、工程流程控制者。
未来真正重要的能力，不是你每分钟能敲多少行代码，而是你能否回答这些问题：
这个功能为什么要做？
它运行在什么硬件与系统环境中？
它与哪些模块发生通信？
一旦失败，应该如何处理？
怎样才能证明它真的可靠？
如何回滚？
如何让后续工程师读得懂？
AI 可以帮忙推导与整理，但最终责任仍不能由它来承担。
以我一直在推进的 Project Velocity 为例。
它是端到端的 AIoT 工程系统，而不是一个简单的 demo。
系统主要分成三个层次：
Node 层：STM32F103 + Zephyr RTOS，连接传感器、按键、LCD、IR、DC Motor 等外设。
Edge 层：RK3588 作为边缘网关，运行 Ubuntu，承担协议转换、数据处理与边缘控制。
Cloud 层：ThingsBoard 用于遥测展示、RPC 控制以及设备管理。
此外，系统里还串联了 MQTT、CANopen、OPC UA、UART、Device Tree、Kconfig、main.c、Python Gateway、Dashboard、Telemetry、RPC 等完整链路。
如果只是让 AI Coding Agent 写代码，它当然能帮你生成很多文件。
比如：
Zephyr 的 main.c
CANopen 通信实现
MQTT 客户端代码
ThingsBoard RPC 处理逻辑
Python 网关脚本
数据格式转换函数
README 文档
测试脚本
这些它都可以做，而且速度非常快。
但关键问题在于：
这些代码能否拼成一个可靠的端到端系统？
这已经不是“会写代码”就能解决的事。
在 Web 应用里，Agent 写错了最多就是页面报错、接口失败、服务重启。
可是在嵌入式与 AIoT 场景中，错误可能直接影响真实设备。
例如 Project Velocity 里，如果 Agent 没弄清硬件边界，可能会出现类似情况：
STM32 的 GPIO 引脚定义不正确
Zephyr overlay 文件与实际硬件不一致
CANopen Node ID 发生冲突
MQTT Topic 设计混乱
ThingsBoard RPC 下发后，边缘网关解析出错
电机控制逻辑缺少保护条件
IR 控制缺少状态确认
传感器数据上传没问题，但控制链路没有被验证
这些隐患，AI编程Agent 未必会主动发现。
因为它能看到的多是代码层面，而不是完整的硬件系统。
因此在 Project Velocity 里，我一直强调一个观点：
AI-Assisted Engineering 并不是让 AI 随意发挥，而是让 AI 在工程约束下工作。
很多人说自己在做 AI 编程，其实只是 Vibe Coding。
所谓 Vibe Coding，就是：
给 AI 一个大概方向，让它凭感觉生成代码。
这种方式适合快速探索、做原型、写小工具。
但如果你要做的是 Project Velocity 这种 MCU–Edge–Cloud 系统，仅靠 Vibe Coding 就会很危险。
因为真正的工程需要的不只是“代码能生成”，还包括：
架构要清楚
硬件映射要正确
协议链路要一致
数据模型要统一
控制路径要可追踪
测试要可复现
版本要能回滚
出错要能定位
这正是 AI-Assisted Engineering 与 Vibe Coding 的核心差异。
Vibe Coding 更看重生成；AI-Assisted Engineering 更看重交付。
未来，工程师不一定要比 AI 更快写代码。
但一定要比 AI 更清楚：
哪些代码不该写，哪些方案不能采用，哪些风险必须提前处理。
当你使用 Coding Agent 时，真正重要的就不只是“帮我写代码”，而是给它足够的工程化约束。
比如在 Project Velocity 中，我不会只说：
帮我写一个 STM32 程序。
我会要求 AI 同时考虑：
使用 Zephyr RTOS
基于 STM32F103
外设需要在 Device Tree overlay 中定义
Kconfig 必须在 prj.conf 中启用
应用逻辑编写在 main.c
CANopen 参数要与边缘网关保持一致
MQTT Topic 要与 ThingsBoard Dashboard 匹配
控制命令必须具备边界检查
所有关键修改都要可测试、可回滚
这也是我在 Project Velocity 讲座里反复提到的“三文件策略”：
overlay / prj.conf / main.c
对 Zephyr 来说，如果只让 AI 写 main.c，很容易出现“代码看起来没问题，但在硬件上根本跑不起来”的情况。
只有把硬件映射、系统配置和应用逻辑一起约束，AI 生成的代码才会更接近真实工程。
AI Coding Agent 最先被淘汰的，不是所有程序员，而是以下几类工作方式：
第一类：只会机械式写代码的人。
如果任务已经定义得很清楚，输入输出明确，测试也明确，那么 Agent 很快就能完成大部分编码内容。
第二类：不理解系统上下文的人。
只会改当前文件，却不了解上游数据、下游接口、硬件限制和实际运行环境，这类工作会变得越来越危险。
第三类：不写测试、不做验证的人。
AI 写代码很快，也可能同样快地埋下隐蔽 bug。如果工程师不建立验证体系，速度越快风险越大。
第四类：不愿意学习新工具的人。
编程 Agent 不会等你准备好。它会先改变团队的开发流程，随后也会影响招聘标准。
但与此同时，AI Agent 也会放大另一类工程师的价值。
未来更有竞争力的工程师，往往具备这些能力：
第一，能把模糊需求转化成清晰任务。
AI 对模糊指令非常敏感。你说得越具体，它越能发挥价值。
第二，能设计系统边界。
知道哪些模块由 MCU 处理，哪些交给 Edge，哪些必须由 Cloud 承担，同时哪些环节仍需人工审核。
第三，能建立测试与验证方法。
包括单元测试、接口测试、硬件在环测试、日志检查、回归测试以及异常场景测试。
第四，能读懂 AI 生成的代码。
不会盲目相信，也不会因为 AI 写得快就直接合并。
第五，能把 AI 纳入工程流程。
让 Agent 参与文档、代码、测试、Review、CI、版本管理，而不是只把它当作聊天机器人使用。
具备这些特质的工程师，不但不会被 AI 取代，反而会因为 AI 获得更强的生产力。
对于学生来说，不要只学“如何让 AI 帮你写作业”。
更重要的是要学会：
如何描述问题
如何拆解任务
如何阅读 AI 生成的代码
如何定位错误
如何编写测试
如何用 Git 管理版本
对于研究生来说，不要只把 AI 当作论文助手。
你应该学会让 Agent 帮你：
阅读资料
整理实验流程
生成原型代码
设计实验记录
对比不同方案
形成可复现的研究工程
对于工程师来说，也不要把 Agent 当成“高级自动补全”。
你应该把它看作一个需要管理的初级工程团队成员。
它能很快产出，但需要你给方向。
它可以执行，但你必须做判断。
它可以生成，但仍需要你去验证。
所以，AI编程Agent 会不会取代程序员？
我的答案是：
它不会取代真正理解系统、能设计架构、能验证结果、能承担交付责任的工程师。
但它会取代大量低价值、重复性强、缺乏上下文理解的编码工作。
这其实并不一定是坏事。
因为工程师本来就不应该只做“代码搬运工”。
真正的工程能力，应该体现在：
你能否把一个想法变成系统？
你能否把一个 demo 打磨成产品？
你能否让一段代码进入真实硬件、真实网络、真实客户场景并稳定运行？
你能否在出错时快速找到原因、控制风险并持续交付？
Project Velocity 给我的最大启发是：
AI 让代码生成变得更快，但工程交付并不会因此变得更简单。
相反，越有 AI，越需要工程师定义边界、建立验证、管理复杂度。
AI编程Agent 的出现，并不意味着程序员的终结。
它更像一次分水岭。
一边是继续停留在“我会写代码”的旧模式。
另一边是进入“我能用 AI 组织工程交付”的新阶段。
未来，真正重要的问题不是：
AI 会不会写代码？
而是：
你能不能带着 AI，把代码变成一个可靠的系统？
这才是从 Vibe Coding 走向 AI-Assisted Engineering 的关键。
也才是 AI 时代工程师真正的护城河。