How many Lines of Code (LOC) are you generating with AI? As a measurement of software development productivity, this metric has endured despite being the source of much debate. Frederick Brooks argued in The Mythical Man Month (1995) that writing just 10 lines of code per day was common, and it was the idea of time that was flawed. Steve McConnell in his book Software Estimation: Demystifying the Black Art (2006) paraphrased Winston Churchill by saying “The LOC measure is a terrible way to measure software size, except that all the other ways to measure size are worse.” Capers Jones in The Technical and Social History of Software Engineering (2013) called out lines of code as problematic for ignoring software system requirements, design, all while penalizing high-level languages or libraries that accomplish more with fewer instructions.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight”. –Bill Gates while vibe estimating (probably)
ESS predicted and actual debugging rates from The Mythical Man Month by Frederick Brooks (1995).
The point is, how to measure software development productivity has been ongoing for decades. In Cursor’s 2026 engineering report, it was shared that the top 1% of AI-active developers generate 46X times more AI-written code per day than the median with industry-wide velocity doubling over the past year (Forbes).
We've been in enough conversations with CISOs and AppSec directors to notice a pattern emerging. Nobody is asking whether to let their teams use AI coding agents or shut it down due to security risks. That matter was settled last year, so the question coming up in planning sessions is how to mitigate the risk.
tl;dr
A security scanning tool integrated directly into an AI IDE and any other AI Tools that generate source code may become the optimal control point for enterprise security. This is why we built Semgrep Guardian and is the topic of an upcoming webinar: Secure AI Coding Without Picking a Winning IDE.
Continuous Integration Scanning Has Worked Fine For Years
CI/CD has been a critical piece of automating software builds for a long time. Build, test, scan, ship. We’re now hearing engineering and security leaders are showing cracks under the pressure to scale.
Initially, keyboards were laid out as they were for a practical reason: mechanical typewriters would jam if certain letter pairs were pressed too fast. By keeping common pairs apart with QWERTY layouts, typists could maintain flow. Dvorak by comparison was designed for efficiency, built from a statistical analysis of letter frequency to dramatically improve words per minute in typing speed. Even taking into account over-optimizing for the English language, switching may be difficult because of a steep switching penalty.
When a human writes code, there's a natural rate limiter: we type slowly, we think about what we’re doing, and a PR represents hours of deliberate work. AI agents don’t have the same constraint and will happily generate a SQL query from unsanitized string concatenation at the same pace it generates any other logic statements because it doesn’t know the difference between fast and careless.
Shipping code is becoming bottlenecked at merge time by trying to introduce a human in the loop too late in the process. “Shift left” has been AppSec’s silver bullet answer to everything, but traditionally it is met with skepticism because it just moves the problem. It is treated like a process, not a system. A process is a sequence of tasks that require humans to learn and follow.
A systems-thinking approach makes the thing you want to happen easy by designing a solution. Financial accounting uses double-entry bookkeeping as a structural redundancy for fault tolerance, using counter-balanced constraints as a safety net. Instead of just shifting left, what if we could intercept AI generated code so that insecure patterns don’t ever make it to the integration step? Further, could we introduce that efficiency without forcing teams to learn a layout that changes how they work by integrating directly within the AI tool?
Why Not Use Deep AI Scans on Every PR?
You might bankrupt yourself before you ship with this approach. Agent-driven analysis is resource intensive; any sizable engineering organization doing even hundreds of merges a day would become a budget problem. Expensive, but not without value.
More critically, you don’t need to do deep scans on everything. Continuous checks belong on every code generation step and can utilize cheaper compute. The more expensive, deep agentic analysis may be more equivalent to a pentest performed periodically against a codebase to reason about auth flows, mapping the context of API endpoints, and tracing data flows thoroughly. That type of analysis is better suited to a scheduled workflow that is purpose matched against the repositories that matter most. For some organizations this may be daily or weekly depending on the repository and pace of change for projects that may get little more than maintenance.
Maximizing precision has a cost curve, so pretending otherwise just means you will overspend on AI or avoid doing it at all which allows risk to creep back in.
Both deterministic and probabilistic reasoning is important. Any vendor that tells you one or the other is sufficient is not understanding the harmonious relationship that comes from designing a solution that can leverage the best of both together. That’s why vendors who have expertise in program analysis come out on top in performance benchmarking.
Our Riskiest Code Isn’t Written By Engineering
This one caught some leaders off guard, but it shouldn't have. If an AI chat can walk a product manager, marketer, sales engineer, or intern through installing an IDE and opening a terminal to run commands, that employee is now writing code. The process guardrails and programs we built a few years ago were focused on training engineering teams, not teaching everybody at the company proper secure coding practices.
These citizen developers are not using the ticketing system. There is no assigned code owner, no security champion program covering their work. They may not even know if they should ask for a security review.
The more mature AI coding tools like Cursor, Claude Code, Kiro, and Replit have enterprise level features. Putting guardrails on the code being generated by models is the most effective way to intercept this growing wave of risk from non-traditional software developers.
AI skills and deterministic checks from an MCP server are table stakes now.
Software Dependencies with Malware is a New Org-Wide Shadow IT Problem
Many enterprises have solutions that prevent employees from installing unsafe applications. With AI coding tools, the software libraries the generated code utilizes has become another attack vector.
A malicious package doesn’t wait for a code path to be executed, which has a lot of security leaders on edge. Endpoint and supply chain tooling will often catch this but the scan is too late in the process if done after install. Once npm or pip finishes installation the machine becomes compromised.
To address this, a narrower control is needed: something that intercepts the code deciding which libraries to pull functionality from before the package is added. Doing this at the code-gen loop is not a replacement for full software composition analysis. Reachability, licensing, and vulnerability still matter for a full understanding of a code base, but many stacks are missing a firewall at the time software is being written.
Can we trust AI to autofix AI?
Ask what's actually happening. If AI was used to generate vulnerable code, why do we think it can generate secure code the second time around?
Contextual reasoning comes into play. Just as we’ve learned that prompt engineering matters quite a bit in the results from AI so too can security scans. The moment code shows up in a text editor generated by AI the problem has shifted from creation to review. Additionally, if a deterministic check adds context about what patterns are insecure, the AI has better informed requirements to produce a second revision. This is foundationally similar to a human reviewing their work and coming up with a second draft.
The harder problem with autofix isn’t using AI to generate the patch, but verifying whether that security fix breaks functionality. Every dependency update has had a similar failure mode, bumping a version may have cascading effects in production. Comparing specifically what changed between the current implementation and a patched one gives strong evidence of correctness.
Trends in AI-Assisted Software Development
There were many questions and hypotheticals exploring similar trends security leaders are facing across industries. Our ideas behind measuring software development productivity and gating releases still have value, but are insufficient because they were built with an assumption about who was writing the code, when it would be reviewed, and how dependencies hit the system.
To address AI-assisted software development effectively, we need solutions that integrate directly into AI coding tools to provide critical security review feedback when it can most effectively be applied. For our own engineering teams, we built Semgrep Guardian because across the organization AI-assisted development uses a variety of tools today: Claude Code, Cursor, VS Code, Kiro, Replit, and more.
If you're evolving your AppSec program against similar questions, we're happy to walk through where we see gaps for most engineering organizations and how to assist the rest of the organization to become secure coders regardless of their experience.
If you have questions about how we do it, join one of our upcoming webinars and events to hear directly from our teams who use it themselves. We’d love to hear your feedback about how easy it is to roll it out to your organization.
