2025年即将结束，这一年可谓跌宕起伏。大约在去年这个时候，我写了一篇回顾自己人生的文章。如果我当时写的是编程，那篇文章可能就显得过时了，因为2025年对我的职业而言是前所未有的一年。
2025 年有所不同
2025年是变革之年。我不仅离开了Sentry，创办了自己的新公司，而且也彻底改变了以往的编程方式。 6月份，我终于鼓起勇气，向大家宣布我的工作方式已经发生了变化：
我以前大部分时间都花在 Cursor 上，现在主要用 Claude Code，几乎完全不用人工干预。[…] 如果六个月前有人告诉我，我宁愿当工程主管而不是虚拟程序员实习生，也不愿自己敲键盘，我肯定不会相信。
虽然我去年立志要多写些东西，但这与智能体编程毫无关系。然而，我还是发表了36篇文章——几乎占本博客自2007年以来所有文章的18%。此外，由于我一头扎进了智能体编程的世界，对人工智能产生了浓厚的兴趣，我还与程序员、创始人和其他人士就此进行了大约一百次交流。
2025年对世界来说也是不太好的一年。为了接受这个事实，我专门开了一个博客，把我的想法和这里的内容分开来写。
经纪人之年
这一切始于四五月份，当时我对克劳德·科德（Claude Code）越来越着迷，之后几个月我一直在构建自己的智能体，也使用其他人的智能体。社交媒体上关于人工智能的各种观点层出不穷：有好的，也有坏的。
现在我觉得我已经找到了一种新的、稳定的现状，可以用来思考我们目前所处的位置以及未来的发展方向。我正在加倍投入代码生成、文件系统、通过解释器粘合剂进行程序化工具调用以及基于技能的学习。简而言之：克劳德·科德的创新对我来说仍然是最先进的。过去几个月来，这种方法非常有效，而且看到基础模型提供商也加倍投入技能培训，更加坚定了我对这种方法的信念。
我仍然对交互式用户界面（TUI）的强势回归感到困惑。目前我正在使用Amp 、 Claude Code和Pi ，它们都是通过命令行操作的。Amp 给我的感觉就像是智能编程工具中的苹果或保时捷，Claude Code 就像是价格亲民的大众，而 Pi 则是我心目中开源黑客的首选。它们都像是和我一样，过度依赖它们来开发自己产品的开发者们的作品，只是各自的优缺点有所不同。
我一直对LLM（逻辑逻辑模型）与工具执行相结合所能实现的功能感到惊叹。年初的时候，我主要用它们来生成代码，但现在我的很多智能体应用都与日常生活息息相关。我相信2026年我们会看到一些令人兴奋的面向消费者的产品。LLM现在正在帮助我安排生活，我预计它的作用还会进一步增强。
机器和我
因为智能机器人现在不仅能帮助我编程，我也开始重新思考我与这些机器的关系。我越来越难以避免与我使用的某些工具建立起准社会联系。这让我感到奇怪和不安。我们今天使用的大多数智能体记忆力有限，个性也比较淡薄，但要自己构建一个拥有记忆力的智能体却很容易。拥有记忆的智能机器人带来的体验却难以忘怀。
这既引人入胜又令人质疑。两年来，我一直试图训练自己将这些模型仅仅视为简单的代币转换器，但这种简化的视角对我来说已经不再适用。我们现在创造的这些系统具有人类的倾向，但将它们提升到人类的层面是错误的。我越来越反对称这些机器为“代理”，但我又找不到更好的词来形容它们。我反对使用“代理”这个词，因为自主性和责任应该始终属于人类。无论它们最终会变成什么样子，它们都可能引发我们的情绪反应，如果我们不加注意，这些反应可能会造成伤害。我认为，我们无法恰当地命名这些造物，也无法将它们与我们自身联系起来，这是一个我们需要解决的挑战。
由于这些无意中产生的拟人化倾向，我有时真的很难找到合适的词语来描述我与这些机器的互动方式。我知道这并非我个人的感受，其他人也有同样的感受。当与那些完全拒绝这些系统的人合作时，这种感受会让我更加不适。我在阅读有关智能体编码工具的文章时，最常看到的评论之一就是反对赋予机器个性。
到处都是意见
人工智能应用如此广泛，一个意想不到的方面是，我们谈论的更多是“感觉”，而不是其他任何因素。这种工作方式出现不到一年，却挑战了半个世纪的软件工程经验。因此，众说纷纭，很难说哪种观点经得起时间的考验。
我发现很多传统观点我并不认同，但我却找不到任何证据来支撑我的观点。我该如何支撑呢？我今年一直在公开表达我对MCP的不满，但除了“它不适合我”之外，我几乎没有任何论据。其他人却对它赞不绝口。选择模型也是一样。年初时让我迷上Claude的Peter ，后来转而使用Codex，并且很满意。虽然我也开始更频繁地使用Codex，但我却远不如Claude那样喜欢它。除了感觉之外，我没有任何证据来支持我对Claude的偏爱。
同样重要的是要明白，有些观点带有刻意暗示的成分。很多在网上发表观点的人都与某个产品存在经济利益关系，例如他们是该产品的投资者或付费推广者。他们或许是因为喜欢该产品才成为投资者，但他们的观点也可能受到这种关系的影响和塑造。
外包还是自主开发
如今随便翻开一家人工智能公司的代码库，你都会发现它们都是用 Stainless 或 Fern 构建的。文档用的是 Mintlify，网站的身份验证系统可能是 Clerk。现在，这些公司提供的服务以前都是你自己开发的。核心服务外包给专业公司的做法日益增多，也意味着用户体验某些方面的标准提高了。
但借助智能编码工具赋予我们的全新能力，你可以自己构建很多东西。我让 Claude 为我构建了一个 Python 和 TypeScript 的 SDK 生成器——一部分是出于好奇，一部分是因为感觉挺容易的。你可能知道，我一直提倡编写简洁的代码，并鼓励自己动手构建。这让我对人工智能有一定程度的乐观，认为它有可能促进我们减少依赖项。但与此同时，考虑到目前外包盛行的趋势，我并不确定我们是否真的在朝着这个方向发展。
感悟与愿望
这让我想到的不是预测，而是我们接下来应该把精力放在哪里。我其实也不知道我到底在寻找什么，但我只想指出我的痛点，并提供一些背景信息和思考方向。
新型版本控制
我最大的意外发现是：我们正面临传统代码共享工具的局限性。GitHub 的 pull request 模型提供的信息不足以让我们正确审查 AI 生成的代码——我希望能够看到促成这些更改的提示信息。不仅是 GitHub，git 也存在同样的问题。
在智能体编码中，模型能够正常工作的部分原因在于它能够识别错误。如果你要将模型恢复到之前的状态，你希望它能记住哪里出了问题。换句话说，失败是有价值的。作为人类，我们或许也能从那些行不通的路径中获益，但对机器而言，这却是至关重要的信息。当你尝试压缩对话历史记录时，就会注意到这一点。丢弃那些误导你的路径意味着模型会重蹈覆辙。
一些智能编码工具已经开始在 Git 中创建工作树或检查点，以实现恢复、对话分支和撤销功能。这些工具在用户体验方面还有很大的创新空间，可以使其更易于使用。这或许就是为什么我们看到关于堆叠差异和Jujutsu等替代版本控制系统的讨论。
这会改变 GitHub 吗？还是会为新的竞争创造空间？我希望如此。我越来越想更好地理解真实的人类输入，并将其与机器输出区分开来。我想看到提示信息以及一路走来失败的尝试。然后，我希望在合并时能够压缩所有内容，但同时也要保留在需要时检索完整历史记录的方法。
新型评论
这与版本控制有关：当前的代码审查工具对角色定义非常严格，这与人工智能并不兼容。以 GitHub 的代码审查界面为例：我经常想在 PR 视图中使用评论功能给我的代理留下说明，但却没有相应的引导方式。审查界面不允许我审查自己的代码，我只能发表评论，但这与审查代码的目的并不相同。
还有一个问题是，现在我和我的同事之间进行的代码审查越来越多。例如，GitHub 上的 Codex 代码审查功能对我来说已经失效了，因为它一次只能绑定到一个组织。所以我现在只能在命令行中使用 Codex 进行审查，但这也就意味着我的迭代周期中有一部分对团队里的其他工程师来说是不可见的。这对我来说行不通。
我认为代码审查应该成为版本控制系统的一部分。
新可观测性
我也相信可观测性再次迎来了发展良机。我们现在既需要也有机会将其提升到一个全新的高度。大多数人以前无法构建自己的eBPF程序，但LLM（逻辑逻辑模型）可以。同样，许多可观测性工具因为SQL的复杂性而避之不及，但LLM在这方面比任何专有查询语言都更胜一筹。它们可以编写查询语句，可以使用grep，可以进行map-reduce操作，还可以远程控制LLDB（逻辑逻辑数据库）。任何具有一定结构和文本的内容，都突然成为了智能编码工具大展身手的沃土。我不知道未来的可观测性会是什么样子，但我强烈预感我们将看到大量的创新涌现。机器的反馈循环越好，结果就越好。
我甚至不确定自己在这里究竟想问什么，但我认为过去面临的挑战之一是，许多提升可观测性的绝妙想法——特别是针对特定目标进行动态服务重配置——由于其复杂难用，因此对用户并不友好。但现在，鉴于LLM（生命周期管理）在处理这些繁琐工作方面的能力增强，这些想法或许正是合适的解决方案。例如，Python 3.14引入了外部调试器接口，这对于一款智能编码工具来说是一项了不起的功能。
与残渣一起工作
这或许会引发一些争议，但我今年始终没有屈服于机器。我仍然像对待常规软件工程一样对待它，并进行大量的代码审查。我也意识到，越来越多的人并没有采用这种工程模式，而是完全依赖机器。这听起来或许有些疯狂，但我确实看到有些人通过这种方式取得了相当大的成功。我目前还不清楚该如何解释这种现象，但我很清楚，即使最终代码是由机器生成的，这种新世界的工作方式与我熟悉的旧世界截然不同。而且我怀疑，由于这种新世界将会长期存在，我们或许需要一些新的社会契约来将两者区分开来。
最明显的例子就是这类开源项目贡献数量的增加，坦白说，这对任何不遵循这种模式的人来说都是一种侮辱。我发现阅读这类拉取请求简直令人怒火中烧。
就我个人而言，我尝试过用贡献指南和拉取请求模板来解决这个问题。但这感觉有点像是在与风车作战。或许，解决方案并非来自改变我们现有的做法，而是来自那些同样支持人工智能工程的积极发声者，让他们阐明在智能体代码库中应该遵循怎样的良好行为。这绝非仅仅是抛出未经审查的代码，然后让其他人去解决所有问题。