充满氛围的一年
内容
2025 年即将结束，这一年真是非同寻常。就在去年这个时候，我写了一篇文章，回顾了我的生活。如果我当时写的是关于编程的内容，可能会过时，因为 2025 年对我的职业来说是一个前所未有的年份。
2025 年的变化
2025 年是一个变化的年份。不仅我离开了 Sentry 并创立了新公司，这一年我也停止了以前的编程方式。在六月份，我终于有足够的信心分享我的工作方式已经改变：
以前我大部分时间都在使用 Cursor，现在我主要使用 Claude Code，几乎完全是无人值守的。 [...] 如果六个月前有人告诉我，我会更喜欢成为工程主管而不是虚拟编程实习生，我不会相信的。
去年我想要写更多的文章，但那与智能编码无关。然而，我发表了 36 篇文章，几乎占了这个博客自 2007 年以来所有文章的 18%。我还与程序员、创始人和其他人进行了大约一百次关于人工智能的对话，因为我在智能编码的世界中发现了新的兴趣。
2025 年对于世界来说并不是一个很好的年份。为了让我自己安心，我创建了一个单独的博客来记录我的想法。
智能编码的年份
一切从四月或五月开始，我对 Claude Code 越来越着迷，花了几个月的时间构建自己的智能编码工具和使用他人的工具。社交媒体上充满了关于人工智能的意见，有些是好的，有些是坏的。
现在，我已经找到了一个新的稳定的状态来思考我们现在的位置和未来。 我正在加倍努力地进行代码生成、文件系统、程序化工具调用和基于技能的学习。基本上：Claude Code 的创新仍然是最好的方法。这种方法在过去的几个月里效果很好，基础模型提供商加倍努力地开发技能，这也加强了我对这种方法的信心。
我仍然对 TUI（文本用户界面）如何卷土重来感到困惑。目前，我正在使用 Amp、Claude Code 和 Pi，所有这些都是从命令行使用的。Amp 感觉像苹果或保时捷的智能编码工具，Claude Code 是价格合理的大众汽车，而 Pi 是黑客的开源选择。它们都感觉像由像我一样使用它们来构建自己的产品的人创建的项目，但有不同的权衡。
我继续被大型语言模型（LLM）与工具执行的组合所做的事情所震撼。今年开始时，我主要使用它们进行代码生成，但现在我使用智能编码工具的很多都是日常事情。我相信我们将在 2026 年看到一些令人兴奋的消费品推动。LLM 现在正在帮助我组织我的生活，我期待这将进一步发展。
机器和我
由于 LLM 不仅帮助我编程，我开始重新思考我与这些机器的关系。我越来越难以不与我使用的一些工具建立寄生社会纽带。我发现这很奇怪，也很令人不安。大多数我们今天使用的智能编码工具没有太多的记忆力，也没有太多的个性，但很容易构建一个具有这些特性的工具。具有记忆力的 LLM 是一种很难抹去的体验。
这既令人着迷，又值得怀疑。我已经尝试训练自己两年，认为这些模型只是简单的令牌翻转器，但这种简化的观点对我来说已经不再有效。我们现在创建的这些系统具有人类的倾向，但将它们提升到人类的水平将是一个错误。我越来越反对称这些机器为“智能编码工具”，但我没有更好的词语来描述它们。我反对“智能编码工具”这个词，因为代理和责任应该仍然在人类手中。无论它们变成什么，它们都可以在我们身上触发情绪反应，如果我们不小心，这可能是有害的。我们无法正确地命名和定位这些创造物与我们之间的关系，这是一个我认为我们需要解决的挑战。
由于这种无意的拟人化，我在与这些机器合作时，真的很难找到合适的词语来描述我的工作方式。我知道这不仅仅是我；还有其他人。与那些目前完全拒绝这些系统的人合作时，这会产生更多的不适感。关于智能编码工具文章中最常见的评论之一就是拒绝给机器赋予个性。
到处都是意见
使用人工智能如此之多的一个意外方面是，我们谈论的更多的是氛围而不是其他任何东西。这种工作方式不到一年，但它挑战了半个世纪的软件工程经验。因此，有很多意见，很难说哪一个会经受住时间的考验。
我发现了很多传统智慧，我不同意，但我没有任何证据来支持我的意见。我怎么会有呢？我很大声地分享了我在整个年份中使用 MCP 的缺乏成功，但我除了“它不适用于我”之外没有任何证据。其他人则发誓使用它。同样，对于模型选择，Peter 在年初让我对 Claude 产生了兴趣，他后来转向了 Codex 并对其感到满意。我没有那么喜欢使用它，尽管我开始更频繁地使用它。我除了“氛围”之外没有任何证据来支持我对 Claude 的偏好。
也很重要的是，要知道一些氛围是带有故意信号的。很多人在网上分享他们的观点，他们对某一产品或另一产品有经济利益，例如因为他们是投资者或被付费的影响者。他们可能因为喜欢产品而成为投资者，但也可能他们的观点受到这种关系的影响和塑造。
外包与自建
从任何人工智能公司今天获取一个库，你会注意到它们都是使用 Stainless 或 Fern 构建的。文档使用 Mintlify，网站的身份验证系统可能是 Clerk。公司现在出售以前你会自己构建的服务。这种对核心服务的外包增加意味着某些方面的用户体验的标准已经提高。
但是随着我们从智能编码工具中获得的新力量，你可以自己构建很多这些东西。我让 Claude 为我构建了一个 Python 和 TypeScript 的 SDK 生成器——部分是出于好奇，部分是因为它感觉足够简单。正如你可能知道的，我是简单代码和自建的拥护者。这让我对人工智能有了乐观的态度，认为它有潜力鼓励构建更少的依赖。同时，我不确定我们是否正在朝着这个方向发展，考虑到当前的外包趋势。
教训和愿望
这让我想到了，不是预测，而是希望我们能把精力放在哪里。 我不知道我在这里寻找什么，但我想指出我的痛点并提供一些背景和思考。
新型版本控制
我最大的意外发现是：我们正在达到传统工具共享代码的限制。GitHub 上的拉取请求模型没有携带足够的信息来正确地审查人工智能生成的代码——我希望能看到导致更改的提示。 不仅仅是 GitHub，git 也存在不足。
使用智能编码工具时，当前使模型工作的部分是了解错误。如果你将其引导回早期状态，你希望工具记住什么出了错。有价值的东西在于失败——人类可能也会从中受益，但对于机器来说，这是至关重要的信息。你会注意到，当你尝试压缩对话历史记录时，丢弃导致你走错路的路径意味着模型将再次尝试相同的错误。
一些智能编码工具已经开始创建工作树或在 git 中创建检查点，以实现对话恢复、分支和撤消功能。有空间进行用户体验创新，使这些工具更容易使用。这可能就是为什么我们看到关于堆叠差异和替代版本控制系统（如 Jujutsu）的讨论的原因。
这会改变 GitHub 还是会为一些新竞争创造空间？我希望如此。我越来越想更好地理解真正的人类输入，并将其与机器输出区分开来。我想看到提示和失败的尝试，并以某种方式在合并时压缩和压缩所有内容，但如果需要，可以检索完整的历史记录。
新型代码审查
这与版本控制有关：当前的代码审查工具分配了严格的角色定义，这些定义不适用于人工智能（AI）。以 GitHub 代码审查 UI 为例：我经常想在 PR 视图上使用评论为我的代理留下笔记，但没有指导性的方法来做到这一点。审查界面拒绝让我审查自己的代码，我只能评论，但这并没有同样的意图。
还有一个问题，即代码审查的增加现在发生在我和我的代理之间的本地环境中。例如，GitHub 上的 Codex 代码审查功能对我停止了工作，因为它只能绑定到一个组织一次。所以，我现在使用命令行上的 Codex 进行审查，但这意味着我迭代周期的一部分对团队中的其他工程师是不可见的。这对我来说不起作用。
代码审查对我来说感觉需要成为版本控制系统（VCS）的一部分。
新的可观察性
我还相信可观察性再次成为一个需要解决的问题。我们现在既有需要，也有机会利用它来取得更大的成就。大多数人没有能力构建自己的 eBPF 程序，但大型语言模型（LLM）可以。同样，许多可观察性工具由于 SQL 的复杂性而避免使用它，但 LLM 比任何专有查询语言都更擅长 SQL。它们可以编写查询、使用 grep、执行 map-reduce，并远程控制 LLDB。任何具有某种结构和文本的内容突然成为代理编码工具成功的肥沃土壤。我不知道未来的可观察性会是什么样子，但我的强烈直觉是，我们将在这里看到大量的创新。机器的反馈循环越好，结果越好。
我甚至不知道自己在这里想要什么，但我认为过去的一个挑战是，许多关于更好可观察性的很酷想法——特别是动态重新配置服务以实现更有针对性的过滤——由于复杂性和难以使用而对用户不友好。但现在，考虑到 LLM 的能力，这些可能是正确的解决方案。例如，Python 3.14 引入了 外部调试器接口，这是代理编码工具的惊人功能。
与不确定性共处
这可能有点更有争议，但我今年没能做到的是向机器屈服。我仍然像对待普通软件工程一样对待它，并且审查了很多内容。我也认识到，越来越多的人不再遵循这种工程模型，而是完全向机器屈服。听起来很疯狂，但我看到有些人在这种方式下取得了成功。我还不知道如何推理这个问题，但很明显，即使最终生成的代码，新世界中的工作方式与我所熟悉的世界大不相同。我的怀疑是，由于那个世界已经到来，我们可能需要一些新的社会契约来区分它们。
最明显的版本是这种类型的贡献越来越多地出现在开源项目中，这对任何不使用这种模型工作的人来说都是侮辱。我发现阅读这样的拉取请求会让我感到愤怒。
我尝试使用贡献指南和拉取请求模板来解决这个问题。但这似乎有点像与风车搏斗。这个问题的解决方案可能不会来自于改变我们正在做的事情，而是来自于那些也支持 AI 工程的有声望的人发表言论，阐述代理代码库中什么是良好的行为。这不仅仅是抛出未经审查的代码，然后让另一个人去处理。