A canary in the coalmine
As 2026 rolls on, our capacity to prompt ourselves silly appears to be limitless.
We’ve already seen the financial, legal, and reputational damage to Deloitte as they partly refunded the Australian government for a 237-page audit report containing LLM-generated hallucinations like fabricated academic references, fake footnotes, and a false quote attributed to a judge.
Naturally, organisations should always explore the full potential of new technologies. But as developers at Meta, Microsoft and Salesforce have started to intentionally burn tokens to inflate the LLM usage targets (a.k.a “Tokenmaxxing”), it’s a warning sign for security leaders to get a grip on unfettered LLM-adoption in DevOps.
Because the trajectory of LLM-generated software and DevOps teams’ ability to maintain security are heading in opposite directions.
The direction of travel
Excluding a model’s training and reasoning limits, the limitations on LLMs to generate new code are set by our capacity to buy tokens, compute power, semi-conductors, data centres, and energy. In other words – an upward trajectory with no signs of stopping.
In contrast, a competent DevOps engineer’s ability to ensure said code’s functionality and security is limited by time, expertise, and – if we listen to increasingly developers – a diminishing motivation to embrace a new role where once-central creativity is relegated to LLM prompting and mountains of LLM-generated code review.
Let’s assume, generously, that the average number of new or changed lines of code (LOC) to review pre-LLM adoption was ~200-300/week. Today, a senior DevOps engineer can easily have several thousand new or changed lines to be reviewed, tweaked, tested, and maintained in the same period. But has their capacity increased?
Studies from OECD, MIT, Google SAIF, and first-hand developer accounts (detailed below) indicate DevOps’ engineers’ capacity to review, secure, and maintain is trending downwards with decreased system-level reasoning, less motivation, and simply not enough time to tackle the growing volume of LLM-generated software.
The asymmetry here is increasingly important. While defenders struggle to review rapidly expanding codebases, attackers can now use LLM-assisted tooling to extract architectural context, CI/CD trust relationships, and exploitable entry points from public repositories in minutes rather than days.
From a risk management perspective, this trajectory is not sustainable if security strategies are not refined for the LLM-code era.
Where exactly is risk introduced
LLM-generated flaws are harder to detect over time as code is constantly revised, creating latent risk that survives commits and maintenance cycles. Much like the visibility gaps exposed by SolarWinds or Log4Shell, organisations may struggle to answer where vulnerable code came from, where it exists, and whether it was ever properly reviewed.
It’s not just vulnerabilities being introduced. At a systematic level, risk is introduced in several ways:
- Fragmented development practices – inconsistent AI/LLM usage across teams (different tools, different behaviours) breaks standardisation and introduces unpredictable security gaps.
- Compounding technical debt through churn – high-volume LLM-generated code leads to disorganised logic, excessive rewrites, and growing complexity that becomes unmanageable over time
- Misplaced trust and reliance – Developers using AI tools are more likely to produce insecure code than those writing unaided. The issue is not intent or competence but over-reliance. When models produce something that looks correct, users are less likely to question it deeply.
- AI/LLMs as an unintended dependency – AI tools embed themselves into the development lifecycle organically, creating long-term reliance and risk that organisations neither planned for nor can easily reverse.
The human aspect
Several studies on the psychology of disengagement, such as the OECD’s ‘The Impact of AI on the Workplace’, have detailed the role of displacement and erosion of autonomy in highly-skilled technical roles such as development. These often-unheard changes are expressed by an increasingly vocal minority of developers, such as Mo Bitar, who has typified and amplified the sense of de-motivation many developers are experiencing.
And within this period of change, developers’ are potentially de-skilling. An MIT study has indicated the prevalence of reduced deep engagement and the loss of ‘system-level reasoning’ which is critical for both functionality and security. Dynamic person-to-person conversations about design, and creativity and deep concentration needed to iterate a truly great product (generally a core reason to love developing) are diminished. In some circles, caring about the code has become “micro-management”, rather than the formerly essential attention to detail, care for the final product, and ultimately the end user.
It’s therefore unsurprising that SonarSource’s 2026 code quality survey found that while 96% of 1000+ developers do not trust the code AI produced, only 48% said they fully reviewed the output. Is this apathy to a new working reality, or simply the impossibility of secure review at increased scale, and a clear indicator that unchecked AI-coding will introduce long term insecurity.
Despite these challenges, a reactive, binary policy of either no LLM code or all LLM code is not the answer. There is a more nuanced message for organisations pursuing or starting to pursue this productivity-driven AI-code path who are seriously reconsidering their approach.
Strategy is everything
Unless you are truly an AI-first company with a ‘develop fast, think later’ policy, the productivity gains are not necessarily worth accruing technical debt and embedding long-term security risk if careful management is lacking.
To avoid the overdone ‘Art of War’ reference; just because Manchester City are ‘playing it out from the back’, doesn’t mean every other team in English football should too. If your goal is to achieve a competitive advantage, strength comes from applying the right strategy for your position, not blindly copying someone else’s. In DevOps terms, adopting AI-driven development without the capability to review, secure, and maintain introduces risk, not advantage.
Organisations looking to safely introduce LLMs into development workflows or offsetting future disruption can tackle the risk head on. Tooling options can help, but there’s several fundamental steps that can first be applied:
- Acknowledge the change and re-engage DevOps engineers. If developers are disengaged, deskilled, or overwhelmed by review workloads, security controls will degrade in practice. Organisations need to actively address workload, restore ownership, and ensure engineers remain accountable for and invested in the code they ship
- Tag AI-generated code and build specific review gates around it to counter invisible vulnerability drift. Traditional SAST wasn’t calibrated for AI output patterns. If you can’t identify where AI touched your codebase six months from now, you can’t audit it.
- Standardise your AI tooling or accept that you haven’t, to counter fragmented practices. Letting every team pick their own LLM or IDE plugin feels like autonomy but from a security standpoint, it’s policy fragmentation. Teams building core infrastructure shouldn’t operate with fundamentally different security postures.
- Set a velocity ceiling, not just a velocity target to counter compounding technical debt. Volume without comprehension is how you get a codebase nobody fully understands. If the pace of generation has outrun the pace of understanding, slow down before the codebase does it for you.
- Make scepticism a policy, not a personality trait to counter misplaced trust. The fact that 96% of developers distrust AI output, and only 48% fully review it may in small part be due to apathy, but realistically it’s volume overload. DevOps teams can formalise the doubt developers already feel by implementing mandatory human sign-off on AI-generated code in defined risk areas.
- Audit your AI tool dependencies to counter unintended reliance. The Trivy breach and SmartLoader MCP spoofing incidents in 2026 have already highlighted the tools developers trust implicitly are also being actively targeted. Map what’s in your pipeline, what data leaves your environment, and build exit criteria. Treat AI tooling as a zero-trust third party, because attackers are already doing it.
Embrace the change
For decision-makers who may not work intimately with development – your DevOps team and personnel are arguably the part of your business in the most heightened state of AI-driven change. We know chaos breeds insecurity. And so there is a choice to either embrace the change with appropriate oversight and risk reduction strategies or to blindly embed long term business risk.
This issue is a fundamental psychological shift for the people tasked with developing the core infrastructure your business is built on. Across academia and government-level studies, there is consistent evidence that AI-assisted development is introducing measurable security risks. Google’s Secure AI Framework (SAIF) does not treat AI-generated code as a neutral efficiency gain, explicitly flagging it as a new attack surface, and one that introduces risks across the software supply chain, from insecure generation patterns to downstream dependency exposure.
The UK’s National Cyber Security Centre guidance is more direct, warning that AI-assisted development introduces systemic vulnerabilities if outputs are not rigorously reviewed and governed. The risk is not just individual bugs, but structural weaknesses emerging from how LLM-generated code is used at scale.
Sean Moran
Head of Research & Enablement