The reason AI coding isn't working on your teamAI编码在你的团队中不起作用的原因
Nobody owns the setup that makes the model worth using - and that's a management job.没有人拥有让模型值得使用的设置——而这是管理者的工作。
👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.👋 嘿，我是Stephane。我帮助工程师成为优秀的工程管理者——无论你是想成为管理者，还是已经在领导团队。
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.付费订阅者可以获得50个Notion模板、《工程管理者实地指南》以及完整存档的访问权限。
Two engineers I know tried the same AI coding tool the same month. Same model, same version, same company even.我认识的两位工程师在同一个月尝试了相同的AI编码工具。相同的模型、相同的版本，甚至在同一家公司。
One of them told me it pretty much one-shotted her feature. The other told me it was overhyped garbage that kept wrecking his codebase and he’d gone back to writing his feature by hand.其中一位告诉我，这个工具几乎一次性完成了她的功能。另一位则告诉我，这是被过度炒作的垃圾，不断破坏他的代码库，他已经回去手动编写功能了。
I believed both of them. Because the tool was never the variable.我相信他们俩。因为工具从来不是变量。
The first engineer had spent a weekend setting it up - a context file at the root of the repo, a few notes per service about how that part of the system worked, the test command scoped so the agent didn’t run the whole suite on every change. The second one had installed it, pointed it at a million-line monorepo, and asked it to “fix the auth bug”. They were bound to get different results.第一位工程师花了一个周末进行设置——在仓库根目录创建一个上下文文件，为每个服务写几条关于系统如何工作的笔记，限定测试命令范围，这样代理就不会在每次更改时运行整个测试套件。第二位工程师只是安装了它，指向一个百万行的单体仓库，然后要求它“修复认证错误”。他们注定会得到不同的结果。
That gap is the whole story of AI coding right now. And most engineering managers are looking at the wrong half of it.这个差距就是当前AI编码的全部故事。而大多数工程管理者只看到了错误的一半。
The model is not the thing you’re buying模型不是你购买的东西
When I built a SaaS with Claude Code, the lesson that stuck with me had nothing to do with how smart the model I was using was. It was how much the result depended on everything around the model - the context I gave it, the way I’d structured the work, the guardrails I set.当我用Claude Code构建一个SaaS时，我学到的教训与我使用的模型有多聪明无关。而是结果在很大程度上取决于模型周围的一切——我提供的上下文、我组织工作的方式、我设置的防护栏。
There’s a name for this now. Martin Fowler’s team at Thoughtworks calls it harness engineering: the idea that the scaffolding around a coding agent - the context files, the tooling, the way it searches and tests - shapes its output as much as the model itself. Anthropic makes the same point in their own writing on working in large codebases, where they say that the harness matters as much as the model.现在这有了一个名字。Martin Fowler在Thoughtworks的团队称之为“驾驭工程”：即编码代理周围的脚手架——上下文文件、工具、搜索和测试的方式——对输出的影响与模型本身一样大。Anthropic在他们关于大型代码库工作的文章中也提出了同样的观点，他们说驾驭与模型同样重要。
That should change how you think.这应该改变你的思考方式。
Your team is going to judge these tools the way the second engineer did. They’ll try them on a real task, in a real codebase, with minimal setup. It’ll produce something mediocre at best. They’ll conclude the tool is overhyped and might stop using it if they were sceptical to begin with. The verdict will feel like it’s about the model. It will actually be about the absence of a harness.你的团队会像第二位工程师那样评判这些工具。他们会在真实任务、真实代码库中尝试，且设置最少。结果最多是平庸的。他们会得出结论：这个工具被过度炒作，如果一开始就持怀疑态度，可能会停止使用。这个结论看似关于模型，实际上却是关于缺乏驾驭。
The data backs this up from the other direction. The METR study found experienced developers were about 19% slower using AI on their own mature codebases - while believing they were 20% faster. The 2025 DORA report found AI amplifies whatever your team already is: it speeds up a healthy system and speeds up a broken one. In both cases the model wasn’t the deciding factor. The setup around it was.数据从另一个方向支持了这一点。METR研究发现，经验丰富的开发者在自己的成熟代码库中使用AI时，速度大约慢了19%——而他们却认为自己快了20%。2025年的DORA报告发现，AI会放大你团队已有的状态：它加速健康的系统，也加速破碎的系统。在这两种情况下，模型都不是决定性因素，而是其周围的设置。
That makes it your job, not your platform team’s这使得这成为你的工作，而不是你的平台团队的工作
If the harness is what determines the result, then the harness needs an owner. And on most teams, nobody owns it.如果驾驭决定了结果，那么驾驭就需要一个所有者。而在大多数团队中，没有人拥有它。
Addy Osmani, who leads engineering on Chrome at Google, wrote a piece with a title that should be on a poster in every EM’s head: “Your AI coding agents need a manager”. His argument is that AI coding at scale stops being a prompting problem and becomes a management problem. The skills that make someone a good tech lead - setting context, defining the work clearly, reviewing output, knowing when to step in - are exactly the skills that make AI coding work.领导Chrome工程团队的Addy Osmani写了一篇文章，标题应该贴在每位工程管理者的脑海里：“你的AI编码代理需要一个管理者”。他的论点是，大规模AI编码不再是一个提示问题，而是一个管理问题。那些让人成为优秀技术负责人的技能——设置上下文、清晰定义工作、审查输出、知道何时介入——正是让AI编码发挥作用的技能。
The thing standing between your team and real gains from these tools is not a better model. It’s a management responsibility that currently has no owner on your team.阻碍你的团队从这些工具中获得真正收益的，不是更好的模型。而是一个目前在你的团队中没有所有者的管理责任。
The instinct, when something needs adopting, is to mandate it. LeadDev did a whole piece on how AI coding mandates are driving developers to the brink. Push hard enough and you won’t get adoption - you’ll get resentment.当需要采用某样东西时，本能是强制推行。LeadDev写了一整篇文章，讲述AI编码强制要求如何将开发者推向崩溃边缘。推得太用力，你不会得到采纳，只会得到怨恨。
Owning the harness means someone makes the setup good enough that using the tool is the path of least resistance.拥有驾驭意味着有人让设置足够好，以至于使用工具成为阻力最小的路径。
What good setup is actually protecting you from好的设置实际上在保护你免受什么
This is the part that turns it from a tooling chore into a real management priority. Better code out of the agent is the obvious payoff. The bigger one is that the harness is your first line of defense against the three problems AI creates on a team.这是将工具杂务转变为真正管理优先事项的部分。代理输出更好的代码是显而易见的回报。更大的回报是，驾驭是你抵御AI在团队中产生的三个问题的第一道防线。
Review capacity. This is the big one. When writing code gets cheap, reviewing it doesn’t. Faros AI looked at data from more than 10,000 developers and found that after AI adoption, pull request volume nearly doubled and review time climbed by 91%. I wrote before about how fast PRs can hide shallow understanding - AI pours fuel on exactly that fire. A senior engineer cannot meaningfully review a thousand lines that took five minutes to generate. The bottleneck has moved from coding to reviews from your most experienced people, and they’re the ones you can least afford to burn out.审查能力。这是个大问题。当编写代码变得廉价时，审查代码并不会。Faros AI查看了超过10,000名开发者的数据，发现AI采用后，拉取请求数量几乎翻倍，审查时间增加了91%。我之前写过，快速的PR可能隐藏浅薄的理解——AI正是火上浇油。一位高级工程师无法有意义地审查五分钟内生成的一千行代码。瓶颈已经从编码转移到了你最资深人员的审查上，而他们是你最不能承受倦怠的人。
Your juniors. AI is very good at the small, well-defined tickets that used to be how junior engineers learned the system. If the agent eats those, what’s left for a junior to grow on? This is a real problem, and good setup is part of the answer - the harness can be tuned to leave room for people to learn, not just to ship.你的初级开发者。AI非常擅长那些小而定义明确的任务，而这些任务过去是初级工程师学习系统的方式。如果代理吃掉了这些，初级开发者还有什么可以成长？这是一个真实的问题，而好的设置是答案的一部分——驾驭可以调整，为人们留出学习空间，而不仅仅是交付。
Trust. The Stack Overflow developer survey found that while 84% of developers now use AI tools, but trust in their accuracy fell to 29%. Two-thirds say the answers are “almost right, but not quite” - which is the most expensive kind of wrong, because it costs time to find. I’ve written about how AI is changing the way teams build trust. The harness is where you decide what the tool is allowed to do unsupervised and what it isn’t.信任。Stack Overflow开发者调查发现，虽然84%的开发者现在使用AI工具，但对其准确性的信任度降至29%。三分之二的人表示答案“几乎正确，但又不完全正确”——这是最昂贵的错误，因为需要花时间发现。我写过AI如何改变团队建立信任的方式。驾驭就是你决定工具在无人监督下可以做什么、不可以做什么的地方。
None of these three problems will magically get solved by a smarter model. All three are shaped by whether someone owns the setup.这三个问题都不会因为更智能的模型而神奇地解决。它们都取决于是否有人拥有设置。
And here’s the cost of not owning it. The team that skips the harness doesn’t get the upside of AI and avoid the downside. They get the worst of both worlds: more code than before, less understanding than before, seniors drowning in reviews, juniors with nothing to learn on, and a tool everyone blames for the mess.而不拥有的代价如下。跳过驾驭的团队既得不到AI的好处，也避免不了坏处。他们得到了最糟糕的两方面：比以前更多的代码、比以前更少的理解、高级开发者淹没在审查中、初级开发者没有东西可学，以及每个人都责怪工具造成的混乱。
The teams that own the harness get the opposite. The agent does the work that should be cheap, the humans spend their attention on the work that shouldn’t be, and the setup is what draws that line.拥有驾驭的团队则相反。代理做那些应该廉价的工作，人类将注意力花在那些不应该廉价的工作上，而设置就是划出那条线。
The question is who on your team owns the harness, what good setup actually looks like, and how you roll it out.问题在于，你的团队中谁拥有驾驭，好的设置实际上是什么样子，以及你如何推广它。
Here’s the playbook I’d use, the setup I’d own, and who I’d put in charge of it:以下是我会使用的剧本、我会拥有的设置，以及我会让谁负责：
The playbook剧本
Below is what “owning the harness” actually means in practice - the four layers of setup that matter, who owns them, the maintenance cadence it needs, and the how to roll it out without getting resentment back.以下是“拥有驾驭”在实践中实际意味着什么——四个重要的设置层、谁拥有它们、所需的维护节奏，以及如何推广而不招致怨恨。
