Architecting the MVP in the Age of AI
构建人工智能时代的 MVP

Architecting an MVP is always conducted under extreme time constraints. AI can help to partially relieve these constraints by suggesting alternatives based on others’ experiences. While it can’t make decisions, it can help teams to be better informed to make those decisions. They still need to validate their decisions experimentally, but AI can help here, too, by generating some of the supporting code necessary to run the experiments.
构建 MVP 总是在极端的时间限制下进行。人工智能可以通过根据他人的经验提出替代方案来帮助部分缓解这些限制。虽然它不能做出决策，但它可以帮助团队更好地了解这些决策。他们仍然需要通过实验来验证他们的决定，但人工智能也可以通过生成运行实验所需的一些支持代码来提供帮助。

Potential Benefits of AI for Software Architecture
人工智能对软件架构的潜在好处

In an earlier article, we defined what "software architecture" means to us:
在之前的 一篇文章中，我们定义了“软件架构”对我们的意义：

"Software architecture is about capturing decisions, not describing structure.[...] The key activity of architecting is forming hypotheses about how the system will meet quality attribute goals, and then using empiricism to test whether the system meets them, and then repeating this loop until the system meets its quality goals".
“软件架构是关于捕获决策，而不是描述结构。[...]架构的关键活动是形成关于系统将如何满足质量属性目标的假设，然后使用经验主义来测试系统是否满足这些目标，然后重复这个循环，直到系统达到其质量目标“。

And the most important architectural decisions are about trade-offs between Quality Attribute Requirements (QARs).
最重要的架构决策是关于 质量属性要求 （QAR） 之间的权衡 。

How do software architects make these trade-offs, and how might AI help? The following table summarizes the ways that AI may help teams with tasks that we feel are important to architecting software. The "Can AI Help" column indicates the relative degree to which AI can help with the task, with the shaded portion of the figure representing the degree to which we think AI can help. While AI cannot completely perform any task, it can partially support some of the tasks more than others.
软件架构师如何做出这些权衡，人工智能如何提供帮助？下表总结了 AI 可以帮助团队完成我们认为对构建软件很重要的任务的方式。“AI 可以提供帮助吗”列表示 AI 可以帮助完成任务的相对程度，图的阴影部分代表我们认为 AI 可以提供帮助的程度。虽然人工智能无法完全执行任何任务，但它可以比其他任务更部分地支持某些任务。

Each of these is discussed in detail in the sections below.
以下各节将详细讨论其中每一项。

Understand the QARs that the solution must satisfy
了解解决方案必须满足的 QAR

A key aspect of architecting an MVP is forming and testing hypotheses about how the system will meet its QARs. Understanding and prioritizing these QARs is not an easy task, especially for teams without a lot of architecture experience.
构建 MVP 的一个关键方面是形成和测试有关系统将如何满足其 QAR 的假设。了解这些 QAR 并确定其优先级并不是一件容易的事，尤其是对于没有大量架构经验的团队而言。

AI can help when teams provide context by describing the QARs that the system must satisfy in a prompt and asking the LLM to suggest related requirements. The LLM may suggest additional QARs that the team may have overlooked. For example, if performance, security, and usability are the top 3 QARs that a team is considering, an LLM may suggest looking at scalability and resilience as well. This can be especially helpful for people who are new to software architecture.
当团队提供上下文时，人工智能可以通过在提示中描述系统必须满足的 QAR 并要求法学硕士提出相关要求来提供帮助。LLM 可能会建议团队可能忽略的其他 QAR。例如，如果性能、安全性和可用性是团队正在考虑的前 3 个 QAR，LLM 可能会建议也考虑可扩展性和弹性。这对于刚接触软件架构的人特别有帮助。

For example, meeting scalability requirements is an important but often overlooked challenge when implementing an MVP. There really are scalability requirements; they are just hard to see. Every system has a business case, and the business case has implicit scalability requirements. Using an LLM may help a team to consider scalability requirements that they may have overlooked, especially when building an MVP.
例如，在实施 MVP 时， 满足可伸缩性要求 是一个重要但经常被忽视的挑战。确实有可扩展性要求;他们只是很难看到。每个系统都有一个业务案例，业务案例具有隐式的可伸缩性要求。使用 LLM 可以帮助团队考虑他们可能忽略的可扩展性要求，尤其是在构建 MVP 时。

Drive architectural decisions
推动架构决策

An early architectural challenge is quickly narrowing down the search for suitable frameworks and technologies. Although an LLM cannot make a decision about which technologies to use, it can narrow the search for alternatives by identifying potential options and collecting reported positives and negatives of those potential options.
早期的架构挑战是迅速缩小对合适框架和技术的搜索范围。尽管法学硕士无法决定使用哪些技术，但它可以通过识别潜在选项并收集这些潜在选项的报告的积极和消极来缩小对替代方案的搜索范围。

Understanding that AI cannot make decisions about trade-offs is important: it can suggest alternatives that help to inform decisions, but balancing trade-offs is up to the development team. To get the most from an LLM, they must provide specific details about the context when asking questions of the LLM.
了解人工智能无法做出权衡决策很重要：它可以提出有助于为决策提供信息的替代方案，但平衡权衡取决于开发团队。为了充分利用 LLM，他们必须在向 LLM 提问时提供有关上下文的具体详细信息。

For example, if performance is one of the QARs the system must meet, asking for recommendations to "make the system fast" in a prompt isn’t likely to result in useful recommendations. Being specific about requirements for response time/latency, turnaround time, or throughput will elicit a much better set of recommendations if key system characteristics are also provided to the LLM. It also may force the team to think more deeply about the domain to be able to provide a concise explanation of the requirements.
例如，如果性能是系统必须满足的 QAR 之一，那么在提示中要求“使系统快速”的建议不太可能产生有用的建议。如果还向 LLM 提供关键系统特征，则具体说明响应时间/延迟、周转时间或吞吐量的要求将引出一组更好的建议。它还可能迫使团队更深入地思考领域，以便能够对需求进行简明的解释。

In a way, the act of prompt engineering and providing important context can be as useful as the results provided by the LLM. Getting good results requires specific requirements, clear communication, and an understanding of the desired outcome. This is true whether or not you are using an LLM. This is a case of "going slower to go faster" because taking time to think more about the problem domain will allow you to benefit from the fast results provided by an LLM.
在某种程度上，提示工程和提供重要上下文的行为可以与 LLM 提供的结果一样有用。获得良好的结果需要特定的要求、清晰的沟通以及对预期结果的理解。无论您是否使用 LLM，都是如此。这是一个“慢一点，快一点”的情况，因为花时间更多地思考问题领域将使您受益于 LLM 提供的快速结果。

Use experiments to obtain empirical results that support their decisions
使用实验获得支持他们决策的经验结果

AI can be very powerful by helping a developer create code to solve a particular problem, but developers have to validate the AI-generated results, as the following quote illustrates:
通过帮助开发人员创建代码来解决特定问题，人工智能可以非常强大，但开发人员必须验证人工智能生成的结果，如 以下引文 所示：

"While AI can generate code, human expertise is still needed to ensure it is correct, efficient and maintainable".
“虽然人工智能可以生成代码，但仍需要人类专业知识来确保其正确、高效和可维护”。

Joanna Parke  乔安娜·帕克
Chief Talent and Operations Officer, Thoughtworks
Thoughtworks 首席人才和运营官

Sometimes validating the AI’s results may require more skills than would be required to create the solution from scratch, just as is sometimes the case when seeing someone else’s code and realizing that it’s better than what you would have developed on your own. This can be an effective way to improve developers’ skills, provided that the code is good. AI can also help you find and fix bugs in your code that you may miss.
有时，验证 AI 的结果可能需要比从头开始创建解决方案所需的更多技能，就像有时看到别人的代码并意识到它比您自己开发的代码更好时一样。只要代码良好，这可能是提高开发人员技能的有效方法。人工智能还可以帮助您发现并修复代码中可能遗漏的错误。

Beyond simple code inspection, experimentation provides a means of validating the results produced by AI. In fact, experimentation is the only real way to validate it, as some researchers have discovered.
除了简单的代码检查之外，实验还提供了一种验证人工智能生成的结果的方法。事实上，正如 一些研究人员 所发现的那样，实验是验证它的唯一真正方法。

In prior articles, we have described the need to use experimentation to test and validate architecture. The fact that parts of an architecture have been generated by AI does not change this fundamental truth: architectures can only be evaluated empirically; they can’t be generated from a set of principles.
在之前的文章中，我们已经描述了 使用实验来测试和验证架构的必要性。架构的一部分是由人工智能生成的这一事实并不能改变这个基本事实：架构只能根据经验进行评估;它们不能从一组原则中生成。

In addition, an LLM may help a team rapidly create simple but sufficient user interfaces (UIs) to test business and architectural hypotheses. Early MVPs don’t need highly polished UIs; in fact, investing too soon in a sophisticated UI can be wasteful. A better strategy could be to use an LLM to quickly generate UI code that is good enough to explore critical issues as early as possible.
此外，LLM 可以帮助团队快速创建简单但足够的用户界面 （UI） 来测试业务和架构假设。早期的 MVP 不需要高度完善的 UI;事实上，过早投资复杂的 UI 可能会造成浪费。更好的策略可能是使用 LLM 快速生成足以尽早探索关键问题的 UI 代码。

Finally, AI can also help with some of the more mundane but important coding tasks, such as creating a set of unit tests. Many teams struggle to find time to create adequate unit test coverage, and the relative simplicity of unit testing makes it a good candidate for AI assistance.
最后，人工智能还可以帮助完成一些更平凡但重要的编码任务，例如创建一组单元测试。许多团队很难抽出时间来创建足够的单元测试覆盖率，而单元测试的相对简单性使其成为 AI 辅助的良好候选者。

Document and communicate the architecture
记录和传达架构

Documenting and communicating architectural decisions and their implementation is a significant aspect of what architects must do. If future teams supporting the system don’t understand the decisions that the team developing the system made, their changes will cause the system to degrade. AI can help with this while the system is being developed. This can help to improve the sustainability of the system over time. Some examples include:
记录和传达架构决策及其实施是架构师必须做的一个重要方面。如果未来支持该系统的团队不了解开发该系统的团队所做的决策，他们的更改将导致系统降级。在系统开发过程中，人工智能可以帮助解决这个问题。随着时间的推移，这有助于提高系统的可持续性。一些示例包括：

• Using voice recording and transcription tools when the team is discussing architectural decisions, and summarizing these discussions. This can provide context in the future when architectural decisions are being challenged and may need to be updated or even reversed.
  在团队讨论体系结构决策时使用录音和听录工具，并总结这些讨论。这可以在未来架构决策受到挑战并且可能需要更新甚至撤销时提供背景信息。
• Turning text into architectural diagrams and documenting existing diagrams.
  将文本转换为架构图并记录现有图。
• Producing standard code documentation, such as API descriptions.
  生成标准代码文档，例如 API 描述。
• Updating design documentation to reflect what got implemented, and flagging areas of the implementation that deviate from the design. Sometimes the implementation corrects flaws in the design, but sometimes it drifts away from the design. Both are useful to know.
  更新设计文档以反映实现的内容，并标记偏离设计的实现区域。有时实现会纠正设计中的缺陷，但有时它会偏离设计。了解两者都很有用。

Understand interfaces to other systems
了解与其他系统的接口

MVP implementations nearly always rely on other systems; no team ever starts completely from scratch. Because of this, they can spend considerable time understanding the interfaces provided by those systems, especially when those interfaces are poorly documented. If these systems were created a few decades ago and written in an old language, such as COBOL that few people can still understand and use, this task may be almost impossible.
MVP 实现几乎总是依赖于其他系统;没有一个团队会完全从头开始。因此，他们可能会花费大量时间来了解这些系统提供的接口，尤其是当这些接口的文档记录不佳时。如果这些系统是几十年前创建的，并且是用一种古老的语言编写的，比如 COBOL，很少有人能理解和使用，那么这项任务可能几乎是不可能的。

When developing an MVP, teams never have time to do this. AI can help with this by scanning code and producing documentation, such as a description of the APIs of existing systems, including some old and poorly maintained ones. AI can also help document potentially overlooked dependencies between systems, such as when one system calls another through an undocumented interface or implicitly through shared data. This improves the quality of the MVA and the chances of success of the MVP.
在开发 MVP 时，团队永远没有时间这样做。人工智能可以通过扫描代码和生成文档来帮助解决这个问题，例如对现有系统的 API 的描述，包括一些旧的和维护不善的系统。人工智能还可以帮助记录系统之间可能被忽视的依赖关系，例如当一个系统通过未记录的接口或隐式地通过共享数据调用另一个系统时。这提高了 MVA 的质量和 MVP 的成功机会。

Understand and manage the technical debt of the system
了解和管理系统的技术债务

Effectively managing technical debt is critical for a sustainable system. Reducing technical debt itself is an inherently challenging trade-off and one that many organizations fail to manage. They are under constant pressure to increase the functionality in each successive, incremental MVP, but in doing so they also usually compound the technical debt related to the associated MVAs.
有效管理技术债务对于可持续的系统至关重要。 减少技术债务 本身本质上是一种具有挑战性的权衡，也是许多组织无法管理的权衡。他们一直面临着增加每个连续增量 MVP 中功能的功能的压力，但这样做通常也会加剧与相关 MVA 相关的技术债务。

AI may help to identify possible areas of the code that may increase technical debt but, because technical debt results from decision trade-offs made in the past, AI can only identify the most obvious instances of poor quality code that may need improvement, and it can’t make the decision trade-offs needed to effectively reduce or eliminate the major sources of technical debt.
人工智能 可能 有助于识别代码中可能增加技术债务的领域，但是，由于技术债务是由过去做出的决策权衡产生的，因此人工智能只能识别可能需要改进的最明显的低质量代码实例，并且无法做出有效减少或消除技术债务主要来源所需的决策权衡。

Conversely, when making a new decision, the AI can help summarize the technical debt associated with the decision and how it differs from other options considered. If teams get better at documenting technical debt that is incurred (through ADRs) they can use that documentation to help drive future decisions about "paying down" the tech debt. That documentation can include the examples provided to the LLM for future decisions.
相反，在做出新决策时，人工智能可以帮助总结与决策相关的技术债务，以及它与所考虑的其他选项有何不同。如果团队更好地记录（通过 ADR）产生的技术债务，他们可以使用该文档来帮助推动未来有关“偿还”技术债务的决策。该文档可以包括提供给 LLM 的示例，以供将来做出决策。

Again, providing as much context as possible in the prompt will ensure that the LLM delivers relevant information. For example, the team could provide known examples of technical debt, such as using a synchronous API as a temporary solution instead of using an asynchronous interface as specified.
同样，在提示中提供尽可能多的上下文将确保 LLM 提供相关信息。例如，团队可以提供已知的技术债务示例，例如使用同步 API 作为临时解决方案，而不是使用指定的异步接口。

Implement feedback loops
实现反馈循环

Experimentation, as already discussed, provides one kind of feedback that teams can use to improve the architecture of their systems. AI can also help them in other ways, by helping them evaluate their decisions through testing, architecture reviews, and automated code reviews. AI may help generate automated tests and also help the team by performing automated code reviews to flag issues that are then evaluated by the team.
如前所述，实验提供了一种反馈，团队可以使用这些反馈来改进其系统的体系结构。人工智能还可以通过测试、架构审查和自动代码审查帮助他们评估自己的决策，从而以其他方式帮助他们。人工智能可以帮助生成自动化测试，还可以通过执行自动代码审查来标记问题来帮助团队，然后由团队进行评估。

Risk identification and mitigation
风险识别和缓解

The architectural risks for a system are unique to its context. Similar to the way it can help with understanding QARs, AI can provide a generic checklist of risks and mitigations, but it can’t predict whether your system will experience them. This can be useful for brainstorming a list of potential risks for a system, provided that you give relevant details to the AI. This may require the team to have a conversation about risks that leads them to make better decisions.
系统的体系结构风险因其上下文而异。与帮助理解 QAR 的方式类似，人工智能可以提供风险和缓解措施的通用清单，但它无法预测您的系统是否会遇到它们。这对于集思广益系统潜在风险列表非常有用，前提是您向 AI 提供相关详细信息。这可能需要团队就风险进行对话，以引导他们做出更好的决策。

Conclusion  结论

While software architects won’t be replaced by AI, they do need to learn how and where they can use AI to make better decisions and achieve better trade-offs. Looking at the work that software architects perform provides insights into where and how AI can help. Focusing on how it helps teams produce an MVP further focuses on how AI can help: it enables teams to relax some of the constraints they face in developing a sustainable architecture while still meeting the time constraints of the MVP. This frees teams to discover more creative solutions to meet architectural challenges.
虽然软件架构师不会被人工智能取代，但他们确实需要学习如何以及在何处使用人工智能来做出更好的决策并实现更好的权衡。查看软件架构师执行的工作可以深入了解 AI 可以在何处以及如何提供帮助。关注它如何帮助团队产生 MVP，进一步关注 AI 如何提供帮助：它使团队能够放松他们在开发可持续架构时面临的一些限制，同时仍然满足 MVP 的时间限制。这使团队能够自由地发现更具创造性的解决方案来应对架构挑战。

About the Authors  关于作者

Pierre Pureur  皮埃尔·普勒尔

Pierre Pureur is an experienced software architect, with extensive innovation and application development background, vast exposure to the financial services industry, broad consulting experience and comprehensive technology infrastructure knowledge. His past roles include serving as Chief Enterprise Architect for a major financial services company, leading large architecture teams, managing large-scale concurrent application development projects and directing innovation initiatives, as well as developing strategies and business plans. He is coauthor of the books "Continuous Architecture in Practice: Scalable Software Architecture in the Age of Agility and DevOps"(2021) and "Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World" (2015) and has published many articles and presented at multiple software architecture conferences on this topic. 

Show moreShow less
Pierre Pureur 是一位经验丰富的软件架构师，拥有广泛的创新和应用程序开发背景、广泛的金融服务行业经验、广泛的咨询经验和全面的技术基础设施知识。他过去的职位包括担任一家大型金融服务公司的首席企业架构师、领导大型架构团队、管理大规模并发应用程序开发项目和指导创新计划，以及制定战略和业务计划。他是《实践中的持续架构：敏捷和 DevOps 时代的可扩展软件架构》（2021 年）和《持续架构：敏捷和以云为中心的世界中的可持续架构》（2015 年）一书的合著者，并发表了许多文章，并在多个软件架构会议上就该主题发表了演讲。显示更多

Kurt Bittner  库尔特·比特纳

Kurt Bittner has more than 30 years of experience delivering working software in short, feedback-driven cycles. He has helped a wide variety of organizations adopt agile software delivery practices, including large banking, insurance, manufacturing, and retail organizations, as well as large government agencies. He has worked for or with large software delivery organizations including Oracle, HP, IBM, and Microsoft. He is also former technology industry analyst with Forrester Research, and has written widely on topics related to agile teaming and leadership.

Show moreShow less
Kurt Bittner 拥有 30 多年的经验，在短时间内交付反馈驱动的周期内提供工作软件。他帮助各种组织采用敏捷软件交付实践，包括大型银行、保险、制造和零售组织，以及大型政府机构。他曾在甲骨文、惠普、IBM 和 Microsoft 等大型软件交付组织工作或与之合作。他还是 Forrester Research 的前技术行业分析师，并撰写了大量与敏捷团队和领导力相关的主题的文章。显示更多