As AI accelerates software development, security verification is becoming one of the most important challenges facing engineering teams.
Artificial intelligence is changing how software gets built. Code that once required hours of manual work can now be generated in minutes. Developers can move faster, automate routine tasks and bring new features to market with unprecedented speed.
But there is another side to this progress.
When software becomes cheaper to produce, vulnerabilities can become cheaper to discover, exploit and scale.
This was the central message of “Software Got Cheaper. So Did Attacking It,” the keynote delivered by Catalin Stoiovici and @Chris Tomlinson at the 4th Data Science & AI Summit in London.
Their presentation examined a growing challenge for organisations adopting AI-assisted software development: the gap between producing code quickly and being able to verify that it is secure.
The code works. But is it secure?
AI coding tools have made significant progress in generating syntactically correct code. Yet code that looks correct and passes basic checks is not necessarily secure.
The presentation highlighted a striking contrast: while syntax correctness has improved substantially, the security pass rate cited in the presentation remained around 55%.
The difference matters. A feature can work exactly as intended while still introducing vulnerabilities such as SQL injection, cross-site scripting or insecure cryptography.
AI-generated code also raises an important question of ownership. When nobody has carefully reviewed how a piece of code works, who is accountable for the vulnerabilities it introduces?
As AI contributes more to software development, organisations cannot assume that successful tests or an approved pull request automatically mean a system is safe.
The responsibility for software security remains with the people and organisations that build, deploy and maintain it.
The real challenge is verification
One of the most important ideas in the keynote was that this is not simply a problem of reviewing more code. It is a problem of verifying how software behaves.
Some vulnerabilities are easy to spot in a single line. Others emerge only when data travels across several components, services and application layers. A function may appear harmless in isolation, while the complete path creates a security weakness.
This makes traditional review practices harder to scale as development accelerates.
Simply asking another AI model to review AI-generated code may not be enough, either. If the reviewing model shares the original model's blind spots, the same problems can remain undetected.
The stronger approach is to combine appropriate security tools with meaningful tests, manageable changes and code that someone has genuinely examined.
The objective is not merely to produce more code or more reviews. It is to establish confidence in what is actually being shipped.
Human oversight must mean human judgement
Keeping a person in the approval process does not automatically make that process effective.
The speakers raised a critical distinction: a human in the loop is not necessarily judgement in the loop.
When people are expected to oversee increasingly automated systems, they can become overly reliant on automated recommendations, experience alert fatigue or gradually lose the skills needed to identify problems independently.
This creates a difficult balance. Organisations need to benefit from AI's speed without allowing human oversight to become a routine sign-off exercise.
Effective oversight requires people to understand what they are approving, recognise uncertainty and know when to challenge an automated result.
The faster AI makes development, the more important it becomes to preserve the time, skills and authority needed for genuine verification.
The economics of cyberattacks are changing
The keynote also explored how AI is changing the economics of vulnerability discovery and exploitation.
If attackers can find weaknesses more cheaply and at greater scale, defenders have less room for slow responses. The presentation cited research indicating that the average time from a vulnerability being patched to its first exploitation had reached negative seven days, highlighting how exploitation can precede a patch.
The speakers also examined the growing pressure on open-source maintainers and bug bounty programmes. When submitting potential vulnerabilities becomes easier, the volume of submissions can rise, including low-quality or AI-generated reports that require time and effort to validate.
This creates a new burden for security teams and maintainers: discovery may become cheaper, but distinguishing genuine threats from noise can become more expensive.
For organisations, security can no longer be treated as a final checkpoint after development. It must be built into the entire software lifecycle, from code creation and testing to deployment, monitoring and incident response.
From AI adoption to accountable engineering
The message for technology leaders is clear. AI-assisted development should not be measured by productivity gains alone.
Organisations also need to ask whether their verification processes can keep pace, whether responsibility for AI-generated code is clearly assigned, and whether their teams can identify and respond to vulnerabilities before attackers do.
The presentation closed with a practical reminder: patch, monitor, release and isolate are all part of the response, but the order and priorities matter. There is no substitute for understanding the systems being deployed and preparing to act when something goes wrong.
With the EU Cyber Resilience Act's reporting obligations beginning on 11 September 2026, as noted in the presentation, the relationship between software security, organisational accountability and regulatory readiness is becoming even more significant.
AI can accelerate software development. It cannot remove the need to understand, verify and take responsibility for the result.
The question every organisation should ask
As AI-generated code becomes increasingly common, the competitive advantage will not belong only to the organisations that can build fastest. It will also belong to those that can verify what they build, recognise what might fail and respond before a weakness becomes a breach.
The central challenge is no longer just how to produce software at scale.
It is how to know what you are shipping, and how to find the vulnerabilities before someone else does.
Keynote: “Software Got Cheaper. So Did Attacking It”
Speakers: Catalin Stoiovici and Chris Tomlinson Event: 4th Data Science & AI Summit Location: London | 1–2 October 2026
Follow Data Science Week by The People Events People Events for more insights from industry speakers on AI, data science, enterprise technology and the challenges shaping digital transformation.