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

Brief Description

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
• Habit 1: Investing in Agent Context
• Habit 2: Slowing Down to Speed Up
• Habit 3: Feeding Agents Instead of Babysitting
• Habit 4: Making Intent Explicit
• Habit 5: Shifting Testing Left
• Human and Organizational Challenges
• Emerging Bottlenecks and Key Takeaways

Evolution to Frontier Development

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.

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%.

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. 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

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

Habit 3: Feeding Agents Instead of Babysitting

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.

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.

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.
• 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.

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.