Advances in development tooling and environments continually reshape technical debt challenges, supporting efforts to eliminate some technical debt while also resulting in incurring new forms. Current rapid advances in AI-based approaches and agentic tooling are no exception; we expect the use of AI in the software development lifecycle to substantially shift both the accumulation and repayment of technical debt. The need to understand and manage technical debt will remain, even if the nature of the debt changes; software must be continually maintained in the face of entropy. In this article, we raise awareness of the Technical Debt Manifesto¹ and discuss the values, beliefs, and principles of technical debt management from this manifesto in the context of the evolving software ecosystem where software is created by a diverse set of contributors in collaboration: professional software developers, nondevelopers utilizing AI-based tools, and autonomous agents. (See “The Technical Debt Manifesto.”) We argue that the relevance of the values, beliefs, and principles of technical debt management will not change no matter how software is created.开发工具和环境的进步不断重塑着技术债务的挑战，既助力消除部分技术债务，也导致了新型债务的产生。当前基于 AI 的方法和智能代理工具的快速发展也不例外；我们预计，在软件开发生命周期中使用 AI 将会从根本上改变技术债务的积累与偿还方式。即便债务的本质发生了变化，理解和管理技术债务的需求依然存在；面对熵增，软件必须持续维护。在本文中，我们旨在提高人们对《技术债务宣言》(Technical Debt Manifesto) 的认识，并在软件生态系统不断演进的背景下，探讨该宣言中的价值观、信念和原则。当前的软件生态由多元化的协作群体共同构建：专业的软件开发人员、使用 AI 工具的非开发人员以及自主智能代理。（参见“技术债务宣言”。）我们认为，无论软件以何种方式创建，技术债务管理的价值观、信念和原则的重要性都不会改变。

“In software-intensive systems, Technical Debt is a collection of design or implementation constructs that are expedient in the short term but set up a technical context that can make future changes more costly or impossible.”²“在软件密集型系统中，技术债务是指一系列在短期内权宜之计的设计或实现结构，但它们构建的技术环境可能会使未来的变更变得更加昂贵，甚至无法实现。”2

Engineering organizations regularly face difficult decisions concerning tradeoffs between the velocity of delivery and the quality or completeness of the system delivered. The need to deliver by a particular deadline means that design and implementation choices may not hinge on long-term scalability, extensibility, or maintainability. Organizations will build the thing they need now, knowing that later on, they will be faced with more work to build it better. The essence of the “debt” metaphor is that engineering capacity is spent now with the knowledge that more capacity will be needed to pay back the debt later. At the same time, interest is paid in terms of the additional cost of changes or maintenance because of the preexisting debt. And, as with financial debt, technical debt can be incurred and managed wisely or unwisely. To incur technical debt wisely is to do so deliberately and with prudent consideration of the costs.^a However, as engineering organizations make many such decisions, it is also necessary to take a principled approach to managing technical debt as a whole.工程组织经常面临关于交付速度与交付系统质量或完整性之间权衡的艰难决策。为了在特定期限内交付，设计和实现的选择可能不会优先考虑长期的可扩展性、可扩展性或可维护性。组织会构建当前所需的系统，并深知未来需要投入更多工作来完善它。“债务”隐喻的本质在于，现在消耗工程能力，是因为预知未来需要更多的能力来偿还债务。同时，由于预先存在的债务，还需要支付额外的变更或维护成本作为利息。正如金融债务一样，技术债务的产生和管理也存在明智与不明智之分。明智地产生技术债务是指审慎考虑成本后做出的刻意选择。a 然而，随着工程组织做出大量此类决策，也必须采取原则性的方法来整体管理技术债务。

AI-based tools can certainly accelerate software development, but gains in speed must be weighed carefully^b and evaluated against potential issues with quality.^c In some cases (for example, the introduction of security vulnerabilities), quality concerns are immediate and can be identified with existing quality assurance tools, such as program analysis. In other cases, quality concerns may be less immediate; evolvability or maintainability concerns may not be discovered for months after the code was written. Of course, technical debt accrues in human-generated code, too, and by empowering engineers to write code more easily, AI may also reduce the cost of fixing some technical debt.基于 AI 的工具无疑可以加速软件开发，但必须仔细权衡速度的提升与潜在的质量问题。c 在某些情况下（例如引入安全漏洞），质量问题是直接的，可以通过现有的质量保证工具（如程序分析）识别。在其他情况下，质量问题可能不那么直接；可演进性或可维护性问题可能在代码编写数月后才被发现。当然，人类编写的代码也会产生技术债务，而 AI 通过赋能工程师更轻松地编写代码，也可能降低修复某些技术债务的成本。

It is likely that AI will both add and remove technical debt from software projects. Much as code formatters ended debates around where parentheses should go, AI is likely to free us from directly fixing some technical debt. But the newly freed capacity will enable engineers to explore new capabilities, resulting in more complex systems, and at the same time, incurring new technical debt.² As teams adapt and adjust the way they work, the forms of technical debt they incur may change. Regardless, teams tend to settle back to a baseline rate of incurring technical debt shaped by their risk tolerance and established debt management practices.³ So, how should software engineering teams work to effectively manage their technical debt in the AI era?AI 很可能会在软件项目中既增加又减少技术债务。正如代码格式化工具终结了关于括号位置的争论一样，AI 很可能将我们从直接修复某些技术债务的工作中解放出来。但释放出来的能力将使工程师能够探索新功能，从而构建更复杂的系统，同时产生新的技术债务。2 随着团队调整工作方式，他们所产生的技术债务形式可能会发生变化。无论如何，团队往往会回归到由其风险承受能力和既定债务管理实践所决定的基准债务产生率。3 那么，软件工程团队在 AI 时代应如何有效管理技术债务？

We argue that the fundamental principles of good technical debt management are as important with AI as they were without AI. AI-based tools may enable more rapid experimentation and exploration, and teams may feel that eliminating technical debt from those explorations is equally easy. As a result, teams may incur more “reckless” technical debt.^a There are already convincing arguments that AI will amplify—rather than replace—existing patterns.^d,^e To quote directly, “Teams that have strong practices, flexible workflows, and shared context often see immediate benefits [of AI]. Teams that rely on brittle processes and implicit knowledge may find those gaps more visible than ever.”^e That is, if a team is not managing technical debt well without AI, adding AI is more likely to make the situation worse, not better. Good technical debt management principles have not changed, but the way they play out in practice for AI-based teams is worth examining directly.我们认为，良好的技术债务管理的基本原则在 AI 时代与在没有 AI 时同样重要。基于 AI 的工具可能使实验和探索更加迅速，团队可能会觉得消除这些探索带来的技术债务也同样容易。结果，团队可能会产生更多“鲁莽的”技术债务。a 已经有令人信服的论点表明，AI 将会放大而非取代现有的模式。d,e 直接引用的话说：“拥有强大实践、灵活工作流和共享背景的团队通常能立即看到 [AI 的] 好处。依赖脆弱流程和隐性知识的团队可能会发现这些差距比以往任何时候都更加明显。”e 也就是说，如果一个团队在没有 AI 的情况下管理不好技术债务，引入 AI 更可能会使情况恶化，而不是改善。良好的技术债务管理原则没有改变，但它们在基于 AI 的团队中的实践方式值得直接审视。

The values, beliefs, and principles listed in “The Technical Debt Manifesto” are applicable to all management of technical debt, but there are a few of these we would like to call out as particularly relevant for AI-based software development. In particular, we see that the unique capabilities and risks of using AI in software development will allow us to better collect data on technical debt and make technical debt more visible. However, we also see that AI may not have access to tacit knowledge to prevent architectural debt or be aware of system context, and this could lead to increases in technical debt. Finally, we see that all of these pieces will strongly depend on newly enabled tooling that could better bring together both humans and AI to tackle technical debt.《技术债务宣言》中列出的价值观、信念和原则适用于所有技术债务管理，但其中有几点我们认为对于基于 AI 的软件开发尤为重要。特别是，我们认为使用 AI 进行软件开发的独特能力和风险将使我们能够更好地收集技术债务数据并使其可视化。然而，我们也看到 AI 可能无法获取预防架构债务所需的隐性知识，也无法感知系统环境，这可能导致技术债务增加。最后，我们认为所有这些方面都将极大地依赖于新启用的工具，这些工具可以更好地将人类与 AI 结合起来，共同应对技术债务。

AI-based tools provide a unique opportunity for technical debt management due to their ability to efficiently collect data. Specifically, AI can be used to collect comprehensive data related to technical debt, either through source code analysis (for example, detecting design smells or violations of design principles) or by detecting self-admitted technical debt in natural language (for example, detecting violations of design decisions or obsolete technologies in issues, code comments, or pull requests). This can facilitate the application of P3, “Collect comprehensive data for technical debt management,” by integrating and making sense of data that come from various sources (see also V4, “both quantitative and qualitative data collection along with research methods to identify, measure, and prioritize technical debt over single-method approaches”). Such data also need to be complemented by tacit knowledge about the system that developers and business stakeholders can make explicit. This is the kind of knowledge that AI cannot synthesize on its own. It also shifts the attention from single data sources that are readily available (like source code) and encourages interdisciplinary thinking (for example, from economics or behavioral sciences) on balancing developer experience with business goals.基于 AI 的工具因其高效收集数据的能力，为技术债务管理提供了独特的机遇。具体而言，AI 可用于收集与技术债务相关的全面数据，无论是通过源代码分析（例如检测设计异味或违反设计原则的情况），还是通过检测自然语言中的自述技术债务（例如在问题、代码注释或拉取请求中检测违反设计决策或使用过时技术的情况）。这可以通过整合来自各种来源的数据，促进原则 P3“收集全面的数据以进行技术债务管理”的应用（另请参阅价值观 V4“定量与定性数据收集以及用于识别、衡量和优先排序技术债务的研究方法，而非单一方法”）。此类数据还需要辅以开发人员和业务利益相关者能够明确表达的关于系统的隐性知识。这是 AI 无法自行综合的知识。这也将注意力从现成的单一数据源（如源代码）转移开来，并鼓励跨学科思考（例如来自经济学或行为科学），以平衡开发人员体验与业务目标。

A key indicator of success in any technical debt management journey is the extent to which technical debt is visible (P6, “Make technical debt visible”). The pace of generating software engineering artifacts with AI and the sheer number of such artifacts make technical debt more difficult to monitor and control. Technical debt remains hidden under an avalanche of new code committed (that includes inadvertent technical debt), exactly when it should be clearly documented and its evolution carefully scrutinized. AI-based approaches can assist here, including by summarizing and presenting the most relevant data so that software engineers are not overwhelmed by excess information and can focus on that which is most relevant to technical debt tradeoffs. This focus supports V3, “transparency, explainability, and replicability in the identification, measurement, and prioritization of technical debt.” Increasing visibility of technical debt also assists with assigning responsibilities for its effective management. Some categories of technical debt can be delegated to AI-based tools—but always under a shared responsibility of technical and business stakeholders, according to P1, “Share responsibility for technical debt management.”任何技术债务管理之旅成功的关键指标在于技术债务的可视化程度（原则 P6，“使技术债务可视化”）。利用 AI 生成软件工程产物的速度以及此类产物的巨大数量，使得技术债务更难监控和控制。技术债务隐藏在大量新提交的代码（包括无意中产生的技术债务）之下，而这恰恰是应该对其进行清晰记录并仔细审查其演进的时候。基于 AI 的方法可以在此提供帮助，包括汇总并呈现最相关的数据，使软件工程师不会被过量信息淹没，从而能够专注于与技术债务权衡最相关的内容。这种聚焦支持了价值观 V3，“在技术债务的识别、衡量和优先级排序中的透明度、可解释性和可重复性”。提高技术债务的可见性也有助于分配其有效管理的责任。某些类别的技术债务可以委托给基于 AI 的工具——但根据原则 P1“共同承担技术债务管理的责任”，这必须始终在技术和业务利益相关者的共同责任下进行。

The capabilities of AI-based tools are still evolving. There is a risk that AI-based tools miss much of the architecture knowledge,^f such as design decisions, technology choices, architecture patterns, and design principles; these often remain tacit in developers’ heads. Without this knowledge, making (automated) changes risks breaking the architecture and incurring a form of technical debt that is notoriously harder to fix. Developers are in a better position to align and check the conformance of any structural changes to the architecture, as long as they have a good grasp of the architecture themselves (see V5, “architecture understanding across the team”). AI-based tools can help as a brainstorming partner to ask the right questions about architecture, mitigate the potential risks of omissions, and identify relevant details in complex system design. This calls for a shift away from code and toward thinking of system-wide quality attributes and how they are affected by changes (P7, “Elevate the role of architecture in technical debt management”).基于 AI 的工具的能力仍在演进中。存在这样一种风险：基于 AI 的工具会遗漏大部分架构知识，f 例如设计决策、技术选择、架构模式和设计原则；这些知识往往作为隐性知识存在于开发人员的头脑中。没有这些知识，进行（自动化）变更就有破坏架构并产生一种众所周知更难修复的技术债务的风险。开发人员更有能力协调并检查任何结构性变更对架构的一致性，只要他们自身对架构有很好的把握（参见价值观 V5，“整个团队对软件架构的理解”）。基于 AI 的工具可以作为头脑风暴的伙伴，提出关于架构的正确问题，减轻潜在的遗漏风险，并识别复杂系统设计中的相关细节。这要求从关注代码转向思考全系统的质量属性以及它们如何受到变更的影响（原则 P7，“提升架构在技术债务管理中的作用”）。

Perhaps one of the most debated concepts of the use of AI in the software development lifecycle is how well AI can take the system and environment context into account to generate code, refactor, or fix bugs. Without a clear and measurable accounting of context, it is difficult to manage technical debt and particularly to prioritize which items need to be fixed first as well as to estimate the cost of fixing them (P2, “Manage technical debt in alignment with its context”). Because of their contextual insights, developers’ perceptions of technical debt should be prioritized over data from AI analysis (B4, “Items that developers observe as technical debt should be addressed, even when they are not supported by metrics”). The understanding and intuition of developers can often not be explicitly articulated, but it does emphasize the “pain points” of development, much more than AI-based tools that focus on clean code and optimize individual metrics. Another important part of context is the concept of value, which underpins the benefit of incurring technical debt in the first place and often remains tacit in developers’ heads. Finally, software artifacts generated by AI-based tools may reduce individual and team knowledge about system structure and behavior (sometimes called cognitive debt).⁴ All this contextual information underscores the need to have developers at the center of making decisions to prioritize and repay technical debt (P9, “Make intentional technical debt tradeoff decisions”).关于在软件开发生命周期中使用 AI，争论最激烈的概念之一可能是 AI 在生成代码、重构或修复 bug 时，能在多大程度上考虑系统和环境背景。如果没有清晰且可衡量的背景核算，就很难管理技术债务，特别是很难确定哪些项目需要优先修复以及估算修复成本（原则 P2，“根据环境进行技术债务管理”）。由于开发人员具有背景洞察力，他们对技术债务的感知应优先于来自 AI 分析的数据（信念 B4，“开发人员观察到的技术债务问题即使缺乏指标支持，也应予以解决”）。开发人员的理解和直觉往往无法明确表述，但它确实比专注于干净代码和优化单个指标的基于 AI 的工具更能强调开发的“痛点”。背景的另一个重要部分是价值概念，它支撑了产生技术债务的初衷，且往往作为隐性知识存在于开发人员的头脑中。最后，由基于 AI 的工具生成的软件产物可能会减少个人和团队对系统结构和行为的了解（有时称为认知债务）。4 所有这些背景信息都强调了让开发人员处于决策中心以优先排序和偿还技术债务的必要性（原则 P9，“做出审慎的技术债务权衡决策”）。

The Technical Debt Manifesto posits that “the most effective technical debt management is as automatic as possible and as manual as needed” (B2). This belief implies that tools—and tool developers—need to identify opportunities in increasing automation while keeping humans front of mind. But how well will AI-based tools be able to increase automation?《技术债务宣言》提出“最有效的技术债务管理应尽可能自动化，并在必要时辅以人工干预”（信念 B2）。这一信念意味着工具——以及工具开发者——需要识别增加自动化的机会，同时始终将人类放在首位。但是，基于 AI 的工具在提高自动化方面能做到什么程度呢？

AI-based tools may be able to automate the identification and management of more complex kinds of technical debt, such as design smells, for example, identifying suboptimal implementations of patterns and their consequences. Nevertheless, there will still be areas where humans will have better context and understanding to identify where technical debt might be and how to fix it. It will still be important for a human to validate that what the tool considers technical debt is, in fact, a problem worth fixing and not simply an acceptable optimization given other quality considerations, such as performance.基于 AI 的工具或许能够自动化识别和管理更复杂的技术债务，例如设计异味，例如识别模式的次优实现及其后果。尽管如此，在某些领域，人类仍然拥有更好的背景和理解力来识别技术债务可能存在的位置以及如何修复它。对于人类来说，验证工具所认为的技术债务是否确实是一个值得修复的问题，而不是在考虑性能等其他质量因素后的可接受优化，这一点仍然很重要。

This tool and human partnership will continue to be central to technical debt management. Therefore, principle P5, “Build seamless and integrated technical debt management toolchains with human oversight,” should continue to guide technical debt tool development and management. AI-based toolchains must support development workflows, both existing and new, while at the same time enabling humans to retain oversight of decisions about technical debt. The more tools (with or without AI) can deliver reliable data and help prioritize and reduce technical debt, the more humans can focus on system design tradeoffs, quality concerns, and operational aspects that cannot be automated.这种工具与人类的伙伴关系将继续成为技术债务管理的核心。因此，原则 P5“构建无缝集成且有人工监督的技术债务管理工具链”应继续指导技术债务工具的开发和管理。基于 AI 的工具链必须支持现有的和新的开发工作流，同时使人类能够保持对技术债务决策的监督。工具（无论是否带有 AI）越能提供可靠的数据并帮助优先排序和减少技术债务，人类就越能专注于系统设计权衡、质量问题和无法自动化的操作方面。

We have no reason to believe, given our 60 years of software engineering history, that technical debt will simply disappear. This makes working from a shared set of values, beliefs, and principles all the more relevant because they are agnostic to process, tool, or AI vendor. No matter how systems are developed and evolved, managing technical debt will be an aspect of the process, and the values, beliefs, and principles in the “Technical Debt Manifesto” will be relevant. As we previously discussed in our thought exercise envisioning what happens when technical debt vanishes, as long as we rely on software systems to assist with our tasks, technical debt will be a reality.² While the mechanisms of developing software will change, and who conducts what task may shift, there will still be software systems that will need to be developed, evolved, and maintained.^g Embracing the values, beliefs, and principles in technical debt management will help endure the test of AI while continuing to focus on increasing the quality, relevance, and timeliness of software systems that reach end users.鉴于我们 60 年的软件工程历史，我们没有理由相信技术债务会凭空消失。这使得基于一套共享的价值观、信念和原则进行工作变得更加重要，因为它们与流程、工具或 AI 供应商无关。无论系统如何开发和演进，管理技术债务都将是流程的一个方面，《技术债务宣言》中的价值观、信念和原则都将具有相关性。正如我们之前在关于技术债务消失后的思想实验中所讨论的那样，只要我们依赖软件系统来协助我们完成任务，技术债务就将成为现实。2 虽然软件开发机制会改变，谁执行什么任务可能会发生转移，但仍然会有软件系统需要开发、演进和维护。g 拥抱技术债务管理中的价值观、信念和原则，将有助于经受住 AI 的考验，同时继续专注于提高交付给最终用户的软件系统的质量、相关性和及时性。