# From AI-Assisted to AI-Native: Building a Frontier Development Team Clare Liguori, AWS | AI Engineer World's Fair 2026 | 20:57 Source: https://www.youtube.com/watch?v=pqlWNihgdjI Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/from-ai-assisted-to-ai-native-building-a-frontier-development-team Published: 2026-08-28 Tags: agent-skills, agents, coding-agents, context-engineering, testing ## TL;DR - Frontier development depends on changing engineering habits, rather than adding an agent to an existing workflow. - Teams get more from agents when they write down context, define intent before coding, and give agents fast local feedback. - 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. ## Key ideas ### Frontier development means engineers spend little time directly writing code [00:56](https://www.youtube.com/watch?v=pqlWNihgdjI&t=56s) 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 [02:24](https://www.youtube.com/watch?v=pqlWNihgdjI&t=144s) 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 [03:57](https://www.youtube.com/watch?v=pqlWNihgdjI&t=237s) 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 [05:54](https://www.youtube.com/watch?v=pqlWNihgdjI&t=354s) 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 [08:22](https://www.youtube.com/watch?v=pqlWNihgdjI&t=502s) 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 [09:31](https://www.youtube.com/watch?v=pqlWNihgdjI&t=571s) 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 [11:09](https://www.youtube.com/watch?v=pqlWNihgdjI&t=669s) 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 [12:33](https://www.youtube.com/watch?v=pqlWNihgdjI&t=753s) 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 [14:04](https://www.youtube.com/watch?v=pqlWNihgdjI&t=844s) 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. ## Notable quotes - "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) - "The second one is slowing down to speed up." (09:29) - "The third one is feeding agents, not babysitting agents." (11:09) - "The more that you spend reviewing the decision to actually build a new product, the slower it is to build the product now because the code only takes 1 to 2 months to write." (18:55) ## Tools & references mentioned - AWS - Kiro - Amazon Bedrock - Bedrock Mantle team - Prime Video - Amazon Stores - Claude - GPT - Sonnet 3.7 - Opus 4.5 - MCP servers - TypeScript - Rust ## 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. ## Editor's note From the pack [Coding agents on real codebases](https://aietalks.com/packs/coding-agents-on-real-codebases): Horthy says read the plan. Blum says fund verification before you fund adoption. Both assume you can see what the agent did. That is easy in Claude Code and much harder when you built the agent and shipped it to other people. Kitaru records those runs so you can replay one and find the step where it went wrong. It is also why this site exists. Written by the AIE Talks editors (the Kitaru team), not by the speaker.