引言
从代码生成到自动化文档，人工智能已经开始渗透到软件开发生命周期的几乎每个阶段。但除了炒作之外，实际上发生了什么变化？我们询问了一群工程师、架构师和技术领导者，AI 辅助工具的兴起如何重塑软件开发的既定节奏，以及他们在现实世界中采用 AI 后学到了什么。
讨论嘉宾
Mariia Bulycheva——Intapp 高级机器学习工程师
Phil Calçado——Outropy 首席执行官
Andreas Kollegger——Neo4j 高级开发者倡导者
May Walter——Hud.io 创始人、首席技术官
InfoQ：AI 辅助工具的兴起对你们组织的软件开发过程有何影响？它们是否改变了你们对软件架构的思考方式？
Mariia Bulycheva：AI 辅助工具加速了原型设计，并减少了在重复编码任务上花费的时间，使我们的团队能够更多地关注架构决策和设计复杂的在线实验，这对于大规模迭代改进复杂的推荐系统至关重要。从数字平台典型的大量多模态数据中获得初步洞察也变得更快、更顺畅、更一致，因为我们可以将初始数据分析委托给了 AI。
我们工作的另一个非常重要的方面是跟上我们领域科学发展的快速步伐。每年，在顶级会议上都会发表数千篇新的研究论文，过去阅读它们并确定哪些可能与我们团队的日常 ML 任务相关是非常耗时的。今天，AI 工具提供了高质量的摘要，甚至突出显示哪些方法可能适用于我们的用例。这已经导致了几个新建模想法的快速实现，否则我们可能需要花费数周甚至数月的时间来发现和测试。
Phil Calçado：绝对有。我们运行的是一个消费者参与平台，其功能之多，任何正常人都无法全部记住。例如，最近，我们需要改变我们处理时区的调度方式。代码变更本身可能只有 10 行，但真正的工作是深入数百个涉及调度的地方，弄清楚每个地方的假设，并添加单元测试以断言调用站点不会中断，而是行为的变化。我们原以为这将是一个为期六个月的项目，因为我们需要逐步研究并进行小的更改。
有了像 Cursor 和 Claude Code 这样的工具，我们大大缩短了这个时间。它们帮助我们找出所有受影响的位置，为每个位置生成单元测试，并将推出分成按子系统分组的小 PR。每个 PR 都带有对所属团队的上下文敏感的描述——不仅仅是“修复调度，请审查”，而是解释为什么以及在他们的世界中预期的影响。
因此，尽管我们像其他人一样看到了原始代码输出的增加，但在我们这样成熟的、超大规模的系统中，最大的提升在于 AI 如何帮助我们研究自己的代码库，将无聊但必不可少的安全检查整合在一起，使系统性变更变得不那么可怕。
Andreas Kollegger：在我们组织中，所有员工现在都可以使用 AI 辅助工具。对于表面层级的界面设计，这些工具帮助我们更快地迭代，探索新想法，并解锁新方法，如氛围编码，专注于更高层次的设计和策略。
但我们也确实遇到了 AI 的局限性。像许多组织一样，我们发现大语言模型（LLM）在需要深厚领域专业知识和全局架构整体视图的高度专业化代码上挣扎。我们的代码库本身就超过了任何 LLM 上下文窗口的容量，而这些模型本身也没有在其中的独特复杂性上进行训练。简而言之，AI 不能发明它不理解的东西。因此，我们有意采取了一种以人为中心的方法：虽然 AI 帮助我们加速和增强，但推动软件架构突破的是我们工程师的专业知识。
May Walter：AI 辅助工具极大地缩短了从想法到工作代码的路径。一旦意图明确，迭代周期就会显著缩短。开发人员正在从代码的唯一作者转变为更像是管理者的角色——指导代理，验证输出，并确保需求得到真正满足。
AI 之前，架构是关于团队之间的所有权和可扩展接口。这引入了一个新的维度：上下文架构——设计代理生成生产就绪代码所需的输入、脚手架和护栏。上下文工程正在成为系统的核心部分，它简化了在复杂环境中快速构建的能力，如分布式和基于事件的系统。
但速度带来了一个新的瓶颈：为生产准备 AI 生成的变更。即使审查有了 AI 辅助，挑战也不再是关于发现语法错误，而是在大型、大规模的系统中验证意想不到的后果。
InfoQ：人工智能的采用如何影响团队内部的入职流程？你们团队或组织中的初级开发人员是否受到软件开发过程中采用人工智能的影响？
Mariia Bulycheva：人工智能工具可以通过提供即时的代码示例、文档摘要和测试建议，显著加快学习过程，这些都支持了初级开发人员。在处理个性化和推荐系统等复杂领域的团队中，这一点尤其有用，因为现在初级人员可以更快地探索新的代码库，而不必总是依赖高级工程师。同时，我们将他们与更有经验的同事配对，以确保他们学习潜在的基本建模和系统设计原则，而不仅仅是捷径。
Phil calado：我们刚刚让暑期实习生展示了他们的项目，几乎每个人都把人工智能称为救星。进入一个有 10 年历史的 Rails 代码库，其中包含数千个可移动的部分，这是令人生畏的。但是能够对 Cursor 或 Claude Code 说，“我是一名懂 Python 和 C++的大三学生，请用我熟悉的方式解释这个 Rails 代码”，这意味着他们可以在几周内提高效率，而不是仅仅把时间花在弄清楚基础知识上。
而且，不仅仅是实习生。在这个庞大的系统中，即使是高级工程师也需要比在小公司更多的准备时间。AI 并没有消除对系统的实际理解，但它确实减轻了“我们在哪里处理认证？”或“我们是否已经有了观察者模式的实现？”这类问题的压力。
当然，这里有一个问题。生成式 AI 擅长复制模式，这通常意味着我们不希望再看到的遗留风格和架构。因此，我们不得不适应。我们正在使我们的工作流程和架构更加适应 AI，并且我们已经开始将当前的指导方针直接嵌入到 Claude Code 和 Cursor 的智能体中。这样，当 AI 提供帮助时，它会引导人们走向现在，而不是过去。
Andreas Kollegger：人工智能的采用增强了我们的入职流程，特别是对于新接触图数据库的初级开发人员。虽然人工智能不能取代经验丰富的导师的指导，但它通过帮助新员工更快地上手，补充了我们现有的入职资源。
入职培训不仅仅是教授编码技能。它是关于建立领域专业知识的。编码能力很重要，但更重要的是理解要编写什么代码以及为什么。这就是为什么我们的入职开发人员，他们对代码库及其架构有深入的了解，在向初级团队成员传授专业知识和上下文方面发挥着关键作用。
May Walter：人工智能降低了贡献的障碍。现在，一个新开发人员可以在他们的第一天就写出可用的代码——这与早期工作仅限于样板或错误修复的日子相比，是一个戏剧性的转变。但真正的机会不在于速度；而是在于能力和范围的深度。
我最常听到的担忧是，人工智能有使入职变得肤浅的风险——初级人员可以在不理解代码为何以某种方式行为的情况下生成代码。我的经验恰恰相反。当代码生成与运行时反馈配对时，初级开发人员从一开始就接触到系统思维：架构在负载下的行为如何，依赖项如何相互作用，以及变化如何波及到业务结果。工程师成为智能体代码生成过程中的业务大使。
他们不再需要花几个月的时间来处理低价值的工作，而是能够处理团队的更多任务。如果做得好，这不会跳过步骤——它会加速步骤。有了正确的文化和期望设定，初级工程师可以更快地发展成为全面发展的工程师，因为他们不仅学习如何编写代码，还学习了为什么它在系统环境中很重要。
InfoQ：在你们团队或组织中，你们是否测量过 AI 辅助开发对生产力或质量的影响？你们学到了什么？
Mariia Bulycheva：我们在样板代码和单元测试生成方面看到了明显的生产力提升，甚至在为推荐系统设置模拟实验方面也是如此。然而，当处理影响大规模客户体验的关键系统时，真正的好处来自于将 AI 辅助与深度工程师参与结合起来。我们了解到，虽然 AI 提高了生产力，但质量仍然取决于仔细验证和清晰的指标和测试。
Phil Calçado:：没有正式的测量。坦率地说，我不相信大多数抛出的“生产力”数字。在软件领域，你可以操纵指标，直到它们说出你想要的任何东西，而 AI 的炒作周期使这变得更糟。事实上，人们再次认真计算代码行数，只是为了增加一轮融资或提高股价，这是令人尴尬的。
Andreas Kollegger：在前端方面，我们看到了生产力的提升，特别是对于那些使用 Cursor 等工具的工程师。我们的许多工程师已经使用 AI 支持来更快地理解、进行表面编码和测试我们的代码库，但我们从 AI 中看到的真正影响是对开发人员体验的影响。通过使用 AI 工具来支持他们的一些活动，我们的工程师现在有更多的时间发挥创造力，并最终改进他们解决问题的方式，并为他们的工作创造新的方法。
May Walter：是的，我们了解到的第一件事是，大多数常见的度量标准并没有太大意义。公认的代码行数、提交次数、PR：AI 可以立即夸大这些数字，但它们只是工程生产力的虚荣指标。
真正的信号存在于下游。发布稳定性、事故频率、随叫随到的时间，甚至代码变更率，都能告诉我们是否真的在加快速度，或者只是在制造更多的脆弱性。AI 将速度转移到了管道的前端，但除非验证循环紧密，否则债务会在后期显现——以缺陷、回归和精疲力竭的团队的形式。
从第一天开始，通过持续的生产反馈，我们可以看到真相所在：功能开发变得更快，但审查周期变得更长了，部署后的错误也出现了。
教训是，AI 生产力需要一个学习曲线和迭代方法。一旦度量，可以逐步改进采用，以捕捉优势——同时避免因快速交付但存在稳定性问题窒息的陷阱。
InfoQ：为了有效地使用 AI 工具，你们的团队或组织中有哪些非技术方面的东西需要改变？
Mariia Bulycheva：最大的变化是在心态上。团队必须从期望 AI 建议是“正确”的，转变为将它们视为需要彻底验证、讨论和测试的起点。这种文化转变鼓励了实验和跨学科合作，将对确定性的关注转变为对探索的关注。在大规模个性化工作中，我们还需要与产品和法律团队就负责任的数据使用和可复制性达成一致。这些协议创造了护栏，使工程师能够安全地探索和部署 AI 辅助解决方案。
Phil calado：我认为关于生成式 AI 工具的最大事情是：这超越了编码。是的，像任何其他工具一样，你必须注意副作用。生成式 AI 可以很容易地生成内容：代码、PR 评论、技术规范、电子邮件、Slack 消息。它也使得总结大量文本并过滤掉非必要的内容变得非常容易。
这两个特性的结合创造了一个奇怪的激励：人们生成了大量的低信噪比内容，然后其他人再次使用 AI 将其过滤回去。这是极其无效的。我们已经开始内部讨论在制作内容时正确使用 AI 的方式。剧透：这不是让 AI 为你写作，而是使用 AI 帮助你写得更好。
Andreas Kollegger：我们在 AI 的早期阶段建立了一个 AI 伦理委员会，组织中的代表们更好地理解和指导 AI 如何影响我们的业务的每一个方面。所有技术都可以成为一股善的力量，但它也需要有意识的思考、行动和指导。
因为我们信任客户数据，我们的开发人员需要在引入 AI 作为助手的任何领域都应用更高的敏感性，从简单的计划文件和电子邮件线程到代码库本身。随着我们采用、集成和扩展 AI，我们所有的开发人员都必须确保人类判断，而不是 AI，指导和监督每一步。
May Walter：最大的变化不是技术上的，而是文化上的。开发人员自然会单独采用工具，但当 AI 被视为个人生产力技巧时，它的效果并不好。只有当它成为共享流程的一部分，有一致的验证步骤和清晰的责任时，它才会有效。此外，AI 工具在缺乏上下文时不会失败，而是产生不准确的回应，这可能会损害用户的信任并增加变更的摩擦。
在 10 名工程师的情况下，每个人都可以以自己的方式进行实验。在 100 名工程师的情况下，这种方法就会崩溃。不同的智能体独立生成代码会造成分裂和风险。我们转向了共同的设置和共享的工作流程，这样 AI 不仅仅是帮助个人更快地移动，而是使整个团队更快地移动。
InfoQ：你们在管理 AI 辅助编码方面设置了哪些护栏（文化、道德或技术），以及你们如何管理个人、团队和组织对 AI 输出的信任问题？
Mariia Bulycheva：我们将 AI 输出视为重复性或样板任务的“初稿代码”，这些代码总是经过单元测试和同行评审。在文化方面，我们强调责任：提交代码的开发人员负责，无论是否有 AI 辅助。对于机器学习工作流程，我们不信任 AI 直接生成模型，相反，在任何模型更改甚至可以考虑用于生产之前，我们依赖于针对既定基线的自动离线评估。这确保了 AI 驱动的贡献达到了与人类编写的代码相同的质量标准。
Phil calado：这仍然是一个非常初级的实践，所以我们一直在尝试不同的护栏和工具。在安全和合规方面，我们的立场从一开始就很明确：作为一个处理世界上一些最大品牌数据的上市公司，我们必须将相同的治理实践应用于 AI 编码工具，就像我们其他地方所做的一样。几年前，这意味着落后于曲线，但今天大多数供应商都有坚实的企业计划，所以我们可以安全地使用最先进的模型，而不会妥协安全性或可审计性。
文化上，我们很早就设定了期望：仅仅因为一个 AI 工具编写了变更，并不意味着它不是你的代码。你仍然拥有它，你需要把每一行都当作是你自己打出来的一样。这与使用 IntelliJ 的提取方法重构没有什么不同，在这种情况下，它可能自动化了机械操作，但你仍然需要理解并验证结果。
Andreas Kollegger：大型企业软件可以提供防止 AI 生成错误的保障，但更高的准确性、上下文和可追溯性是使 AI 输出可解释和可验证的关键，而不仅仅是性能。这就是为什么我们引入了一个广泛的测试计划，涵盖了从单个单元测试到详尽的生产级验证的所有内容。
与此同时，我们的工程师在纪律和创新之间保持平衡至关重要。我们鼓励工程师尝试各种想法，探索可能尚未准备好投入生产的项目。这种环境允许快速迭代和创造力，同时确保只有最有价值和经过充分测试的创新才能过渡到生产。其结果是一种独特的平衡：保持客户的信任和稳定，同时不断推进图驱动的创新，使 AI 更准确、透明和可解释。
May Walter：我们必须赢得对 AI 输出的信任，而获得信任的唯一方法便是创造上下文。每个 AI 生成的变更都经历了与人类编写的代码相同的标准——审查、测试、验证——但有一个额外的要求：它必须在运行时证明自己。
对我们来说，信任不是来自对模型的信念；而是来自观察代码在现实世界条件下的行为。新版本的性能和旧版本一样吗？它是否引入了新的错误或在负载下改变了性能？当运行时上下文持续可用时，AI 就不再是黑盒。它变成了一个可以信任的伙伴，因为它与工程师依赖相同的信号进行推理。
InfoQ：你们认为软件开发团队低估了 AI 编码工具的哪些方面？你们认为有哪些当前的 AI 增强型开发工作流程或模型被过度炒作，哪些仍然没有得到充分利用？
Mariia Bulycheva：许多团队低估了上下文管理的重要性，因为 AI 的效果取决于你提供的上下文（代码库、文档、架构、在线测试的实验设置）。在大型系统中，这意味着不仅要管理代码片段，还要管理模型性能数据、日志和实验历史，以有效指导 AI 工具。过度炒作：AI 据说取代了工程判断的“一键式开发”。未充分利用：AI 辅助调试、实验设置和复杂 ML 工作流的文档记录，这可以大幅降低长期维护成本。
Phil Calçado：现在 AI 中有很多空洞的炒作，很难挑出一个罪魁祸首。但大多数团队都低估了的这一点是：AI 编码工具不是一个单程的魔法盒子。你不能只是向它们抛出一个提示，就期望得到一致、正确的结果。
这是任何真正构建 AI 产品的人都知道的痛苦教训。无论你的提示工程有多聪明，有效使用 LLMs 来自于结合工作流程并确保正确的上下文在正确的时间可用。否则，你只是在掷骰子。
我在以前为一个流行的代码审查工具构建 AI 管道时亲眼目睹了这一点。模型可能已经记住了所有写过的 Python 书籍，但如果你问 10 个开发人员“正确的方法”去做某事，你会得到 11 个答案。如果没有你的代码库、组织标准和实际目标的上下文，LLM 就不知道哪个适用。这就是为什么你会得到完全不同的解决方案，甚至是对立的——这取决于当你提问时，概率之神想要倾向于哪一边。
Andreas Kollegger：许多软件开发团队低估了 AI 编码工具可以简化开发人员最不喜欢的任务，比如编写测试和文档。虽然 AI 编码演示承诺低代码和无代码，通常看起来微不足道或不可靠，但它们展示了 AI 如何将自然语言和代码之间进行转换，这对于自动化繁琐的任务和重复的设置是理想的。类似地，有一种专门用于项目初始化和代码生成的编码工具。
有一种工作流程被夸大了，但却没有得到充分利用，那就是让编码智能体通宵运行，并在早上检查他们的工作。我不建议在无人监督的情况下重构新产品功能或大量代码，但编码智能体非常适合一个定义良好的 GitHub 问题，它有良好的讨论，一个孤立且可重现的例子，以及一个可测试的修复。
May Walter：大多数团队低估的是，模型已经足够好（并且正在变得更好）——缺失的成分是组织上下文。等待“更好的模型”是一种分心。真正的挑战是设计提供生成生产级代码所需的上下文的系统：你的架构、编码标准、数据边界和业务优先事项。如果没有这些，即使是最好的模型（或工程师）也会表现不佳。
另一方面，今天被过度炒作的是原始代码生成和静态代码审查。这些工作流程在演示中看起来令人印象深刻，但它们并没有解决大型组织中软件工程最难的部分：调试和质量保证。智能体仍然缺乏运行时上下文，并且很少有工具来评估哪些更改在业务影响方面真正关键。
这个差距很重要，因为更快的代码生成意味着更多的更改流入生产环境——而且没有更强大的流程来决定要监控什么，团队冒着为了脆弱性而牺牲速度的风险。未充分利用的前沿不是更快地编写代码，而是构建验证循环和运行时感知工具，以在这些更改部署之前增加确定性。
结论
从这次讨论中得出的第一个，也许是最重要的结论是，尽管在软件开发过程中采用 AI 工具无疑降低了贡献的门槛，但它仍然是一个乘数，而不是灵丹妙药。只有与强大的组织环境相结合，AI 才能增强生产力。基于 AI 的工程有潜力成为软件开发的核心，就像 CI/CD 管道曾经一样。然而，架构、编码标准和实验脚手架是成功采用 AI 的支撑支柱。
与此同时，随着 AI 工具的发展，组织中开发人员的角色也从代码作者转变为系统编排者。新采用的策划、验证和集成 AI 输出的过程并没有取代软件工程这门手艺；相反，它增强了它。批判性思维和架构意识比以往任何时候都更重要。
当然，采用任何新技术都会带来陷阱，对于 AI 和基于 AI 的工具也是如此。降低贡献的进入门槛也意味着增加了浅薄理解和生产次品代码的风险，这可能对初级开发人员的职业发展和整个组织产生负面影响。指导和运行时反馈是重要的护栏，以及文化和伦理保障：AI 输出必须被视为初稿，人类必须对其负责。当涉及到 AI 时，信任不是授予的：它是一个过程，通过测试、同行评审、运行时验证和透明度赢得。
成功的指标也必须重新思考，因为 AI 夸大了所有传统的生产力指标。有意义的信号来得更晚：稳定性、变动、事件，以及有多少时间可以释放给创造力和架构。将 AI 扩展视为一个协作过程，而不是个人生产力的提升，这需要协调的工作流程和对周围流程的更高成熟度。
无论好坏，很明显，AI 带来的变化已经到来，正在重塑软件开发的工艺。仍然有未被充分利用的方面，但上下文设计和运行时感知工具已经是下一个架构前沿。从长远来看，AI 竞赛的赢家将是那些将其整合到具有问责制、信任和能够以负责任的方式共同发展的团队级流程中的人。
原文链接：
https://www.infoq.com/articles/ai-developers-rewriting-software-process/
