CyberDefenseMagazine

AI Moved into the Dev Workflow. Security Didn’t.


AI coding tools were supposed to sit alongside the development process. Today, they’re increasingly becoming the development process. Many of these systems are also evolving from coding assistants into autonomous development agents capable of generating, testing, and modifying software with limited human intervention.

Tools can now handle architecture decisions, generate tests and ship changes, all within a single environment that roughly 84% of developers already use or plan to adopt. One company reported going from 25,000 lines of code a month to 250,000 after embedding an AI-native coding tool into their workflow.

That scale of acceleration creates a visibility problem for security teams. When code is being generated, tested and merged inside AI-native environments that operate independently of centralized review processes, security loses the sight lines it has historically relied on. Developers are making architecture and implementation decisions inside their own workflows, and there’s no natural moment for security oversight to step in. The result is something closer to shadow development, or AI-assisted coding environments that produce production-bound code faster than security processes were ever designed to track.

Traditional security was built around distinct review stages and centralized oversight. That model assumes a pace and structure that no longer reflect how software gets built. A periodic checkpoint at the end of the pipeline catches far less than it used to. As development accelerates, the distance between where vulnerabilities are introduced and where they’re caught keeps widening.

The Part Security Teams Are Struggling With

Security was designed around the assumption that development happens in stages: code gets written, then reviewed, then tested, then shipped. When AI tools handle generation, testing and iteration inside a single environment, those stages compress into one continuous motion, and the handoff points that security processes were built around stop existing.

Developers using tools like Cursor and Claude Code move fast through early stages — research shows getting a project from zero to 30% complete is largely AI-driven. But the final stretch still requires careful human judgment, and that’s precisely where security decisions get made without security teams in the room. When individual developers are resolving architecture and implementation questions inside their own AI-assisted environments, there’s no natural moment for centralized oversight to step in. That’s the shadow development problem in practice: production-bound code accumulating in environments that security was never built to reach.

As AI accelerates code generation, organizations build up vulnerabilities, misconfigurations and architectural risks faster than security teams can evaluate and address them. Unlike traditional technical debt, this exposure often stays invisible until it surfaces as an incident, a compliance issue or an operational bottleneck. The longer organizations run AI-driven development without adapting how security operates, the faster that debt compounds.

This visibility problem comes at a human cost. Appknox’s AI and Developer Burnout Report found that many security professionals in AI-heavy environments are experiencing heightened pressure because the oversight model hasn’t kept pace with the development model. One DevSecOps engineer shared that “AI catches issues quickly, but every miss feels heavier now that the system expects near-perfect vigilance.”

Asking security teams to maintain the same standard of coverage over a faster, more decentralized development process (without changing how security operates) compounds the problem rather than solving it.

What Adaptation Actually Looks Like

Adding more scanners or pushing reviews earlier in the pipeline doesn’t fix a structural problem. Security teams that are genuinely adapting have stopped treating security as something that happens after development and started building it into how development works.

That requires a different way of thinking about what security tooling is supposed to do. Rather than adding checkpoints, organizations need to create a continuous security feedback loop where findings move between runtime validation, exploitability analysis and developer remediation without breaking the development process to do it.

In practice, that means three concrete shifts. Security analysis needs to be grounded in how applications behave at runtime. Prioritization needs to reflect actual exploitability in a specific application context, not a standardized severity score that ignores how the app is architected. And remediation guidance needs to land inside the environments developers are already working in.

Each of these shifts reduces the distance between where a vulnerability gets identified and where it gets fixed. In AI-native development, that distance determines if a fix occurs in time to prevent the damage. Those shifts require security to operate as a continuous function, with findings surfaced as they emerge and remediation guidance delivered before code moves forward.

Leadership Is Part of the Solution

The structural shifts outlined above are available to any organization willing to implement them. The reason most haven’t comes down to how AI adoption decisions get made at the leadership level.

Most organizations have treated AI integration as a development productivity initiative. Tooling gets procured, developers get access and output accelerates. What rarely happens in parallel is a conversation about what that acceleration costs the security function — in coverage, in oversight capacity and in the cognitive load placed on the people responsible for catching what the new development model introduces.

Appknox’s burnout research found that security risks increase specifically when organizations adopt AI without guardrails. That finding reflects a planning failure, not a people failure. Speed gets resourced, so security gets expected to absorb the consequences with the same headcount, tooling and processes as before.

Closing that requires CIO and CISO alignment on what AI-native development actually demands from the security function. When those conversations happen in silos — technology leaders focused on velocity, security leaders focused on risk — organizations end up with AI adoption plans that optimize for one without accounting for the other. Security budget allocation needs to reflect the development model in place, not the one that existed before AI tools entered the workflow.

As AI coding tools evolve into autonomous development agents capable of generating and modifying code with limited human intervention, governance becomes just as important as oversight. Organizations need clear policies for how AI-generated code is reviewed, validated and approved before reaching production. This means defining acceptable levels of autonomy, establishing audit trails for AI-driven changes and ensuring security controls stay embedded throughout the development workflow. Without that governance layer, AI-native development can scale faster than an organization’s ability to manage the risks it introduces.

Developer enablement matters, too. Security that operates inside AI-native workflows only works if developers understand how to use it. That requires structured training, realistic expectations about what AI tools will and won’t catch, and clear guidance on when human judgment needs to override an AI-generated output.

Organizations must commit to repositioning security as a continuous, workflow-native function if they expect to reduce their exposure to vulnerabilities. In doing so, they can also expect to remove a structural tension that slows engineering down and burns security teams out at the same time.

AI-native development is already the default for most engineering teams. Security infrastructure that hasn’t been rebuilt for that reality will keep falling further behind. The exposure that accumulates in the meantime doesn’t wait for the next planning cycle.

About the Author

Harshit Agarwal is the MD and co-founder of Appknox, a leading mobile application security platform trusted by enterprises and governments. With a strong background in cybersecurity and entrepreneurship, he has been instrumental in scaling Appknox’s global presence and helping businesses secure their mobile applications against evolving threats. Harshit is a thought leader in mobile security and compliance, driving innovation in AI-powered testing and continuous security monitoring.

Harshit Argawal can be reached online at [email protected] and https://www.linkedin.com/in/agarwalharshit/ and at our company website https://www.appknox.com/



Source link