近年高速发展的大语言模型正在冲击和重塑着整个社会。其中首当其冲、最引人注目的领域，当属 AI Coding。
我每天高强度从事软件开发，又对 AI 有一定的认识，当然不会错过这波技术革新。自 GPT-4 大火、人们开始为 Chatbot 付费以来，历经多种流行的 AI 工具，我工作中 AI 生成代码的比例从两年前的10%，逐渐上升到70%，再到近几个月的100%。完全可以说，作为程序员的自己，已经被 AI 淘汰了。
有些时候，只要测试跑通，我甚至看都不看就可以合入 AI 提交的代码。
你敢信：不再是“AI辅助人类编程”，而是“人类根本没有在编程”。
AI 真能负责 100% 的代码吗？这种方式是否可持续？
这篇文章不是关于 AI Coding 「好」与「不好」的空泛讨论，也不是关于程序员还有没有存在的价值。
而是：当 AI Coding 已经无可辩驳的强大，当代程序员如何与它共存。
AI 的能力版图
用 AI 写代码，最基础的模式是让它编写函数。函数级 AI 编程非常实用，代码质量极高，且任何偏差都容易被发现和纠正。坦率地说，只要输入的 prompt 正确且恰当，在函数级编程上，人类不可能优于 AI。
但在函数级以外呢？如果要写一个大型的程序，包含大量的函数、类、对象，包含复杂架构和业务逻辑——这样的复杂程序设计，AI 也能达到、甚至超越人类程序员吗？
有人会说不行，还提出「AI 将从事低端繁琐的编码工作，人类将负责高级的架构设计」。
我觉得这是扯淡。这些人根本没有真的用 AI 写过多少代码。
你要是每天跟 AI 一起编程，就会发现它的架构设计能力其实很强，超过80%的人类高级架构师。
这也很好解释：普通程序员一辈子写不了几个大型程序，很多时候甚至轮不到他来设计架构。
有些项目架构是现成的，开发者只能在屎上雕花；有些项目本就是玩具项目，无需高并发和稳定性，再烂的架构也能兜住。
而 LLM 的训练语料是所有的开源代码，它见过市面上所有的主流架构、所有的开发模式，洞察所有语言和框架的特性，比普通程序员有着更广泛、深刻的项目经验和架构理解。
如果能清晰梳理产品形态、需求，细化性能与成本要求，并给出风格偏好，LLM 可以输出极其优秀的架构设计。
从这个角度讲，AI 比人类更擅长做程序顶层设计。
由此可知，AI擅长做底层（函数），也擅长做顶层（架构）。那为什么，在我们经验中，它做不好中间层呢？
- 现阶段可能是受限于技术水平，导致上下文长度不够、注意力难以管控。（当然，在 Claude Code 出现之后问题已经改善了很多）
- 也可能是因为实际业务中，中间层容易发生设计变更（这些变更往往与实际业务相关，而 AI 不了解实际业务）。
但我认为，更关键的原因在于：中间层需要更多「学习」。
软件开发真正有价值的部分——虽然人们羞于承认——一直都是这个学习过程：快速理解业务、从之前的项目经验中提取知识、使用新的工具和方法、理解他人的代码并复合出更大价值。
而当前的 LLM 工具都是 0 学习的纯推理系统（即使有 Memory 机制，也只是把历史交互记录下来供后续参考，并没有产生新的权重和网络结构）。
即使「边缘学习」也是要考虑成本的。
现在的 LLM 已经如此庞大，训练和微调都耗费不菲。要让它更广泛地应用，必须在边缘部分使用廉价的学习机制去适配具体场景。而很多时候，人类劳动力反而是廉价的。
即使只是一种局部最优，在这个临时解决方案中，形成了一个典型的三明治结构：
人类的新角色
如果你问一个小公司的老板最近在忙什么，他大概率告诉你「在打杂」。这个现象符合某种规律：小公司往往有一套固定的商业模式，一旦跑通，几个员工就能完成整个流程。老板变成了「为员工打杂」的角色——雇佣员工，监督他们工作，帮他们把别的杂务都处理好，让员工能专注于核心任务。
AI 编程如今也是这样。由于 AI Coding Agent 已经强大到可以主力完成复杂软件的开发，程序员成了一个类似于老板的角色——雇佣 AI，监督它工作，并从成果中获取收益。因此程序员每天都在面临这个问题：AI 还需要些什么？我怎么能让它工作得更好？
具体来说，人类在这个新体系中扮演以下角色：
- 上下文存储器：AI 的上下文窗口有限，而项目的历史、决策背景、隐性知识都需要有人记住并在恰当的时候提供给 AI。人类成为 AI 的外挂记忆体。
- 领域专家系统：AI 拥有通用编程能力，但对具体业务领域的理解往往不足。人类基于对业务的理解，帮助 AI 完成项目冷启动，将通用能力转化为专业产出。
- 边缘学习器：人类负责快速学习新的业务知识、工具方法，完成 AI 无法完成的「边缘学习」，将 LLM 的泛化能力与专业性结合，达到专家级效果。
- 代码整理者：AI 负责常规业务性开发，人类负责「打扫战场」——整理代码架构，保持代码库的清晰和可维护性。
这些角色的共同特点：它们都是「辅助性」的。
人类不再是编程的主力，而是让 AI 能够更好工作的支持系统。
稳定性工程
AI 的工作是「模糊的」，或者说「不稳定的」。由它开发出的代码，可能仅仅是对于正确结果的「近似解」。那么，每一个 AI 实施的环节都产生一定程度的「偏离」。
在复杂工程中，所涉环节众多，这种偏离可能具有累积效应。如果把 AI 编程视为一种链式调用，它具有类似深度神经网络的梯度消失/爆炸模式——最终可能导致整个项目失控。（而且你很难快速修正关键错误，因为每个环节都可能有错。）
因此，在 AI 开发的软件项目中，应该在重要的关键环节主动制造稳定层（由人类负责维护），让 AI 开发的部分去依赖稳定层。
这样即使关键环节出现错误，由于是人类自己开发的，也很容易找到和解决问题。
且当 AI 开发的部分出错时，错误不会被稳定层传导出去，会很容易被发现。
回到链式调用的假设中：人为参与的环节越多，整体编程过程越可控。AI 程序员需要找到最佳的交叉参与机制，让人类只在关键环节进行很少的介入，就使整个创造过程稳定。
既然 AI 的输出是「近似解」，偏差就是客观存在的。我们选择用 AI 来开发项目，是因为 AI 开发的效率收益远大于它造成的偏差的损失。
在这个问题上，正确的态度不是「接受错误」，而是设计容差——把对偏差的考量纳入设计，甚至专门设计容差量。
参考其它工程领域的经验，这就涉及几个核心原则：
- 不确定性原则：承认系统中存在不可消除的不确定性，并围绕它进行设计。
- 系统冗余：在关键路径上设置冗余机制，使单点故障不致于导致整体崩溃。
- 功能性优先：先保证系统能工作，再追求完美。一个能跑的近似解胜过一个永远完成不了的精确解。
- 经济性原则：容差设计要考虑成本。过度的冗余和校验同样是浪费。
现实世界并非完美，因此设计必须允许不完美，并能在不完美中工作。这是与 AI 协作的工程师必须内化的认知。
变难吃的三明治
随着 AI 能力发展和 AI 编程工程体系的成熟，前面描述的三明治结构会「降本增效」，逐渐发展成一个难吃的形状——人类负责的部分越来越小，AI 负责的部分越来越多。
中间那层「人类主导」的夹心会越来越薄。上下文窗口会越来越长，注意力机制会越来越强，边缘学习的需求可能被某种轻量级微调机制替代。每一次技术进步，都会压缩人类的参与空间。
我们尚不清楚人类负责的部分能否减少为 0。但它会减少，这是必然的。找到方法让它继续减少，是 AI 程序员接下来要做的功课——听起来有些讽刺，但这就是现实：如果尊重技术进步的铁律，我们的工作，就是让自己变得更加不必要。
在普遍使用 AI 执行编程的场景下，人们不再关心「某个功能能否实现」——程序员能力不再是瓶颈，你提的需求，AI 必将实现。
「执行速度」成为核心。一个好的 AI 程序员将以数倍于传统方式的效率生产软件产品。
好的工程管理能放大这个优势：越短的反馈循环，越适合用 AI 来快速迭代验证，并享受效率提升的指数增长价值。
It’s All About Taste
乔布斯说过：Ultimately, it comes down to taste.（最终，一切归结于品味。）
当 AI 在编程技术上已经超越大多数人类，当实现任何功能都不再是障碍，什么会成为区分程序员的标准？
答案也许是品味。
同一个目标往往有多种实现方案。AI 可以给你列出所有可行的路径，但选择哪一条，需要的是判断力——对「好」的深刻理解。这不是技术能力，而是审美能力。
什么样的代码是优雅的？什么样的架构是简洁的？什么样的交互是自然的？什么样的产品是有灵魂的？这些问题没有标准答案，却有好坏之分。能分辨这种好坏，就是品味。
在后编程时代，只有有品味、有追求的程序员才能写出独特的程序。技术趋同是必然的——所有人都用同样强大的 AI——但品味无法复制。它来自于对领域的深刻理解，对用户的真诚关怀，对美的持续追求。
这或许是人类程序员最后的价值锚点。但也注定了，好的程序员更难被外部评价体系发现。
镜中的后编程时代
很多人把 AI 和人类视为对立面或互补关系——AI 强的地方人类弱，人类强的地方 AI 做不到。
这种观点令人安心，因为它暗示着人类总有不可替代的价值。
但实践告诉我，事实可能并非如此。
AI 和人类有很多相似的特质：泛化能力、学习能力、记忆力、联想能力……
这使得人类身上的很多问题，在 AI 上也存在；曾经只有人类擅长的事情，现在 AI 也越来越擅长。
固然，AI 在工作上还有很多问题。但如何解决 AI 存在的问题？我越来越觉得像在照镜子——实际上是在解决自己存在的问题：
AI 不是人类的「对立面」，而是人类的「镜像」。
人类会的，AI 也会；AI 不会的，人类也不会。
曾经，写代码是一种「编程」。现在，编排一批 AI Agents 稳定地构建起一套复杂系统也是一种「编程」。这就是镜中的「后编程时代」。
当历史的车轮滚滚向前，copilot 已经悄悄接过方向盘。我们别无选择：既要确保自己还在车上，又要寻找新的领航方法。
面对 AI 这头难以驯服的巨兽，如何驾驭它踏碎过往、走出新路，让软件工程提速、却又不至于失控？可能是眼下最直接的问题。