An AI coding agent, used to write code, needs to reduce your maintenance costs
An AI coding agent, used to write code, needs to reduce your maintenance costs
用于编写代码的 AI 编程代理，必须能够降低你的维护成本
I’ll get straight to the point: your AI coding agent, the one you use to write code, needs to reduce your maintenance costs. Not by a little bit, either. You write code twice as quick now? Better hope you’ve halved your maintenance costs. Three times as productive? One third the maintenance costs. Otherwise, you’re screwed. You’re trading a temporary speed boost for permanent indenture. Oh, you want to know why? Sure. Let’s go for a drive. On a dark desert highway… 我开门见山地说：你用来写代码的 AI 编程代理，必须能够降低你的维护成本。而且不能只降低一点点。你现在的写代码速度快了两倍？那你最好祈祷你的维护成本已经减半了。生产力提升了三倍？那维护成本就得降到三分之一。否则，你就完蛋了。你这是在用暂时的速度提升，换取永久的“卖身契”。哦，你想知道为什么？没问题，让我们开车上路吧。在黑暗的沙漠公路上……
Productivity is Determined by Maintenance Costs
生产力由维护成本决定
Every line of code you write has to be maintained: bug fixes, cleanup, dependency upgrades, and so forth. I’m not talking about new features or enhancements. Just maintenance. For every month you spend writing code, you’ll spend some amount of time in the following year maintaining that code, and some in each year after that, forever, as long as that code exists. 你写的每一行代码都需要维护：修复 Bug、清理代码、升级依赖等等。我指的不是新功能或增强功能，仅仅是维护。你每花一个月写代码，在接下来的一年里，你都要花一定的时间去维护这些代码，并且在之后每一年里，只要这些代码还存在，你就得一直维护下去。
Let’s say you asked a crowd of, say, 50 developers what those maintenance costs were. Using a technique called Wisdom of the Crowd, you could get a reasonably accurate response. It turns out that the specific numbers don’t matter for the overall point I’m making here. Your crowd might tell you that, for each month you spend writing code, you’ll spend… 10 days on maintenance in the first year; and 5 days on maintenance each year after that. 假设你问一群开发者（比如 50 个人）这些维护成本是多少。利用“群体智慧”（Wisdom of the Crowd）技术，你可以得到一个相当准确的回答。事实证明，具体的数字对于我这里要表达的整体观点并不重要。你的群体可能会告诉你，你每花一个月写代码，第一年就需要花 10 天进行维护，之后每年需要花 5 天进行维护。
If you were a particularly obsessive individual, you could spend hours making a spreadsheet modeling how those estimates affect productivity over time. A spreadsheet like this. The first month of a new project is glorious. You spend all your time building fancy new features. The next month is slightly less glorious. A fraction of your time—not much, but a smidge—goes to fixing bugs and cleaning up design mistakes from the first month. In the third month, a smidge more. And the fourth month, the fifth, the sixth… Eventually, it’s not glorious at all. 如果你是一个特别执着的人，你可以花上几个小时制作一个电子表格，模拟这些估算如何随时间影响生产力。就像这样的表格：新项目的第一个月是辉煌的，你把所有时间都花在构建炫酷的新功能上。第二个月辉煌程度稍减，你的一部分时间——不多，但有一点点——被用来修复 Bug 和清理第一个月留下的设计错误。第三个月，又多了一点点。第四个月、第五个月、第六个月……最终，它一点也不辉煌了。
According to our crowd’s maintenance estimates, you’ll spend more than half your time on maintenance after 2½ years. After ten years, you can hardly do anything else. Halving the crowd’s maintenance estimates gives you three more years before you hit the 50% mark. Doubling them sees you below 50% in less than a year. The lesson is clear. If you want a productive team, you have to focus on their maintenance costs. 根据我们群体给出的维护估算，2 年半后，你将花费超过一半的时间在维护上。十年后，你几乎无法做任何其他事情。将群体的维护估算减半，你可以多出三年时间才达到 50% 的临界点。如果估算翻倍，不到一年你就会跌破 50% 的生产力。教训很明确：如果你想要一个高产的团队，你必须关注他们的维护成本。
All Models Are Wrong
所有的模型都是错的
Do these numbers ring true to you? They do to me. In my career as a consultant, I specialized in late-stage startups, and they all had the exact problem shown in the graph above. About 5-9 years in, they’d notice their teams were no longer getting shit done, and then they’d call me. Their teams weren’t quite as bad as the graph shows. Maybe their maintenance costs were lower. Or maybe… and this feels more likely to me… their maintenance costs were exactly that bad, and they papered over the problem instead. 这些数字对你来说真实吗？对我来说是的。在我担任顾问的职业生涯中，我专门研究后期初创公司，它们都存在上述图表中显示的同样问题。在运营 5-9 年后，他们会发现团队不再能产出成果，然后就会找我。他们的团队情况可能没有图表显示的那么糟糕。也许他们的维护成本更低。或者——我觉得更有可能的是——他们的维护成本确实有那么糟糕，只是他们掩盖了问题。
Maybe they: Decided not to fix every bug, or upgrade every dependency; Added people when the team got slow… and then kept adding more, because it was never enough; Scrapped it all and started over with a rewrite. There’s room to debate the precise maintenance numbers, but overall, the model feels right. If you’ve been around the block, you know this graph is true. You’ve seen how productivity melts away over time. You have the scars. 也许他们：决定不修复每一个 Bug，也不升级每一个依赖；在团队变慢时增加人手……然后不断增加，因为永远不够；或者干脆推倒重来。关于具体的维护数字还有讨论的空间，但总的来说，这个模型是正确的。如果你在行业里摸爬滚打过，你就知道这张图表是真实的。你已经见证了生产力是如何随着时间流逝而消融的。你身上有这些伤疤。
What Does This Have to Do With AI?
这与 AI 有什么关系？
Only everything. Let’s say your team just started using Rock Lobster, the latest and greatest agentic coding framework, and it Doubles!! your code output! Woohoo! The code’s a bit harder to understand, though, and your team is drowning in pull requests, and you maybe kinda sorta teensy weensy don’t actually read the code before smashing the approve button. Like, at all. I mean, you skimmed it, during boring meetings, sometimes, and that’s gotta be good enough, right? LGTM, let’s get this shit done! 关系太大了。假设你的团队刚开始使用 Rock Lobster（目前最棒的代理编程框架），它让你的代码产出翻倍了！哇哦！但代码变得更难理解了，你的团队被 Pull Request 淹没，而你在点击“批准”按钮之前，可能根本没怎么读过代码。一点都没读。我的意思是，你只是在无聊的会议中偶尔扫了一眼，这应该足够了吧？“LGTM（看起来不错）”，赶紧把活干完！
So now you’re producing two months of work in a month, and let’s say you’ve doubled how much each “month” of output costs to maintain. Next month’s maintenance costs quadruple. Oh. About five months after you start using Rock Lobster, your productivity is back down to where you started, and a few months after that, it’s worse than it would have been had you never touched Rock Lobster in the first place. I’m not saying your AI doubles maintenance costs. Or productivity. This is an extreme example. But even if your AI produces code that’s just as easy to maintain as your human-written code, the productivity gains don’t last. 所以现在你一个月完成了两个月的工作量，假设你让每个“月”的产出维护成本翻了一倍。下个月的维护成本就会翻四倍。哦。在你开始使用 Rock Lobster 大约五个月后，你的生产力就会回到起点，再过几个月，情况会比你从未接触过 Rock Lobster 时还要糟糕。我并不是说你的 AI 一定会让维护成本翻倍，或者生产力翻倍。这是一个极端的例子。但即使你的 AI 产出的代码与人类编写的代码一样易于维护，生产力的提升也是无法持久的。
You Can Check Out Any Time You Like
你随时可以退场
Agents are expensive, and they’re only getting more so. Once your agent’s juice is no longer worth the squeeze, you might decide to save your pennies and go back to coding the old way. Like a caveman. With your fingers. Ha! Joke’s on you! When you stop using the agent, all the productivity benefit goes away… but the added maintenance costs don’t! As long as that code’s still around, you’re stuck with lower productivity than if you had never touched the agent at all. 代理很昂贵，而且只会越来越贵。一旦你发现使用代理的投入产出比不再划算，你可能会决定省点钱，回到老办法写代码。像个穴居人一样。用你的手指。哈！你被耍了！当你停止使用代理时，所有的生产力红利都会消失……但增加的维护成本却不会！只要那些代码还在，你的生产力就会一直比从未接触过代理时更低。
The Passage Back
回归之路
The math only works if the LLM decreases your maintenance costs, and by exactly the inverse of the rate it adds code. If you double your output and your cost of maintaining that output, two times two means you’ve quadrupled your maintenance costs. If you double your output and hold your maintenance costs steady, two times one means you’ve still doubled your maintenance costs. Instead, you have to invert your productivity. If you’re producing twice as much code, you need code that costs half as much to maintain. Three times as much code, one third the maintenance. This is the secret to success. All the benefits, none of the lock-in. 只有当大模型（LLM）降低你的维护成本，且降低的比例正好与它增加代码的比例成反比时，数学逻辑才成立。如果你产出翻倍，维护成本也翻倍，2 乘以 2 意味着你的维护成本翻了四倍。如果你产出翻倍但维护成本保持不变，2 乘以 1 意味着你的维护成本依然翻了一倍。相反，你必须反转你的生产力逻辑。如果你产出的代码量是原来的两倍，你需要代码的维护成本降到原来的一半。产出三倍，维护成本降到三分之一。这就是成功的秘诀。享受所有好处，同时避免被锁定。
Can We Kill the Beast?
我们能战胜这头怪兽吗？
I dunno. All my reading of the finest news sources says that coding agents increase maintenance costs. Some people do say they help them understand large systems better. But big decreases in costs, of the size we need to see? No. Just the opposite. That’s a problem. 我不知道。我阅读的所有顶级新闻来源都表明，编程代理增加了维护成本。有些人确实说它们能帮助他们更好地理解大型系统。但是，我们所需要的这种大幅度成本降低出现了吗？没有。恰恰相反。这是一个问题。