AI将终结我们所知的技术债
我花了无数时间与团队协商以偿还"技术债务"。一个冲刺接一个冲刺，我都会提出同样的理由：我们需要回去清理那些能用但很混乱的代码，因为我们之前需要快速发布。一个冲刺接一个冲刺，我都会输。业务需要新功能，业务优先。
让我们坦诚地说一件我们很少说的事：要求时间来修复我们自己选择写坏的代码，这公平吗？这是我们欠代码的债吗？
我们服务于业务。不是代码库。如果是这样，我们为什么要欠代码任何东西？
或者我们是不是在过去二十年里一直在误用这个术语？
1、债务从来不是关于烂代码
这个隐喻最早由Ward Cunningham在1992年提出。当时，Ward正在开发一个金融应用程序，需要证明为什么需要重构。为此，他使用了财务人员能理解的语言：债务类比：
"发布首次编写的代码就像负债。少量债务可以加速开发，只要及时通过重写偿还。危险在于债务未偿还。在不太正确的代码上花费的每一分钟都算作该债务的利息。"
他在2009年的一个视频中澄清了他的意思。与该术语的使用方式相反，他的意思并不是为了更快发布而写糟糕的代码是可以的。事实上，他说的几乎相反。即使你的理解仍然部分，用你当前的理解编写代码并发布产品也是合理的。
"债务"并不是指混乱代码。它是当你更了解试图解决的问题时产生的差距，而代码则落后了。你通过重构它来匹配你现在的理解来偿还它。
问题是：这个领域甚至从未就此定义达成一致。
"混乱不是技术债务。混乱只是混乱。技术债务不意味着bug和缺陷。它不意味着混乱代码。它意味着有意的次优结构。"
Robert 'Uncle Bob' Martin
注意，他自己的定义也不是Cunningham的。软件界两个最常被引用的声音，两个不同的定义，都不是大多数团队实际使用的。我们从未真正同意这个词的含义。
但有一件事是确定的：你不欠代码库干净的代码。你欠业务一个反映你对问题最佳理解的产品。
2、为什么我们把"债务"简化为"混乱代码"
在软件历史的大部分时间里，编写代码是构建软件的昂贵部分。没有能够将业务需求转化为机器可执行指令的高度专业化人员，你就无法做到。想构建更多？雇更多人。想更快？牺牲质量。
当我们选择了速度换质量的交易时，它有了一个名字：债务。我们知道不对但我们承诺以后清理的代码。而"以后"，往往从未到来。
定义漂移的原因是代码是可见的且修复成本高，所以它看起来像债务。理解的差距——你是否在构建正确的东西的知识——是不可见的。这导致行业只关注有价格标签的东西：代码。
造成这种情况的原因不是无能。而是激励机制。 业务提出需求，工程团队找到交付方式，而成本被推到了永远不会到来的未来。
3、当重构几乎免费时
AI正在重新定义构建软件的经济学。编写代码从未如此便宜。重构几乎是免费的。这意味着我们花了20年称之为"技术债务"的东西——混乱代码——现在变成了廉价的部分。而我们首先写混乱代码的旧理由——没有足够时间做对——正在消失。当代理在几秒钟内重写一个实现时，"我们为了发布不得不走捷径"就不再是借口了。
仍然昂贵的是AI无法为你做的事：知道你真正想要什么。
AI代理的好坏取决于你对问题的理解。给它一个清晰的理解，带有真实的验收标准和防护栏，它就是力量倍增器。给它一个模糊的理解，它就会放大模糊性，只是更快。
所以相信Cunningham的话。债务从来不在代码中。它存在于你理解的东西和你构建的东西之间的差距中。AI不会缩小那个差距。它只是让你在思考清楚之前把代码扔进去变得比以往任何时候都便宜。
AI不会终结技术债务。它将终结我们追逐了20年的那个版本，并用一个更糟糕的版本替代它。
4、是的，债务在爆炸。但看看是哪种
一项对470个真实世界拉取请求的CodeRabbit研究发现，AI合著的拉取请求比纯人工的多约1.7倍的问题。同时，Forrester报告称，大多数技术领导者预计他们的技术债务负担在好转之前会变得更糟。
很好。让我们仔细看看实际发生了什么。
研究中最大的跳跃不是在风格或语法上。它读起来像是一个称职的工程师写的。是在逻辑和正确性上，上升了75%。
问题在于我们发布的每个功能中嵌入的数十个假设，在实现了错误的东西或跳过了没人想到要指定的验证的代码中。单个很小。但它们加在一起就变成了一个实际上不能解决问题的产品。
混乱不在于代码的外观。它在于团队理解的东西和代理发布的东西之间的差距。
那就是Cunningham定义的技术债务，以机器速度。债务没有爆炸是因为AI写更差的代码。它爆炸了是因为AI让我们跳过思考直接发布。
5、实现债务 vs 理解债务
将混乱代码与混乱理解分开的需求变得难以忽视。所以让我们命名这两者。
我们一直称之为技术债务的东西本质上是实现债务：能用但不对的代码，为了按时发布某些东西而编写。这是AI正在使之廉价的债务。随着代理变得更有能力，重写笨拙实现的成本越来越低。
我们需要开始解决的是理解债务：我们在给代理提供信息时没有的清晰度。你从未问过业务的问题。没人定义的边缘案例，因为生成一些东西然后看看更快。它存在于你认为正在解决的问题和你实际正在解决的问题之间的距离。
有些人已经开始称之为"意图债务"或"认知债务"。我认为它更简单，也更古老：它一直是Cunningham的意思。
这应该让每个工程领导者担心的是：当公司全速推进AI原生工程，同时花比以往更少的时间决定他们真正想构建什么时，实现债务注定会消失，而理解债务将会爆炸。
6、你的工作一直是提供清晰度
这就是它从工程问题变成管理问题的地方。
如果昂贵的债务现在是理解，那么你团队中最稀缺的就不再是编写代码的能力。而是思维的清晰度、产品意识、尽早提出不舒服问题的勇气。这些过去是强大工程之上锦上添花的东西。现在，它们正在成为主要事件。
这改变了四件具体的事。
- 你的招聘方式不同了。 编码能力正在被商品化。你无法商品化的是判断力：那个阅读模糊需求并在打开Claude之前就知道需要回答哪些问题的人。
- 资历意味着不同的东西。它过去追踪某人编码的能力。现在，它更接近于某人消除模糊性的能力——为自己、为代理、为团队的其他成员。
- 规划改变了。 主要问题不再是"我们能构建这个吗？"而是"我们真的理解我们在构建什么吗，我们需要产生什么影响？"只估计工作量的规划衡量的是错误的东西。真正的问题是，在我们把它交给一个将要构建它的代理之前，我们是否对我们想构建的东西有足够的清晰度。
- 你自己的工作改变了。 管理技术债务过去是关于你会以后清理的代码的谈判。现在它是关于在对话、规范、图表中捕获理解债务，在它变成一万人不打算编写的行数来构建一个不能解决我们需要的产品之前。
你可能已经看到了这个的某个版本。一个团队快速行动。然后一个功能上线，感觉有些不对。不是因为代码坏了，甚至不是因为写得差，而是因为它解决的问题与业务实际拥有的问题不同。需求漂移了，没人发现，因为交付某些东西比停下来问我们真正需要什么更快。那就是理解债务。没有代理会为你发现它。
7、隐喻正在回归
二十多年来，我们一直在为我们写的代码支付利息。从现在起，我们将为我们在开始构建之前对问题的理解程度支付利息。讽刺的是，这正是Cunningham一直以来的意思：如果我们不同步解决方案与我们关于问题的知识，就有代价要付。
在AI时代闪耀的团队将是那些理解技术债务从来不是真正关于代码的团队。
原文链接: AI Will Kill Technical Debt as We Know It
汇智网翻译整理，转载请标明出处