From What Developers Say to What They Do
For professional developers using AI coding assistants, security awareness is difficult to study because a person’s stated principles and their behavior during implementation can diverge. This chapter focuses on how the USENIX researchers made that divergence observable. Understanding the study’s two kinds of evidence, its three AI-relationship cohorts, and its deliberately incomplete task prompts lets readers judge the later findings without treating a small exploratory sample as a universal measurement of developers.
Two views of the same developer
The study used two components in one session lasting approximately 45 to 60 minutes. First came a semi-structured interview. Participants described how they approached security in ordinary development work, which tools or habits they relied on, how they used AI coding assistants, and how confident they felt about catching security issues before code shipped. The interviewer could follow up on a participant’s own answers, so the conversation was not a fixed survey with a predetermined set of responses.
The second component was a think-aloud coding task. Participants used Gemini CLI with Gemini 2.5 Pro in a hosted VS Code environment. They worked while explaining what they were doing and why. The researchers could therefore observe not only the final output, but also the sequence that produced it: the initial request, later prompts, changes to the generated code, moments of hesitation, and security-relevant decisions or omissions.
These components answer different questions. An interview can reveal a developer’s mental model. It can show whether they know that access control, input validation, secret handling, or other security properties matter. It can also reveal how they describe trust: perhaps as a scale, perhaps as a relationship with a junior colleague, or perhaps as a division of responsibility between a person and a tool. Such accounts are valuable because they expose concepts and intentions that may not be visible in a short task.
But an interview does not demonstrate that a principle will be invoked under time pressure. Someone can say that every endpoint should verify authorization and still fail to ask for an authorization check when an assistant is generating the endpoint. A person can say that AI output requires review and still accept a suggestion after a quick functional test. The task therefore supplies a second view: not a perfect simulation of everyday work, but an opportunity to see which concerns actually cross into the interaction.
The order also matters. The interview preceded the coding task, which could have prompted participants to think more deliberately about security than they would in an ordinary session. That makes the observed omissions notable, but it does not remove the possibility of priming. The researchers acknowledge this tension rather than pretending that a think-aloud session is an invisible window into routine development.
The participants were 15 professional software developers recruited through purposive and snowball sampling. No students or university employees were included. Their roles included full-stack, machine-learning, frontend, research-and-development, and general software engineering work. The sample ranged from entry-level to mid-level engineers. One participant completed the interview but declined the coding component, so the behavioral observations came from 14 coding sessions. Keeping those denominators separate is essential: claims about what participants said can concern 15 people, while claims about initial prompts or observed task behavior concern 14.
The researchers grouped participants by when AI tools entered their professional formation. The Pre-AI cohort began professional software engineering before large-language-model tools became widely available. The AI-era cohort was trained before the shift but entered the workforce as AI tools became mainstream. The AI-native cohort both trained and began working during the period when accessible AI coding assistants were already part of software development. The boundaries—before 2022, 2022–2023, and 2024 onward—are a way of describing each participant’s relationship to the technology during professional formation.
They are not levels of competence. A Pre-AI developer is not automatically more security-aware, and an AI-native developer is not automatically dependent or careless. The categories help pose a question: does the period in which someone learned to develop software predict how they behave when an assistant participates? The study’s later result is that this cohort membership did not reliably predict security performance in the observed sessions. That result is meaningful only if the reader first understands what the cohorts measure and what they leave out.
The categories also cannot represent every relevant difference among developers. Formal security education, recent experience with a particular application domain, familiarity with threat modeling, team review practices, and the nature of a person’s current work may matter more for a given task than the date when AI entered their career. A cohort is a comparison lens, not an explanation by itself.
The sequence captures the study’s central methodological move. The researcher first hears how a developer says they work, then watches that developer work with an assistant. The comparison is not a test of honesty. People may describe their usual production standards while treating a research task as low-stakes, or they may sincerely believe they review carefully without noticing how quickly they rely on a plausible suggestion. The value lies in making the difference inspectable.
A deliberately incomplete task, and evidence with limits
The coding task offered three options aligned with common development activities. A participant could implement a new feature, initialize a backend project, or debug existing code. The feature task asked for an /update-profile HTTP endpoint that accepted a user identifier, display name, and biography, updated a persistent or mock store, and returned a JSON result. The project-initialization task asked for a runnable backend with configuration, routing, and a health endpoint. The debugging task presented a file-upload function in which simultaneous uploads could interfere with one another because all users wrote through the same temporary path.
These tasks place security at different points in the work. A profile endpoint raises questions about whether the requester is authorized to change the account named in the request, and whether submitted data is handled safely. Project initialization raises questions about secure defaults, configuration separation, and secret management before an application has acquired a large body of code. Debugging a concurrency problem raises a different issue: a behavior that looks like a reliability defect may also become a security problem when one user’s file can end up in another user’s directory.
The prompts did not state those security requirements. That omission was intentional. If the researchers had told participants to validate input, protect secrets, or check authorization, the task would have measured how developers respond to an explicit cue. By describing ordinary functional work and leaving the security conditions unstated, the researchers could observe whether participants supplied those conditions themselves.
This design does not mean the tasks were security-free. The requirements created security-relevant opportunities, and a careful developer could recognize them. The omission instead creates a boundary between what the task explicitly demanded and what the participant chose to add. That boundary is where the study looks for a preventive habit: does security enter when the developer first frames the work, or only after the assistant returns something that appears to work?
The task also preserves ecological value by allowing participants to choose the activity that best matched their regular work. That choice avoids forcing every developer through an unfamiliar programming exercise, but it introduces variation. Different participants did not all encounter the same task, and one participant attempted all three. The resulting observations are richer than a single scripted benchmark, while being less suited to a clean numerical comparison across identical conditions.
The three options were also probes of different security transitions. Feature implementation tests whether a developer carries a security boundary into a new behavior: who may change a record, which fields are controlled by the caller, and what happens to untrusted input. Project initialization tests whether secure defaults and separation of environments appear before a system has accumulated code that makes those choices harder to change. Debugging tests whether a developer recognizes that a race condition is not merely an inconvenient failure but can affect the confidentiality and ownership of user data when simultaneous requests share state. The researchers were therefore not looking for one universal “security step.” They were watching whether security reasoning appeared at the point where each task made it relevant.
That distinction gives the observations more explanatory value than a single pass/fail score, but it also limits direct comparison. A participant who chooses project planning is not exposed to exactly the same decision as someone who chooses debugging. A missed authorization check and a missed concurrency problem are both security-relevant omissions, yet they require different knowledge and different review questions. The task menu makes the session closer to ordinary work; it does not create equivalent experimental conditions. The study can identify patterns in how security enters the interaction, but it cannot rank participants by a common security score.
The observation was organized around transitions rather than only outcomes. Researchers could examine how a participant refined or escalated a prompt after seeing an answer, whether they questioned a security-relevant choice, and how much independent verification occurred before the task was considered complete. This matters because the same final code can result from very different processes. A developer may produce a safe result because they requested a constraint at the outset, because they noticed and corrected a flaw, or because the assistant happened to suggest a suitable pattern. Those paths should not be treated as evidence of the same security habit.
During analysis, the researchers reviewed interview transcripts and used reflexive thematic analysis. The first author open-coded the transcripts, developed an initial codebook, and worked with the research team to organize codes into themes. Coding-session recordings were considered alongside the source files produced during the sessions. The analysis focused on prompting and iteration, security-relevant decisions, and how much independent verification participants performed. This is triangulation: interview accounts, interaction traces, and resulting code are compared so that no single form of evidence carries the entire interpretation.
Triangulation improves the question being asked, but it does not turn qualitative evidence into a controlled experiment. The study does not randomly assign developers to different assistants, prompts, training programs, or organizational policies. It does not measure a representative population. It cannot isolate whether a particular interface feature caused an omission, whether a different model would have elicited more security reasoning, or how behavior would change after months of production use.
There are four practical limits to keep in view. First, the sample contains only 15 professionals and is described by the authors as male-skewed. Its composition limits generalization across roles, industries, experience levels, and demographic groups. Second, the coding sessions used one setup: Gemini CLI with Gemini 2.5 Pro. Other assistants may differ in how they expose context, request permission, present uncertainty, or edit files. Third, the interview-first design may have primed security reflection. The fact that most participants still did not address security in their initial task prompts is informative under those conditions, but it is not proof that the same proportion would behave that way in all workplaces. Fourth, asking people to think aloud may introduce deliberateness that routine coding lacks.
The task setting may also have been lower-stakes than production. One participant explicitly distinguished what they accepted for the research task from what they would accept in actual job life. That difference can have more than one explanation: limited time, the absence of a real customer, the knowledge that the code would not ship, or an ordinary tendency to relax review for experiments. The study cannot resolve which explanation dominates. What it can show is that a developer’s declared production standard and observed behavior in a low-stakes AI interaction are not necessarily identical.
These limits should change the strength of the conclusion, not erase the observation. A claim such as “the study observed no security requirements in the initial prompts of its 14 coding sessions” is precise about its denominator and setting. A claim such as “developers generally do not include security requirements in AI prompts” exceeds the evidence. The first is an empirical observation; the second would require broader samples, consistent tasks, multiple tools, and ideally repeated observation in real development environments.
The study’s design therefore prepares a more specific investigation than “does AI make code secure?” It asks how an assistant changes the path from intention to implementation. The key objects are the developer’s stated knowledge, the request sent to the assistant, the assistant’s response, the review that follows, and the conditions under which the result is accepted. Once those objects are separated, the next issue becomes visible: a developer may understand security in principle while omitting it from the initial request. That is the prompting gap, and it is the mechanism through which preventive security can be pushed downstream into review.