AI Coding Gains Depend on Behavior, Not Tools

Ninety percent of the teams used the same tool. Half of them saw less than 3x improvement in how fast they shipped to production. The other half hit a median of 4.5x, and some broke past 10x. The tool was identical. The difference was entirely in how those teams worked.

That finding, from an Amazon Stores pilot that tracked 50 ordinary engineering teams for the better part of a year, is the premise of a talk Clare Liguori, senior principal engineer at AWS, delivered at the AI Engineer conference. Her full presentation is available on YouTube. The 50-team study is the one worth paying attention to, because unlike the headline experiments Liguori describes first, this one had no asterisks about elite personnel or artificial conditions.

The earlier experiments are worth knowing about precisely because they do have asterisks. The Bedrock Mantle team: six engineers rebuilt an inference data plane in 76 days that had been estimated at 30 people over 18 months. Remarkable, but two of those six were distinguished engineers, which at Amazon is a very small population. Then came a Prime Video sprint, ten days, six engineers isolated from on-call duty and distractions, working off a backlog that a senior engineer had spent three weeks pre-scoping into precise, well-bounded tasks. Also remarkable. Also not most people's jobs.

The 50-team pilot is different. Normal seniority mix. Existing codebases, not greenfield. Regular workdays with all the interruptions those involve. And still: the behavior split produced a performance split.

"The teams that achieved step function improvements intentionally changed the way that they worked," Liguori says, "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."

That framing matters. It means the question for any team holding a new AI coding license isn't "are we using this?" It's "have we actually changed anything?"

The five habits, and what they're really asking of you

Liguori names five habits that distinguished the high-gain teams. They are, almost uniformly, more demanding than they sound.

Invest in agent context. Everything engineers carry in their heads, the conventions, the why-we-don't-do-it-that-way institutional memory, the gotchas in the codebase, agents don't have any of it. The habit is externalizing that knowledge into steering files and skills files, then treating every agent mistake as a signal that something is missing from the documentation rather than a reason to take the wheel back. What's worth noting here: this isn't a one-time setup cost. As models improve, the workarounds you documented for earlier behaviors become dead weight that bloats context and degrades performance. The habit runs in both directions: write it down, then prune it back.

Slow down to speed up. Liguori is admirably direct that productivity went down for almost every team when they first tried to work this way. Some teams rewrote error messages so agents could understand failures. Some built new MCP servers. Some restructured their codebase entirely so agents could navigate it. A few switched programming languages, moving toward TypeScript or Rust partly because typed languages give compilers something useful to say when things break, and an agent that gets clear error signals can self-correct without a human babysitter. This is months of investment before the hockey-stick shows up. Organizations that respond to "we have AI now, why aren't you faster?" are actively preventing this habit from forming.

Feed agents, don't babysit them. This one is where I think the productivity gap becomes easiest to see. If you're in a back-and-forth conversation with your coding assistant all day, you are the bottleneck. You're waiting 30 to 60 seconds per round trip, you can't run multiple agents in parallel, and you're doing the cognitive equivalent of standing over someone's shoulder watching them type. The shift Liguori describes is giving agents enough context to self-validate: run, compile, pass tests, meet coverage thresholds, then surface only when those conditions are met. You're not watching; you're reviewing results. That's what makes parallelism possible. The broader AWS engineering context around tools like Kiro makes clear this isn't hypothetical; AWS engineers describe moving from hands-on iteration to reviewing batches of agent output, which is a fundamentally different job.

Make intent explicit. Liguori's observation here is one I find genuinely useful: iterating with an agent on code when the underlying intent is wrong is an expensive way to converge on the right answer. The more productive pattern is arguing about a specification document first. A document is faster to revise than a diff spread across a codebase. This habit asks engineers to front-load the thinking, to write down what they actually want before anything gets built. That's a discipline most teams claim to have and most teams skip under deadline pressure.

Shift testing left. Fast feedback loops are what let agents run for hours without human intervention. Linters, unit tests, integration tests with local deterministic mocks rather than live cloud services: these give an agent something concrete to measure itself against. Liguori's point is that the ROI on good testing infrastructure is finally high enough to justify actually building it. If your agent has to spin up cloud dependencies to know whether its output is correct, every loop is slow, and slow loops mean more human babysitting, which returns you to the problem the third habit was solving.

The costs Liguori doesn't undersell

The back half of the talk is where things get real for working engineers, and it deserves attention proportional to what it's actually describing.

"Flowmaxxing" is real, Liguori says, crediting the term to someone at a conference she couldn't recall (so: her secondhand attribution, not independently sourced). Engineers staying up late trying to craft the perfect prompt so an agent runs overnight and delivers a finished change by morning. That's not hustle culture as a productivity strategy. That's a burnout pattern with a technical flavor. The always-on relationship with AI tools creates a new version of the same trap that on-call rotations create: the sense that the system is always available to work, so you should be too.

The cognitive load issue is real, and I want to sit with it longer than Liguori does, because it touches something that affects a lot of people reading this. Senior engineers have spent years reviewing other people's code. They have pattern recognition for what's wrong, what's risky, what's technically correct but architecturally questionable. Reviewing AI output, which is often syntactically clean and idiomatically plausible, exercises exactly that muscle. For junior engineers, that muscle is still developing. Writing code is how you build it. When the primary activity shifts from writing to reviewing, junior engineers lose the training ground that built every senior engineer who's now succeeding in this new model.

This isn't a reason to dismiss frontier development. It's a reason to think carefully about how teams structured around it actually develop junior talent, and to be skeptical of any organization that celebrates 4.5x shipping velocity without asking what that velocity costs the people three years into their career. If you're early-career and feeling like reviewing AI output is harder than writing your own code, you're not failing to adapt. You're accurately identifying a genuine gap in the current model. That gap is on the model to solve, not on you.

The bottleneck that nobody's calendar is ready for

Liguori's observation about decision speed is the one that will matter most in 2026, and it's the one organizations are least prepared for.

When building a product took 9 to 12 months, a two-month approval process was friction you could absorb. When building a product takes one to two months, that same approval process is now longer than the build itself. The review meetings, the launch checklists, the stakeholder alignment cycles: these weren't designed for a world where code is the fast part. "Often I find that frontier engineering teams spend more time making decisions than they do writing code," Liguori says.

What that means practically: if you're an engineer at an organization with slow governance structures, and your team starts hitting frontier-level output, you are about to discover that your company's approval processes are the ceiling. Not your skills, not your tooling, not your habits. The org chart. That's useful to know before you spend two months overhauling your workflow and wondering why shipping velocity hasn't changed.

Liguori's prescription is to favor reversible decisions made fast over optimal decisions made slowly. That requires organizations to actually trust their teams, which is a different kind of change than rewriting steering files.

The teams that are pulling ahead aren't just using AI differently. They've accepted that the whole shape of the job is different now: less typing, more thinking; less coding, more deciding; less solo flow state, more parallel orchestration. That transition is genuinely hard, and Amazon is still figuring out how to scale it from 50 teams to thousands.

If you just got handed a Kiro license and told to go faster, here's what Liguori's data actually says your situation is: you have the same tool as everyone else, and the tool is not what determines your outcome. What determines your outcome is whether you (and your organization) are willing to do the slower, less glamorous work of changing how you actually work. If your manager is pressuring you for results before that groundwork is laid, Liguori's talk gives you something concrete to point at: Amazon's own pilot found that productivity goes down before it goes up, and skipping the investment is how you end up in the half of teams that saw less than 3x.

That's not a defense against accountability. It's just an accurate description of what the transition costs.

Rachel "Rach" Kovacs covers cybersecurity, privacy, and digital safety for Buzzrag.