← back
From AI-Assisted to AI-Native: Building a Frontier Development Team — Clare Liguori, AWS
Takeaway
Large agent-assisted productivity gains require deliberate workflow and codebase changes, with attention to how results are measured.
Summary
- Liguori reports a median 4.5x productivity improvement among stronger-performing Amazon pilot teams that changed how they worked with agents.
- Bedrock Mantle used six engineers over 76 days against an initial estimate of 30 people for 18 months, but involved unusually experienced staff.
- A Prime Video sprint benefited from protected focus time and three weeks of task preparation, limiting comparison with everyday work.
- A broader 50-team pilot used production deployment velocity; habits include documenting context, pruning obsolete instructions, and improving tools and error messages.
ai-native-developmentkiroengineering-productivity
Original description
Amazon watched 50 ordinary teams for the better part of a year, teams with normal seniority mixes working in existing codebases. Ninety percent of them used the same coding assistant. Half saw under 3x improvement in deployment velocity to production. The other half saw a median of 4.5x and sometimes past 10x. The tool was not the variable. The teams that pulled ahead had deliberately changed how they worked, and the rest had sprinkled agents on top of the way they already worked. Clare Liguori calls the result frontier development, and defines it by behavior: engineers writing one to two percent of their own code, agents running for hours without interruption, several running at once. Her five habits are mostly unglamorous. Write down what lives in your head, then keep pruning it as models improve so old workarounds stop bloating context. Expect to get slower first, because brownfield codebases need real work before agents succeed in them, which for some teams meant better error messages, new tools, or restructuring outright. Feed agents rather than babysitting them, since a running conversation keeps you in the loop and makes parallelism impossible. Fix the intent in a document before arguing with generated code. Shift testing left, with local deterministic mocks, so the feedback loop is fast enough for an agent to self correct. The new bottleneck is decision speed. Speaker info: https://x.com/clare_liguori / clareliguori https://clare.dev/ Timestamps: 0:00 - Four phases, and only 10% to 20% felt 1:22 - What the pilots actually measured 2:34 - Thirty people for 18 months, or six people for 76 days 3:43 - Why that team was not reproducible 4:51 - A ten day sprint, and its asterisks 5:57 - Fifty ordinary teams, and the real split 7:04 - Same tools, different ways of working 8:14 - Habit one: invest in agent context 9:21 - Pruning context as models improve 10:31 - Habit two: slow down to speed up 12:50 - Feeding agents instead of babysitting them 13:58 - Making intent explicit before writing code 15:09 - Shifting testing left with local mocks 16:15 - Burnout, FOMO and cognitive load 17:23 - What organizations have to change 19:41 - When decision speed becomes the bottleneck