从 AI 辅助到 AI 原生：如何打造前沿开发团队

简要描述Brief Description

AWS 高级首席工程师 Clare Liguori 根据亚马逊各团队的实证试点，阐述了从基础 AI 代码辅助迈向前沿开发的转型。她借助 Bedrock Mantle 团队、Prime Video，以及亚马逊商店部门一项涉及 50 个团队的研究案例说明，要实现 4.5 倍乃至超过 10 倍的生产力提升，必须从根本上改变工程工作流程，而不只是采用新工具。她详细介绍了五项必不可少的日常习惯：投入精力构建引导上下文，放慢节奏以重新设计代码库，持续为自主智能体提供输入而非事事看护，通过规范驱动开发明确表达意图，以及将确定性测试左移；同时也探讨了开发者认知过载、管理层预期和新的运营瓶颈等组织层面的挑战。Clare Liguori, Senior Principal Engineer at AWS, outlines the transition from basic AI code assistance to frontier development based on empirical pilots across Amazon. Drawing on case studies from the Bedrock Mantle team, Prime Video, and a 50-team study across Amazon Stores, she demonstrates that achieving 4.5x to over 10x productivity gains requires fundamentally altering engineering workflows rather than merely adopting new tools. She details five essential daily habits—investing in steering context, slowing down to re-architect codebases, feeding autonomous agents instead of babysitting them, making intent explicit through spec-driven development, and shifting deterministic testing left—while addressing organizational challenges such as developer cognitive overload, management expectations, and new operational bottlenecks.

目录Table of Contents

• 向前沿开发的演进
  Evolution to Frontier Development
• Early Experiments: Bedrock Mantle and Prime Video
• 亚马逊门店试点及其核心差异化优势
  Amazon Stores Pilot and the Core Differentiator
• 习惯 1：投入智能体上下文建设
  Habit 1: Investing in Agent Context
• 习惯二：放慢脚步，才能加快速度
  Habit 2: Slowing Down to Speed Up
• 习惯三：为智能体提供资源，而不是事事盯着它们
  Habit 3: Feeding Agents Instead of Babysitting
• 习惯 4：明确表达意图
  Habit 4: Making Intent Explicit
• 习惯 5：将测试左移
  Habit 5: Shifting Testing Left
• 人员与组织面临的挑战
  Human and Organizational Challenges
• 新兴瓶颈与关键要点
  Emerging Bottlenecks and Key Takeaways

向前沿开发演进Evolution to Frontier Development

我叫 Clare Liguori，是 AWS 的高级首席工程师。我主要负责我们的智能体编程助手，但今天我想分享我们在亚马逊内部的工程团队中观察到的一些实践和显著的生产力提升。My name is Clare Liguori, and I am a Senior Principal Engineer at AWS. I primarily work on our agent coding assistant, but today I want to share the practices and significant productivity gains we have observed across engineering teams inside Amazon.

从事智能体 AI 工作三年多来，我见证了行业经历了 AI 辅助编程的多个阶段。我们最初借助行内代码补全来编写下一行代码或函数，随后转向对话式聊天来询问代码相关问题，之后氛围编程也得到了广泛应用。在此前的这些阶段中，生产力提升通常徘徊在 10% 到 20% 之间。Having worked on agentic AI for over three years, I have seen the industry evolve through multiple phases of AI-assisted coding. We started with inline code completion to write the next line or function, moved to conversational chat to ask questions about code, and saw broad adoption of vibe coding. Throughout those earlier phases, productivity gains typically hovered around 10% to 20%.

最近，我们进入了一个早期采用阶段，我们称之为前沿开发。在亚马逊内部的试点项目中，各团队的生产力提升中位数达到4.5倍，多个团队更是超过了10倍。Recently, we entered an early adopter phase of what we call frontier development. In internal pilots across Amazon, teams are achieving a median productivity improvement of 4.5x, with several exceeding 10x.

前沿开发者的特点体现在三种截然不同的行为上：Frontier developers are characterized by three distinct behaviors:

1. 免手动编码：他们只手动编写所生成代码的 1% 到 2%，其余部分交由自主代理完成。
   Hands-off coding: They manually write only 1% to 2% of the code produced, delegating the remainder to autonomous agents.
2. 交互不频繁：他们会将编程助手配置为无需人工干预即可自主运行数小时。
   Infrequent interaction: They configure their coding assistants to run autonomously for hours without manual intervention.
3. 尽量减少空闲时间：他们并行运行多个智能体来处理积压任务，而不是等待单次生成完成。
   Minimizing idle time: They run multiple agents in parallel across a backlog of tasks rather than waiting on a single generation.

Early Experiments: Bedrock Mantle and Prime Video

率先大规模展示前沿开发成果的是 Amazon Bedrock Mantle 团队，该团队负责管理我们的基础模型托管基础设施。在接到构建全新推理数据平面的任务时，最初的范围评估认为，由于迁移和模型路由的复杂性，这项工作需要 30 名工程师投入 18 个月。The first group to demonstrate frontier development at scale was the Amazon Bedrock Mantle team, which manages our foundation model hosting infrastructure. When tasked with building a new inference data plane, initial scoping estimated the effort at 30 engineers over 18 months due to the complexity of migrations and model routing.

相反，Mantle 团队退后一步，指派六名工程师负责该项目，并借助我们的智能体工具在 76 天内交付了整个系统。这个探路项目证明，交付速度提升 20 倍是可能的。Instead, the Mantle team took a step back, assigned six engineers to the project, and delivered the entire system in 76 days using our agent tooling. This pathfinder project proved that a 20x improvement in delivery speed was possible.

不过，仍有一个关键问题：这六人都是公司顶尖的分布式系统和大型语言模型架构专家，其中包括两位杰出工程师。人们自然会质疑，普通团队在日常项目中能否复现这些成果。However, a key caveat remained: those six individuals were among the company’s top distributed systems and LLM architecture experts, including two Distinguished Engineers. Questions naturally arose as to whether these results could be replicated by standard teams on everyday projects.

为测试可复现性，Prime Video 团队开展了一次为期 10 天的实验性冲刺。他们将六名工程师安排在一间专用房间里，并向他们开放了代理工具的完整使用权限。根据这 10 天的工作速度估算，项目交付周期从 90 周缩短至 24 周。To test reproducibility, the Prime Video organization conducted an experimental 10-day sprint. They placed six engineers in a dedicated room with full access to agent tools. Based on their velocity over those 10 days, the estimated project delivery timeline dropped from 90 weeks down to 24 weeks.

尽管 Prime Video 冲刺验证了这套工具的潜力，但它是在人为设定的条件下进行的。工程师无需承担值班职责，也没有会议，并且只需处理由一名高级工程师在此前三周内准备好的、范围明确且高度细分的待办任务。剩下的挑战是，如何在正常运营条件下实现这些收益。While the Prime Video sprint validated the potential of the tooling, it operated under artificial conditions. The engineers had no on-call responsibilities, no meetings, and worked from a backlog of highly granular, pre-scoped tasks prepared by a senior engineer over the preceding three weeks. The remaining challenge was determining how to achieve these gains under normal operational conditions.

亚马逊门店试点与核心差异化优势Amazon Stores Pilot and the Core Differentiator

为了了解智能体工作流在标准环境中的表现，Amazon Stores 组织在 50 个工程团队中开展了一项结构化的长期试点。这些团队由初级、中级和高级工程师组成，分布情况具有代表性，他们负责处理存在技术债务的既有代码库。To understand how agentic workflows perform in standard environments, the Amazon Stores organization conducted a structured, long-term pilot across 50 engineering teams. These teams represented a typical distribution of junior, mid-level, and senior engineers working on brownfield codebases with existing technical debt.

这项研究通过衡量部署到生产环境的速度来评估生产力——追踪经过验证的变更多快能交付给客户，而非仅仅统计代码提交次数。结果显示出明显差距：一半团队的生产力提升不到 3 倍，另一半团队的提升中位数达到 4.5 倍，部分团队甚至超过 10 倍。The study measured productivity via deployment velocity to production—tracking how quickly verified changes reached customers rather than just counting code commits. The results showed a stark divide: half of the teams experienced less than a 3x productivity gain, while the other half achieved a median increase of 4.5x, with some reaching over 10x.

工具并非决定性因素。试点中超过 90% 的团队都使用相同的内部工具，包括我们的智能体编程助手。团队之间的差距完全源于工作方式的不同。Tooling was not the differentiator. Over 90% of all teams in the pilot used the same internal tools, including our agent coding assistant. The divide stemmed entirely from how teams worked.

取得适度进步的团队，只是在现有的手动开发流程中叠加了 AI 工具。表现最出色的团队则有意改变了核心工程习惯，以最大限度地发挥智能体的自主性。Teams seeing modest gains simply layered AI tools onto their existing manual development processes. The top-performing teams deliberately altered their core engineering habits to maximize agent autonomy.

习惯一：为智能体上下文投入资源Habit 1: Investing in Agent Context

第一个必不可少的习惯，是系统性地投入精力构建智能体上下文。开发者通常通过 Slack 讨论串、入职导师、代码审查和站会来传递隐性的组织知识。前沿团队则将这些经验知识转化为持久化文档、引导文件和技能配置。The first essential habit is investing systematically in agent context. Developers traditionally share implicit institutional knowledge through Slack threads, onboarding mentors, code reviews, and standups. Frontier teams convert this tribal knowledge into persistent documentation, steering files, and skill configurations.

每当代理出错或偏离团队标准时，这些工程师不会只是手动修正代码。他们会追问代理的引导仓库中缺少了什么上下文、约束或指令，并据此更新配置。Whenever an agent makes a mistake or deviates from team standards, these engineers do not simply correct the code manually. They ask what context, constraint, or instruction was missing from the agent's steering repository and update the configuration accordingly.

此外，保持上下文精简需要持续清理。随着基础模型从早期版本发展到 Claude 3.7 Sonnet 和 Claude Opus 4.5 等前沿模型，许多旧有的变通方案和负面约束已不再适用。前沿模型开发者会定期审查引导文件，删除过时且会不必要地占用上下文窗口的规则。Furthermore, maintaining context requires continuous pruning. As foundation models advance from earlier generations to frontier models like Claude 3.7 Sonnet and Claude Opus 4.5, many legacy workarounds and negative constraints become obsolete. Frontier developers regularly audit steering files to remove outdated rules that unnecessarily bloat context windows.

习惯二：慢下来，才能更快前进Habit 2: Slowing Down to Speed Up

采用前沿开发方式，需要先经历一段速度下降期，之后才能实现生产力的指数级提升。团队必须预先投入工程精力，为自主智能体做好存量代码库的准备工作。Adopting frontier development requires an initial drop in velocity before reaching exponential productivity gains. Teams must invest upfront engineering effort into preparing their brownfield repositories for autonomous agents.

这项基础性工作包括改进 CLI 和工具链的错误消息，让智能体能够独立诊断故障；启动 Model Context Protocol (MCP) 服务器，为智能体提供必要的能力；以及重新规划目录结构，以便更轻松地浏览。This foundational work includes improving CLI and tooling error messages so agents can diagnose failures independently, spinning up Model Context Protocol (MCP) servers to grant agents necessary capabilities, and restructuring directory layouts for easier navigation.

在一些情况下，团队甚至将代码库迁移到了强类型语言。Python 或 JavaScript 这类动态、无类型语言，常常迫使模型在没有编译器反馈的情况下猜测类型和运行时行为。迁移到 TypeScript 或 Rust 则能提供严格的编译器错误，供智能体解析并自主解决。In several instances, teams have even transitioned their codebases to strongly typed languages. Dynamic, untyped languages like Python or JavaScript often force models to guess types and runtime behaviors without compiler feedback. Moving to TypeScript or Rust provides strict compiler errors that agents can parse and resolve autonomously.

习惯 3：为智能体提供信息，而不是事事盯着它们Habit 3: Feeding Agents Instead of Babysitting

实现高生产力的一大障碍，是需要通过持续的实时对话式提示来盯着智能体工作。工程师坐在 IDE 前等待代码片段生成的 30 到 60 秒里，会一直处于同步阻塞状态，无法并行开展其他工作。A major barrier to high productivity is babysitting agents through continuous, real-time conversational prompting. Sitting in front of an IDE waiting 30 to 60 seconds for a code snippet keeps the engineer synchronously blocked, preventing parallel execution.

前沿工程师不会持续进行轮流交互。相反，他们会提供全面的任务定义和明确的验证标准，让智能体能够长时间自主执行。Frontier engineers do not engage in constant turn-taking. Instead, they provide a comprehensive task definition alongside clear validation criteria, allowing the agent to execute independently for extended periods.

通过为代理提供构建、执行、测试和自我纠正的工具，开发者只需在最终产物达到要求的质量标准和测试覆盖率标准后进行一次审核。将这些要求自动化并纳入引导文件，可确保所有任务都得到一致执行。By giving the agent the tools to build, execute, test, and self-correct, the developer only reviews the final artifact once it satisfies the required quality and test coverage bars. Automating these requirements inside steering files ensures consistent execution across all tasks.

习惯 4：明确表达意图Habit 4: Making Intent Explicit

前沿工作流高度依赖规范驱动开发。在非正式的氛围编程中，工程师往往只提供含糊、笼统的提示，并在生成的代码偏离预期架构时反复迭代。与其在前期完善设计意图，不如等到代码差异广泛出现后再逐一修改，效率要低得多。Frontier workflows rely heavily on spec-driven development. In informal vibe coding, engineers often provide vague, high-level prompts and iterate repeatedly on generated code when the architecture deviates from expectations. Iterating across widespread code diffs is significantly slower than refining design intent upfront.

对于复杂或含义模糊的功能，工程师会先与智能体协作，反复完善一份结构化的规范文档。通过文本明确架构、接口契约和边界条件，智能体便能在首次生成时产出准确的代码，避免后续代价高昂的重写。For complex or ambiguous features, engineers iterate with the agent on a structured specification document first. Refining architecture, interface contracts, and boundary conditions in text allows the agent to generate accurate code on the first pass, avoiding costly downstream rewrites.

习惯 5：将测试左移Habit 5: Shifting Testing Left

为了让智能体能够自主运行数小时，它们需要快速、确定性的反馈循环。当智能体遇到错误时，全面的测试套件可以让它自行诊断并纠正问题，无需人工干预。To enable agents to operate autonomously for hours, they require rapid, deterministic feedback loops. When an agent encounters an error, comprehensive test suites allow it to self-diagnose and correct without human intervention.

高绩效团队会在自动化代码检查工具、单元测试、集成测试套件、性能基准测试和安全扫描工具上投入大量资源。High-performing teams invest heavily in automated linters, unit tests, integration suites, performance benchmarks, and security scanners.

至关重要的是，团队还会为下游云服务构建确定性的本地模拟服务。要求智能体部署远程基础设施或连接到远程基础设施，会引入延迟和不稳定因素。本地模拟服务可直接在开发者的机器上即时、可重复地运行，从而最大限度地增加智能体的迭代次数。Crucially, teams also build deterministic local mocks for downstream cloud services. Requiring an agent to deploy or connect to remote infrastructure introduces latency and flakiness. Local mocks provide instant, reproducible execution directly on the developer's machine, maximizing the agent's iteration cycles.

人力与组织方面的挑战Human and Organizational Challenges

作为一家前沿工程组织开展工作，会面临独特的文化和认知挑战：Operating as a frontier engineering organization introduces distinct cultural and cognitive hurdles:

• 开发者倦怠与错失恐惧：工程师常常会忍不住熬夜编写提示词、同时管理多个智能体任务，导致在终端之间频繁切换上下文，并承受认知过载。
  Developer Burnout and FOMO: Engineers frequently experience the temptation to craft overnight prompts and manage multiple concurrent agent tasks, leading to terminal context switching and cognitive overload.
• 代码审查疲劳：审查大量 AI 生成的代码需要耗费大量脑力。资深工程师经过多年的磨练，已具备娴熟的审查能力；而初入职场的工程师往往觉得，评估复杂的代码差异比从头编写代码更费力。
  Code Review Fatigue: Reviewing large volumes of AI-generated code requires significant mental effort. While senior engineers have honed review skills over years, early-career engineers often find evaluating complex diffs more taxing than writing code from scratch.
• 管理层共识：领导层必须认识到，团队需要专门的时间来重构代码库并积累背景知识，之后才能实现生产力提升；同时应抵制强行要求立即提高效率的冲动。
  Management Alignment: Leadership must recognize that teams need dedicated time to restructure codebases and build context before productivity gains materialize, resisting the urge to mandate instant velocity increases.
• 分阶段推广：如果在由专注的探路团队验证内部最佳实践、工具集成和指导模式之前就推行覆盖整个组织的要求，往往会失败。
  Phased Rollouts: Broad organizational mandates often fail if rolled out before internal best practices, tooling integrations, and steering patterns have been validated by focused pathfinder teams.

新兴瓶颈与关键要点Emerging Bottlenecks and Key Takeaways

随着原始代码生成速度加快，组织瓶颈逐渐向上游转移到决策环节，向下游转移到运营审批环节。As raw code generation accelerates, organizational bottlenecks shift upstream to decision-making and downstream to operational approvals.

当软件实现需要 9 到 12 个月时，花两个月定义产品、再花两个月进行安全或上线评审，只占整个周期的一小部分。而当智能体将实现阶段压缩到短短几周时，治理、产品范围界定和架构审批便成为主要瓶颈。组织必须简化决策框架，尤其是针对可逆的“双向门”决策。When software implementation required 9 to 12 months, spending two months on product definition and two months on security or launch reviews represented a minor fraction of the timeline. When agents compress the implementation phase into a matter of weeks, governance, product scoping, and architectural approvals become the primary constraints. Organizations must streamline decision-making frameworks, particularly for reversible two-way door decisions.

前沿工程并非由采用某种特定工具来定义，而是通过从根本上转变工程习惯、工作流程和团队协作流程，将人的注意力从原始执行工作中解放出来。Frontier engineering is not defined by adopting a specific tool, but by fundamentally transforming engineering habits, workflows, and team processes to decouple human attention from raw execution.