Several years into a software development career, the signals can be subtle at first. Features ship faster, review queues grow longer, yet the progression conversation with your line manager went nowhere useful, and the deep technical confidence you expected to have built by now feels harder to locate. If that describes your situation, the data says you are not alone. A survey of 1,000 developers across the UK, US, Germany, Spain and the Netherlands, published by Adaptavist in November 2026, found that mid-career developers are the group most likely to say AI is holding back their professional progression. The UK is one of the five markets surveyed, making the findings directly relevant to developers working here.

What the Adaptavist survey found about the middle of the career ladder

The research, based on fieldwork carried out in March 2026, divided respondents by career stage. Among mid-career developers, 35% said AI is negatively affecting their career progression. That figure sits noticeably above the 26% of early-career developers and 27% of experienced developers who said the same thing. The gap matters because mid-career is precisely the stage where developers in UK engineering teams are expected to shift from completing tickets to owning technical decisions, a transition that relies on accumulated depth rather than speed alone.

The frustration stretches beyond progression anxiety. Given a free choice, 44% of mid-career developers would remove AI from the workplace altogether, compared with 31% of early-career developers and 40% of experienced ones. Across the whole sample, 54% said AI is making them more anxious about their long-term career prospects, and nearly half believe software development is becoming a less attractive career because of it. For anyone at this stage of a UK tech career, those numbers warrant a considered response rather than dismissal.

The Chartered Institute of Personnel and Development (CIPD), which surveys UK employers annually on learning and development spend, has consistently reported that technology roles attract some of the highest employer investment in training. Whether that investment is translating into genuine technical depth, rather than surface-level AI-tooling courses, is a fair question for UK developers to put directly to their managers.

Less hands-on coding means fewer chances to learn

The survey points to a learning gap, not simply a morale problem. According to Adaptavist, 63% of developers say AI has reduced how much they learn through hands-on coding. Overall, 43% feel they have fewer learning opportunities because of AI, rising to 45% among experienced developers.

There is also a quieter concern about what counts as expertise over time. 44% of respondents believe AI is making core software engineering skills less important, and seven in ten are concerned that junior developers are becoming too reliant on the technology. Matt Saunders, DevOps lead at Adaptavist, put the tension plainly:

Developers may be relying on automation for more of their work, but they still need hands-on experience to understand the code, solve problems and make sound technical decisions.

That observation carries particular weight in the UK context. The Resolution Foundation has argued in several reports on skills investment that the UK has historically underinvested in workforce upskilling relative to comparable economies. When AI tools absorb the routine work that once trained mid-career developers in depth, the risk is that a structural skills gap compounds an already patchy picture of on-the-job learning.

Prospect, the trade union representing around 150,000 engineers and technical professionals, including members at firms such as ARM Holdings in Cambridge, has flagged concerns about how automation reshapes career development pathways. Those concerns map closely onto what the Adaptavist survey captures: speed gains at the surface do not automatically produce the technical judgement that gets engineers promoted.

Your job is shifting from writing code to supervising it

The day-to-day reality of development work is changing in observable ways. Half of respondents (51%) say they now manage AI rather than simply use it. Around 82% regularly deploy multiple agents for a given task, and nearly seven in ten say monitoring and overseeing agents is now an explicit part of their daily role. Three in five say their employer expects them to deliver more with fewer resources because AI is available.

Trust in those agents is not unconditional. 29% say AI needs tighter human oversight, 21% are less willing to grant agents full autonomy, and four in ten now review AI-generated output more closely following high-profile incidents involving AI systems.

That oversight work is a genuine skill, but only if the person doing it understands what they are reviewing. Spotting a subtle logic error in an agent's pull request draws on exactly the hands-on knowledge the survey says is getting harder to build. Oversight without depth is, in practice, guesswork with a sign-off attached. For UK developers thinking about how their role appears on a CV or in a performance review, the distinction between active technical oversight and passive rubber-stamping is worth making explicit with your manager.

ACAS (Advisory, Conciliation and Arbitration Service) guidance on performance management emphasises that employees have a reasonable expectation that the work they are measured on reflects their actual contribution. If your performance review criteria have not kept pace with how your role has changed, that is a concrete point to raise, with reference to your job description, before the annual cycle closes.

Five ways to keep building real skill alongside AI

None of this is a case for rejecting the tools. It is a case for being deliberate about where your learning comes from, and for protecting that learning even when sprint velocity is the metric your team is tracking. A few habits worth adopting:

• Protect some unassisted practice. Pick a slice of work each sprint, perhaps a tricky bug or a small feature, and work through it without an assistant. Treat it as deliberate practice, not inefficiency.
• Explain before you merge. If you cannot explain clearly why AI-generated code works, you have found a gap worth closing. Read the documentation, trace the logic, then approve. That process itself builds the technical fluency that progression conversations reward.
• Volunteer for decisions, not just delivery. Design reviews, incident write-ups and architecture discussions are where mid-career judgement becomes visible. These are also the contributions most likely to show up positively in a promotion case.
• Make your oversight work legible. Keep a brief log of issues you caught in AI-generated output and their likely cost if missed. It turns invisible review work into evidence you can bring to your next progression conversation.
• Track what you have learnt each quarter. If the list is shrinking, that is worth raising with your manager before the gap shows up in your confidence, your performance rating, or your CV.

What to ask your employer, or your next one

The Adaptavist research concludes with a call for organisations to rethink how they measure AI adoption and to actively support developers through the transition. Developers in the study said they would rather be judged on software quality, delivery speed, productivity and cost savings than on AI usage volume alone. You can bring that same framing into your own conversations at work.

In your next one-to-one or formal review, it is entirely reasonable to ask:

• Is there a training budget or ring-fenced learning time, and does it cover deep technical skills as well as AI tooling?
• How is AI use measured in performance reviews, and does oversight and review work count towards progression criteria?
• Who provides technical mentorship to mid-career engineers now that more of the routine work is automated?

The CIPD's annual Learning at Work Survey regularly finds that UK employees in technical roles report a gap between the training their employer offers and the skills they feel they actually need. If your employer's answer to these questions is vague, that gap may be wider than the job description suggested. If you are weighing a move, add the same questions to your interview checklist. A team that has genuinely thought about how engineers grow alongside AI will usually offer a concrete answer. When you reach salary negotiation, a learning budget, conference allowance or certification support can be worth asking for alongside base pay. The ONS Annual Survey of Hours and Earnings (ASHE) publishes pay benchmarks for software and IT roles in the UK, which gives you a grounded starting point for any compensation discussion before you walk into the room.

The wider signal for UK developers

Matt Saunders summed up what is at stake in the same research: AI is changing what it means to be a software developer, but organisations cannot afford to lose sight of how engineers develop their skillsets. That observation carries real weight in a UK market where, according to DSIT's UK Semiconductor and Digital Technology Strategy, the government has identified software engineering talent as a critical long-term asset worth investing in. The challenge for individual developers is that institutional strategy does not automatically translate into a learning conversation with your line manager on a Thursday afternoon.

If you are mid-career and feeling the squeeze, the survey data is clear: that reaction is a broadly shared professional response to a structural shift, not a personal shortcoming. Prospect and other bodies representing technical workers have begun documenting how automation is reshaping career development expectations across engineering disciplines. The practical response, for now, is to keep some of your learning in your own hands, make your technical judgement visible in the work you choose to take on, and ask specific questions of employers about how skill-building is treated, as part of the job rather than an optional extra added to the bottom of a job advertisement.