From AI-Assisted to AI-Native: Building a Frontier Development Team — Clare Liguori, AWS

Inline completion helps write the next line or function. Chat answers questions about a codebase. Vibe coding turns implementation into a running conversation. Yet Clare Liguori, Senior Principal Engineer at AWS working mostly on Kiro, had personally felt only about a 10–20% productivity improvement through those earlier phases. That is her anecdotal starting point. Amazon’s internal pilots were beginning to report much larger gains: a median of 4.5×, sometimes exceeding 10×. The question is what changed in the work itself.

Amazon calls the emerging practice frontier development and defines it through observable behavior:

• Hands-off coding: Engineers write perhaps 1–2% of the code they produce; agents write the rest.
• Infrequent intervention: Engineers aim to give agents enough direction to run for hours without interruption.
• Concurrent work: Multiple agents work through a backlog in parallel, reducing idle time.

These behaviors change where human attention goes. An engineer must prepare work that can continue without a new instruction after every generated change.

The first striking example was Bedrock Mantle. Bedrock’s model-hosting service needed a new inference data plane, with an original estimate of 30 people over 18 months. The anticipated work included building the service and migrating customers and models. Instead, six engineers built the new data plane in 76 days with Kiro. Liguori describes this as the pathfinder result, reporting up to 20× improvement from an assessment that looked at commits.

The six included two distinguished engineers and some of Amazon’s strongest experts in distributed systems and LLM architecture. Their result established a possibility, but its staffing made reproduction an immediate concern. Other teams could adopt the tool; they could not simply acquire the same concentration of expertise.

Prime Video tested a different group of six engineers in a 10-day sprint. Their progress changed the project delivery estimate from 90 weeks to 24 weeks, and the team compared sprint commits with its earlier commit history. The 24-week figure was a revised forecast, rather than a completed delivery. The conditions were also unusually favorable: no on-call duties, limited meetings and few distractions.

The preparation explains part of what made that sprint executable. A senior engineer had spent the preceding three weeks creating small, well-scoped tasks with detailed requirements. Six engineers could then spend the protected sprint churning through already-defined work. The fast execution rested on earlier human effort to remove ambiguity. That left the next question: could ordinary teams sustain this pattern while maintaining existing systems and handling their normal obligations?

Amazon Stores observed 50 teams for the better part of a year. These teams had normal mixes of early-career, mid-career and senior engineers. They worked in existing codebases, unlike Mantle’s greenfield build. The measure also moved closer to customer delivery: deployment velocity to production, or how quickly teams could get changes out to customers.

Half the teams achieved less than a 3× increase. The stronger-performing half saw a median of 4.5×, with some exceeding 10×. Ninety percent used Kiro alongside other internal tools. Liguori attributes the split to deliberate changes in working practices: the teams pulling ahead reorganized how they worked, while the others added assistants to their existing routines. This observational account does not isolate the causal effect of individual habits or establish gains every team should expect. Its deployment measure also differs from the earlier commit assessments and revised project estimate.

Interviews with the pilot teams, Bedrock Mantle and Prime Video produced five recurring habits. The emphasis on habits matters: a protected sprint can demonstrate potential, while everyday development requires a repeatable way to define, delegate and check work. Building that routine takes time.

The first habit is investing in agent context. Much of a team’s operating knowledge lives in people’s heads and moves through Slack conversations, onboarding, mentoring, code reviews, stand-ups and sprint planning. Agents need access to that knowledge too. Whenever an agent makes a mistake or chooses an unwanted approach, the practical question is what it needed to know that was missing from the skills or steering files. Those files turn a correction into guidance available on future tasks.

Context maintenance includes subtraction. Earlier models required numerous prohibitions to work around recurring quirks; improved model behavior made some of those instructions unnecessary. Keeping every old workaround adds context without necessarily improving the next run. The habit therefore has two directions: add missing team knowledge, and prune instructions whose original purpose has disappeared.

The second habit is accepting an initial slowdown. Almost every interviewed team reported lower productivity while intentionally adopting its new workflow. Existing codebases needed engineering work before agents could succeed independently. That investment addressed several distinct obstacles:

• Opaque failures: Better tool error messages helped models understand what went wrong and attempt a correction.
• Missing operations: New tools and MCP servers gave agents ways to perform work they otherwise could not complete.
• Difficult navigation: Restructuring code helped agents find and understand the parts they needed to change.

These are concrete preparation costs, rather than benefits that arrive automatically with access to a coding assistant.

Some teams went as far as changing programming languages. Liguori had seen teams struggle with Python and JavaScript when their workflow lacked compiler feedback that would expose mistakes before the agent returned its work. Moves to TypeScript and use of Rust offered more useful compiler diagnostics. The mechanism is actionable feedback: the agent gets a signal it can use to repair its own output. A language migration is optional, and these examples do not establish that every codebase needs one.

The third habit addresses the engineer’s own waiting time. A conversation that repeatedly generates code, waits 30 seconds to a minute, and returns for human review keeps the engineer occupied throughout execution. Each response requires reading and redirection. That attention cannot also go to other work, and running several such conversations in parallel becomes difficult.

An independent assignment gives the agent both the work and the means to validate it. The agent should keep correcting its changes until they meet a stated quality bar: the code runs, compiles, passes tests, is testable and has high coverage. Putting these expectations in steering files makes them recurring instructions. The human no longer has to supply the same completion standard in every prompt.

The fourth habit is making intent explicit. A high-level prompt can produce extensive changes before anyone notices that the requirements or technical design were misunderstood. Correcting code scattered across a repository is then an expensive way to discover what the feature should do. For ambiguous, complex work, Amazon engineers refine a specification before implementation.

Kiro can generate the initial specification, so explicit intent does not require manually writing the whole document. The engineer and model can work through disagreements in one place before those disagreements become implementation changes. Conversation remains useful here: its purpose is to settle the task, giving later autonomous execution a clearer destination.

The fifth habit, shifting testing left, supplies the feedback that makes a long independent run useful. Agents will make mistakes. Linters and unit, integration, performance and security tests give them signals they can act on before returning to an engineer. Familiar engineering hygiene gains another use: the same checks can support repeated autonomous correction throughout implementation.

A concrete change is the move from integration tests that depend on live services to mock services with deterministic responses running entirely locally. In the earlier arrangement, testing required starting other services and connecting to cloud systems. With local mocks, the agent can perform the test loop on a laptop. A failed check supplies feedback; the agent changes the code and checks again. Reducing the wait for each result permits more correction cycles in the same period. The benefit concerns speed and repeatability in this local loop; a mock does not establish every property of the live integration.

Where does the engineer stop being required at every turn? The diagram follows that local correction loop: the assignment and quality bar enter at the start, while failed checks return to implementation rather than immediately returning to the human.

The loop makes the relationship between testing and autonomy visible. Clear instructions alone cannot tell the agent whether its implementation works. Local checks supply that information quickly enough for it to continue repairing the change. Meeting the completion standard becomes the point at which it returns to the engineer.

These habits do not produce effortless productivity. Engineers may stay up late trying to perfect a prompt so an agent can run overnight and leave a finished change in the morning. Multiple concurrent agents also mean switching between terminal tabs and tasks. Independence at the agent level can increase pressure and cognitive load for the person coordinating the work.

Review is a particular difficulty. Senior engineers have often spent years assessing other people’s code. Early-career engineers may not yet have developed that skill, and reviewing generated output can feel harder than writing the code themselves. Reducing manual implementation therefore changes the human task; it does not necessarily make that task easier.

Organizations must also allow the initial investment. Liguori admits sharing the leadership temptation to ask why a team with strong models and tools is not already shipping faster. She describes taking two months to invest in a codebase, discover team practices and establish new habits. Constant pressure to ship features every month can consume the time needed to make agents effective.

Expansion needs the same patience. Amazon learned through an exceptional pathfinder, a focused sprint and the 50-team pilot before attempting broader adoption. At the time of the talk, the 2026 challenge was extending the approach to the next 2,000 teams—a scaling objective, rather than an achieved result. An immediate organization-wide mandate would send teams into the new workflow before they had learned which practices and context their own environment required.

The ending moves beyond coding practices to the time a customer waits for a product. Liguori describes work that previously took 9–12 months to implement and can now take 1–2 months. If the organization still spends two months deciding whether to build it and another two months approving launch, those decisions become the longest part of delivery. Their duration did not have to increase for them to become the bottleneck; implementation became much shorter.

Frontier teams can consequently spend more time making decisions than writing code. The practical recommendation is to make decisions faster, especially when they are easy to reverse. Reversibility identifies choices that can be revisited, giving organizations a specific place to reduce deliberation as the implementation loop accelerates.

Frontier development requires a deliberate change in daily work across engineers and their organizations. The closing invitation is to examine each interaction with an AI tool: what knowledge, clearer intent or feedback would let the work continue without another intervention? The same question eventually reaches product decisions and launch processes. Freed attention still needs somewhere useful to go.