How Teachers Detect AI in GCSE Computer Science Coursework

GCSE Computer Science coursework presents a unique challenge when it comes to academic integrity. Unlike most subjects, students are expected to produce both working code and extended written commentary - design rationales, testing strategies, and evaluative analysis - and it is this written component where AI tools pose the greatest risk. ChatGPT and Claude produce technically fluent prose of exactly this kind, close to what a capable student might write, so knowing what to look for and how to use detection tools responsibly is now part of moderating NEA submissions.

What follows is aimed at UK secondary Computer Science teachers and combines professional judgment with detection tools such as GradeOrbit.

Why GCSE Computer Science NEA Is Vulnerable to AI

Both AQA and OCR GCSE Computer Science specifications include a Non-Exam Assessment component that requires students to work independently over an extended period. The NEA is not just about writing code - students must produce substantial written sections covering their design decisions, how they planned and tested their solution, and a final evaluation of how well the project meets its objectives. These written components often carry significant marks and are completed outside of direct classroom supervision.

This structure creates the conditions where AI use becomes tempting. Students work on their projects at home, often over several weeks, with limited teacher oversight of the writing process. AI tools are particularly effective at producing the kind of technical prose these tasks demand: explaining how an algorithm works, describing a testing strategy, or evaluating the usability of a piece of software. The result is that a student who struggles with written communication can paste a few bullet points about their project into ChatGPT and receive polished paragraphs that read like a textbook.

Importantly, the vulnerability lies in the written elements rather than the code itself. While students could use AI to generate code, this is easier to investigate through viva-style questioning. The written design, testing, and evaluation sections are harder to verify because they describe processes rather than demonstrating a skill in real time.

What AI-Generated CS Coursework Looks Like

Recognising AI-generated writing in Computer Science coursework requires an understanding of how real students tend to write about their projects compared to the output of large language models. Several patterns can help you identify submissions that warrant closer attention.

Overly Polished Technical Explanations

When a student genuinely understands the algorithm they have implemented, their explanation tends to be functional but imperfect. They might describe a bubble sort by saying something like "it goes through the list and swaps things that are in the wrong order, and keeps doing that until nothing gets swapped." AI-generated explanations, by contrast, tend to read like documentation: precise, comprehensive, and structured with a clarity that most GCSE students do not naturally produce. If a design section reads as though it was written by someone with a computer science degree, that discrepancy is worth noting.

Generic Evaluation and Testing Commentary

AI tools produce evaluation sections that cover all the standard points a mark scheme might reward - robustness, usability, maintainability, efficiency - but without grounding those points in the student's actual project. A real student writing about testing their quiz application might say "I tested what happens when someone types a letter instead of a number for their answer and it crashed, so I added a try-except block." An AI-generated evaluation is more likely to discuss testing categories in the abstract: "Boundary testing was conducted to ensure the program handles edge cases appropriately." The lack of specific, concrete examples tied to the student's own code is a strong signal.

Disconnection Between Code Quality and Write-Up Quality

One of the most telling indicators is a mismatch between the sophistication of a student's code and the sophistication of their written commentary. A student whose Python program uses basic constructs, inconsistent variable naming, and minimal error handling but whose written evaluation discusses object-oriented design principles, time complexity, and software development methodologies has likely had significant help with the writing. This does not prove AI use on its own, but it should prompt further investigation.

Absence of Debugging Narrative

Real programming projects involve frustration, dead ends, and unexpected bugs. Students who have genuinely built their own solutions can describe specific problems they encountered: "My validation loop kept running forever because I forgot to update the counter variable" or "The program gave the wrong score because I was checking the answer before converting it to lowercase." AI-generated testing sections tend to describe testing as a smooth, systematic process without the messy reality of actual development. If a testing section reads like a checklist rather than a story, it is worth questioning.

How GradeOrbit's AI Detection Tool Works

GradeOrbit's AI detection is part of its school accounts. Rather than asking whether a write-up sounds like AI in general, it compares the student's NEA documentation with their own earlier written work already on file - pieces the department has marked in GradeOrbit. You can run it from a student's profile or across a whole class. Write-ups typed in a word processor or IDE go in as a PDF (Word files aren't accepted, so export first), and handwritten design notes as scans or photos, including from your phone via the QR camera link. For a class set, bulk upload splits the pages by the number of pages per student and matches the name on each cover page to your class list, asking you to pick the student when a name isn't clear.

The primary output is a score from 0 to 100 that measures how far the write-up departs from the student's own earlier writing: low means consistent with how they usually write, high means different in ways worth a closer look. The score is accompanied by a confidence label: Low, Medium, or High - which reflects how certain the analysis is of its assessment. The tool also provides a list of detected signals that contributed to the score, and a reasoning paragraph that explains the overall assessment in plain language. Results appear on the student's profile, and a student with no earlier work on file is skipped, with a note telling you so.

On a GradeOrbit school account, unlimited AI detection is included in every teacher seat with no per-check charge and no tiers to choose between. It runs under your school's signed Data Processing Agreement (DPA), where students' work is held with their real names; uploaded scans are removed when a run archives (90 days by default, adjustable by the school), and student records follow the school's retention window and are wiped at offboarding. By contrast, on an individual teacher account where no school DPA is in place, uploaded student work for marking is redacted client-side in your browser and never stored - it is analysed and the results returned without any data being retained. Across all tiers, student work is never used to train AI models.

Understanding Likelihood Scores for Computer Science

Likelihood scores are probabilistic assessments, not definitive verdicts, and this distinction matters particularly for Computer Science coursework. Technical writing naturally uses a more formal register than creative or personal writing. When a student writes about data structures, algorithms, or testing strategies, they are likely to use standardised terminology and structured explanations - patterns that can overlap with the characteristics of AI-generated text. This means that genuinely student-written technical prose can sometimes produce moderately elevated likelihood scores.

For this reason, the likelihood score should always be interpreted alongside your knowledge of the individual student. Consider whether the quality of the written work is consistent with what you have seen from the student in class. Think about whether the write-up matches the complexity and style of their code. Ask yourself whether the student has demonstrated, in conversation or in lessons, the level of understanding reflected in their written commentary. A student who consistently contributes thoughtful answers in class and whose code shows genuine problem-solving is more likely to have written a polished evaluation themselves than a student who has struggled throughout the course.

The score is a starting point for investigation, not a conclusion. It helps you identify which submissions deserve closer attention, but the final judgment is always yours.

What to Do When You Suspect AI Use

If a likelihood score or your own reading of a submission raises concerns, the most productive first step is a conversation with the student. This does not need to be confrontational. Ask the student to explain their testing strategy in their own words. Ask them to walk you through why they chose a particular algorithm or data structure. Ask them to describe a specific bug they encountered during development and how they resolved it. Students who wrote their own coursework can usually discuss these things fluently, even if their written version is less polished than what they submitted.

If concerns remain after speaking with the student, consult your school's academic integrity policy. Both AQA and OCR have published guidance on the use of AI tools in NEA, and your centre's approach should be aligned with the relevant exam board's position. It is also worth discussing the situation with your Head of Department or exams officer before taking formal action.

For further guidance on interpreting detection results and managing the conversation with students, see our guides on how to interpret AI detection scores.

Keeping the Focus on Understanding

The aim with a Computer Science NEA is not to catch students out but to make sure the marks reflect what each student understands about their own project. A detection score adds one more piece of evidence to the judgments you already make from their code, their lessons and a conversation about how the program was built.

On GradeOrbit for Schools, detection accepts PDFs, photos and scanned pages, compares each write-up with the student's own earlier work, returns a score with the reasoning behind it, and is included in every teacher seat for AQA and OCR work alike; schools can start with a free school trial.