LLM Use, Cheating, and Academic Integrity in Software Engineering Education

1. Problem Statement

The paper addresses the evolving landscape of academic integrity in Software Engineering (SE) education following the widespread adoption of Large Language Models (LLMs). While cheating in universities is historically context-dependent, the introduction of generative AI has fundamentally altered the mechanics of misconduct.

• The Core Issue: In SE, where coursework relies heavily on code artifacts, the boundary between legitimate collaboration/reuse and cheating has always been ambiguous. LLMs have exacerbated this by reducing the effort required to generate plausible code and documentation, making it difficult to distinguish between "assistance" and "substitution."
• The Gap: Existing literature largely focuses on the prevalence of cheating or technical detection methods. There is a lack of understanding regarding how SE students interpret rules, justify their decisions to use LLMs inappropriately, and perceive the consequences of such actions.
• Research Question: How do software engineering students describe their experiences with LLM cheating, and what contextual, motivational, and educational factors influence these behaviors?

2. Methodology

The study employs a cross-sectional survey design combining quantitative and qualitative data collection.

• Participants: 116 undergraduate software engineering students from multiple countries (with significant representation from South Africa, the UK, USA, Canada, and Germany). The sample included students across all years of study (19.8% first-year to 35.3% fourth/fifth-year).
• Instrument: An anonymous survey hosted on Qualtrics, structured into five sections:
  1. Experiences: Specific instances of LLM use perceived as misaligned with course rules (e.g., generating code, debugging, documentation).
  2. Motivations & Decisions: Factors driving the decision (e.g., workload, peer norms, unclear rules).
  3. Affected Areas: Which parts of the SE curriculum are most impacted.
  4. Consequences: Perceived academic, personal, and professional outcomes.
  5. Demographics & Guidance: Background info and awareness of institutional policies.
• Data Collection & Filtering:
  • Recruitment via Prolific (with prescreening for SE enrollment and LLM experience) and snowball sampling.
  • Quality Control: A multi-stage filtering process removed incomplete responses, failed attention checks, and submissions exhibiting signs of AI-generated text (e.g., repetitive phrasing, lack of situational detail) to ensure the data reflected genuine human reflection.
• Analysis:
  • Quantitative: Descriptive statistics for closed-ended items.
  • Qualitative: Iterative thematic analysis of open-ended responses using inductive coding. Two researchers independently coded subsets of data, resolving discrepancies through consensus to ensure reliability.

3. Key Contributions

• Student-Centric Perspective: Shifts the focus from detection and prevalence to the lived experience and reasoning of students regarding LLM misuse.
• Contextual Nuance: Identifies that misuse is not a monolithic behavior but varies significantly by task type (e.g., programming vs. documentation) and assessment context (e.g., routine homework vs. exams).
• Emotional & Cognitive Mapping: Maps the disconnect between students' emotional responses (often indifference) and their cognitive awareness of long-term learning deficits.
• SE-Specific Insights: Highlights how the artifact-based nature of SE education (code, testing, design) creates unique vulnerabilities compared to essay-based disciplines.

4. Key Results

A. Patterns of Misuse

Misuse was most prevalent in programming assignments and labs (71%), followed by regular classwork (46%) and documentation tasks (41%).

• Common Practices: Generating full solutions, debugging code, writing documentation/reports, and solving quiz questions.
• Less Common: Use during major exams (15%) was less frequent and more consistently identified by students as a clear violation.

B. Drivers and Contextual Factors

The primary drivers were structural and situational, not purely ethical:

1. Workload & Time Pressure: 78% of respondents cited heavy workloads and overlapping deadlines as the primary motivator. LLMs were viewed as a pragmatic survival tool.
2. Remote/Online Context: 60% noted that remote coursework lowered barriers to use, reducing the fear of being "physically caught."
3. Ambiguity in Guidance: 34% cited unclear or missing rules regarding AI use. Many felt they were operating in a "grey area," especially regarding intermediate work or drafts.
4. Perceived Low Risk: 34% believed they would not be detected, particularly in online settings.
5. Peer Norms: 30% felt pressure to conform because they believed the majority of their peers were using LLMs.

C. Emotional Responses vs. Learning Impact

• Emotions: The dominant emotional response was Indifference (36.2%), followed by Guilt (20.7%) and Anxiety (18.1%). Many students rationalized the behavior as necessary or inconsequential.
• Learning Impact: Despite emotional indifference, students demonstrated high awareness of the negative educational consequences:
  • Programming/Implementation (69%): Fear of becoming "illiterate programmers" who cannot code without AI.
  • Debugging/Testing (54%): Inability to diagnose errors or understand generated solutions.
  • Skill Gap: A recognition that LLM reliance leads to a mismatch between assessment grades and actual professional competence.

D. Perceived Consequences

• Formal Penalties: Students anticipated course failure (44.8%) or warnings (25.9%) if caught, but many perceived formal sanctions as unlikely or limited.
• Long-term Risks: 85.3% acknowledged that the primary consequence is reduced skill development and over-reliance, which threatens future professional readiness.

5. Significance and Implications

For Research

• Beyond Detection: The study argues that detection-focused approaches are insufficient. Research must investigate how students negotiate ambiguity and justify boundary-crossing in AI-mediated environments.
• Activity-Sensitive Design: Future studies should treat LLM cheating as a heterogeneous phenomenon that varies by task (coding vs. design vs. documentation) rather than a uniform behavior.

For Education and Practice

• Clarify Expectations: Institutions must move beyond vague "no AI" or "AI allowed" policies. Guidance must be specific to the process (e.g., "You may use AI for brainstorming but not for generating final code").
• Assessment Redesign:
  • Shift from output-based grading (submitting code) to process-based assessment (oral code walkthroughs, in-class debugging, iterative development logs).
  • Align assessments with learning objectives that require deep conceptual understanding which LLMs cannot easily substitute.
• Address Workload: The data suggests that excessive workload drives misconduct. Pacing and workload management are critical integrity interventions.
• Preserve Core Skills: Curricula must ensure sustained, hands-on engagement in programming and debugging to prevent the erosion of foundational engineering competencies.

Conclusion

The paper concludes that LLM misuse in software engineering is a systemic issue driven by the misalignment between assessment design, workload pressures, and unclear institutional guidance. Students are not unaware of the risks; rather, they are making calculated trade-offs between immediate academic survival and long-term skill acquisition. Effective solutions require a shift from punitive detection to pedagogical alignment and clearer, activity-specific expectations.