Technical Summary: From Preventive to Reactive: How AI Coding Assistants Transform Developers' Security Awareness

Problem Statement

While AI coding assistants (e.g., GitHub Copilot, ChatGPT, Claude) have rapidly become central to professional software development, their impact on developer security awareness remains poorly understood. Existing literature has largely focused on two areas: (1) technical evaluations measuring vulnerability rates in AI-generated code, and (2) productivity metrics. However, a critical gap exists regarding the cognitive and behavioral processes through which developers engage with security in authentic, ongoing workflows.

Prior studies indicate that AI-generated code often contains exploitable vulnerabilities and that developers using AI may be more confident in their code's security than it warrants. Yet, it is unclear how these tools transform the mental models and habits of security. Specifically, does AI shift security from a preventive practice (during coding) to a reactive one (during review)? Does a developer's professional formation relative to AI adoption (Pre-AI, AI-era, AI-native) predict their security performance?

Methodology

The authors conducted a mixed-methods qualitative study involving 15 professional software engineers. The study employed a two-part design to capture both stated beliefs and observed behaviors:

1. Semi-Structured Interviews: Participants were interviewed regarding their daily security practices, familiarity with AI tools, and how AI has altered their security workflows.
2. Observed Think-Aloud Coding Sessions: Participants completed security-relevant coding tasks using Gemini CLI with the Gemini 2.5 Pro model in a shared, self-hosted VS Code environment.
   • Tasks: Participants chose from three realistic scenarios: (a) implementing a new feature (HTTP endpoint with user data), (b) initializing a new project (backend scaffolding), or (c) debugging a concurrency vulnerability.
   • Observation: Researchers recorded prompting strategies, iteration patterns, and security-relevant decisions (or omissions) in real-time.

Participant Cohorts:
To investigate the role of professional formation, participants were categorized into three cohorts based on when they entered the workforce relative to the widespread adoption of LLMs:

• Pre-AI: Career began before widespread LLM availability (pre-2022).
• AI-era: Career began during the mainstream adoption of AI tools (2022–2023).
• AI-native: Career began entirely within the era of accessible AI coding assistants (2024 onward).

Analysis:
Data was analyzed using reflexive thematic analysis. Interview transcripts were coded iteratively, and coding session observations were triangulated with interview responses to identify divergences between stated security knowledge and actual behavior.

Key Findings

1. Shift from Preventive to Reactive Security

The study identifies a fundamental structural shift in how security is practiced. Security thinking has moved from the act of writing code (preventive) to the act of reviewing code (reactive).

• Observation: None of the 14 participants who completed coding tasks included security requirements in their initial prompts, even when they had explicitly articulated security concerns during the interview.
• Implication: Security is treated as a downstream concern to be caught during review rather than a first-class requirement to be specified upfront. This transition is structurally encouraged by interaction models that frame code generation as a purely functional task.

2. Decoupling of Knowledge and Behavior

There is a significant gap between a developer's security knowledge and their security behavior when using AI.

• Observation: Participants who possessed relevant security knowledge often failed to apply it during prompting. For instance, a participant with 1.5 years of experience (P10) successfully identified a critical authorization flaw, while more senior participants missed it.
• Result: Experience level and AI familiarity (cohort membership) were not reliable predictors of security performance. Security outcomes depended heavily on whether the individual possessed specific security knowledge and had developed habits of security-oriented prompting.

3. Poorly Calibrated Trust

Developers applied similar levels of trust to boilerplate code and security-critical logic, despite the tools providing no indication that the risks differed.

• Observation: Participants often accepted functionally plausible but security-incomplete code without verification. The "confidence" of the AI output (even when incorrect) created a false sense of reliability.
• Mental Model: While many developers described AI as a "junior colleague" in interviews, this framing did not consistently translate into rigorous security review behaviors during coding sessions.

4. Emergence of Informal Coping Strategies

In the absence of formal tool support or organizational guidance, developers independently invented strategies to manage AI security risks:

• Restricting Agent Permissions: Limiting file write or execution permissions for AI agents.
• Prompt Engineering: Creating security-oriented prompt templates or configuration files to constrain AI behavior.
• Post-Implementation Querying: Explicitly asking the AI, "Are there any remaining security concerns?" after a functional implementation was complete.
• Limitation: These strategies were effective when used but existed entirely outside formal guidance, making their adoption contingent on individual initiative rather than systemic support.

Key Contributions

1. Practice-Grounded Account: The paper provides empirical evidence of how AI-assisted development reshapes the human side of secure coding, moving beyond static vulnerability metrics to analyze cognitive and behavioral shifts.
2. Structural Explanation: It argues that the shift from preventive to reactive security is not merely a result of developer carelessness or lack of knowledge, but a structural outcome of current AI tool design and adoption models.
3. Cohort Analysis: It challenges the assumption that experience level correlates with security proficiency in AI-assisted contexts, showing that "AI-native" developers are not inherently more or less secure than their predecessors.
4. Identification of the "Prompting Gap": The study highlights the consistent absence of security requirements in initial prompts as a critical failure point in the human-AI interaction loop.

Significance and Claims

The paper claims that the security risks associated with AI coding assistants are not solely about the quality of the code generated, but about how these tools reorganize developer attention and workflow.

• Structural, Not Individual: The authors assert that the problem is structural. Current tools frame code generation as a functional task, leaving security as an afterthought. This design choice encourages a reactive security posture that is difficult to sustain under time pressure.
• Design Implications: The paper argues that fixing this issue requires intervention at three levels:
  1. Tools: Security must be a first-class concern in the generation workflow (e.g., automatic security review passes, mandatory security prompts for sensitive contexts).
  2. Trust Calibration: Interfaces must differentiate between boilerplate and security-critical code, surfacing uncertainty and alternative implementations to prevent over-reliance.
  3. Organizations: Security-aware AI use must be formalized as a competency. Organizations need to provide shared prompt templates, review checklists, and policies, rather than relying on individual developers to invent coping strategies.

The study concludes that while AI does not erase security knowledge, it reorients its application. Without structural changes to tools and organizational practices, the shift toward reactive security will likely concentrate risk among the engineers who depend most heavily on these tools.