正在打开每日关注
正在打开每日关注
Agent 时代，团队应把重复修复与隐性领域知识编码为自动化基础设施，持续放大工程与协作产出。
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.
是什么 这是一条关于 Agent 时代研发效能的观点。作者把传统工程师的高杠杆实践——编辑器自动化、Lint 规则、CI 与 E2E 测试——重新放到 Agent 工作流中审视。Agent 不应只是一次性修复问题，而应把反复出现的问题沉淀为规则、例程和可复用的知识基础设施。
核心论点 第一，DevEx 与基础设施自动化会同时加速人和规模化运行的 Agent；第二，把解决方案写成代码，比每次消耗模型上下文和 token 更稳定、更彻底；第三，自动化能把资深成员脑中的领域知识外显，让陌生代码库的贡献、首日上手和跨职能协作更容易。所谓“loops”，本质是消除一整类忙碌工作，而不是孤立地重复调用 Agent。
关键洞察 团队应维护 CLAUDE.md、REVIEW.md、skills、注释和文档，使架构约束、框架选择与验收标准成为 Agent 可读取、可执行的上下文。真正的杠杆不只是模型更聪明，而是组织能否持续把经验转化为机器可执行的反馈回路。
边界与风险 规则若过时、冲突或过度具体，会放大错误并增加维护成本；自动化也不能替代产品判断、设计判断与责任归属。应从高频、可验证的重复问题开始，用测试和代码评审持续校准知识资产。