AI & Automation
Why Do Some Engineering Teams Gain 3× with AI While Others Reach 10×?
AI coding assistants are only the first step. I’m interested in how workflow design, validation and human handoffs shape productivity.
💡 Why do some engineering teams improve by less than 3× with AI, while others improve by more than 10×?
A while ago, someone asked me about a case mentioned in a talk from overseas.
You can watch the full talk here: https://youtu.be/pqlWNihgdjI
AWS Senior Principal Engineer Clare Liguori shared observations about AI adoption across roughly 50 development teams in Amazon Stores.
Most teams were working with similar AI coding assistants and tool environments, and their productivity did improve.
These were internal company figures, of course, but I think a sample of 50 teams is still a valuable point of reference.
Even within one large company, among very capable engineering teams using highly similar AI tools, the results were dramatically different.
Some teams improved by less than 3×. Others went beyond 10×.
So here's the question.
Why?
If the tools were similar, what actually made the difference?
The most obvious answer is probably:
"It depends on how people use AI, right?"
Yes. That's not wrong.
And I can see this quite clearly in the people around me.
The output and productivity I get from AI can be noticeably higher than what some junior developers get.
But that doesn't mean I'm exceptionally brilliant or particularly good at writing prompts.
In fact, I often ask AI to help organize my prompts first, so I can think through the problem more completely.
What really changes the outcome is that AI is working on top of my existing development and professional experience.
I know where problems might appear, what I shouldn't trust immediately, how to break down requirements, and how to verify the result.
So much of my work still follows this pattern:
Human analyzes → AI does a piece → human checks → AI continues → human takes over again.
Of course that makes things faster.
⚠️ But that's only the first layer.
It explains how an "individual" can amplify their existing capabilities using AI.
I can use AI to scale up what I've learned from my past experience.
But it still doesn't explain why a "team" might improve so much more.
What if AI didn't just help with one step, but started changing the entire Workflow—or even became an independent handoff point within it?
That may sound abstract.
Let's imagine we're a shop owner who knows absolutely nothing about website development.
All the owner says is:
"Please make a website for my shop."
Today's AI might genuinely produce something presentable within a day.
But a software engineer—especially one who has worked on medium-sized or large systems—will instinctively start asking all sorts of questions:
Is the UI/UX comfortable to use? Does the workflow make sense? How should the frontend and backend be divided? Can it handle the traffic? Might it later need membership features or grow into a digital platform? What about performance, versioning, security, and testing?
But does the client care about all of that? www
What the client really wants is:
"I want the thing I asked for to work properly."
In the past, those technical details were often handled by separate RD, QA, UI/UX, and PM roles.
Now that AI is here, it's easy for all of those tasks to land on one engineer, who keeps asking AI to do each piece.
From the "individual" perspective, that engineer becomes much faster and more versatile.
But there's a problem.
The engineer is still the biggest bottleneck in the entire workflow.
That's why what I really want to do now is let AI do more than just "execute".
I want it to participate in the Workflow itself, within clear rules and boundaries.
What do I mean?
Suppose all I say today is:
"I want to build a website for a client."
I don't want AI to simply start writing Code.
I want it to gather Context, organize requirements, make a Plan, execute, verify, find problems, and repair them.
In other words, I want AI to carry out a much longer stretch of the process on its own:
Context → Plan → Execute → Verify → Repair
And only come back to me when it reaches a decision that really requires a human.
At that point, AI isn't just changing:
Coding Speed
It starts changing:
Workflow Design
And, eventually:
Team Design
Which things truly need to be done by an engineer? Which are just moving information around, repeatedly confirming things, or waiting? Which checks can be automated directly? Where should the Human Gate stay?
And based on my own experience, this doesn't necessarily have to start with an expensive fully autonomous Agent.
Even in Chat mode, when Context, rules, boundaries, and verification are organized well, there's already a lot more work AI can carry forward.
So what I really want to study now is no longer just:
"How do I get AI to write several times more Code for me?" "How do I write better prompts?" "How should AI be configured?"
It's this:
"How can AI complete more of the steps that used to require a human in the middle?"
If we really go all the way down that road, the next question might be:
Will an RD team in the future still need the same roles and division of work it has today?
👉 In the next post, I'd like to discuss a method I'm already using myself:
Treating GitHub as AI's external memory and Source of Truth.
#AIAgents #AIAssistedDevelopment #SoftwareEngineering #EngineeringProductivity #AINative