AI Detectors and Technical Writing: Code, Citations, and Formulas

Here’s an uncomfortable fact for anyone who writes for a living in a technical field: the cleaner and more standardized your writing is, the more likely a detector is to call it a robot. Code, lab reports, math proofs, and reference-heavy literature reviews all share a trait that AI detectors are tuned to punish. They’re predictable. And predictability, to most detectors, looks an awful lot like a machine.

If you’re a CS student whose function got flagged, or a researcher whose carefully written methods section came back with a scary “AI” percentage, this is for you. Let’s get into why it happens and what you can reasonably do about it.

Key takeaways

• Detectors mostly measure how *predictable* your text is, not whether a human wrote it. Code, equations, and standardized prose are predictable by design.
• Citations and bibliographies are some of the most formulaic text you’ll ever produce, so they can drag a score up on their own.
• A peer-reviewed study of one anatomy/physiology course found detectors false-flagged about 1.3% of student writing; human graders did worse, around 5%.
• The same low-perplexity mechanism that flags code is the one that penalizes non-native English speakers (Stanford, Liang et al., 2023).
• Scores are probabilities, not proof. Keep your drafts and version history so you can show your work.

What a detector is actually measuring

Almost every popular AI detector is built around one idea: predictability. The technical term is perplexity, and the short version is that detectors run your text through a language model and check how surprised that model would be by each word, given the words before it. Low surprise reads as machine; the choppy, uneven word choices humans make read as “burstiness,” and detectors treat the absence of it as a red flag. GPTZero, for example, describes its own approach as a blend of per-sentence perplexity and burstiness across a document. If you want the full mechanics, we walk through them in how AI detection actually works.

Hold that up against technical writing and the problem jumps out. None of it measures whether a human wrote the text. It measures whether the text is statistically smooth. Those are very different questions, and technical writing is where the gap between them gets wide.

Why code confuses detectors

Code is the clearest case, so start there.

A programming language is, by definition, a system of rigid rules. After if (, something predictable follows. After an opening brace, you get a body and then a closing brace. Indentation is conventional. Variable names like i, temp, result, and data show up everywhere. Boilerplate (imports, constructors, getters and setters) is close to identical across thousands of projects.

To a perplexity model, that’s a goldmine of low-surprise tokens. The next character is almost always guessable, which is exactly the signature it associates with generated text. So a function you wrote by hand, debugged for two hours, and understand line by line can come back flagged. Not because it looks generated, but because *all* code looks “predictable” to a tool that learned its instincts on essays and blog posts.

There’s also a blunter issue: a lot of detectors just weren’t designed to ingest code. Feed them a fenced code block and you’re outside the distribution they were trained on. The number they spit out isn’t a careful judgment. It’s closer to a shrug rendered as a percentage.

Citations, references, and the bibliography trap

This one catches people off guard. Your reference list can hurt you.

Think about what a citation actually is. “Liang, W., Yuksekgonul, M., Mao, Y., Wu, E., & Zou, J. (2023). GPT detectors are biased against non-native English writers. *Patterns*, 4(7).” That’s a fixed template with the slots filled in. Author, year, title, venue, volume. There’s almost no room for personal voice, no surprise, no burstiness. A page of references is one of the most uniform blocks of text a human ever produces, which means it can read as low-perplexity and pull your overall score in the wrong direction.

The same goes for dense in-text citation and block quotes. When you quote a source verbatim, those words aren’t in your voice, by definition. A literature review stitched from many short quotes and citations hands a detector a lot of non-you, highly formatted text to react to. Researchers have noted that properly quoted passages sometimes get misread as generated, which is a maddening outcome when the entire point of the quote was to be faithful to a source.

This isn’t a reason to cite less. It’s a reason to understand that a flag on a reference-heavy section tells you about format, not authorship.

Equations, formulas, and the prose around them

Math content trips detectors on two fronts.

The notation itself (LaTeX, symbols, inline formulas) is gibberish to a tool expecting natural language. Some tools strip it, some choke on it, and either way you’ve added noise.

The sneakier problem is the connective prose. Technical and mathematical writing leans on a small set of conventional phrases because precision demands it. “Substituting equation 3 into equation 4 yields…” “It follows that…” “Assume without loss of generality…” “By the triangle inequality…” These aren’t lazy. They’re standard because the field agreed on them, and clarity beats novelty when you’re proving something. But standard means predictable, and predictable means low-perplexity. You can’t really fix this by writing your proof in a quirky voice; nobody wants a quirky proof. The realistic move is to keep your *explanatory* prose clear and in your own words, and accept that the formal scaffolding will always score “machine-like.” It’s supposed to.

A worked example: the flagged methods section

Picture a grad student, Maya, writing the methods section of a microbiology paper. Here’s the kind of sentence she writes:

> “Cultures were incubated at 37°C for 24 hours. Optical density was measured at 600 nm. Samples were centrifuged at 10,000 g for 10 minutes, and the supernatant was collected for analysis.”

Every sentence is short, declarative, passive, and conventional. That’s not a flaw. It’s the house style of experimental science, and reviewers would frown if she got creative with it. Standardized methods exist so other labs can reproduce the work exactly.

Run that paragraph through a detector, though, and the perplexity is low across the board, the burstiness is near zero, and the structure is repetitive. The tool sees a smooth, predictable, formulaic passage and outputs a high “AI” probability. Maya wrote every word. The detector isn’t lying, exactly. It’s answering “is this predictable?” with a confident yes, and then mislabeling that answer as “is this AI?”

You don’t have to be in a lab to hit this. A CS student submitting a sorting function, or a finance analyst pasting in the same compliance boilerplate every quarterly report requires, runs into the identical wall. Good technical writing optimizes for the exact qualities detectors flag.

How often this actually goes wrong

Fair question: is this a real risk or a horror story? The honest answer is that the false-positive rate on technical writing is low in percentage terms but absolutely not zero, and the stakes are personal.

A peer-reviewed study in *Advances in Physiology Education* ran AI detectors on writing from a single anatomy/physiology course (about 190 student submissions) and reported a false-positive rate near 1.3% for the detectors, versus roughly 5% for human raters. So the detectors beat the humans there. Worth being honest about the study’s own headline, though: it found that aggregating several detectors together pushed false positives close to zero. That’s a genuine fix, but it’s one a lab or a journal can adopt, not something an individual student controls. You don’t get to pick which single detector your school runs, and 1.3% across a class of 300 writing five assignments each still adds up to a pile of individual accusations. Being the 1.3% feels like 100%.

OpenAI built its own AI-text classifier and then pulled it in July 2023, citing low accuracy. By OpenAI’s own published numbers, the tool correctly caught only 26% of AI text while wrongly flagging 9% of human text. If the company that makes the models couldn’t make detection reliable enough to keep online, that should calibrate how much faith you put in any single score. We dug into why detectors sometimes flag human text if you want the longer version.

The bias connection you should know about

In 2023, a Stanford team (Liang et al., published in *Patterns*) ran GPT detectors on TOEFL essays written by non-native English speakers. More than half got misclassified as AI-generated, while essays by US eighth-graders were judged almost perfectly. The reason matters here: the misclassified essays had measurably *lower perplexity*. Writers with a smaller range of English phrasing produced more predictable text, and the detectors punished them for it.

This is the same mechanism that flags your code and your methods section. Low perplexity gets read as “AI,” whether the cause is a citation template, a chemistry protocol, a closing brace, or a writer working in a second language. The detector can’t tell the difference between “machine-generated” and “constrained by format or fluency.” It just sees smooth text. That’s not a bug you can write around. It’s the design.

What technical writers can reasonably do

You can’t make a reference list bursty, and you shouldn’t try to make a proof quirky. So the goal isn’t to game a number. It’s to protect yourself and write well anyway.

• Keep a paper trail. Document version history, draft files with timestamps, commit logs for code, lab notebooks. If a score ever gets used against you, evidence of process beats arguing about a percentage. This is the single most useful habit, and we cover it in our guide on how students can defend themselves.
• Separate the formulaic from the explanatory. Let your methods, citations, and equations be standard. Put your real voice into the parts where voice belongs: the introduction, the discussion, the “why this matters” passages. Those sections carry your authorship and read as human.
• Don’t sand down your prose to nothing. Over-editing for “natural” output often makes writing blander, which is its own AI tell. If a section genuinely reads flat and robotic, revise it for clarity and rhythm, not for a score.
• Treat the score as a signal, never a verdict. Detectors output a probability. A high number on a technical document is a prompt to look closer, not a finding of guilt.

If you want to sanity-check how a piece of writing reads before you hand it in, you can check a draft for free and see which sentences a detector reacts to. Use it to find the genuinely flat passages worth improving, not to chase a perfect green light. The point is to write clearly and stand behind your work, not to outsmart a probability estimate.

Frequently asked questions

Bottom line: technical writing is predictable on purpose, detectors are built to flag predictability, and the collision produces scores that say nothing reliable about who actually wrote the words. So know how the tool works, hang onto your drafts, and don’t let a percentage overrule what you know about your own writing.