Topic starter
02/08/2026 11:31 am
TL;DR: AI-assisted code generation is accelerating software output faster than security review can keep up, while static analysis that explains risk in developer context may finally narrow the gap, according to Semgrep. The deeper shift is upstream: organisations are moving from catching bad code in production to preventing it in the IDE and pull request.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “28 Years Later: Some Things Changed. The Important Stuff Didn't.”.
Key questions
Q: How should teams stop AI-generated code from introducing insecure patterns before merge?
A: Security teams should enforce checks in the pull request and IDE workflow, because that is where insecure code can still be stopped cheaply.
Q: Why does AI-assisted development create more security risk even when scanners improve?
A: Because scanners only help if the team can act on their output.
Q: What are the signs that shift-left security is being applied too late?
A: Shift-left security is being applied too late when vulnerabilities are discovered after code has already moved far through the pipeline, forcing teams back into rework.
Practitioner guidance
- Embed security checks into pull requests Require authentication, authorisation, and secret-handling checks before merge so insecure patterns are blocked before release, not found after deployment.
- Tune developer-facing findings for context Use findings that explain the code path, likely exploitability, and developer-relevant remediation so teams can act without translating security jargon.
- Measure prevention at the point of creation Track whether issues are prevented in the IDE or pull request rather than only counting production findings, because late-stage detection is a backlog signal, not a control outcome.
Bottom line: AI-assisted code generation is increasing the speed of software delivery faster than many security review processes can adapt.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:46 pm
Shift-left code security is really a governance problem about where control is enforced. The important change is not that AI writes code, but that code production now outruns the organisations' ability to review it late in the lifecycle. That makes prevention at the point of creation a structural issue, not just a tooling preference. Practitioners should treat this as a control-placement decision, not a developer productivity debate.
A question worth separating out:
A: Pull request detection prevents the vulnerable pattern from shipping, while production detection only reduces exposure after the code is already live. The difference is not just timing. It changes remediation cost, blast radius, and how much security learning the engineering team can still absorb.
👉 Read our full editorial: AI-assisted code security is shifting left, but the root problem remains