Computer Science Reports and AI Detection: Code, Pseudocode and the Prose in Between

Turnitin's published position on code is short and specific: the model "does not reliably detect AI-generated text in the form of non-prose, or code", and the FAQ adds that Turnitin is "not pursuing ChatGPT code detection at this time." So your listings, your pseudocode blocks and your terminal transcripts are not what the AI percentage is about. It is about the paragraphs between them, which in a CS report means the design rationale, the algorithm walk-through, the complexity analysis and the evaluation discussion. Those paragraphs are also the most uniform writing in the document, because good technical writing is supposed to be uniform.

Separately from any of that: what your department allows you to generate is set by its academic integrity policy, not by what a detector measures. Answering one of those questions does not answer the other, and treating them as the same question is how people end up in a meeting.

Two sentences carry the whole thing. The first is in the FAQ's definition of what gets analysed:

"The model does not reliably detect AI-generated text in the form of non-prose, or code, nor does it detect short-form/unconventional writing such as bullet points (short non-sentence structures)."

Read on one more line, because that is where it becomes useful:

"This means that a document containing several different writing types would result in a disparity between the percentage and the highlights."

A CS report is a document containing several different writing types by construction, so that disparity is the normal state for this genre rather than an anomaly. The report guide states the same exclusion with a longer list, naming poetry and scripts alongside code, and adding tables and annotated bibliographies to the short-form side.

The second sentence usually travels without its surroundings, so it is worth saying where it lives. It is the last line of the answer to "Why is AI detection not being added to Gradescope?", and that answer runs: Turnitin does "not currently have plans to add these capabilities to Gradescope, since the primary use case for Gradescope is handwritten text while for AI detection we're focusing on typed text", then, "In addition, we are not pursuing ChatGPT code detection at this time."

That matters more for computer science than for any other subject, because Gradescope is where a lot of programming coursework is handed in. If your implementation goes to an autograder and your written report goes to a Turnitin assignment, those are two pipelines with different jobs, and the AI writing percentage you eventually see was calculated on the second one. Which Turnitin product has AI detection covers the licensing side of that split.

The definition is on the report guide, and its examples are worth noticing:

"Qualifying text (prose sentences contained in long-form writing format) means individual sentences contained in paragraphs that make up a longer piece of written work, such as an essay, a dissertation, or an article, etc."

An essay, a dissertation, an article. A project report written in the register of an API reference is none of those three, and Turnitin does not publish a ruling on it. What it publishes is the sentence test, so here is that test applied element by element. This is our mapping, not the vendor's.

Two consequences fall out of that table. Your denominator is small, so the percentage is a statement about a slice of the file rather than the file, which the FAQ says in as many words: "This percentage is not necessarily the percentage of the entire submission. If text within the submission is not considered long-form prose text, it will not be included." And if the report is listing-heavy, the qualifying prose can fall low enough that the all-or-nothing behaviour of short documents becomes relevant. The file requirements say a submission needs "at least 300 words of prose text in a long-form writing format" before a report is produced at all.

Turnitin publishes a description of what its false positives tend to have in common:

"Sometimes false positives (incorrectly flagging human-written text as AI-generated), can include content without a lot of structural variation, text that literally repeats itself, or text that has been paraphrased without developing new ideas."

And the next sentence, which is addressed to your marker rather than to you:

"If our indicator shows a higher amount of AI writing in such text, we advise you to take that into consideration when looking at the percentage indicated."

Now read those two properties against a well-written technical document. Structural variation is the thing a reference section deliberately removes: every function gets the same frame, name then parameters then return value then failure modes, so a reader who has learned the frame once can skim the rest. Saying it the same way twice is precisely how you tell a reader that two components behave the same. A style guide that told you to vary the shape of each entry would be a bad style guide.

The same shape appears in the algorithm walk-through, for a different reason. That section usually restates in English what the listing above it already says. Restating something has nowhere to go stylistically. Every step opens with the step, every sentence has the same subject, and the paragraph is a transcript of control flow.

Two honest limits on this. Turnitin gives no frequency for those properties, only a list of what false positives "can include", so nobody can tell you how much of the effect this accounts for. And the model's behaviour is not a rulebook you can reason backwards from: the FAQ says "Our model is not explicitly programmed to evaluate specific signals such as 'burstiness,' 'perplexity,' or other individual metrics sometimes referenced in public discussions." The perplexity and burstiness myth has the fuller version, including the sentence elsewhere on the same page that stops you over-reading that one.

Here is the asymmetry that makes CS reports different from essays. The content excluded from the measurement is not inert background. It is the part of the document where a single altered character makes the document wrong, and a revision pass reads it whether or not anyone is scoring it.

There is a second failure that is harder to see, because the output reads perfectly well. A technical document gives one concept one name. If a revision leaves `hash map` in section 3 and `dictionary` in section 4 for the same object, or alternates between `worker` and `thread`, the document has stopped telling the reader whether those are one thing or two, and a marker cannot resolve it without reading your code. That is damage to the document, and no score enters into it either way. Worth spelling out, because it cuts against a habit that serves you everywhere else: in most writing a defined term is a word choice, and in this genre it is closer to an identifier.

None of these need tooling you do not already have open.

• Copy every command out of the document and run it in a scratch directory. Setup instructions are the first thing to rot and the last thing anyone rereads.
• List the identifiers your code defines and search the document for each one. Anything present in the code and missing from the document is a rename that happened without you.
• Pick your five most important concept terms and search each. One name per concept, everywhere, or fix it now.
• Read every complexity claim against the function it describes. `O(n log n)` and "efficient" are not interchangeable, and only one of them is markable.
• Diff anything inside quotation marks against a real run. Log lines and error messages are quotations.

If the flagged block is your algorithm walk-through, there is a question worth asking before you touch the sentences: is that section doing anything the listing above it does not already do? A walk-through that renames the variables and adds "then" between the steps is duplicated content in a report, whatever any detector says about it. The version that earns its place explains why the loop is structured that way, what the alternative was, and where it falls over.

That is also where your writing has somewhere to go. Design rationale, rejected alternatives, the bug that took two days, what the benchmark does not measure, the limitation you would fix with another week. Those paragraphs vary in shape because the thinking in them varies. Reference-style sections do not, and should not.

Worth being straight about the limits of that advice: I am describing what makes a report better to read and better to mark. Nobody, us included, can tell you what it does to a number. Turnitin does not publish the pooling function or the segment length, and it warns that its own model "may not always be accurate (it may misidentify human-written, AI-generated, and AI-paraphrased text), so it should not be used as the sole basis for adverse actions against a student."

What makes a CS report slow to revise has little to do with sentences. One rewritten paragraph might carry four identifiers, a flag and a version number, and every one of them has to go back against the code before you can trust the paragraph. Count the cost in paragraphs touched.

Which is why HumanPen makes you name the scope first. Upload the document, then either mark the passages or import a Turnitin or iThenticate AI report and let its flagged passages draw the boundary. Everything outside it is left untouched, which for this genre means your listings and your command blocks are not in the pass at all unless you put them there. The engine will not go smaller than a paragraph, so a selection that stops mid-paragraph is widened to cover the whole one and drawn for you to confirm first, and credits count the words actually rewritten. Terminology is on the list of things it aims to preserve alongside structure, citations and layout. Passages still flagged afterwards can be rewritten again at no charge where the conditions for that are met.

There is a line in its FAQ about reviewing complex documents after download. For a report full of identifiers, that means the checklist in the previous section, not a read-through. The document-level version of what breaks in a round trip, fields and cross-references included, is in Word fields, tables of contents and cross-references.

Does Turnitin detect AI-generated code? Turnitin says its model does not reliably detect AI-generated text in the form of non-prose or code, and the FAQ says it is not pursuing ChatGPT code detection at this time. That is a statement about what this report measures. It is not a statement about what your institution permits, which is a separate document you should read.

Is my pseudocode block scored? The published rule is that the model analyses prose sentences inside paragraphs, and it lists short-form and non-sentence structures as things it does not detect. A pseudocode block is line-structured rather than sentence-structured. The paragraph introducing it is prose.

Why is the highlighting so concentrated in one section? Partly arithmetic. If most of your file is excluded, the highlighting can only appear in what is left. Turnitin also describes scoring overlapping segments and pooling the values, so uniform stretches of text tend to produce uniform results rather than a scatter.

My complexity analysis section came back flagged and I wrote every word of it. That happens, and the FAQ paragraph on false positives is the thing to put in front of a marker, especially its closing sentence advising them to take the property of the text into account when reading the percentage. What it will not do is settle authorship, in either direction.

My report is nearly all listings and no AI report was generated. Check the floor before assuming something failed. The file requirements say a submission needs at least 300 words of prose text in a long-form writing format, and a listing-heavy report can sit under that even when the page count looks healthy. The general exclusion list is in what content does Turnitin AI skip.