Frontier development depends on changing engineering habits, rather than adding an agent to an existing workflow.
2
Teams get more from agents when they write down context, define intent before coding, and give agents fast local feedback.
3
As code generation gets faster, decision-making and product launch reviews become the bottlenecks.
Summary
Clare Liguori describes a shift from chat-based coding assistance to what Amazon calls frontier development. Frontier developers write only 1 to 2 percent of their code themselves, run agents for hours, and keep several agents working in parallel. In Amazon's pilot with 50 ordinary teams using existing codebases, half saw less than a 3x increase in deployment velocity, while the other half had a median increase of 4.5x and sometimes more than 10x. The difference was how teams worked. Liguori presents five habits: record agent context, accept an initial slowdown while improving the codebase, feed agents tasks they can validate themselves, make intent explicit in specifications, and move testing left with fast local mocks. She is also clear about the costs. Parallel agents increase cognitive load, reviewing generated code can be difficult, and organizations must allow time for the transition. Once code takes less time to write, decisions and launch approvals become the long pole.
Frontier development means engineers spend little time directly writing code
Liguori places frontier development after inline completion, chat, and vibe coding. She says her own productivity had improved by only 10 to 20 percent through those earlier phases, while Amazon pilots saw a median 4.5x improvement and sometimes more than 10x. She defines frontier developers through three behaviors: they write about 1 to 2 percent of their code, let agents run for up to hours without intervention, and run several agents in parallel against a backlog. The shift is measured by how little the engineer stays in the loop while the work continues.
The strongest early result came from an unusually expert team
The Bedrock Mantle team had estimated its new inference data plane at 30 people over 18 months. Instead, six people built it in 76 days with Kiro. Liguori calls this the first pathfinder example inside Amazon and says it suggested an improvement of up to 20x. The result was difficult to reproduce because the six engineers included two distinguished engineers and specialists in distributed systems, LLMs, and architecture. The example showed what was possible, but it did not describe a normal engineering team.
A controlled sprint produced strong results without representing ordinary work
Prime Video ran a 10-day experiment with six engineers using Kiro. Based on the progress in that sprint, the estimated delivery time fell from 90 weeks to 24 weeks. The team compared its commit history with what it had done before the experiment. Liguori adds several qualifications: the engineers had no on-call duties, few meetings, and limited distractions. A senior engineer had also spent three weeks preparing small, well-scoped tasks with detailed requirements. The sprint demonstrated a repeatable pattern with a different group of engineers, but it was still a carefully structured period rather than normal day-to-day work.
The tool was shared, but the teams that changed their workflow pulled ahead
Amazon Stores observed 50 ordinary teams working on existing systems with a normal mix of early-career, mid-career, and senior engineers. The teams were measured by deployment velocity to production, rather than commits alone. Half saw less than a 3x increase. The other half had a median increase of 4.5x, with some exceeding 10x. Ninety percent used Kiro along with other internal tools. Liguori says the difference was not the tools. The stronger teams deliberately changed how they worked, while the others placed Kiro on top of their existing process.
Agents need written context, and that context needs regular pruning
Engineers normally pass knowledge through Slack, onboarding, mentoring, code reviews, stand-ups, and planning. Frontier teams write that knowledge down in skills files and steering files. Each agent mistake becomes a prompt to ask what information is missing. Liguori says this context cannot be left untouched. Models improved substantially over the period she describes, so instructions added to work around older model quirks can become unnecessary context. Teams need to revisit the files and remove rules that newer models no longer need. Otherwise, the context grows with obsolete workarounds.
Teams often have to slow down and improve the codebase before agents can speed up
Most interviewed teams became less productive at first. Liguori says they had to do engineering work before agents could operate effectively in brownfield codebases. That work included improving error messages, building new tools and MCP servers, restructuring code so agents could navigate it, and sometimes changing programming languages. She has seen teams move from Python or JavaScript to TypeScript or Rust because types and compiler errors give agents better signals. These changes take time, and the productivity increase comes later. Teams should expect the initial slowdown rather than treat it as evidence that the approach failed.
Agents produce more when they receive tasks and validation rules instead of constant replies
A developer who waits for every generated change and responds in a continuous conversation remains the bottleneck. Liguori says that pattern makes parallel agents difficult because the engineer is occupied with one conversation. A better workflow gives an agent the task, the relevant information, and instructions for self-validation. The agent can then run, compile, test, and check coverage before returning. Teams can place those requirements in steering files so they apply repeatedly. The goal is for the agent to return when it reaches a quality bar, rather than after every small coding step.
Written specifications reduce wasted iteration on the wrong implementation
Liguori contrasts high-level prompting with a workflow based on explicit intent. Amazon engineers often use behavior-driven development and write specifications for ambiguous or complex features. They can ask Kiro to generate much of the specification, then refine the document through conversation before asking for code. It is easier to correct a document than to correct code changes spread across a codebase. When the requirements are wrong, iterating on generated code creates a long sequence of corrections. A clear specification gives the agent a more stable target.
Fast local tests let agents correct their own mistakes
Agents need a quick feedback loop if they are expected to work for hours. Liguori recommends linters, unit tests, integration tests, performance tests, and security tests. She describes a particular investment in locally running mock services with deterministic responses. Instead of waiting for live services or setting up an entire cloud-connected system, the agent can run the checks on a laptop. Faster feedback gives it more chances to find and fix mistakes. Liguori describes this as familiar engineering hygiene whose payoff becomes larger when an agent can use it continuously.
"The teams that achieved step function improvements intentionally changed the way that they worked, and the other simply kind of sprinkled Kiro and some of the other tools that we have on top of their existing way of working."07:19
Who should watch
You are adding coding agents to an existing codebase and are seeing only modest gains from a tool that works well in demos.
Your team wants agents to work independently, but its context, tests, error messages, or service interfaces are not ready for that workflow.
You lead an engineering organization where generated code is arriving faster than product decisions, reviews, or launch approvals can handle.
