AI won't fix a weak engineering team: 5 signs yours might be one

Most CTOs we speak to didn't buy AI coding tools because their team was brilliant. They bought them because something wasn't working. For example, their delivery was slow, the backlog kept growing, or a competitor seemed to ship twice as fast. AI looked like the way to close the gap without another six months of hiring.

It's a bet, but it's also the one most likely to disappoint.

Google's DORA research team put it in one line in its 2025 State of AI-assisted Software Development report: "AI doesn't fix a team; it amplifies what's already there." Strong teams get stronger. Struggling teams find their problems arrive faster, in bigger batches, with more code attached.

We've written about how AI reveals which Engineers are Elite and why the same AI tool gives different results depending on who uses it. This article is moving the focus away from the person to the team. If AI is an amplifier, the useful question isn't "which tool should we buy?" It's "what exactly will it amplify here?"

Below are five signs the answer might be a weak engineering team, and what to do about each one.

Can AI fix a weak engineering team?

No. And the reason matters more than the answer.

A weak engineering team is rarely weak because its people can't write code. It's weak because the system around the code is fragile. Reviews are slow. Tests are thin. Ownership is fuzzy. Decisions live in someone's head. Requirements arrive half-formed.

AI speeds up exactly one part of that system: producing code. Everything downstream stays the same speed, or slows down under the extra load.

The DORA data shows this directly. In 2025, AI adoption was linked to higher delivery throughput for the first time. It was also still linked to lower delivery stability. DORA's explanation is plain: without strong automated testing, mature version control and fast feedback loops, more change volume leads to more instability. Teams with loosely coupled architecture saw gains. Teams stuck with tightly coupled systems and slow processes saw little or no benefit.

Same tools. Different foundations. Opposite results.

Why isn't AI improving productivity for every team?

Because individual speed and team delivery aren't the same thing.

Faros AI's AI Productivity Paradox report tracked telemetry from more than 10,000 developers across 1,255 teams. On teams with high AI adoption, developers completed 21% more tasks and merged 98% more pull requests. That sounds like a win until you look at what happened next:

• PR review time went up 91%
• Average PR size grew 154%
• Bugs per developer rose 9%
• At company level, Faros found no significant correlation between AI adoption and better throughput, DORA metrics or quality

Faros points to Amdahl's Law: a system only moves as fast as its slowest link. Speed up code generation and the slowest link becomes review, testing or release. On a strong team, those links were already solid. On a weak one, they were the problem to begin with.

So how do you tell which one you're running? Look for these five signs.

How do you know if your engineering team is weak? 5 signs to check

1. Is your code review queue growing faster than your output?

This is usually the first sign, and the easiest to miss, because the dashboard looks great. More PRs. More commits. More tickets closed.

Then look at the queue. If pull requests are sitting longer, getting bigger and receiving lighter reviews, AI hasn't made your team faster. It has moved the bottleneck from writing to reviewing.

On a team a few senior Engineers can take that shift because senior Engineers already review well and set clear standards. On a team review was already the smallest part. Now review has double the work. Reviewers skim. Approvals come faster, not because the code is better. Because no one has time to review carefully.

What to check: median time from PR opened to merged, average PR size, and how often reviews come back with no comments at all. Compare the last three months with the three months before AI adoption.

2. Do more releases mean more incidents?

A weak engineering team often looks fine when it ships slowly. Slowness hides instability. Fewer deploys means fewer chances to break things.

AI removes that cover. DORA's 2026 ROI of AI-assisted Software Development report, covered by InfoQ, calls this the "instability tax". Its sample model shows the change failure rate rising from 5% to 6% after AI adoption, enough to erase hundreds of thousands in value through downtime alone.

If your deploy frequency went up and your incident count went up with it, your safety nets weren't built for this volume. That means weak automated testing, manual change approval, big releases instead of small ones, and rollbacks that take hours instead of minutes.

What to check: change failure rate and time to restore service, before and after AI adoption. If either got worse, fix the pipeline before you add more speed to it.

3. Is your team copying code instead of improving it?

Healthy codebases get refactored. Engineers spot repeated code, take it out, and put it into shared modules so the system becomes easier to update. It’s work. It’s not exciting.. When a team is under pressure, this is the first thing that gets cut.

Now AI makes it even easier to skip. Why go back? Clean things up when you can just generate a new version in seconds?

GitClear's research on 211 million changed lines of code shows what that looks like at scale. Between 2021 and 2024, the share of changed lines linked to refactoring fell from 25% to under 10%. Copy-pasted code rose from 8.3% to 12.3%. For the first time in GitClear's data, cloned code overtook moved code.

A strong team treats that as a warning and pushes back. A weak team doesn't notice until every change touches five places and nobody's sure which copy is the real one.

What to check: how often your team refactors versus adds, whether duplicated blocks are rising, and how long "small" changes are starting to take.

4. Does only one person really understand how the system works?

Every weak engineering team has one. The Engineer who gets pulled into every incident. The one whose holiday slows the whole roadmap. The one who knows why that config flag exists and what happens if you change it.

That's a people risk without AI. With AI, it becomes a quality risk too.

AI tools only know what they can see. If your architecture decisions, edge cases and business rules live in one person's head instead of in docs, tests and code, the AI generates plausible code with none of that context. The newer Engineers who lean on it most can't tell what's missing.

Faros saw exactly this split. AI use was highest among Engineers newer to the company, who used it to find their way around unfamiliar codebases. Adoption was lower among senior Engineers, who seemed less convinced it could handle work that depends on deep system knowledge. DORA lists "AI-accessible internal data" as one of the seven capabilities that make AI pay off. A team that runs on tribal knowledge has none.

It also explains a finding DORA cites from Stanford research: AI delivers 35 to 40% productivity gains on simple greenfield tasks, but often 10% or less on complex legacy code. Legacy systems are where undocumented knowledge piles up.

What to check: your bus factor for each critical service, how current your architecture docs are, and whether a new joiner can ship safely without asking the same person every time.

5. Can your team explain why it's building what it's building?

This one isn't about code at all, which is why it's easy to overlook.

On a weak engineering team, Engineers work from tickets they didn't help shape. They don't know the customer problem behind them. Priorities change mid-sprint. Nobody can say what "done" means beyond "the ticket is closed".

Give that team AI, and it builds the wrong thing faster.

DORA found that a user-centric focus is a prerequisite for AI success. AI is most useful when it's pointed at a clear problem, and that focus increased its positive effect on team performance. Without it, AI output drifts because the direction was never clear in the first place.

This is also where adding more Engineers stops speeding up delivery. More hands, human or AI, can't make up for unclear ownership and direction.

What to check: ask three Engineers, separately, what the current quarter's most important outcome is. If you get three different answers, AI won't fix that.

Should you cut engineers or fix the system first?

Fix the system. The data is fairly clear on this.

DORA's 2026 ROI report describes a "J-curve": most organisations see a temporary productivity dip after adopting AI, driven by the learning curve, the verification cost of reviewing AI-generated code and the need to rework testing and change approval. Leaders who read that dip as failure and cut budget or people during it risk losing the return completely.

The report goes further and discourages headcount reduction as an AI strategy. Keeping and training existing staff is more cost-effective, and it protects the institutional knowledge that sign 4 depends on.

In practice, fixing the system usually means:

• Small batches, so reviews stay readable, and rollbacks stay cheap.
• Automated testing strong enough to catch what reviewers miss.
• Clear ownership of every service and every decision.
• Documentation and context that both people and AI tools can reach.
• Senior Engineers with the judgement to set standards, not just enforce them.

None of that is new. It's the same engineering discipline that mattered before AI. AI has just made the cost of skipping it visible, and much faster to arrive.

What should CTOs do if they spot these signs?

Start by measuring the system, not the tool. If AI adoption went up and review time, incident rates, or rework went up with it, you're not looking at an AI problem. You're looking at an engineering foundations problem that AI has brought to the surface.

Then look at capability, not headcount. A weak team rarely needs more people. It needs the right few people, with the judgement to review well, refactor when it counts and own the system end to end. That's the thinking behind sizing teams around capability rather than capacity, and why so many CTOs are now weighing 10 developers aga.

inst 3 elite Engineers

It's also what Elite Systems. Elite Teams. means for us at TechPods. We build dedicated teams of Bulgarian Engineers who sit in your standups, work in your codebase and share ownership of the system, not just the ticket queue. We look for Engineers who can orchestrate AI instead of just using it, and who strengthen the foundations AI needs to be worth the licence.

If two or more of these signs sound familiar, talk to TechPods before the next AI tooling budget goes to the board. Co-Sourcing, NOT Outsourcing.