AI-native software development requires a new engineering model
SiliconANGLE Paul Nashawaty ● Covered by 3 sources
AWS execs say most dev teams still waste time on maintenance, not new code, despite AI tools. The fix isn't better AI — it's rebuilding how teams actually work.
Based on reporting by SiliconANGLE, Paul Nashawaty — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Every engineering leader has bought the AI coding tools by now. Copilot-style assistants, AI-native IDEs, code completion baked into everything — it's table stakes. And yet a striking number of organizations report their developers still spend almost no time building anything new. On the AppDevANGLE podcast, Deepak Singh and Steve Tarcza of AWS and Amazon laid out why that gap persists, and their answer has nothing to do with which model you're running.
Singh pointed to internal and external studies showing teams using identical tools land in wildly different places. Some see a 15% to 30% productivity bump. Others hit three to ten times that, or more. Same IDE, same assistant, same underlying model. The variable, Singh argued, isn't the technology at all — it's whether an organization actually redesigned its planning, specs, code reviews and handoffs to let AI agents participate as real contributors, rather than bolting a chatbot onto workflows built for humans only.
Tarcza framed the deeper issue as one of context. Foundation models know syntax and libraries fine, but they have no idea how a specific company actually operates — its architecture decisions, its coding standards, its priorities. Teams that write that knowledge down, whether as documentation, specifications or what he called steering files, are the ones who can hand agents meaningfully bigger chunks of work. Everyone else is stuck re-explaining the basics every session.
Trust came up repeatedly, and for good reason. Tarcza called it the currency of AI adoption — if engineers don't trust what an agent produces, adoption stalls no matter how capable the model is. AWS's answer leans on specification-driven development and automated reasoning that surfaces ambiguity before any code gets generated, the idea being that speed only matters if people are actually willing to ship what comes out the other end.
Inside Amazon, that shift already shows up in unglamorous places: agents summarizing Slack threads, triaging tickets, drafting specs, handling operational toil that used to eat developer hours. Tarcza cited one retail feature, Add to Order, that shipped two months ahead of schedule once the team moved to spec-driven development and put AI at the center of planning and execution rather than treating it as an autocomplete layer bolted on at the end.
My take — AI-written commentary, not fact-checked reporting
The 15%-to-30% versus 3x-to-10x split is the real story buried in here, and most companies will ignore it because rethinking planning and review processes is harder than buying another seat license. Layering a chatbot on top of the same broken workflow was always going to be a rounding error, not a transformation. Organizations chasing the bigger multiplier will have to do the unglamorous work of writing down how they actually operate — which, conveniently, is the same discipline good engineering orgs should have had before AI ever showed up.
Read more about this at: SiliconANGLE
