Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things. I think many of these automations have become even more important now. This is true for a number of reasons. First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time. Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time! Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation. Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.
我一直在想一件事：过去，我认识的最优秀的工程师都会花很多时间以各种方式把自己的工作自动化。比如更好的 vim/emacs 自动化，编写 lint 规则来捕捉重复代码问题，搭建一整套 e2e 测试，这样他们就不需要手动对 app 做 smoke test。这类事情是工程师能做的杠杆最高的工作，因为它能放大他们自己的产出，而这反过来又意味着他们能构建更多东西。我认为，现在这些自动化已经变得更加重要了。原因有很多。第一，infra 和 DevX 自动化能让你更快。如果你还在运行一支 agent 大军，那么这些 agent 里的每一个也都会被加速。更多自动化 == 单位时间内更多产出。第二，把事情转移到代码里会提升效率。你的 agent 也许可以在每次看到某个问题发生时都去修复它，但那会消耗 token，而且还可能漏掉一些情况。如果 Claude 转而写一个 lint 规则、CI 步骤或例行程序，那么这类问题就可以被彻底自动化，并且永久解决。这其实就是人们谈论 loops 时真正想表达的意思——重点不是一次性地解决单个问题，而是把整类繁琐工作自动化掉。这根本不是什么新想法。工程师这么做已经很久了！第三，也是最重要的一点，自动化能让其他人更容易为 codebase 做贡献。我越来越多地看到，工程师在第一天就能开始为 codebase 提交贡献，因为 Claude 可以替他们理解和导航 codebase；同时，非工程师如今也能像工程师一样高效地为 codebase 做贡献。而阻碍这两件事的，恰恰是那些存在于人脑中、而不是存在于自动化里的领域知识——也就是你过去在 ramping up 时必须学习的那些东西。agent 带来的变化在于：能够被编码为基础设施的领域知识，不再局限于 lint 规则、类型和测试所能表达的内容；它现在几乎可以涵盖所有领域知识，并以代码注释、skills、CLAUDE.md 规则和 memories 的形式被编码下来。如果我给一个自己并不了解的 iOS codebase 提了一个 PR，而 code reviewer 因为我没有使用正确的 framework 拒绝了它；或者如果一个设计师做了一个新功能，却因为没有遵循正确的架构模式而被拒绝，这些都说明自动化失败了。每个团队都应该编写那些 CLAUDE.md、REVIEW.md、skills 和文档，使 agent 即使在 prompter 不额外提供任何上下文的情况下，也能在他们的 codebase 中高效工作。这听起来很疯狂，但同时它也是工程师一直以来所做之事的自然延伸：自动化，并把领域知识编码为基础设施。随着 model 变得更聪明、harness 日趋成熟，这项工作会变得更容易。与此同时，每个团队都应该主动寻找方法，把自己的领域知识转化为 infra，这样 Claude 就能写出更好的代码，code review 就能自动捕捉问题，而下一个接手你们 codebase 的人也能更轻松地做出贡献。