讨论AI原生团队与传统团队差异，强调工程师扩展角色

AI原生软件工程团队的运作方式与传统团队截然不同。明显的区别在于，AI原生团队使用编码代理来更快地构建产品，但这导致我们在运作方式上的许多其他变化。例如，一些优秀的工程师现在扮演着比编写代码更广泛的角色。他们部分地是产品经理、设计师，有时甚至是市场人员。此外，在同一办公室工作的小团队，能够面对面沟通，可以极其迅速地行动。

因为我们现在可以快速构建，更大比例的时间必须花在决定要构建什么上。为了解决这个项目管理瓶颈，一些团队正在将工程师与产品经理（PM）的比例从例如8:1降低到低至1:1。但我们还能做得更好：如果有一位PM决定构建什么，一位工程师负责构建，那么他们之间的沟通就会成为瓶颈。这就是为什么我见过的最快团队往往拥有既懂产品工作（可选地，也有一些懂工程工作的PM）的工程师。当工程师理解用户并能决定构建什么并直接构建时，他们就能极其迅速地执行。

我见过工程师成功扩展他们的角色以包括产品决策，PM扩展他们的角色以构建软件。科技行业工程师多于PM，但两者都是有前途的道路。如果你是工程师，你会学到一些产品管理技能很有用；如果你是PM，请学习构建！

除了产品管理瓶颈，我还看到设计、市场、法律合规等方面的瓶颈。当我们把编码速度提高10倍或100倍时，其他一切相比之下都变慢了。例如，我的一些团队如此迅速地构建了很棒的功能，以至于市场组织手忙脚乱地想办法与用户沟通——这是一个市场瓶颈。或者当一个团队可以在一天内构建软件，而法律部门需要一周来审查时，这就是法律合规瓶颈。由此可见，代理编码不仅改变了软件工程的工作流程，也改变了其周围的所有团队。

当更小的AI赋能团队能完成更多工作时，通才脱颖而出。传统公司需要汇集许多专业领域的人——工程、产品管理、设计、市场、法律等——来执行项目并创造价值。这导致了由专家组成的大团队共同工作。但如果一个两人团队要完成需要五个不同专业领域的工作，那么其中一些人就必须在单一专业领域之外扮演角色。在一些小团队中，个人确实有深度专业化。例如，一人可能是优秀的工程师，另一人是优秀的PM。但他们也理解推进项目所需的其他关键职能，并能根据需要参与思考其他类型的问题。当然，熟练使用AI工具大有裨益，因为它帮助我们思考涉及不同角色的问题。

即使在两人团队中，为了快速行动，也必须最小化沟通瓶颈。这就是为什么我重视在同一地点工作的团队。远程团队也能表现良好，但最高速度是通过让所有人在同一房间，能够即时沟通解决问题来实现的。

这篇文章聚焦于大约2-10人的AI原生团队，但并非所有事情都能由小团队完成。我将在未来讨论更大团队的协调。

我意识到这些对工作角色的转变对许多人来说难以应对。同时，我受到鼓舞的是，愿意学习相关技能的个人和小团队现在能够完成比以前多得多的任务。这是学习和构建的黄金时代！

[原文：
https://
deeplearning.ai/the-batch/iss