AI Is Writing More Code. Who’s Checking It for Security?

AI is writing more code than ever, but Forrester's 2026 survey shows security scanning hasn't kept up. Here's the gap, why attackers love it, and how to close it in your pipeline.

$ cat table_of_contents.txt

AI coding assistants are making software faster to write, but the checks that catch security flaws haven’t kept up. That’s my takeaway from Forrester’s Software Development Market Insights, 2026, a report AWS is giving away through AWS Marketplace.

It arrived as an AWS marketing email. Before clicking anything, I checked it: the sender’s domain, the Reply-To address and where the link really went. It was legitimate, so I read it.

I’m not a professional developer. I’m a retired electrician in Honolulu, studying for the AWS Certified Developer – Associate exam (DVA-C02) and working through Black Hat Python. Reading this survey with both hats on, one question kept coming back: if AI is writing more of the code, who’s checking it for security?

What the numbers say

Forrester’s Developer Survey, 2025, asked developers at companies with 1,000 or more employees what they use and plan to use. AI and cloud tools lead the list.

What Forrester foundThe number
Organizations using AI in the coding phaseAlmost half of enterprise respondents
Developers saying AI agents made a task more than 50% more productiveAt least 30%, for each task asked about
Organizations with a low-code (“AppGen”) platform66%, and 17% more plan one within 12 months
Developer time spent on work that delivers softwareJust over 80%

Forrester calls AI coding agents “TuringBots,” and the biggest gains came from generating and upgrading code. Planned adoption is led by cloud-based tools: CI/CD pipelines, test automation and cloud development environments. Agile and DevOps are simply how large teams work now.

The gap: the checks haven’t kept up

Forrester names three barriers to progress: scaling agile, low test automation and developer experience. The second one is a security problem.

  • Most testing is still manual. On average, fewer than a quarter of most test types are automated. Functional tests fare better.
  • Security scanning lags the most. Static code analysis, the automated scan that reads code for flaws before it runs, has low automation rates. Forrester’s verdict: organizations “are not paying enough attention to security.”
  • Open-source use is often unmanaged. One-third of enterprise developers called their organization’s approach to open source ad hoc. Forrester warns this delays finding and fixing vulnerabilities.

Here’s the contradiction. Developers said they measure success by quality, and “security improvements” made that list. Yet the automated check that would deliver it is among the least used.

Why it matters, through an attacker’s eyes

Attackers don’t care who or what wrote the code. They care about the flaw that slipped through, and Black Hat Python‘s web chapters show how little scripting it takes to go looking for one.

AI assistants can make those flaws more likely, not less. In a 2022 study, Neil Perry, Megha Srivastava, Deepak Kumar and Dan Boneh found that participants with an AI assistant “wrote significantly less secure code than those without access.” They were also “more likely to believe they wrote secure code.” The participants who trusted the AI less and reworked their prompts produced fewer vulnerabilities.

Open source adds a second risk. Log4Shell (CVE-2021-44228), the 2021 flaw in the Log4j logging library, let attackers run their own code on systems that logged text they controlled. Log4j was in services, websites and products everywhere, so the flaw was too (NPCC bulletin). With an ad hoc open-source policy, you can’t quickly answer the first question: are we affected?

I’ve felt this on a small scale. When an actively exploited SQL injection flaw in WordPress (CVE-2026-63030, “wp2shell”) hit, I patched this blog by hand after the automatic updater silently failed. One flaw in widely used code becomes everyone’s emergency at once.

What teams (and learners) can do

The fix is to make the security check as automatic as the code generation.

  1. Scan every change. Add a static analysis step to the CI/CD pipeline, so no code ships unchecked. On AWS, that’s a CodePipeline stage running a scanner in CodeBuild, the same deployment material DVA-C02 covers.
  2. Scan what you deploy. Amazon Inspector offers Lambda standard scanning for vulnerable packages and Lambda code scanning for flaws in your own code.
  3. Review AI suggestions like a new hire’s code. The study above found that the more skeptical users wrote safer code.
  4. Know your open source. A written policy and a list of what you depend on turn the next Log4Shell into a quick check instead of a scramble.

For learners, the easiest start is free. Bandit, a security linter from the PyCQA project, scans Python code for common security issues. On Debian it’s one package:

sudo apt install bandit
bandit -r ~/your-python-project

Next on my list: running it over my Black Hat Python exercises. Those scripts are meant to be offensive tools, so I’m curious what a security linter makes of them.

The bottom line

Faster code is only good news if the checking speeds up with it, and Forrester’s numbers say it hasn’t yet. For anyone studying DVA-C02, the pipeline is where the two meet: build it so the security scan runs every time, and speed stops being a risk.

Sources