In this post, I’ll share how AWS ProServe became a frontier team, the practices that enabled it, and what your engineering organization can take from our experience.

Building a frontier team is something every organization can do. For customers who want help accelerating, AWS ProServe is a partner whose consultants have already absorbed AI-native development into how they work every day.

AI-native development moves at a pace traditional consulting cadences weren’t built for. Work that used to span months compresses into days, and the rhythm changes accordingly: tighter loops, faster feedback, more decisions made in the flow of building. Helping a customer operate at that pace requires consultants who know which decisions can move quickly, which need careful human judgment, and how to keep quality high when execution speeds up. That intuition emerges from doing the work.

Our driver mirrored what Swami described: free consultants from non-coding overhead (documentation, coordination, status reporting, repetitive scaffolding) that consumed most of every engagement. This let human judgment focus where it actually moves outcomes. So we did what frontier teams do. We invested in agent context, restructured work around what agents do well, and stopped treating AI as an assistant. We started treating it as a foundation.

Swami’s blog describes three paths Amazon teams took into AI-native development: a pathfinder initiative, a structured sprint, and an in-situ experiment. AWS ProServe began as a pathfinder.