Dominic Jainy stands at the leading edge of the intersection between rapid software innovation and digital fortification. As an expert in DevSecOps and the evolving landscape of artificial intelligence, he has spent years navigating the shift from manual coding to the current era of autonomous agents. With the rise of tools capable of generating massive amounts of infrastructure and application logic in the blink of an eye, Dominic offers a crucial perspective on how security teams must adapt to keep pace with a world that moves at the speed of an algorithm. In this conversation, we explore the challenges of managing the sheer volume of AI-generated output, the persistent nature of vulnerabilities in automated code, and why Static Application Security Testing (SAST) has become the non-negotiable heartbeat of the modern development pipeline.
How are AI coding agents fundamentally changing the daily workload and the pressure felt by modern development teams?
It is a bit like trying to drink from a high-pressure firehose that never shuts off, as we are seeing practitioners now producing upwards of 12,000 lines of code per day with AI agents. This is a volume of output that simply shatters any traditional concept of manual oversight or human-led quality assurance. When you realize that widespread AI adoption has actually led to a 91% increase in code review time, you begin to feel the actual weight of the bottleneck we’ve created. No human, no matter how skilled or focused, can keep up with that pace line-by-line without missing the critical, subtle details that could jeopardize the entire system. We are also seeing a 9% climb in bug rates, which tells us that while we are moving faster, we are also tripping more often, leaving teams feeling like they are constantly racing to catch up with their own tools.
When these agents produce such a staggering high volume of code, what are the primary security risks that start to emerge within the codebase?
The biggest misconception is that AI creates some new, alien category of bugs, but in reality, it just replicates our own worst human habits at an industrial scale. A recent study highlighted that AI-generated code had an average pass rate of only 56%, which is a sobering way of saying that 44% of scanned codebases contained at least one security flaw. We see a lot of injection flaws and exposed secrets, and the real danger is the repetition where a single insecure pattern is duplicated across dozens of files or components by the agent. Unlike a functional bug that crashes the application and triggers a loud alert, these security flaws are silent and invisible, often sitting in production for months before anyone notices. It creates a massive “security debt” that grows quietly until it becomes a full-blown crisis.
Why has the timing of security scanning become so critical, and why is “shifting left” more than just a buzzword in this automated era?
If you wait until the end of the development cycle to run a scan, you are essentially setting yourself up for a nightmare of expensive rework. Scanning a small change in the IDE as it is being written takes only seconds, providing that immediate “aha” moment for the developer or the agent to fix it on the spot. However, if you let those changes accumulate into a large batch to be checked at the end, the scan takes far longer and you often find that the flaw is already buried under layers of new code built right on top of it. It is incredibly frustrating and demoralizing for a team to have to tear down an entire week’s worth of progress because a foundational vulnerability was missed at the very beginning of the loop. Ideally, SAST should live inside the environment where the code is born, catching mistakes way before they ever reach a repository or a pull request.
In a world where code generation is becoming increasingly autonomous, how do we define the remaining role of the human developer in the security process?
We have to recognize that while SAST finds issues automatically and points developers straight to the problem, a person still needs to provide the final layer of interpretation and decision-making. The human role is shifting from a tedious line-by-line reviewer to a high-level curator who rules out false positives and decides on the best path for remediation. Many modern tools now provide contextual explanations of why a flagged issue is a risk, which saves developers from having to spend hours researching every single flag from scratch. This allows the human element to focus on the security-sensitive areas that truly matter, acting on guidance directly without needing to be an expert in every niche of cybersecurity. It turns the developer into a strategic pilot rather than a manual laborer.
How should organizations approach governance and policy to ensure that bots and humans are held to the same standards?
We must move away from relying on human memory or individual judgment to trigger security checks and instead bake these requirements directly into the automated CI/CD workflows. Whether a piece of code was written by a human or an autonomous agent, it must clear the exact same security bar before it is allowed to reach a pull request or merge into a production branch. As agents become more autonomous—even to the point where they can open their own PRs or merge branches—we simply cannot afford to lower our vigilance just because a person isn’t overseeing the merge. By building the requirement into the pipeline, you ensure that the security check happens every single time, without exception, creating a consistent safety net that scales with the speed of the AI.
What is your forecast for the future of application security in a world dominated by AI agents?
I believe we are rapidly approaching a state of “autonomic security,” where the tools that generate the code and the tools that protect it will exist in a continuous, self-correcting loop. In the coming years, the gap between the speed of code generation and the speed of security review will finally close, but only for the organizations that move away from manual gatekeeping and embrace full SAST integration. We will see agents not just writing code, but also learning from the SAST flags to stop making the same mistakes, essentially training themselves to be more secure over time. For the reader, the focus should not be on fear of the volume of code, but on the mastery of the automated checkpoints that keep that volume under control. The future isn’t about writing less code; it’s about building better systems to watch over the code we are already generating.