What is the future of software engineering with Adam Bender, Principal Software Engineer at Google谷歌首席软件工程师 Adam Bender 谈软件工程的未来
What we see in software engineering circles is that the AI coding debate is mostly about speed. Does the model write good code, ship faster, and pass the tests? Adam Bender thinks that’s too small a question.眼下软件工程圈关于 AI 编程的争论，大多集中在速度上：模型写的代码好不好、上线快不快、测试能不能通过？Adam Bender 认为，这种问法格局太小了。
Adam is a Principal Software Engineer at Google, where he’s spent close to fourteen years. He edited the testing chapters in Software Engineering at Google, wrote the Testing Overview, and has trained new technical leads since 2017. Right now he’s running a Large-Scale Change across Google’s entire codebase to refactor TODOs in every language, millions of lines he’ll mostly never read.Adam 是谷歌的一名首席软件工程师，已在那里工作了将近十四年。他参与编辑了《Google软件工程》中的测试章节，撰写了“Testing Overview”，并从 2017 年起负责培训新的技术负责人。目前，他正在谷歌整个代码库中推进一项大规模变更（Large-Scale Change），对所有语言中的 TODO 进行格式重构，涉及数百万行他大概率永远不会亲自阅读的代码。
I called him after his Google I/O talk this year because he’s making a point that many people in the industry miss. Programming is the narrow act: one person, one program. Engineering is what happens when many people build together and need that work to survive, ship, and scale for years. AI is already fast at the first and has barely touched the second.今年 Google I/O 演讲结束后，我联系了他，因为他提出了一个许多业界人士忽视的观点：编程是狭隘的行为——一个人，一个程序；工程则是多人协作构建，并需要让成果在多年里存活、交付和扩展。AI 在前者上已经很快，但几乎还未触及后者。
What happens when we make code generation 10 times faster and engineering doesn’t keep up? What speeds up is the pressure on everything nobody automated: testing, review, culture, and whether a human can still hold the system in their head.如果代码生成快了 10 倍，而工程能力跟不上，会发生什么？加速的是所有未被自动化环节的压力：测试、评审、文化，以及人类是否仍能在大脑中掌控整个系统。
In particular, we talk about:具体来说，我们讨论了：
Why speed hides the risk. Your developer ecosystem behaves like a complex adaptive system. Change the output of one node and the effects surface in places you never connected to it.为什么速度会掩盖风险。你的开发者生态系统表现得像一个复杂自适应系统：改变其中一个节点的产出，其影响会在你从未关联过的地方浮现。
Programming versus engineering. One is a single person writing a program. The other is keeping that program alive, integrated, and worth maintaining over years. AI moves the first and stalls on the second.编程与工程的区别。前者是一个人写程序；后者是让程序持续存活、保持集成、并在多年后仍值得维护。AI 推动了前者，却在后者上停滞不前。
Why culture comes before tooling. Any Google engineer can propose and run an edit across the whole codebase, millions of lines, often without AI. Copy the tool, skip the beliefs underneath it, and it falls apart.为什么文化先于工具。任何谷歌工程师都能向整个代码库提交并执行修改，涉及数百万行代码，而且往往不需要 AI。照搬工具，却跳过其底层的信念体系，一切都会崩塌。
Conway’s Law once agents join the org. Agents don’t care about time zones, proximity, or politics, the human limits the law rests on. So what shape do they produce instead?当智能体加入组织后的康威定律。智能体不在乎时区、距离或政治——这些正是该定律所依赖的人性限制。那么它们会催生出怎样的组织形态？
Your internal APIs are now public. An agent won’t respect a boundary you only enforced with good manners. Adam lays out where to start hardening, and in what order.你的内部 API 如今已形同公开。智能体不会尊重那些仅靠“礼貌”维持的边界。Adam 梳理了该从哪里开始加固，以及优先级。
What testing loses first at 10x output. Agents are good at unit tests, so teams create far more than they need. The real gap is integration testing, where the system outgrows your ability to check it.产出放大 10 倍时，测试最先失去什么。智能体擅长写单元测试，于是团队会生成远超需求的单元测试。真正的缺口是集成测试——系统复杂度已经超过了你能检验它的能力。
Intellectual control, the thing keeping him up at night. Can a human still reason about the system in front of them? For now, AI is making that harder, and he explains why.让他夜不能寐的“智识掌控力”（intellectual control）。人类还能对眼前的系统进行有效推理吗？目前，AI 正在让这件事变得更难，他解释了原因。
Teaching ten years of judgment in six months. A new engineer with fifty agents and no instinct yet. His honest answer is “I don’t know,” then the two things that partly work.如何在六个月里教会十年沉淀的工程判断力。一位拥有五十个智能体却尚无直觉的新人。他的诚实回答是“我不知道”，然后分享了两种部分有效的方法。
Where to start on Monday. Define what quality means for your business first, then map the whole ecosystem, including the pieces you stopped noticing years ago.周一从哪里开始。先为你的业务定义清楚“质量”意味着什么，然后绘制整个生态系统图谱，包括那些你多年前就已熟视无睹的部分。
So, let’s dive in.那么，让我们开始吧。
Get oriented on a big PR before you review it (Sponsored)在评审大型 PR 前先理清全貌（赞助内容）
You get tagged on a pull request for one file you own. Before you can judge that file, you have to work out what the whole change does, and that reconstruction is most of the work.你因为 ownership 的一个文件被拉进了一个拉取请求（pull request）。在能评判那个文件之前，你得先搞清楚整个变更在做什么，而这种“重构上下文”才是工作量的大头。
CodeRabbit Review does that orientation for you. It reorganizes the PR into cohorts and ordered layers, and where a change involves a new call path, a lifecycle, or a data model, it draws the sequence diagram, state machine, or ERD beside the diff. You see how the change fits together before reading a single line of it.CodeRabbit Review 能帮你完成这种上下文构建。它会把 PR 重新组织成若干群组和有序层级；当变更涉及新的调用链路、生命周期或数据模型时，它会在代码 diff 旁边直接画出时序图、状态机或 ERD。你还一行代码都没读，就已经看清了变更的整体结构。
From there, you navigate it with the keyboard, leave inline comments, and submit a review that posts natively to GitHub or GitLab. It’s opt-in per reviewer, so nothing changes for anyone who skips it.接下来，你可以用键盘浏览代码、留下行内评论，并提交会直接发布到 GitHub 或 GitLab 的评审。每位评审者可以自行选择是否使用，不用的人完全不受影响。
Free during launch, then part of the Pro+ plan.上线初期免费，后续纳入 Pro+ 套餐。
1. Most of the conversation about AI and coding is about speed. When someone only asks whether the AI writes good code, what are they not seeing?1. 关于 AI 与编程的讨论，大多集中在速度上。当一个人只关心 AI 写的代码好不好时，他忽略了什么？
Your developer ecosystem is a kind of Complex Adaptive system, which means when it experiences change - like the introduction of AI code generation - it is difficult to predict the impacts. Because of the deep interconnections across our developer ecosystems, which evolved organically over 20+ years, a substantial change in output of a single node in the system is likely to have many surprising outcomes.你的开发者生态系统是一种复杂自适应系统（Complex Adaptive System），这意味着当它经历变化——比如引入 AI 代码生成——时，其影响很难预测。我们的开发者生态系统经过 20 多年的有机演化，内部深度互联，系统中某一个节点产出的显著变化，很可能会引发诸多意想不到的结果。
What I have observed in talking to engineers both inside and outside Google is that the “ecosystem” nature of a developer environment wasn’t as well appreciated as I had thought. It’s understandable because our approach to software development has been relatively stable over the last 15-20 years, with most changes being evolutionary.通过与谷歌内外工程师的交流，我发现开发者环境的“生态系统”属性并没有我想象中那样被重视。这可以理解，因为过去 15 到 20 年间，我们的软件开发方式相对稳定，大多数变化都是渐进式的。
Unfortunately, those two facts - the complexity of our ecosystems and the lack of attention to the systemic connections create a condition where it is easy to be overconfident or blind to the potential risks of dramatically accelerating ecosystem disruption.遗憾的是，这两个事实——生态系统的复杂性，以及对系统性关联的忽视——共同造就了一种境况：人们很容易对急剧加速生态系统颠覆所带来的潜在风险过度自信或视而不见。
2. You said, “engineering is programming integrated over time”. AI is speeding up the programming part, but why doesn’t that speed up the engineering part too?2. 你说过，“工程是编程在时间上的积分”。AI 正在加速编程环节，那为什么没有同步加速工程环节？
First, I want to give credit to Titus Winters, Hyrum Wright, and Tom Manshreck, who coined the phrase in the book Software Engineering at Google.首先，这句话要归功于 Titus Winters、Hyrum Wright 和 Tom Manshreck，他们在《Google软件工程》一书中首创了这个说法。
The key difference is that programming is a narrow act performed by a single person or agent. The outcome of programming is, unsurprisingly, a program, but that is likely of little value unless you can also ship it, extend it, maintain it, and scale it. Software Engineering is what happens when you have many people practicing programming together and want to ensure their long-term ability to do so in an economically viable way. 核心区别在于，编程是由单个人或单个智能体执行的狭隘行为。不出所料，编程的结果就是一个程序，但如果无法将其交付、扩展、维护和规模化，它的价值可能微乎其微。软件工程则发生在多人共同编程之时，目标是确保这种协作在长期内具备经济可行性。
Put another way, I can write programs for myself all day long, but if that code doesn’t need to be integrated with others’ work, isn’t likely to be maintained, and has little to no economic value, I can get by without all kinds of activities like testing, documentation, operations, release management, and more.换句话说，我可以整天为自己写程序，但如果这些代码不需要与他人工作集成、不太可能被长期维护、也几乎没有经济价值，那我可以完全不用搞测试、文档、运维、发布管理那些事儿，日子照样过得去。
For now, AI has shown the ability to increase individual productivity, but it has yet to help us solve the other problems that arise when you want to continue growing, maintaining, and reliably operating that software. Why is that the case? I think it probably has a lot to do with the fact that programs, in isolation, are very language-shaped, and much easier to validate for Agentic systems. The engineering aspects require much more nuanced trade-offs, unclear success criteria, and solutions that are nowhere near as structured.目前，AI 已展现出提升个人生产力的能力，但尚未帮助我们解决那些随着软件持续成长、维护和可靠运营而浮现的其他问题。为什么会这样？我认为很大程度上是因为孤立的程序非常“像语言”，对智能体系统来说验证起来容易得多；而工程层面的问题需要更微妙的权衡、更模糊的成功标准，以及远非结构化的解决方案。
ℹ️ Check my review of the book Software Engineering at Google.ℹ️ 查看我对《Google软件工程》的书评。
3. Half of your book is about culture, not code. Why can’t anyone copy Google’s technical choices without first understanding the culture?3. 你的书有一半在讲文化，而非代码。为什么任何人如果不先理解谷歌的文化，就无法照搬其技术选择？
Let me answer that with an example from the book and my talk. Google has a process called Large-Scale Changes that allows any engineer at the company to propose an edit to the entire codebase and, if approved, execute it themselves.我用书中和演讲里的一个例子来说明。谷歌有一项名为 Large-Scale Changes（LSC，大规模变更）的流程，允许任何工程师向全公司代码库提交修改提案，获批后自行执行。
Typical LSCs range into the millions of lines of code. I’m actually working on an LSC to refactor the format of TODOs across our entire codebase, in every language, to validate some new techniques. If we are successful, we will change millions of lines of code across parts of the codebase to which I have absolutely no connection. I probably won’t even look at the code. I will rely on the reviewing engineers to sign off on the change. Keep in mind this has all been done without AI for the last 15 years.典型的 LSC 涉及数百万行代码。我目前正在推进一项 LSC，重构整个代码库中所有语言的 TODO 格式，以验证一些新技术。如果成功，我们将修改数百万行与我所在领域毫无关联的代码。我可能根本不会去看那些代码，而是依赖负责评审的工程师来批准变更。请记住，过去 15 年来，这一切都是在没有 AI 的情况下完成的。
Consider what is culturally necessary for this process to work:想想看，要让这个流程运转起来，文化上必须具备哪些条件：
I need to be able to access all the code, whether I work on it or not.我需要能够访问所有代码，无论我是否负责维护它们。
I need a way to validate my changes don’t break anything - which means everyone has to have bought into testing, and I need to be able to reliably run those tests.我需要有办法验证我的修改不会破坏任何功能——这意味着所有人都必须认同测试的价值，并且我能可靠地运行这些测试。
I need the belief that such work is valuable and that reviewers need to spend time reviewing my changes.需要有人相信这类工作是有价值的，并且评审者愿意花时间审阅我的变更。
I need the foundational belief that maintenance of our codebase is a shared responsibility.需要有一种根本的共识：代码库维护是共同责任。
Specific to my LSC on TODOs, there needs to be a shared cultural belief in standardization.具体到我这项关于 TODO 的 LSC，还需要大家共同认可标准化的价值。
You can build incredibly powerful code mutation tools, but without the right engineering culture, the ability to navigate the human aspects of the codebase will doom you to failure. As long as software involves people, culture, processes, and tools, they are all dependent on each other.哪怕你造出了极其强大的代码变更工具，如果没有正确的工程文化，缺乏协调代码库中“人的因素”的能力，最终也会失败。只要软件还涉及人，文化、流程和工具就是相互依存的整体。
4. In your talk, you use Conway’s Law as the door into everything else. Now that agents write and change code, do they become part of that shape too?4. 你在演讲中把康威定律（Conway’s Law）当作切入点，进而展开所有话题。既然现在智能体（agent）也能编写和修改代码，它们是否也成为了这种“组织形态”的一部分？
Conway was one of the first to observe the deep connection between how we organize and the systems we produce. That connection often seems invisible because, as engineers, we are not really expected to think about how our organizations work, and we can often get away without worrying too much. AI may change that dynamic quite a bit.康威最早注意到组织方式与产出系统之间的深层联系。这种联系常常看不见，因为作为工程师，本来也没人被指望去琢磨组织怎么运转，而且大家往往也能应付过去。但 AI 很可能会大大改变这种动态。
AI's ability to amplify outcomes will make many things that were previously invisible much more visible. For example, in a world with reliable agentic programming, your organization's decision-making abilities will be under intense pressure to accelerate to keep pace with software construction. How much did the average engineer even think about their executive’s decision-making process before?AI 放大结果的能力，会让许多原本看不见的东西变得清晰可见。例如，在一个拥有可靠智能体编程的世界里，组织的决策能力将面临巨大压力，必须加速才能跟上软件构建的速度。在此之前，普通工程师又有多少会去思考高管们的决策流程呢？
One of the interesting things about agents is that they aren’t impacted by time zones; they don’t require physical proximity to build trust bonds, and as far as I can tell, they don’t have a notion of politics. These are some of the underlying forces that give rise to Conway’s law. That suggests Conway’s law could be a byproduct of the limitation of human cooperation skills and agents won’t necessarily be affected. Agents will almost certainly have subtle organizing principles, likely influenced by whatever incentives they recognize, but we shouldn’t expect those principles to reflect our human experience.智能体有个有趣之处：它们不受时区限制，无需近在咫尺就能建立信任，且据我所知没有政治观念。而这些正是催生康威定律的部分底层力量。这意味着康威定律可能只是人类协作能力受限的产物，智能体未必会受此影响。未来，智能体几乎肯定会遵循某种微妙的组织原则，而这些原则很可能取决于它们识别到的激励，但我们不应指望这些原则会与人类经验相似。
5. One of the most interesting things you said is that all your internal APIs just became public, because an agent won’t respect a boundary you only ever enforced with good manners. Where should a team start hardening?5. 你提到过一个非常有趣的观点：所有内部 API 都忽然变成了公开 API，因为智能体不会尊重那些只靠“礼貌”维持的边界。团队应该从哪里开始加固？
Here is the simple formula I’m using:我目前在用一套简单的公式：
Build an inventory of all internal APIs (intentionally exposed or not) and all data stores. You have to know where everything is. Remember that agents can find everything and are persistent.清点所有内部 API（无论是否故意暴露）以及所有数据存储。你必须知道所有东西都在哪里。记住，智能体什么都能找到，而且锲而不舍。
Develop a risk formula that captures what your organization considers most important. Use it to prioritize hardening your most critical assets.制定一个风险公式，体现组织最看重什么。用它来优先加固最关键的资产。
Use Platform Engineering techniques to create well-lit paths for agents and humans alike and lock everything else down. If you lack the capability to lock things down, you will need to build that first. You can start by preventing agents from taking any destructive actions, especially in your production systems.利用平台工程技术，为智能体和人打造清晰的默认路径（well-lit paths），并将其余部分全部锁定。如果你目前还不具备锁定能力，那就必须先建立这种能力。可以从禁止智能体执行任何破坏性操作开始，尤其是在生产系统中。
Develop really robust internal observability. You want to know how APIs and data are being accessed at all times.建立非常强大的内部可观测性（observability）。你需要随时了解 API 和数据是如何被访问的。
6. If no one is writing the code, a year from now, who is actually watching the codebase as it grows?6. 如果没人再亲自写代码，一年以后，当代码库不断增长时，实际上还有谁在盯着它？
If we aren’t careful, the answer is no one, and that’s a huge problem. The average software system is too complex for any one person to reliably reason about today. Luckily, it is still within reach of human-scale teams to evaluate. If we grow those systems by 10x in size without improving our ability to reason about them, we will completely lose the ability to make changes safely, which could severely limit our ability to evolve and maintain systems.如果我们不加以小心，答案就是“没人”，而这将是个巨大的问题。如今，普通软件系统已经复杂到个人难以可靠地理解。所幸，人类规模的团队目前还尚能评估它们。但如果我们让系统规模膨胀 10 倍，却未能同步提升对系统的理解能力，我们将彻底丧失安全变更的能力，从而严重制约系统演进和维护的可能。
From the earliest days of LLM-driven development, I have tried to steer folks to spend as much time building tools for understanding as we do for creation. Alas, I haven’t been as convincing as I would like.从 LLM 驱动开发的早期开始，我就一直试图引导大家：花在“理解”工具上的时间，应该和花在“创造”工具上的一样多。可惜，我的说服力还不够。
7. You wrote the testing chapters in the book, and yet on stage you admitted you don’t have the integration testing tools you want. When output increases 10x, which part of testing breaks first?7. 你撰写了书中的测试章节，却在台上坦言自己还没有理想中的集成测试工具。当产出增加 10 倍时，测试的哪个环节会最先崩溃？
To clarify quickly, I was the editor of the series of testing chapters and wrote the Testing Overview. 先快速澄清一下：我是那一系列测试章节的编辑，并撰写了“Testing Overview”（测试概览）。
I don’t have the integration tools I want, but it is not for lack of trying. Google had good-sized teams of incredibly smart people building better integration test tooling, yet we still have a long way to go. I think the problem stems from the fact that unless teams consider integration testing as an essential system property to be evolved in lockstep with their systems - equal to concurrency, or reliability in importance - the complexity of the underlying system rapidly escapes our ability to build system-level tests. Truly excellent integration testing will come from a system explicitly designed to be integration testable, however most teams don’t have the luxury of investing in that kind of work, maybe AI can make it more cost effective?我尚未拥有理想的集成测试工具，但这并非因为缺乏尝试。谷歌曾投入规模不小的团队，由极其聪明的人负责打造更好的集成测试工具，但我们仍有很长的路要走。我认为问题根源在于：除非团队将集成测试视为与系统同步演进的核心属性——其重要程度不亚于并发性或可靠性——否则底层系统的复杂度会迅速超出我们构建系统级测试的能力。真正卓越的集成测试，需要系统从一开始就被显式设计为“可集成测试”的；然而大多数团队没有奢侈到能投入这类工作，也许 AI 能让它更具成本效益？
As far as what breaks first? I think teams will likely drown in unit tests at first because agents are really good at writing them. This is a problem we have wrestled with at Google even before AI. It is really easy to generate lots of little tests that appear to add value but are low-value because they duplicate other tests, lack precise assertions, are flaky, are tedious to maintain, or otherwise fall short. Also, keep in mind that today it is very common to require all tests to pass before shipping; the more tests you have, the harder it is for all of them to pass at any one time, even if they are independently very reliable.那什么会先崩？我认为团队最初可能会被单元测试淹没，因为智能体太擅长写单元测试了。这个问题在谷歌即便在 AI 出现之前也一直困扰着我们。生成大量看似有价值的小测试其实很容易，但它们实际价值很低：重复已有测试、缺乏精确断言、不稳定、维护繁琐，或者在其他方面不达标。另外请记住，如今通常要求所有测试通过才能上线；测试越多，要让它们在同一时间全部通过就越难，哪怕每个测试单独看都很稳定。
One thing I have learned after nearly 14 years of Google is that it is possible to have too much of a good thing, even tests! This isn’t an invitation to give up testing, far from it; this is a call to apply a much more intentional approach and invest in reimagining how we validate software when code is cheap.在谷歌工作近 14 年，我学到的一点就是：再好的东西也可能过量，测试也不例外！这并不是要放弃测试，绝非如此；而是呼吁大家采取更有意图的策略，重新思考在代码变得廉价的时代，我们该如何验证软件质量。
8. You said the thing keeping you up at night is intellectual control, whether a human can still reason about the system in front of them. Is AI making it worse?8. 你说过让你夜不能寐的是“智识掌控力”（intellectual control）——即人类是否仍能理解眼前的系统。AI 正在让情况变得更糟吗？
At the moment, AI is only making this problem worse because most of the energy invested has been focused on code creation. As I mentioned previously, this kinda makes sense because validating generated code is much more straightforward than validating nuanced guidance about system health.目前，AI 只会让这个问题更糟，因为大部分投入精力都集中在代码生成上。正如我先前提到的，这有点道理，因为验证生成的代码要比验证关于系统健康的微妙指导简单直接得多。
Mechanisms to hill-climb towards correct code are well understood and apparently pretty cheap to implement. Quicksort is quicksort, and it’s easy to test. Diagnosing novel errors in a production system requires the ability to put the complete system state into a context window and pair that with guidance on the nature of a highly bespoke system with no analog anywhere in the world. That’s still an unsolved problem as far as I can tell.让代码一步步逼近正确的“爬山”机制已被充分理解，实现成本显然也很低。快速排序就是快速排序，测试很简单。然而，诊断生产环境中的全新错误，需要将完整系统状态放入上下文窗口，并配合对某个世上独一无二的深度定制系统的本质理解。据我所知，这至今仍是个未解难题。
I do think AI has the potential to be massively helpful here because it is incredibly good at identifying patterns and predicting outcomes. What we are missing is a massive context-engineering exercise to make our systems more legible and predictable for AI.我确实认为 AI 在这方面有巨大潜力，因为它极其擅长识别模式和预测结果。我们现在缺的是一场大规模的上下文工程（context engineering）实践，让系统对 AI 而言更易读、更可预测。
9. How do you teach someone ten years of judgment in six months, when they have fifty agents and none of the instinct yet? Have you seen anything that even partly works?9. 当一个人拥有五十个智能体却毫无直觉时，你怎么在六个月内教会他十年才能积累的工程判断力？你看到有任何方法哪怕部分有效吗？
Honest answer… I have no idea. I have been teaching new technical leads (TLs) at Google since 2017, and one thing remains constant: it is very hard to learn judgment and develop intuition just by listening to lectures or participating in discussion groups. Real intuition comes from making a judgment, taking action, and experiencing the consequences. That’s the loop we need to put new developers through more often.老实回答……我不知道。从 2017 年起，我就在谷歌培训新的技术负责人（TL），有一点始终不变：光靠听讲座或参加讨论组，很难学会判断力和培养出直觉。真正的直觉来自做出判断、付诸行动、并亲身经历后果。这是一个需要让新开发者更频繁经历的闭环。
One idea I have been experimenting with is using Role-Playing Games to help build the kind of discernment needed. I believe the SRE community at Google has seen good results with a form of RPG called Wheel of Misfortune, in which participants simulate incidents and are challenged to address them.我一直在尝试的一个想法是利用角色扮演游戏（RPG）来培养所需的辨别力。据我所知，谷歌的 SRE 社区在使用一种名为 Wheel of Misfortune 的 RPG 时取得了不错的效果：参与者模拟事故场景，并被要求处理它们。
I've been talking with my friend Titus quite a bit about this problem, and he thinks investing in apprenticeship techniques like pair programming is a great way to quickly transmit high-bandwidth experience to new developers. I think he's right. I think deeper human connection is a great way to accelerate the transfer of engineering experience.
The other thing I’d recommend is that every single incoming software engineer learn something about system theory and systems thinking. Learning about general system dynamics and system patterns can help you develop analytical tools and mental models for the complexity we are working with, and, specifically, it can help you gain clarity at an abstraction level above the individual lines of code that agents are increasingly responsible for. It isn’t exactly the same thing as deep intuition, but it can be powerful enough to achieve similar outcomes.我和朋友 Titus 就这个问题聊过很多，他认为投入师徒制技巧（比如结对编程）是向新人快速传递高密度经验的好方法。他说的没错。我认为更深层次的人际连接是加速工程经验传承的绝佳途径。另外，我想建议每一位新入行的软件工程师都去学习一些系统理论和系统思维。了解通用的系统动力学和系统模式，有助于你建立分析工具和心智模型，来应对我们正在处理的复杂性；具体来说，它能帮你在比单行代码更高的抽象层级上获得清晰认知——而这正是智能体越来越多地接手底层代码时你最需要的。这不完全等同于深度直觉，但其威力足以达成类似效果。
Milan here: check these two books I recommend on improving systems thinking.Milan 插一句：推荐两本提升系统思维的书，来看看。
10. You ended by telling the room they have more agency than they think. For an engineer who cares about quality and feels carried along by all of this, where do they actually start on Monday morning?10. 你最后告诉在场的人，他们拥有的能动性比想象中更大。对于那些关心质量、却感觉被这一切裹挟前行的工程师，周一早上到底该从哪里入手？
The first thing you can do is define what quality actually means for your system and your business. Figure out the indicators of both technical and business impact that would give a leading indication that quality is suffering. This is not going to be an easy exercise, and very likely the things you think matter don’t matter as much to your business leads as they probably should. However, starting the conversation about what matters will make it much easier to address impacts as they emerge.第一件可以做的事，是为你的系统和业务定义清楚“质量”到底意味着什么。找出那些能在质量下滑时提前发出信号的技术与业务影响指标。这不会是个轻松的练习，而且你眼中的重点，对业务负责人来说很可能没那么重要——尽管它们本该如此。不过，开启“什么才是真正重要的”这场对话，将让你在问题浮现时更容易应对。
If you were to do two things on Monday, the second would be to try to map out your developer ecosystem - all the parts, cultural and technical - and try to work out the second- and third-order consequences of much more code. 如果周一要做两件事，第二件就是试图绘制出你的开发者生态系统图谱——包括文化和技术层面的所有组成部分——并试着推演代码量暴增会带来哪些二阶和三阶后果。
Be creative and don’t forget the hidden parts of the ecosystem you have taken for granted for years. Everything is up for grabs if we achieve a 10x increase in programming productivity.大胆发散，别忘了那些多年来被你视作理所当然、实则隐藏在生态系统中的部分。一旦编程生产力真的提升 10 倍，一切都将被重新洗牌。
📔 The Laws of Software Engineering book is out📔《软件工程定律》现已出版
The book began as a document I wrote over the years. During my 20+ year career in Tech, I saw the same things happening at companies with different technologies and teams. I wrote down what I saw. I learned about Galls Law from a project that did not work out. Brooks’ Law was observed in a team that grew larger, and everything slowed down. Goodhart’s Law arose from a time when we met all our goals, yet the results were no better. They have been even worse.这本书源于我多年来写下的文档。在我 20 多年的科技职业生涯中，我发现不同技术、不同团队的公司里总在发生同样的事情。我把看到的一切都记录下来。Galls Law（高尔定律）来自一个失败的项目；Brooks’ Law（布鲁克斯定律）则源于团队扩张后一切变慢的经历；Goodhart’s Law（古德哈特定律）来自一段达成了所有目标、结果却并未变好、反而更糟的时光。
Later, I met engineers who had figured out the same things. Most of them learned these lessons the hard way, as I did. They had a project that failed a team that got tired or a codebase that was a mess. This is how engineers usually learn these lessons because no one tells them. It is true, and it costs a lot.后来，我遇到了一些同样领悟到这些道理的工程师。他们中的大多数人跟我一样，都是通过惨痛经历才学会的：经历过项目失败、团队倦怠，或者代码库变成了一团乱麻。工程师通常就是这样学会这些教训的，因为没人会告诉他们。的确如此，而且代价高昂。
This book is a list of what I learned.这本书就是我学到的一切的清单。
This issue covers 20 laws in software engineering. My book covers 56 laws across architecture, people, time, quality, scale, code, and decision-making.本期内容涵盖了软件工程中的 20 条定律。我的书则覆盖了 56 条定律，横跨架构、人员、时间、质量、规模、代码和决策。
Each chapter discusses what the law says, where it comes from, when it applies, and what it looks like in a project. Some chapters also include connecting ideas such as The Two-Pizza Rule, The Cobra Effect, and Impostor Syndrome.每一章都会讨论定律的内容、来源、适用场景，以及它在项目中的具体表现。部分章节还包含关联概念，例如 Two-Pizza Rule（两只披萨法则）、The Cobra Effect（眼镜蛇效应）和 Impostor Syndrome（冒名顶替综合症）。
This book is something you can keep at your desk and look at when you need help.这是一本可以放在案头、在需要时随手翻阅的书。
Forewords are written by Dr. Rebecca Parsons, CTO Emerita at Thoughtworks, and Addy Osmani, Engineering Director at Google Cloud AI. Reviewed by 20 engineers and leaders from Google, Amazon, Uber, Oracle, Yelp, Nutanix, and CodeScene.本书前言由 Thoughtworks 荣誉 CTO Rebecca Parsons 博士，以及 Google Cloud AI 工程总监 Addy Osmani 撰写。另有来自 Google、Amazon、Uber、Oracle、Yelp、Nutanix 和 CodeScene 的 20 位工程师与领导者参与审阅。
Want to advertise in Tech World With Milan? 📰想在 Tech World With Milan 中投放广告？📰
If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.如果你的公司希望触达创始人、高管和决策者，可以考虑与我们合作投放广告。
Love Tech World With Milan Newsletter? Tell your friends and get rewards.喜欢 Tech World With Milan 通讯？分享给朋友，领取奖励。
Share it with your friends by using the button below to get benefits (my books and resources).点击下方的按钮分享给朋友，即可获得福利（我的书籍和资源）。
Track your referrals here.在此查看你的推荐进展。
