Software development is now moving faster than most security programs can absorb. AI coding tools are helping teams write and commit code faster, but 2025 and 2026 research from GitLab, Veracode, and Checkmarx points to the same problem: governance, testing, and code ownership are lagging behind. If you ship AI-assisted code, the practical answer is blunt: treat it as untrusted until reviewed, scanned, and traced.
Software development has outrun its safety rails
The search intent here is informational with a practical edge: you want to understand what changed in software development, why security teams are worried, and what a sane response looks like without slowing engineering to a crawl. The uncomfortable answer is that speed itself isn’t the enemy. Unverified speed is.
GitLab’s 2026 AI Accountability Report, released on June 23, 2026, surveyed 1,528 developers and technology buyers in six countries. It found that 91% of organizations had two or more AI coding tools in active use, while 78% said developers write or commit code faster. That tracks with what many engineering managers already feel: pull requests arrive sooner, prototypes look finished earlier, and backlog estimates are getting fuzzier.
Governance didn’t keep pace. In the same GitLab report, 80% said AI tools were adopted faster than governance policies, and 92% reported governance challenges with AI-generated code. That’s not a small process gap. It’s a structural mismatch between how fast code can now be produced and how slowly most organizations still approve, test, audit, and document it.
For a broader view of how AI is changing engineering work, the shift is also visible in engineering quality skills under AI pressure. The skill premium is moving away from typing code and toward asking better questions, reviewing unfamiliar output, and spotting the kind of subtle risk that looks harmless in a green build.
The numbers are too consistent to dismiss
One study can be noisy. Several studies pointing in the same direction deserve attention. Stack Overflow’s 2025 Developer Survey reported that 84% of respondents were using or planning to use AI tools in their development process, up from 76% the prior year. GitLab’s 2026 Global DevSecOps Survey, covering 3,266 professionals, said the current code-source mix was 34% AI-generated, 37% written from scratch, and 29% copied from other sources.
The security signal is just as clear. Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models across Java, Python, C#, and JavaScript. According to Veracode, 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Java performed worst in that testing, with a 72% security failure rate across tasks.
Checkmarx added a production-risk angle in June 2026. Its Future of Application Security 2026 report surveyed 2,350 CISOs, AppSec managers, and developers across 14 countries between March 10 and March 30, 2026. The company reported that organizations with 81% to 100% AI-generated production code were nearly three times more likely to ship known-vulnerable software than those with 1% to 20% AI-generated production code, citing 47% for the high-AI-code group.
| Source | Year | Scope | Finding |
|---|---|---|---|
| GitLab AI Accountability Report | 2026 | 1,528 developers and tech buyers | 91% of organizations used two or more AI coding tools |
| GitLab Global DevSecOps Survey | 2026 | 3,266 DevSecOps professionals | 34% of code was reported as AI-generated |
| Stack Overflow Developer Survey | 2025 | Developer respondents | 84% used or planned to use AI tools in development |
| Veracode GenAI Code Security Report | 2025 | 100+ LLMs, four languages | 45% of AI-generated samples failed security tests |
| Checkmarx Future of AppSec | 2026 | 2,350 security and development professionals | High-AI-code companies were nearly 3x likelier to ship known-vulnerable software |
A concrete calculation makes the risk easier to see. If a team merges 200 AI-assisted changes in a quarter and the Veracode 2025 failure rate of 45% were even directionally applicable, 90 changes would deserve security scrutiny before production. The exact number in your codebase will differ. The workload implication won’t.
Why AI-generated code is harder to govern
Traditional software development left fingerprints. You could often tell whether a block came from a senior engineer, a Stack Overflow answer, a vendor SDK, or a rushed copy-paste from a previous project. AI blurs that provenance. GitLab reported in 2026 that 43% of respondents could not reliably distinguish AI-generated code from human-written code in their own codebase.
Maintainability is the hidden tax. In the same GitLab release, 73% were concerned about maintainability, and 82% said AI-generated code risks creating new technical debt. That squares with what good reviewers see: generated code may be syntactically tidy while repeating old patterns, adding unnecessary abstractions, or solving the wrong problem very confidently.
The pitfall nobody mentions enough is dependency hallucination. A model can suggest a package name that looks plausible, or pull in an abandoned library because it appeared in old training data. Cloudsmith’s 2026 Artifact Management Report overview said the average application now contains more than 1,200 dependencies, and its 2026 webinar page reported that only 17% of organizations had automated guardrails for AI-specific risks such as malicious model weights or hallucinated dependencies. Even if you treat those Cloudsmith figures as single-source signals, the direction is sobering.
Supply chain exposure also expands when coding agents can read repositories, propose changes, run commands, or fetch packages. Cursor’s April 2026 partnership with Chainguard, reported by Axios, is a useful market signal: serious coding-tool vendors know vulnerable or malicious open-source code is now part of the AI coding problem, not a separate issue.
Security needs to move left, but not blindly
Shifting security earlier in software development has been good advice for years. With AI coding, it becomes incomplete advice. Earlier checks help, but they don’t solve the problem if the model-generated code is reviewed by the same person who prompted it, under the same delivery pressure, with the same blind spots.
A better pattern is layered distrust. Generated code should face static analysis, dependency scanning, secret detection, software composition analysis, and human review that focuses on behavior rather than style. If you’re using agents that interact with tools or external context, the threat model also starts to overlap with prompt injection attacks against automated systems.
Some teams will be tempted to solve this with more AI review. That’s useful, but only up to a point. The review agent may catch missing input validation or a risky SQL pattern, yet it can also share assumptions with the generator. Human reviewers still matter most where business logic, authorization boundaries, and abuse cases are involved.
For teams already experimenting with agentic workflows, AI code review can reduce reviewer fatigue, but it shouldn’t become a rubber stamp. Honestly, this only makes sense if the AI reviewer is treated as one signal among several, not as the final authority before merge.
A practical security checklist for AI-assisted teams
The goal isn’t to ban AI from software development. That would be performative in many organizations and ignored in the rest. The better move is to make the safe path the fastest path, so developers don’t have to choose between shipping and following policy.
- Label AI-assisted changes in pull requests. You don’t need a scarlet letter, but reviewers should know when generated code, generated tests, or agent-made refactors are present.
- Require dependency provenance checks. New packages should be verified against trusted registries, active maintainership, license policy, and known vulnerability databases before merge.
- Run security tests before human review. Static analysis, SCA, secret scanning, and IaC checks should comment directly in the pull request, not appear days later in a dashboard nobody opens.
- Review authorization and data handling manually. AI tools are often good at boilerplate and bad at your specific trust boundaries.
- Measure escaped defects by code source. If you don’t track whether incidents came from AI-generated, copied, or human-written code, you’re debating vibes instead of evidence.
Repository context matters here. Tools that understand architecture, ownership, and past incidents are more useful than autocomplete with confidence. That’s why repository intelligence for AI coding is becoming a serious category rather than a nice-to-have feature.
Agent permissions deserve special care. If your coding assistant can open tickets, modify files, call build systems, or interact with internal APIs, you’re no longer dealing with simple code suggestion. You’re dealing with delegated capability, and the security model starts to look closer to the concerns covered in MCP server security practices.
The uncomfortable trade-off: speed versus accountability
Can faster software development still be safe? Yes, but only if accountability gets faster too. Security can’t remain a late-stage ceremony when code is being generated, edited, and merged at machine tempo.
There is also a cultural problem. The Register summarized Checkmarx research in June 2026 as finding that 70% of developers believe AI-generated code has more vulnerabilities and 30% knowingly ship vulnerable code into production. Treat that as reported secondary coverage, not a primary survey excerpt, but the behavior it describes is familiar: deadlines beat discomfort.
The counter-argument deserves airtime. AI can improve security when used well. It can generate tests, explain unfamiliar code paths, identify missing validation, and help junior developers understand secure patterns faster. Terminal-native tools and coding agents, such as those compared in terminal AI coding workflows, can be very productive when paired with strict permissions and repeatable checks.
Still, productivity gains are not automatically quality gains. In software development, code that arrives faster still has to be owned by someone. If nobody can explain why a function exists, what data it trusts, and how it fails, the organization hasn’t gained engineering capacity. It has rented uncertainty.
What good teams will do next
The strongest teams won’t argue about whether AI belongs in software development. They’ll assume it is already there and build controls around reality. Shadow AI usage, copied snippets, model-generated tests, and agent-written pull requests all need the same thing: traceability.
Start with policy that developers can actually follow. A two-page AI coding standard beats a 40-page PDF that legal approved and engineers ignore. Specify which tools are allowed, what data may be pasted into them, when AI use must be disclosed, and which code paths require human security review regardless of test status.
Then put numbers on the dashboard. Track AI-assisted pull requests, security findings per thousand lines changed, dependency additions, vulnerable packages blocked before merge, and post-release defects tied to code source. Over a few quarters, you’ll see whether AI is helping your software development process or simply making messes faster.
My view: the winners won’t be the teams that generate the most code. They’ll be the teams that delete more bad code, understand the remaining code better, and refuse to confuse velocity with progress.
FAQ
Is AI-generated code less secure than human-written code?
It can be. Veracode reported in 2025 that 45% of tested AI-generated code samples failed security tests, while Checkmarx reported in 2026 that heavier AI-code use correlated with a higher likelihood of shipping known-vulnerable software.
Should companies ban AI tools in software development?
A blanket ban is usually unrealistic. A safer approach is approved tools, clear disclosure rules, automated scanning, dependency controls, and mandatory human review for sensitive code paths.
What is the biggest risk of AI coding tools?
The biggest risk is untraceable code entering production. If you can’t tell whether code was AI-generated, copied, or hand-written, you also can’t measure its defect rate or assign meaningful ownership.
How can developers use AI coding tools safely?
Use them for drafts, tests, refactors, and explanations, but verify every security-sensitive change. Treat generated code like a helpful stranger’s pull request: useful, sometimes impressive, and never trusted by default.
EN 
FR 
ES