Frontier Development Hits 4.5x Gains at Amazon

Frontier development now delivers a median 4.5x productivity improvement inside Amazon (NASDAQ:AMZN) according to senior principal engineer Claire La Gory in a talk shared via AI Engineer.

La Gory said she personally felt only 10 to 20 percent gains from three prior waves: inline completion, chat, and vibe coding.

She has worked on agentic AI for over three years and mostly works on Kiro, Amazon's agent coding assistant.

What frontier development actually means

Amazon defines frontier developers by three behaviors that together push agents to do almost all the typing.

They write only 1 to 2 percent of the code they ship, with agents generating the rest.

They interact infrequently, aiming for agents that run for up to hours without intervention.

They minimize idle time by running multiple agents in parallel against a backlog of tasks.

The headline pilots that sparked the shift

The first proof point was the Bedrock Mantle team that rebuilds the inference data plane for Bedrock, Amazon's model hosting service for Claude and GPT.

The original estimate was 30 people over 18 months to build the new service and migrate customers and models.

Six people built it in 76 days with Kiro, measured on commits, for an effective gain of up to 20x.

That team included two distinguished engineers and other top experts in distributed systems and LLM architecture, which made the result hard to replicate.

The second experiment was a 10-day sprint in Prime Video with six engineers going all in on Kiro.

Based on progress in those 10 days, the team cut its delivery estimate from 90 weeks to 24 and compared commit volume to their prior baseline.

The sprint also came with artificial conditions: no on-call duties, few meetings, and a senior engineer who spent the previous three weeks writing small, well scoped tasks with detailed requirements.

The more realistic test across 50 teams

Amazon Stores, which covers amazon.com and physical stores, ran a longer pilot across 50 normal teams working in existing brownfield codebases with a mix of early career, mid-career and senior engineers.

The pilot tracked deployment velocity to production, not just commits, for the better part of last year.

Half the teams saw less than 3x improvement while the other half hit a median of 4.5x and sometimes more than 10x.

Ninety percent of those teams used Kiro among other internal tools, so tool access did not explain the gap.

The difference was workflow: teams that intentionally changed how they worked saw step function gains, while teams that simply layered Kiro on top of existing processes did not.

StartupHub.ai data shows Amazon at 81 out of 100, well ahead of Bedrock at 17 out of 100, which helps explain why Amazon could run a 50 team longitudinal study that smaller platform teams cannot replicate without external tooling.

The five habits that separated the winners

Habit one is investing in agent context, writing down tribal knowledge that usually lives in Slack, onboarding, code reviews and standups into skills and steering files.

La Gory described the habit as asking what is missing in steering files every time the agent makes a mistake, then pruning that context as models improve.

She cited Sonnet 3.7 in mid last year needing many do not rules, versus Opus 4.5 as of last November and the six months of model progress since, which required less bloat.

Habit two is slowing down to speed up, accepting that productivity dips while teams do real engineering for agents to succeed.

Teams improved error messages, built new tools and MCP servers, restructured codebases for agent navigation, and in some cases switched languages from untyped Python or JavaScript to TypeScript or Rust for compiler feedback that agents can act on.

Habit three is feeding agents, not babysitting them, which La Gory called the key to parallelization.

Babysitting looks like 30 seconds to a minute of waiting after each prompt, which blocks running multiple agents, while feeding means giving the agent a way to self validate against compile, tests and coverage and only returning when a quality bar is met.

Habit four is making intent explicit through specs before code, often using behavior driven development already embedded in Amazon Q and Kiro.

La Gory argued it is faster to iterate with a model on a document than on code spread across a codebase when the initial intent was wrong, and Kiro can generate the draft spec for humans to refine.

Habit five is shifting testing left to give agents a fast feedback loop for hours of self correction.

Teams added linters, unit tests, integration tests, performance and security tests, and mocked services to run deterministically locally so agents avoid slow cloud dependencies.

Why this matters beyond Amazon

The numbers land as the industry debates whether AI code assistants are 20 percent helpers or true force multipliers, with GitHub Copilot, Cursor, Windsurf and Devin all pushing agentic workflows but still mostly reporting completion style gains.

Amazon's data suggests the ceiling is not the model but the repository: brownfield code without tests, types and fast local mocks caps agent autonomy regardless of model quality.

The talk also maps to a visible market shift toward spec driven and test driven agent loops, from Kiro and Amazon Q Developer to tools like Continue, Factory and Codium that emphasize steering files and local execution.

For startups, the implication is that buying seats is not the unlock, and the ROI now justifies hygiene work that engineering teams have long deferred.

What still breaks

La Gory flagged burnout risk she called flow mat, with engineers staying up late to craft an overnight prompt and juggling cognitive load across terminal tabs while reviewing AI output.

Review load is especially heavy for early career engineers who have not yet built the code review muscle that senior engineers use daily.

Organizations also struggle to accept the slowdown before speedup, and leaders she included herself often ask why velocity is not instant given powerful models and stories of 20 PRs a day on X.

Rolling out too broadly too fast without capturing org specific best practices creates a second failure mode, which is why Amazon frames 2026 as scaling from 50 teams to the next 2,000 with deliberate habit building.

The final bottleneck she sees is decision making: when code that took 9 to 12 months now takes one to two months, product review and launch approvals become the long pole and frontier teams spend more time deciding than coding.

The takeaway she left was blunt: frontier engineering requires intentionally changing how work happens, not just adding a better autocomplete.