一个大胆的假设：C语言之于汇编，Java之于C，Python之于Java，现在LLM智能体正在对所有编程语言做同样的事。
这里说的LLM智能体，指的是一种全新的开发模式：多个智能体并行工作，大部分时间自主运转，只在关键节点需要人类介入。判断这个假设是否成立的标准很简单：如果一个开发者借助多智能体能产出十倍于从前的成果，那它就是真的。2026年初的今天，我还不能完全确定，但已经在认真考虑这种可能性。
对于在软件行业摸爬滚打多年的人来说，质疑声不会少。先回应几个常见的：
“十倍代码量不等于十倍产出，那只是垃圾代码。”没错，衡量标准应该是实际交付的功能价值，不是代码行数。如果假设成立，真正的“代码”其实是你给LLM的指令。
“LLM是给不会写代码的人用的。”LLM确实会带来大量新程序员，但这不意味着老手用不上。事实上，很多资深开发者正在借助LLM实现产出的飞跃。
“用LLM就是偷懒不想动脑。”恰恰相反。当你用LLM做更多事情时，你需要思考和工作得更多，而不是更少。管理一支智能体舰队比自己写代码更费心力，因为你要设计的东西是原来的好几倍。
“LLM会让我们的编程技能退化。”可能吧。但我们在工作中也不会担心汇编或C语言技能生疏。大多数人只在业余时间练习这些，因为没人能证明用汇编写业务代码会更高效。
“LLM写的代码比我差太多。”几乎肯定如此。但你的汇编代码也比不上专家。只要LLM生成的代码足够高效，能跑起来，就已经可以交付了。系统会丑一些，但它能用。
“用LLM智能体太贵了。”如果它们能带来50%的生产力提升，对比你的薪资，其实一点都不贵。而且LLM只会越来越便宜。它们只在绝对值上贵，相对值上并不贵。
“我试了一下午，纯粹浪费时间。”学习曲线是存在的。想想你当初花了多少时间和编程工具、语法搏斗，才勉强上手。
以上这些反对意见在逻辑上都站不住脚，但情感上确实不容易接受。
真正触及核心的问题有两个：质量和可理解性。LLM生成的代码会不会很快变成一堆垃圾？我们是不是在沙子上建房子？LLM生成的代码量会不会大到我们永远无法理解？即使系统能跑，我们是否会因为不理解而永远失去控制？
我认为质量和可理解性应该成为任何LLM编程框架的核心目标。从经济角度看，只追求质量是不够的。可理解性可能是浪漫主义的幻想，也可能是一个值得押注的长期赌注。我选择后者。
有趣的是，LLM比以往任何高级语言都更具非确定性。但它们也能在高层次描述上帮你理清思路，这是以前任何抽象层都做不到的。
未来的开发会是什么样子？我看到四个核心要素：文档是一组描述系统规格的页面，包括目的、核心实体、接口、约束、关键流程和编码规范；实现是代码库加上所有数据，代码库应该能从文档重建，数据应该与文档描述一致；对话是多个智能体在执行任务时产生的思考流，人类可以随时查看或介入；任务是一组动态的离散工作单元，可以嵌套，有状态追踪。
两个存量，两个流量。文档和实现是系统的积累，对话和任务是构建它们的过程。人类当然可以直接修改文档和实现，但这种情况会越来越少，因为大部分工作流是智能体驱动的，人类主要在与智能体交互。
智能体可以扮演多种角色：独立完成任务的执行者、协调下一步的管理者、试图破坏新功能的测试者、脱离上下文审查代码的评审者、解决冲突的合并者。重要的是人类可以灵活配置，指令可以是一次性的，也可以是文档的一部分。
MCP协议带来了一个打破应用孤岛的机会。它可以被视为一种通用的数据请求接口，让你的智能体能够从任何现有应用中提取功能和数据，放到你自己设计的动态画布上。你可以说“从某个系统给我拿这些数据”，LLM就会去取，然后在你想要的地方做一个漂亮的即时可视化。这才是真正的孤岛终结者。
如果我们用一个好的底层基座而不是臃肿的技术栈，LLM输出的代码量会大幅减少，也更容易理解。系统的前端变成了文档和智能体，后端变成了基座。
还有一些开放问题：文档和对话如何与实现一起存储？版本控制系统怎么用？这些都等待探索。
