TLDR AI doesn’t make teams better - it makes their existing quality impossible to hide.
Let me say this upfront - I’m not anti-AI. I use it every day, it saves me hours, and I wouldn’t want to go back.
But with all the AI cheerleading right now, there’s a quieter truth that doesn’t get talked about. I’ve been speaking to senior engineers, engineering managers, and CTOs across different teams, and the sentiment is surprisingly consistent. Everyone feels the same shift happening, but almost nobody is saying it out loud - especially not upwards.
So let’s talk about the problem.
We’ve all heard the idea that LLMs can 10x engineer output. In reality, that only really applies to engineers who already understand what they’re building.
When someone understands the patterns, architecture, and tradeoffs, an LLM becomes a genuine accelerator. It helps them move faster, explore options, and spot issues earlier. But without that foundation, the same multiplier works in the opposite direction - amplifying weak decisions, poor structure, and unnecessary complexity.
If you’ve ever asked an LLM a simple question and got way more than you needed, you already understand the problem. Coding is no different - LLMs generate far more than what’s required.
Now scale that across a team.
So yes, some engineers might be 10xed. But the flip side is just as real - for others, the multiplier runs in reverse, turning a -1 into a -10. More output, more problems, and more work for the rest of the team.
We’d all love to hire only great engineers, but that’s rarely how teams actually turn out. Most teams are a mix - and that mix is exactly where LLMs amplify everything, both good and bad.
What’s changed is that it’s getting harder to tell the difference. AI makes it easier to produce convincing output without fully understanding it, and the signals we used to rely on are getting noisier.
And even if you could identify it perfectly, it’s not static. People burn out, priorities shift, standards slip.
So this isn’t something you can solve purely through hiring.
In theory, that’s fine - because code gets reviewed.
You’d think this wouldn’t be a problem because “all code gets reviewed.” And that’s true - in theory. But once you have more than one of these engineers, that safety net disappears.
They review each other’s work, approve it, and low-quality LLM-generated code slips into the codebase unnoticed until much later. Meanwhile, stronger engineers end up catching everything else - filtering large volumes of generated output, rewriting it, and trying to keep standards intact.
At some point, your best engineers stop being builders and become AI cleanup specialists. A title that started as a joke but slowly became a reality
That cost adds up quickly. The more low-quality LLM-generated output the team produces, the more your best engineers get pulled into review work instead of building. They become the bottleneck, they get frustrated, and eventually they burn out or disengage.
And once they leave, everything gets harder - and the decay accelerates.
On the surface, AI makes teams look faster. You see more pull requests, more commits, more activity, and a general feeling that things are moving. But velocity and activity aren’t the same thing. When output goes up without the right filters in place, what you actually get is noise disguised as progress.
Good engineers produce more - and then spend more time reviewing. Others also produce more - and then approve each other’s work.
Everything looks healthy on the surface. But behind the scenes, senior engineers are stretched thin, foundational decisions get deferred, and the roadmap quietly slows down.
This is the velocity illusion - the team feels busier, but the organisation slows down, because the work isn’t actually moving the needle.
All of this extra code doesn’t just create review overhead - it quietly drives up costs across the entire stack. More code means longer builds, more CI minutes, and more dependencies. It happens slowly, almost invisibly, until one day a simple pull request takes ten minutes to build instead of two.
Every extra build, every unnecessary dependency, every longer pipeline turns into more compute.
And whether intentional or not, the incentives are simple - more compute means more revenue.
The easier it is to generate code, the easier it is to consume compute.
And right now, the house is winning - not your team.
Right now, you’re looking at companies you’ve invested in - teams of 50, 100, sometimes more engineers - and comparing them to a single builder shipping faster than ever.
One person, a few tools, and something real in days.
But that’s the wrong comparison.
A solo builder is working without constraints. No legacy systems, no coordination overhead, no long-term maintenance. They can move fast because they’re not carrying the weight your companies are.
Your teams are.
So when you ask, “why can’t they move this fast?” - you’re not measuring execution, you’re ignoring context.
The same applies to SaaS.
Looking at a new pitch and asking “couldn’t this just be built with AI?” misses the real question.
It’s not whether something can be built quickly - it’s whether it can be maintained and built on top of.
Because building has never been the expensive part.
Maintaining is where the cost lives. Every line of code is a liability
And you’re already starting to see the impact. Systems become less reliable, harder to change, and slower to evolve.
Not because they can’t be built quickly - but because of how they were built.
AI makes it cheaper than ever to build. But it doesn’t make it cheaper to maintain - in many cases, it does the opposite.
And the quality of what you build determines which side you end up on.
So before you push for more output, fewer engineers, or higher “AI adoption” - make sure you’re measuring the right thing.
Because once you optimise for the wrong signal, everything downstream follows.