AI code humanizer: what people mean, and why text tools do not apply

Three different products hide behind one phrase. The first is the one the query usually intends: a tool that takes a model's output in Python or Java and changes it so an AI code detector labels it human. The second is a readability tool, a formatter or linter that renames variables, adds comments and reorders functions so code looks hand-written to a person. The third is not a product at all: a text humanizer, built for essays, with code pasted into it.

The 12 tools in the full humanizer ranking are prose paraphrasers. Their pricing pages describe essays, blog posts, emails and research text, and the protocol's 24 inputs are six prose genres. No page on this site scores a tool on code, because no run includes code.

Because what a text humanizer does is exactly what code cannot survive. A prose humanizer substitutes synonyms, reorders clauses, varies sentence length and shifts tone, and the reader forgives a slightly different word. Code forgives none of that. A renamed keyword is a syntax error; a reordered statement can change what the program does; a "synonym" for a library call is a call to a function that does not exist.

There is a narrower version of humanizing that code does survive: renaming variables, reformatting whitespace, adding or stripping comments, splitting or merging functions. Those edits leave the program's behaviour alone and change its surface. Yang and colleagues call these revision attacks and tested their own detector against them (Yang et al. 2023, Zero-shot detection of machine-generated codes, arXiv, read 9 November 2026). The catch is that surface edits are also what a style guide produces, so the same pass that a student might use to hide a model's work is one a maintainer uses to make code readable, and a detector cannot tell the motive.

The same two families as text detectors, applied to tokens of code. Wu and colleagues' survey of detection methods sorts the field into watermarks, statistics-based detectors, trained neural classifiers and human-assisted methods, and names out-of-distribution text and deliberate attacks as shared problems (Wu et al., A survey on LLM-generated text detection, arXiv 2310.14724, read 9 November 2026). Code is an out-of-distribution case for a detector trained on prose: the vocabulary is small, the syntax is rigid, and two correct solutions to the same problem can be nearly identical whoever wrote them.

Yang and colleagues found that existing training-based and zero-shot text detectors were ineffective on code, which they attribute to the statistical structure of code, and modified DetectGPT with a surrogate model to estimate the probability of the rightmost tokens, testing on Python from the CodeContest and APPS datasets and generalising to Java (Yang et al. 2023, arXiv 2310.05103, read 9 November 2026). They also report that a small code model, PolyCoder at 160 million parameters, served as a stronger detector than a billion-scale one. Nguyen and colleagues took the classifier route: GPTSniffer, built on CodeBERT, classified snippets as human or AI and outperformed two baselines, GPTZero and OpenAI's text classifier, with similar training data and paired snippets improving the result (Nguyen et al. 2023, Is this snippet written by ChatGPT?, arXiv, read 9 November 2026).

The education study is the one a student or instructor should read first. Pan and colleagues collected 5,069 coding problems with human solutions from Quescol, Kaggle and LeetCode, wrote 13 variants of each prompt to instruct ChatGPT, and assessed five AI content detectors on the outputs, concluding that existing detectors perform poorly in distinguishing human-written from AI-generated code (Pan et al. 2024, Assessing AI detectors in identifying AI-generated code, ICSE-SEET, read 9 November 2026). The same caution that governs prose detectors governs code ones, and the guide on whether AI detectors work sets out the prose figures. No detector score should be the only evidence in a misconduct case.

Not as such. Google's guidance on AI-generated content states that appropriate use of AI or automation is not against its guidelines, that using automation to generate content primarily to manipulate search rankings violates its spam policies, and that AI gives content no special gain, so useful content might do well and poor content might not (Google Search Central, Guidance about AI-generated content, read 9 November 2026). Its helpful content page adds the "How" question: when automation substantially generates content, a disclosure is useful where a reader might reasonably ask how the page was made (Google Search Central, Creating helpful, reliable, people-first content, read 9 November 2026).

For a developer publishing tutorials or snippets, that guidance points away from a humanizer and toward two plainer things: code that runs, and a line saying how it was produced. Nothing in either Google page read suggests that a search system runs an AI code detector over page content, and nothing suggests that disguising a model's code would help a page rank.

Read the policy that applies to you. A programming course's AI policy says whether model-assisted code is allowed, with what disclosure, and that answer is not changed by any tool. A developer publishing code owes readers working code and, where a reader would reasonably ask, a note on how it was made, which is what Google's guidance asks for, read 9 November 2026.

If the question behind the search is "will this code be flagged", the three studies above are the honest answer: code detectors exist, specialised ones do better than prose ones, and the one classroom-scale assessment found them poor. A reading from any of them is true for its date and its model, and should sit beside the code's own history, commits, drafts and the writer's ability to explain it, before anyone draws a conclusion.