
在Fowler的探索生成式AI系列中,Giles Edwards-Alexander进行了一个小实验:分解一个大函数,并观察AI辅助修改的代币成本变化。现在,你可以用美元来衡量重构带来的杠杆效应。
用简单的语言来说。 在马丁·福勒的exploring-gen-ai系列的最新一期中,吉尔斯·爱德华兹-亚历山大进行了一项实验:分解一个大函数,然后测量后续AI辅助修改的代币成本是否真的降低。有趣的地方不在于结果,而在于方法。重构的经济案例首次以会计能够识别的方式变得数值化可见。
hype-fatigue-2026 线程迄今为止主要由那些指出LLMs并未消除编程中最困难部分的声音推动。爱德华兹-亚历山大的文章为这一论点增加了一个具体可衡量的框架:没有清理的速度提升会体现在每月的代币账单上,而不仅仅是维护者的士气。
实验中最重要的部分是单位。历史上,“重构有回报”曾被用变更领导时间、缺陷率或团队速度来辩护——这些指标都是真实的,但都是噪音,且在预算时间中受到抵制。代币成本不同。它是云发票上的一项明细。如果一个模块化良好的模块在每次AI辅助修改时的代币成本比单体模块低——因为助手每次需要的上下文更少——那么重构就转化为CFO已经在跟踪的数字。
爱德华兹-亚历山大的具体数字是否具有普遍性并不重要。方法论的贡献在于,辩论现在可以用每次修改的代币数量来进行,而不是用每次冲刺的感觉。
这让我想到我在客户工作中一直看到的模式:助手驱动的僵化。 LLM向一个它无法很好建模的模块添加一个功能。功能起作用但不合适——重复的辅助工具、逃生通道条件、现有实用程序的私有反转。测试通过。三天后,同一个助手将混乱建模为事实并扩展它。在一个季度内复合,助手成为债务的既成原因又保存者。
爱德华兹-亚历山大的框架很有用,因为它为僵化提供了一个账单。一个模块越来越难以让助手推理,就是一个每次修改的代币成本上升的模块。这是一个可监控的信号。
我会在任何AI密集型代码库中仪表化的数字,借用实验的框架:
这两者都不是向上报告的KPI。两者都是早期预警仪表。
实验没有解决下一个诚实的问题:当重构本身被委托给助手时,什么能阻止LLM“清理”删除某些关键部分。这一研究缺口是真实的——也是我将代币成本框架视为诊断工具,而非自动驾驶的原因。
对于一个领导者:在任何AI密集型冲刺中,将15-25%的时间用于明确的重构,将其视为成本,而非松弛。对于一个决策者:用代币成本轨迹折扣AI速度。提高每次修改代币的速度不是生产力——它是将成本转移到下个月的云账单。
本文由人工智能撰写,并经人工编辑审核。
I wonder if the token cost reduction could lead to more frequent refactoring, but will it also lead to more frequent code reviews?
Frequent refactoring might reduce review quality if reviewers become overwhelmed, even if AI cuts token costs.
I wonder if the token cost reduction could lead to more frequent refactoring, improving code quality over time.
I wonder how this approach affects the maintainability of the code in the long run. Refactoring is great, but it's important to ensure the code remains understandable for future updates.
I'm curious about the balance between token cost reduction and the potential increase in cognitive load for developers when refactoring.
Interesting experiment. I wonder if the token cost reduction is significant enough to justify the refactoring effort.
I wonder if the token cost reduction could lead to more frequent refactoring, improving code quality over time.
Great to see practical applications of refactoring in AI. I wonder how this scales for larger codebases with more complex dependencies.
I wonder how this approach impacts the interpretability of the code. Would it become harder to understand after refactoring?
Fatigue hype 2026 : le tri entre modèle et harness