生成AI将如何影响产品工程团队 — 第6部分 | 后记
这是一个由开发人员专用的生成AI生产力工具（如Github Copilot、ChatGPT和Amazon CodeWhisperer）如何影响整个产品工程团队结构的六部分系列的最后一部分。
在这最后一部分，我们将考虑之前文章中所忽略的许多复杂性，人工智能时代人工工程师的不可替代价值，并提出领导者需要反思、适应和创新的行动号召。
“之前的内容”
在这个系列的文章中，我们经历了一段相当长的旅程，我认为快速回顾一下我们在之前的五篇文章中所涵盖的内容是值得的，这样我们才能介绍到目前为止我们还没有涵盖的所有内容：
第1部分中，我们看到了证据表明像Copilot和ChatGPT这样的生成AI编码工具有可能显著提高技术角色人员（如工程师和数据科学家）的生产力。这些工具通过自动化繁琐、重复、耗时的任务改变了开发人员所需完成的工作。理论上，它消除了开发人员不喜欢的工作方面，使他们宝贵的工作变得更快、更容易。
第2部分中，我们考虑到开发人员任务的自动化程度提高和开发人员生产力的增加可能会导致产品团队中工程师与产品经理的比例发生重大变化；在过去，一个产品经理通常负责五名工程师，但有了生成AI工具，这个比例可能会接近1:1。
第3部分中，我们探讨了生成AI编码助手不仅具有协助重构代码或编写测试等基本功能的能力。我们还探讨了长期影响可能导致AI工具重构遗留代码，包括创建测试和文档，并简化一些团队结构，如移动应用开发，这些团队通常不是因为价值流分化，而仅仅是因为技术技能不同。我们还考虑了对初级工程师及其专业发展的可能影响。
第4部分中，我们考虑了这种变化如何使公司能够大幅减少工程师人数但保持同样的产出，或者在相同的预算下大幅提高产出，或者两者结合。我们开始模拟了在增长投资、预算维持或成本削减之间选择可能会对工程和产品人数产生的影响。
第5部分中，我们研究了这些优势可能以不同方式影响不同类型的公司。新创公司应尽快开始使用这些新工具。较大的公司，他们有最大的财务动力来转变团队结构，将因文化惯性而难以适应，但应鼓励他们开始尝试这些工具，并根据自己的战略决策来采纳它们。我们还看到了“人肉外包”外包公司最有可能受到负面影响，因为客户会尽量保留内部员工并在其他地方节约成本。
到目前为止，我们所讨论的一切都围绕着假设“下一代产品工程团队可能会有更少的工程师”展开，但我认为我们远未证明或证伪这个假设。
“是的，但是……”
现在，我想回答我在过去几个月的讨论中所接收到的许多发人深省的挑战，以及我在原始假设的服务中所做的大量假设。
我留下了许多潜在的反驳意见未加以回应，不是因为它们没有困扰我，而是因为在使用这些工具进行实验并看到它们如何真正协助团队方面，还有太多的不确定性和工作要做。
下面是许多批评和未回答问题的大列表：
你对AI工具写出高质量代码抱有很大的信心。它们不可能和人类一样好。
我承认，我对这些工具的质量印象深刻，但我也不是试图证明它们需要像优秀的开发人员一样出色。我有意避免了没有技术专长的场景，因为根据我的经验，使用这些工具仍然需要大量的监督和指导。监督是为了确保它们不会做出任何愚蠢或危险的事情（比如将API密钥写入源代码），指导是为了确保它们做正确的事情（使用正确的语言、框架或设计模式）。
我有一种感觉，这些人工智能工具需要成为软件工程的麦当劳；尽管去一家非连锁餐厅，享受非凡的服务，可能是一种超然的体验，但这并不总是可能的。麦当劳普遍干净、便宜、健康（我的意思是不会被细菌感染），而且最重要的是一致的。正如我最亲爱的意大利朋友在面对一家大连锁披萨外卖时所说的：“它不会害死你。” 在某种程度上，这就是我们在追求人工智能工具的标准。
但是，我也不认为这就是故事的终结。我们今天看到的工具远远没有达到未来一年内的质量水平。即使我将原始文章编辑成这个系列，每天都有关于更多改进的消息；加州大学伯克利分校推出了一个模型，它能比GPT4更好地编写API调用。微软宣布了“扩张关注”，使模型能够通过LongNet扩展到数十亿个令牌。StackOverflow宣布了OverflowAI，承诺对愚蠢问题做出更多尖锐的回答（对不起，我的意思是更好和更有用的搜索）。
即使您对现在的工具能力持怀疑态度，忽视它们可能发展的潜力将是一种短视行为。
[编辑：即使在我初稿此文的一周左右时间里，Stack Overflow宣布了OverflowAI，Github宣布了额外的工具以防止知识产权问题，StabilityAI宣布了针对编码的LLM。市场的变化速度惊人]
人工智能工具将面临知识产权问题、安全问题，如果它们停止工作，我们将无法再工作
是的，这些都是可能的。
但是，这不是我们第一次解决此类问题，并且我们已经有了缓解这些问题的方法。我与很多公司进行交流时发现，他们都有一些疑虑，担心泄露公司机密会被用来进一步训练LLM。虽然对于免费和个人订阅来说可能是真的，但我强烈建议您，亲爱的读者，自己对大型供应商进行调查，了解使用他们的风险以及供应商对这个非常合理的担忧所采取的措施。看看一些大公司的常见问题解答，看看它们是否对您的使用情况和风险配置提供了足够好的答案：OpenAI、Github Copilot、AWS CodeWhisperer（Google Duet仍处于封闭测试阶段，没有提供数据安全文档）。
安全和数据保护也是类似的情况。今天大多数人已经依赖于Github、Microsoft或AWS的安全性。您可能要么将代码存储在Github上，要么将应用程序或数据存储在Azure、GCP或Amazon上。问问自己为什么对于超级云供应商的风险您可以接受，但对于一个编码工具就不能接受。使用ChatGPT的风险是不可忽视的，五月份有泄露数据的报道，本周有可能被越狱的消息，以及云安全供应商Netskope报告的内部用户持续数据泄露。与任何其他技术一样，您可以选择简单地禁止它在您的组织中的使用，但人们总能找到办法。要真正解决安全问题，您需要教育用户并提供安全易用的替代方案。如果OpenAI无法胜任，也许其他供应商可以。
另一个担心是意外暴露知识产权风险；例如，模型被（“无意间”？）训练了闭源材料，而工具暴露了您的组织面临违法（并承担补救违约风险）的风险，仅仅使用了这个工具。不幸的消息是，如果您认为这是一种新风险，您可能应该更仔细地审视一下您在组织中使用开源的情况。许多公司在正确管理和了解他们的软件所涉及的闭源和开源依赖风险方面远远不够。您当然应该关注这些工具中的任何一个可能会意外使您违反他人的知识产权，但您应该扩展您已经为开源软件和开发人员的大红色剪贴板使用的控制措施。
这些风险是您自己的，如果您真的认真考虑这些工具可能提供的机会，您还应该阅读文档并与供应商讨论他们正在采取的措施来保护您免受这些风险的影响。确保您做好功课。Copilot的Common Sense隐私报告给出了63%的分数，低到足以获得“黄色”警告（在“学校”和“家长同意”方面得分特别低，拖累了它的分数）。
这应该始终是您的采购流程的一部分。您应该始终从风险的角度考虑您将要接近生产代码或数据的任何工具，并由您决定您对风险的接受程度以及如何减轻风险。
更积极的一点是，我认为Salesforce最近的公告是这些工具发展方向的良好指示。Salesforce在AI Day的营销推广主要集中在他们所称之为“Einstein Trust Layer”的内容上，这似乎是一个真正令人印象深刻的包装器，用于保护客户和公司信息的访问安全（真的，即使它不是关于代码的，请查看这个视频）。
我们刚刚看到七家主要的科技公司（亚马逊、Anthropic、谷歌、Inflection、Meta、Microsoft和OpenAI）签署了自愿的“负责任的AI”承诺，其中包括对输出进行水印处理。可以合理地假设，这个市场上最大的参与者，大多数已经是我们信任并委托大量数据和基础设施的公司，将发布类似的信任和安全包装器，回答了许多有关知识产权、安全性、隐私和LLMs与真实性之间关系不明确的问题。
仍然需要有人来设计整体解决方案。
另请参阅：
- 某人将需要管理所有数据和数据管道
- 某人将需要管理应用程序之间的重叠
- 某人将需要保护产品
- 某人将需要监控和响应问题
- 某人将需要管理团队和产品之间的依赖和交互
是的，你说得对。还有很多工作需要完成，不仅仅是编写代码。
这太棒了！
这意味着我们仍然需要一段时间的人来完成这些工作，并开始向我们展示应该为我们的工程师提供培训的方向。但我们也应该期望工具、自动化和经过更好测试、质量更高的代码将对这些问题产生积极的影响。通过更多的文档、更少的“聪明”代码、更干净的接口、更好的可解释性和更好的测试覆盖率，我们可能会减少这些类型的挑战。
但大多数工程师的时间实际上并没有用在编写代码上，因为我们不断被告知参加愚蠢的会议
是的，没错。AI并不能解决所有问题，但如果你是一个花费更多时间参加会议而不是编写代码的工程师，问题不在于你的生产力，而在于你的组织管理方式。
也许AI有一天会解决这个问题，但在短期内，更小、更精简、更自动化的组织可能不需要那么多会议。
坦率地说，对于大多数组织来说，提高开发人员的生产力最好的方法是更好地优先处理工作，对低价值结果说“不”，并给团队更多的时间专注于提供高质量的产品。但如果我们做不到这一点，也许我们可以用AI编码助手来代替。
我们不能用AI代替产品经理吗？
啊，这是个好问题。
这些文章已经收到的一个令人惊讶的反馈是：“这真的很有趣，但在我们的业务中，我们几乎没有足够的产品支持”。事实证明，通过我的5:1的工程师比例，我展示了一种无意识的偏见，而许多技术团队已经面临巨大的困境，因为他们的比例不仅比这个高得多（比如10:1或更高），而且组织中对产品技能的重视程度也不够高。一些公司似乎仍然认为工程师只是编写代码，而产品经理是一种昂贵的奢侈品。
我认为从客户那里获取需求是一件非常重要的事情。我也认为进行有效且易于理解的商业优先级处理过程非常困难。在软件开发领域，要让利益相关方自己进行提示设计还需要一段时间。
产品经理对于优秀的产品工程至关重要。产品经理关注工程资源，帮助业务确定最有价值的结果。我认为我们现在最不需要的是减少产品支持，即使我们可以通过自动化来协助他们的日常任务。
我的猜想是，产品经理和技术负责人的角色将是这些新团队中最关键的。
你还没有考虑过X或Y或Z
你几乎肯定是对的。但如果你已经考虑过了，那太好了！给我留个评论，展开讨论，或者最好写一篇新文章来解释你对Y或Z的想法。（但不是X。我们不再谈论X）
让我们总结一下
整个系列文章的目的是出于一个担忧：今天，我感到不够多的产品和技术领导人在讨论如果生成式AI编码工具的承诺实现，他们的团队可能会发生什么。我们不仅仅是在谈论对开发者生产力的小幅提升。可能会发生产品创建方式的改变。
如果我们所讨论的一些事情是真实的，那么构建软件的团队很可能会有与今天截然不同的资源配置，对产品和技术人员预算产生重大影响。整个行业都面临着颠覆的风险，特别是开发者角色减少。
尽管公司可能通过寻求更多的结果来缓解这一问题，但企业能够支持的价值流有限。那些仔细而果断地理解和接受即将发生的变化的公司，可能会获得重大竞争优势。
这个论点还有一个哲学方面。我相信人类工程师可能具有无法言喻和不可替代的价值，但我无法准确地告诉你它是什么。
我们知道开发者编写代码，我们可以根据他们编写代码的速度和代码的有效性来评估他们的价值。但这种说法无法完全理解工程师的真正工作。多年来，可以轻易证明熟练的人类工程师能够做到算法无法做到的事情，但现在不再是这样。如果人类和机器之间的区别仅仅在于可以创建的解决方案的复杂性，那么我们正处于危险的摇摆之中。正如我之前写的：
工程师不仅仅学习如何编码，他们还学习如何思考。
作为一个行业，我们必须认识到新一代工具能够轻松复制广泛的工程任务。在这样做的同时，我们也应该明白，人类仍然拥有一些不容易复制的独特技能。作为领导者，我们的工作是识别出这些技能，并投资于人才优化。
这篇文章是一个行动的呼吁。如果你是一个产品或技术领导者，你应该将这看作是一个考验，考虑一下生成式AI工具对你的团队将产生什么影响，并让你的团队参与回答这个问题。
给他们时间和空间来考虑这些工具将如何帮助他们，最有可能带来创新的源泉将是你的团队自身。但作为领导者，你也需要承认，那些不愿意为圣诞节投票的人可能会有些不情愿。由于就业的真实威胁，人们可能感到害怕和不愿参与，你需要利用他们的才能帮助你了解是否应该削减预算。做老板是很难的，但如果你不如你的竞争对手那样果断和坚决，那就没有其他选择了。
我们应该清楚，最有趣、混乱、无规律、有影响力和令人兴奋的进展将出现在那些小型初创公司以及科技行业之外的团队中。不要忽视你自己组织中的非技术人员，或者创业社区中的小公司正在做的事情。
首先要教育自己，然后教育你自己企业内部的其他人，了解风险的真正情况。通过在你的企业内部寻找对技术变革持有好奇心的早期采用者，以及关注科技巨头和小型初创公司的行动，来考虑机会。要意识到这些进步有可能从根本上改变你的产品工程，然后走出去，保持好奇心，提问，并鼓励你的团队做同样的事情。
我尚未能够证明自己的假设是错误的，但现在我请求你的帮助来设计这个实验。
系列文章的其他部分：
- 第1部分
- 第2部分
- 第3部分
- 第4部分
- 第5部分
附言：如果您喜欢这些关于团队的文章，请关注我的Teamcraft播客，我和我的合作伙伴Andrew Maclaren会和嘉宾们聊聊团队成功的要素。