There is a quiet crisis forming at the base of the software development pipeline, and most organisations won't notice it until it is already expensive. GitHub Copilot crossed 1.8 million paid subscribers in 2024. Cursor, the AI-native IDE, has become the default environment for a significant cohort of developers leaving university and bootcamps. These tools are genuinely impressive — they reduce boilerplate, accelerate prototyping, and lower the barrier to producing working code. But there is a meaningful difference between producing working code and understanding it, and that distinction is now beginning to surface in hiring processes, code reviews, and production incidents across the industry.
Senior technical leads at UK organisations are starting to report a consistent pattern: junior developers who are articulate about what they want a system to do, and almost entirely unable to reason through why it isn't doing it. They can prompt. They struggle to debug. This is not a criticism of the individuals — it is a structural outcome of how these tools are being adopted without sufficient guardrails, and it deserves serious attention from anyone responsible for building and sustaining a capable engineering team.
What the Tools Do Well — and What They Conceal
To be clear, AI coding assistants are not inherently harmful. For experienced developers, Copilot and similar tools function as a high-quality autocomplete — they handle the tedious, mechanical parts of software development and free up cognitive bandwidth for architecture, logic, and problem-solving. When used by someone who already understands what correct code looks like, these tools accelerate without atrophying. The problem is not the tool itself; it is the developmental stage at which it is being introduced.
Learning to code has always required a period of struggle. Syntax errors that won't compile, logic bugs that take hours to trace, algorithms that only click after you've implemented them badly twice — these are not inefficiencies to be optimised away. They are the mechanism by which foundational understanding is built. When an AI assistant resolves that struggle automatically, it removes the friction that drives comprehension. A developer who has never had to wrestle with a null pointer exception, trace a recursive call stack, or implement a sorting algorithm from first principles has not learned to code — they have learned to curate code. That is a different skill, and it is not a substitute.
The Measurable Gap Appearing in Engineering Teams
The evidence is beginning to move beyond anecdote. Engineering managers and CTOs in sectors from fintech to public sector digital services are describing a widening capability gap between developers who trained before widespread AI tool adoption and those who entered the workforce after it. The symptoms are specific: difficulty reading unfamiliar codebases, inability to articulate the time or space complexity of a proposed solution, and a troubling tendency to accept AI-generated output without interrogating whether it is correct or appropriate for the context.
This last point carries particular risk. AI coding tools do not always produce secure, performant, or idiomatic code. They produce plausible code — code that often works in the happy path but may introduce subtle vulnerabilities, inefficient patterns, or dependencies that are inappropriate for the licensing or compliance requirements of a given project. An experienced developer catches these issues during review. A developer who has been trained primarily to evaluate code by whether it runs, rather than whether it is well-constructed, may not. The consequence is technical debt that is difficult to detect and expensive to remediate, accumulated quietly over months of AI-assisted but under-scrutinised development.
Why This Is a Leadership Problem, Not Just a Training Problem
It is tempting to frame this as an education issue — something to be resolved by universities updating their curricula or bootcamps reintroducing fundamentals. Those adjustments are needed, but they do not absolve technical leaders of responsibility. The decisions being made right now about how AI tools are provisioned, supervised, and integrated into development workflows will determine the capability trajectory of engineering teams for years. If junior developers are given full, unrestricted access to AI coding assistants from day one without structured guidance, mentorship, or deliberate opportunities to work through problems independently, the organisation is effectively outsourcing its training programme to a large language model.
This matters at the strategic level because capability in a software team is not just a function of what individuals can produce today — it is a function of the team's capacity to reason through novel problems, adapt to new constraints, and maintain systems whose original authors have moved on. A team that cannot read, reason about, or modify code without AI assistance is brittle in ways that may not be immediately visible but that become acute during incidents, migrations, and architectural transitions. Technical leaders need to think of foundational engineering skills the way they think about security posture: not glamorous, not optional, and considerably cheaper to maintain than to rebuild.
Practical Guardrails for Organisations Adopting AI Development Tools
None of this argues for banning or restricting AI tools wholesale — that would be both impractical and counterproductive. The competitive advantages these tools offer are real, and organisations that ignore them will fall behind on delivery speed. The goal is intentional adoption: deploying AI assistance in ways that accelerate productive developers without substituting for the development of junior ones. Some practical approaches are already proving effective. Structured 'no-AI' exercises — debugging sessions, algorithmic problem sets, or code review tasks conducted without tool assistance — can be built into onboarding and ongoing development programmes without significant overhead. Pairing junior developers with senior engineers for a defined proportion of their working week, with explicit expectations around explanation and reasoning, preserves the mentorship dynamic that AI tools cannot replicate.
Code review processes should also be revisited with this risk in mind. Reviewing AI-generated code requires a slightly different posture than reviewing human-written code — reviewers should be specifically checking for the subtler failure modes: overengineering, inappropriate library choices, security assumptions that don't hold in the production environment. Teams that treat AI-generated output as a starting point to be critically evaluated, rather than a solution to be lightly approved, will build better habits across the entire engineering function. The objective is not to be sceptical of the tools but to ensure that the humans using them remain the ones doing the thinking.
The organisations that will manage this transition well are not those that restrict AI tools most aggressively, nor those that deploy them most enthusiastically — they are those that are most deliberate. If you are a CTO, an engineering director, or a technical lead responsible for a team that includes developers in the early stages of their career, the time to establish clear norms around AI tool use is now, before the capability gap becomes load-bearing.
At iCentric, we work closely with technical teams navigating exactly this kind of structural challenge — building bespoke software solutions that require genuine engineering rigour, and helping organisations think clearly about how they build and sustain the teams that deliver them. The question of how AI tools should fit into a healthy development culture is one we are thinking about carefully, and we are happy to explore it with you.
At what career stage does AI tool use become risky for skill development?
The risk is highest in the first two to three years of a developer's career, when foundational habits around debugging, code comprehension, and algorithmic reasoning are still forming. Once those foundations are solid, AI tools tend to amplify capability rather than replace it. The critical period is early — and that is precisely when most organisations give the least structured guidance on tool use.
How can we tell whether our junior developers are over-reliant on AI tools?
A reliable signal is performance under constraint: ask a junior developer to debug a straightforward issue without tool assistance, or to walk you through the logic of a solution they have submitted for review. If they cannot explain the reasoning behind AI-generated code or struggle significantly without autocomplete, that indicates dependence rather than competence. Structured technical interviews that include unprompted problem-solving are also revealing.
Do AI coding tools pose a risk to code security, and how serious is it?
Yes, and the risk is underappreciated. AI coding assistants are trained on public code repositories, which contain a significant proportion of insecure patterns. They will suggest code that compiles and runs correctly while introducing SQL injection vectors, insecure dependency choices, or improper input validation. Developers who lack the experience to recognise these issues — and who treat AI output as reliable by default — are a material security risk. Security-aware code review is essential.
Is this problem specific to junior developers, or does it affect senior engineers too?
Senior engineers are not immune, but they are considerably more resilient. Because they have existing mental models of correct code, they are better placed to interrogate AI suggestions critically. The more relevant risk for experienced developers is overconfidence in AI-generated solutions in unfamiliar domains — assuming the output is correct because it looks plausible. This is a different failure mode, but it still warrants deliberate attention.
Should organisations restrict AI tool access during onboarding periods?
A measured restriction during specific onboarding exercises is reasonable and increasingly common in technically rigorous organisations. The goal is not a blanket ban but a structured introduction — ensuring developers spend defined time working through problems independently before AI assistance is introduced as a productivity layer. This mirrors how proficiency in other technical disciplines is developed, and it need not significantly delay a new hire's contribution to real work.
How do you build AI tool policies that senior developers will actually follow?
Policies that treat AI tools as inherently suspicious tend to be ignored. More effective is framing the guidance around code ownership and review responsibility — making clear that every developer is accountable for the correctness, security, and maintainability of code they submit, regardless of how it was generated. When individual accountability is explicit, the incentive to understand AI-generated output rather than simply pass it along changes accordingly.
Are UK universities and bootcamps adjusting their curricula to address this?
Some are, but progress is inconsistent. A number of UK university computer science programmes have introduced AI-tool-restricted assessments and increased emphasis on algorithmic fundamentals in response to these concerns. Bootcamps are more variable — commercial pressures can push them towards teaching the fastest path to employment, which currently involves heavy AI tool use. Employers should not assume that new hires arrive with AI-independent competence, regardless of their training background.
What does good mentorship look like in a team that uses AI coding tools heavily?
Good mentorship in this context means deliberately creating space for explanation and reasoning that the AI skips over. Senior developers should regularly ask juniors to articulate why a solution works, not just confirm that it does. Pair programming sessions where the AI tool is set aside for part of the session, and code walkthroughs that require the junior developer to explain logic unprompted, are practical mechanisms that preserve the learning dynamic without significantly reducing team output.
How does this issue affect organisations that outsource development or use contractors?
For outsourced and contract development, the risk shifts: you have less visibility into how code was produced and less opportunity to assess individual capability directly. It becomes more important to specify quality and review standards in contracts, to include security and code quality audits as part of acceptance criteria, and to ensure that any code being absorbed into a long-term codebase has been reviewed by engineers capable of evaluating it critically — not just tested against functional requirements.
Is there evidence that this problem will self-correct as the technology matures?
There is no strong basis for assuming self-correction. If anything, as AI tools become more capable, the temptation to defer to them increases rather than decreases, and the gap between what a developer can direct and what they can independently produce may widen further. Structural interventions — in hiring standards, onboarding practice, and code review culture — are more reliable than waiting for the technology or the market to resolve the issue organically.
Get in touch today
Book a call at a time to suit you, or fill out our enquiry form or get in touch using the contact details below