【EN】AI-Native Engineering Teams vs. Traditional Teams
原文 | Original
AI-native software engineering teams operate very differently than traditional teams. The obvious difference is that AI-native teams use coding agents to build products much faster, but this leads to many other changes in how we operate.
For example, some great engineers now play broader roles than just writing code. They are partly product managers, designers, sometimes marketers. Further, small teams who work in the same office, where they can communicate face-to-face, can move incredibly quickly.
Because we can now build fast, a greater fraction of time must be spent deciding what to build. To deal with this project-management bottleneck, some teams are pushing engineer:product manager (PM) ratios downward from, say, 8:1 to as low as 1:1. But we can do even better: If we have one PM who decides what to build and one engineer who builds it, the communication between them becomes a bottleneck. This is why the fastest-moving teams I see tend to have engineers who know how to do some product work (and, optionally, some PMs who know how to do some engineering work). When an engineer understands users and can make decisions on what to build and build it directly, they can execute incredibly quickly.
I've seen engineers successfully expand their roles to including making product decisions, and PMs expand their roles to building software. The tech industry has more engineers than PMs, but both are promising paths. If you are an engineer, you'll find it useful to learn some product management skills, and if you're a PM, please learn to build!
Looking beyond the product-management bottleneck, I also see bottlenecks in design, marketing, legal compliance, and much more. When we speed up coding 10x or 100x, everything else becomes slow in comparison. For example, some of my teams have built great features so quickly that the marketing organization was left scrambling to figure out how to communicate them to users — a marketing bottleneck. Or when a team can build software in a day that the legal department needs a week to review, that's a legal compliance bottleneck. In this way, agentic coding isn't just changing the workflow of software engineering, it's also changing all the teams around it.
When smaller, AI-enabled teams can get more done, generalists excel. Traditional companies need to pull together people from many specialties — engineering, product management, design, marketing, legal, etc. — to execute projects and create value. This has resulted in large teams of specialists who work together. But if a team of 2 persons is to get work done that require 5 different specialities, then some of those individuals must play roles outside a single speciality. In some small teams, individuals do have deep specializations. For example, one might be a great engineer and another a great PM. But they also understand the other key functions needed to move a project forward, and can jump into thinking through other kinds of problems as needed. Of course, proficiency with AI tools is a big help, since it helps us to think through problems that involve different roles.
Even in a two-person team, to move fast, communication bottlenecks also must be minimized. This is why I value teams that work in the same location. Remote teams can perform well too, but the highest speed is achieved by having everyone in the room, able to communicate instantaneously to solve problems.
This post focuses on AI-native teams with around 2-10 persons, but not everything can be done by a small team. I'll address the coordination of larger teams in the future.
I realize these shifts to job roles are tough to navigate for many people. At the same time, I am encouraged that individuals and small teams who are willing to learn the relevant skills are now able to get far more done than was possible before. This is the golden age of learning and building!
【中译】AI 原生工程团队 vs. 传统工程团队：本质差异全面解析
原文 | Original
AI-native software engineering teams operate very differently than traditional teams. The obvious difference is that AI-native teams use coding agents to build products much faster, but this leads to many other changes in how we operate.
For example, some great engineers now play broader roles than just writing code. They are partly product managers, designers, sometimes marketers. Further, small teams who work in the same office, where they can communicate face-to-face, can move incredibly quickly.
Because we can now build fast, a greater fraction of time must be spent deciding what to build. To deal with this project-management bottleneck, some teams are pushing engineer:product manager (PM) ratios downward from, say, 8:1 to as low as 1:1. But we can do even better: If we have one PM who decides what to build and one engineer who builds it, the communication between them becomes a bottleneck. This is why the fastest-moving teams I see tend to have engineers who know how to do some product work (and, optionally, some PMs who know how to do some engineering work). When an engineer understands users and can make decisions on what to build and build it directly, they can execute incredibly quickly.
I've seen engineers successfully expand their roles to including making product decisions, and PMs expand their roles to building software. The tech industry has more engineers than PMs, but both are promising paths. If you are an engineer, you'll find it useful to learn some product management skills, and if you're a PM, please learn to build!
Looking beyond the product-management bottleneck, I also see bottlenecks in design, marketing, legal compliance, and much more. When we speed up coding 10x or 100x, everything else becomes slow in comparison. For example, some of my teams have built great features so quickly that the marketing organization was left scrambling to figure out how to communicate them to users — a marketing bottleneck. Or when a team can build software in a day that the legal department needs a week to review, that's a legal compliance bottleneck. In this way, agentic coding isn't just changing the workflow of software engineering, it's also changing all the teams around it.
When smaller, AI-enabled teams can get more done, generalists excel. Traditional companies need to pull together people from many specialties — engineering, product management, design, marketing, legal, etc. — to execute projects and create value. This has resulted in large teams of specialists who work together. But if a team of 2 persons is to get work done that require 5 different specialities, then some of those individuals must play roles outside a single speciality. In some small teams, individuals do have deep specializations. For example, one might be a great engineer and another a great PM. But they also understand the other key functions needed to move a project forward, and can jump into thinking through other kinds of problems as needed. Of course, proficiency with AI tools is a big help, since it helps us to think through problems that involve different roles.
Even in a two-person team, to move fast, communication bottlenecks also must be minimized. This is why I value teams that work in the same location. Remote teams can perform well too, but the highest speed is achieved by having everyone in the room, able to communicate instantaneously to solve problems.
This post focuses on AI-native teams with around 2-10 persons, but not everything can be done by a small team. I'll address the coordination of larger teams in the future.
I realize these shifts to job roles are tough to navigate for many people. At the same time, I am encouraged that individuals and small teams who are willing to learn the relevant skills are now able to get far more done than was possible before. This is the golden age of learning and building!
中文翻译 | Chinese Translation
AI 原生软件工程团队的运作方式与传统团队有着本质不同。显而易见的区别是：AI 原生团队使用编程智能体来更快地构建产品，但这也带来了许多其他方面的变化。
例如，一些优秀的工程师现在扮演的角色远不止写代码——他们兼做产品经理、设计师，有时甚至是营销人员。此外，在同一办公室面对面沟通的小型团队，其移动速度可以极快。
由于现在可以快速构建，必须花更多时间来决定构建什么。为了应对这一项目管理瓶颈，一些团队正在将工程师与产品经理的比例从比如说 8:1 降低到低至 1:1。但我们可以做得更好：如果我们有一个 PM 决定构建什么，一个工程师负责构建，他们之间的沟通就成为了瓶颈。这就是为什么我看到的最快速移动的团队，往往是那些工程师懂一些产品工作（以及可选地，PM 懂一些工程工作）的团队。当工程师理解用户并能直接决策构建什么并构建它时，执行速度可以极快。
我见过工程师成功扩展自己的角色到做产品决策，PM 扩展到构建软件。科技行业工程师比 PM 多，但两条路都有前景。如果你是一名工程师，学习一些产品管理技能会很有用；如果你是一名 PM，请学会构建！
除了产品管理瓶颈，我还看到设计、营销、法律合规等方面的瓶颈。当我们将编码速度加快 10 倍或 100 倍时，其他一切都相形见绌。例如，我的一些团队以极快速度构建了出色功能，但市场团队却手忙脚乱地想如何向用户传达——这就是营销瓶颈。或者当一个团队能在一天内构建出法律部门需要一周才能审查的软件时，那就是法律合规瓶颈。智能体编程不仅在改变软件工程的工作流程，也在改变它周围的所有团队。
当更小、AI 赋能团队能完成更多工作时，通才型选手脱颖而出。传统公司需要汇聚来自许多专业领域的人——工程、产品管理、设计、营销、法律等——来执行项目并创造价值。这导致大型专业团队需要协作。但如果一个两人团队要完成需要五种不同专业的工作，那么其中某些人必须扮演超出单一专业的角色。在一些小型团队中，个人确实有深厚的专业分工。例如，一个人可能是出色的工程师，另一个人是出色的 PM。但他们也理解推动项目所需的其他关键职能，并能切入思考其他类型的问题。当然，精通 AI 工具是一个很大的帮助，因为它帮助我们思考涉及不同角色的问题。
即使在两人团队中，要快速行动，沟通瓶颈也必须最小化。这就是我重视在同一地点工作的团队的原因。远程团队也可以表现出色，但最高速度需要每个人都在场，能够即时沟通解决问题。
本文聚焦于大约 2-10 人的 AI 原生团队，但并非所有事情都可以由小团队完成。我将在以后讨论大型团队的协调问题。
我意识到这些角色转变对许多人来说很难应对。但与此同时，我受到鼓舞的是：愿意学习相关技能的个人和小团队，现在能够完成比以前多得多的工作。这是学习和构建的黄金时代！
社区精彩评论 | Top Replies
@PokemonismDev: "当 AI 清除了'编码瓶颈'，真正的瓶颈已转向 Intent——决定'建造什么'和'为什么建造'。我们正在从一个大型专业化组织是效率标准的时代，过渡到一个小型超敏捷通才团队可以以前所未有的速度执行的时代。随着技术指数级进步，最深层的人类特质——批判性思维、产品愿景和跨学科洞察——正变得最有价值。这是建设者的黄金时代！"
@TheMindRound: "从主要代码编写者转变为系统架构师和代码审查者的转变是深刻的。工程师不再是敲语法，而是编排智能体并确保架构愿景保持一致。瓶颈不再是打字速度，而是 prompt 清晰度和系统设计！"
@msaed_ai: "AI 原生工程正在将 PM 变成主要的技术约束。我们不再受限于能多快地打字，而是受限于能多清晰地定义问题空间。小型面对面使用编码智能体的团队，与传统结构相比基本上以'曲速'运行。"
@_PradeepGoel: "AI 真正揭示的是，有多少软件其实是协调开销。当构建速度加快，最高价值的人是那些能够减少歧义和做出决策的人。"
*来源：@AndrewYNg / X，2026-04-30*