AI写代码被吹上天了,但程序员不会因此消失

最近看到很多关于 AI 编程的文章,尤其是 Cursor、Claude Code、Vibe Coding 相关内容,给人的感觉仿佛软件开发已经进入了“全民开发时代”:不会写代码的人也能做产品,程序员即将被 AI 替代,未来随便拉几个人组队就能做出互联网产品。 作为一个长期使用 Cursor 辅助开发的人,我承认 AI 的进步确实非常惊人。我自己几乎每天都在使用 AI 写代码,而且体验很好。但如果因此认为软件开发已经被彻底颠覆,甚至认为程序员这个职业即将消失,那显然高估了 AI 当前的能力。 客观来说,AI 更像一次生产力升级,而不是程序员的替代者。 对于后台管理系统、CRUD业务、接口开发、脚手架代码、测试代码、文档编写这类标准化工作,AI 已经表现得非常优秀。很多过去需要初中级程序员花费大量时间完成的任务,现在一句提示词就能生成质量不错的代码。在这些领域,AI 的效率确实已经超过了绝大部分开发者。 但问题是,真正的互联网系统从来不是靠生成代码构建出来的。 一个成熟的线上系统,真正困难的部分往往是业务建模、架构设计、性能优化、高并发处理、稳定性治理、容灾设计以及各种复杂场景下的技术决策。代码实现反而只是整个过程里相对容易的一环。 AI 可以帮你快速搭建一个电商系统,但它很难替你解决流量暴增时的扩容问题、缓存击穿问题、数据库热点问题、分布式事务问题以及各种线上故障。很多时候,系统的上限并不取决于代码写得快不快,而取决于架构是否合理、方案是否成熟、风险是否被提前识别。 这也是为什么我一直认为,Vibe Coding 更适合做原型、工具和中小型项目,而不是直接用于复杂生产系统。 Vibe Coding 最大的问题不在于代码写错,而在于开发者可能不知道哪里有问题。AI 生成的代码往往能够运行、能够通过测试,看起来一切正常,但其中可能隐藏着性能瓶颈、安全漏洞、并发缺陷或者架构隐患。如果开发者缺乏足够的工程经验,就很难发现这些问题。项目规模小时看不出区别,一旦用户增长、业务复杂度上升,各种技术债就会集中爆发。 事实上,技术发展一直遵循同样的规律。 框架出现的时候,很多人认为程序员要失业;云计算兴起的时候,很多人认为运维会消失;GitHub 和开源生态成熟后,也有人认为技术门槛会被彻底抹平。但最后发生的事情并不是专业人才消失,而是重复劳动减少了,工程师开始把更多精力投入到更高价值的工作中。 AI 本质上也是如此。 它替代的是重复性劳动、标准化劳动和机械性劳动,而不是业务理解、架构思考和工程判断。真正决定一个系统质量的,始终是人的认知能力和经验积累。 前段时间 Google CEO 桑达尔·皮查伊提到一个观点:AI 降低了软件开发门槛,会让原本没有能力进行数字化建设的行业开始转型,最终带来更多的软件需求。 我比较认同这个判断。 开发成本下降,不一定意味着程序员需求减少,反而可能意味着更多企业和行业开始建设自己的系统。过去不值得做的软件,现在值得做了;过去做不起的项目,现在做得起了。需求总量很可能比今天增长数倍甚至数十倍。 因此,未来真正面临风险的未必是程序员,而是不愿意使用 AI 的程序员。 就像当年不会使用搜索引擎的人被淘汰,不会使用 Git 的人被淘汰,不会使用云平台的人被淘汰一样,未来不会使用 AI 的开发者竞争力一定会下降。 但与此同时,仅仅会用 AI 也远远不够。 未来最有价值的工程师,依然是那些既懂业务、懂架构、懂工程,又能够熟练驾驭 AI 工具的人。AI 会极大放大优秀工程师的生产力,却很难替代他们的判断力。 代码越来越不值钱,但理解问题、设计系统和解决复杂问题的能力,反而会变得更加稀缺。 所以,与其讨论“AI 会不会取代程序员”,不如思考另一个问题:当人人都能生成代码的时候,你还能提供什么是 AI 无法替代的价值。真正的竞争,未来才刚刚开始。

June 9, 2026

从Vibe Coding到代理工程:AI正在改变软件开发的组织方式

最近看了OpenClaw(ClawdBot)创始人Peter Steinberger 的一次访谈,最大的感受不是AI写代码越来越强,而是开发模式本身正在发生变化。很多人还在讨论 Vibe Coding,但在他看来,开发已经进入了 Agent Engineering(代理工程)阶段。 按照他的描述,现在开发过程中已经很少亲自写代码或者逐行阅读代码,而是同时管理 5~10 个 Agent 并行工作。有的负责实现功能,有的负责测试,有的负责重构,有的负责排查问题。开发者更像项目经理,负责分配任务、观察执行过程和判断最终结果,而不是亲自完成每一个细节。过去程序员是在写代码,现在更像是在管理代码生产流水线。 这种变化也带来了质量控制方式的改变。传统开发强调 Code Review,而 Peter 更关注验证系统本身。他认为与其检查每一行代码,不如构建完善的测试和验证闭环。只要 Agent 能完成需求、通过本地测试并验证结果符合预期,他很多时候会直接合并代码,而不会再花大量时间审查具体实现。未来的软件工程可能会越来越从“检查过程”转向“验证结果”。 访谈中另一个有意思的观点是人与 AI 的关系正在从命令变成沟通。他提到自己越来越少给 Agent 下达机械指令,而是花时间理解 Agent 如何拆解任务、如何做出决策。当 AI 无法正确完成任务时,他首先考虑的是自己是否没有把需求表达清楚。这意味着未来开发者的一项核心能力可能不再是编码,而是如何高效地与智能体协作。 OpenClaw 本身也是这种开发模式的产物。整个项目最初几乎就是 Peter 一个人在家用了十天时间完成,高峰时期甚至创造过 GitHub 单日 1374 次提交记录。放在过去,这样的工作量往往需要一个团队完成,而现在借助 Agent,一个人的生产力边界被大幅扩展。 最让他震撼的案例来自一次语音翻译任务。Agent 在收到 WhatsApp 语音消息后,自主决定调用本地 FFMPEG 将音频转换成 WAV 格式,再调用 OpenAI API 完成识别和翻译,整个流程并没有被提前写成固定工作流,而是 Agent 根据目标自行规划执行路径。这种能力与传统自动化脚本最大的区别在于,它不只是执行命令,而是在主动寻找解决方案。 在 Peter 看来,OpenClaw 的核心价值也不是聊天机器人,而是“数据解放”。今天用户的数据分散在 WhatsApp、Telegram、Slack、Gmail、Notion 等各种平台中,虽然数据属于用户,但控制权往往掌握在平台手里。OpenClaw 希望让 Agent 直接帮助用户操作这些数字资产,打破大型科技公司构建的封闭生态。 基于这种趋势,他甚至认为未来很多传统 App 都可能被个人 Agent 替代。用户不再需要在不同软件之间切换,而是直接向自己的 Agent 描述目标,由 Agent 完成邮件处理、日程安排、文档管理和信息检索等工作。届时,一个普通人可能拥有多个数字员工,甚至运行属于自己的“小型公司”。 不过他也强调,目前最大的挑战仍然是安全。随着 Agent 拥有文件访问、浏览器控制、终端执行和 API 调用能力,提示词注入攻击带来的风险也在快速放大。因此他建议尽量在 VPS、Docker 或虚拟机等隔离环境中运行 Agent,而不要直接给予系统最高权限。 ...

June 6, 2026