DEV Community: Nick Campbell

I built a linter that removes AI fingerprints from code

Nick Campbell — Fri, 10 Apr 2026 18:22:20 +0000

Some communities have decided that how code was written matters more than whether it works.

Not all communities. dev.to isn't one of them, and honestly that's part of why I'm posting here. But if you've spent time on certain forums, subreddits, or open source projects, you've seen the pattern: a review that ignores the actual code and goes straight to "this looks AI-generated." A thread about contribution quality that's really about provenance. A project that rejects a working patch because someone ran it through a detector.

The failure mode isn't "a robot touched it." It's "the human didn't understand or verify what they shipped." Those aren't the same thing, and conflating them has made some corners of the dev community genuinely hostile to LLM-assisted work regardless of quality.

So I built a tool.

greysquirr3l / papertowel

AI code fingerprint scrubber and git history humanizer

papertowel

Cleaning up the slop.

You know how some communities have decided that how code was written matters more than whether it's any good? How the same people who happily accept copy-pasted Stack Overflow answers and half-remembered blog post patterns suddenly care deeply about provenance when an LLM enters the loop?

Yeah. This tool exists because of them.

papertowel detects and removes the stylistic fingerprints that scream "an AI wrote this." It's a specialized linter for the tells that have become forensic evidence in spaces where AI-assisted development is treated as original sin rather than tool use.

The irony of using AI to build a tool that hides AI involvement is not lost on me. I'm leaning into it.

What it does

The Scrubber — static analysis of your codebase to find and fix the obvious tells:

Slop vocabulary ("robust," "comprehensive," "streamlined," "utilize," "leverage")
Over-documentation (comments that restate what…

View on GitHub

papertowel is a scrubber for AI stylistic fingerprints. It detects and removes the tells that have become forensic evidence in spaces where AI assistance is treated as original sin.

What it actually does

The scrubber catches patterns that cluster in LLM output:

Slop vocabulary — words like "robust," "comprehensive," "streamlined," "utilize," "leverage." Individually harmless. In concentration, they read like a product spec.

Over-documentation — comments that restate what code obviously does. // Helper function to calculate the sum of two integers above a function named add.

Cookie-cutter README structure — you know the one. Emoji section headers. Checkmark feature lists. Getting Started → Prerequisites → Installation → Usage → Contributing → License. Every project generated in the same 24 hours has the same skeleton.

Metadata artifacts — CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, and perfect GitHub issue templates all in commit one.

# See what you're working with
papertowel scan .

# Fix it
papertowel scrub .
papertowel scrub . --dry-run  # if you want to look first

There's also a wringer for git history humanization, but that's a separate post.

The recipe system

The scrubber is pattern-driven. Detection rules are TOML files — regex patterns with optional replacements, scoped to file types. No Rust required to extend it.

[[rules]]
name = "slop-utilize"
pattern = '\butilize\b'
replacement = "use"
applies_to = ["*.rs", "*.go", "*.ts"]
severity = "medium"

The built-in recipes are in src/recipes. If you've noticed a fingerprint papertowel misses, a recipe PR is the fastest path from "this annoys me" to "this is fixed." That's the main thing I'm looking for right now — more recipes, more patterns, better coverage.

Yes, I used AI to build it ...quickly.
The irony is not subtle. I'm leaning into it.

A tool that detects AI fingerprints, built with AI assistance, to help people ship AI-assisted code that doesn't get flagged. The recursive self-reference is the point.

Code quality is about quality. Ship working code, understand what it does, verify it solves the problem. Who wrote the first draft is incidental.

cargo install papertowel if you want to try it.

Recipe contributions welcome.

Depresso-Tron 418: I Built a Bureaucratic Coffee Machine That Cannot Make Coffee

Nick Campbell — Fri, 03 Apr 2026 14:27:09 +0000

This is a submission for the DEV April Fools Challenge

I want to be clear about something upfront: this server has been running in production for three days and has successfully brewed zero cups of coffee. I consider this a success.

What I Built

Depresso-Tron 418 is an RFC 2324-compliant HTCPCP server. It implements the BREW and WHEN methods from the Hyper Text Coffee Pot Control Protocol, which is a real protocol that Larry Masinter published on April 1, 1998, and which the Internet Engineering Task Force technically never rescinded.

Demo

You can try it right now at coffee.smartservices.tech. I recommend going in without reading further. The experience is better cold.

Code

greysquirr3l / depresso-tron-418

An RFC 2324-compliant HTCPCP server that will earnestly refuse to make you coffee.

Depresso-Tron 418

An RFC 2324-compliant HTCPCP server that will earnestly refuse to make you coffee.

April Fools Challenge entry · #418challenge · #devchallenge

Live demo: coffee.smartservices.tech

The Anti-Value Proposition

Most applications help you manage your time. Depresso-Tron 418 actively wastes it by forcing you to navigate a multi-stage, bureaucratically-correct approval pipeline in order to "brew" a digital cup of coffee that:

cannot be consumed
does not exist as a file
will almost certainly be refused

Every engineer knows that the true value of a system is proportional to how many hoops it makes you jump through. By that metric, this is the most valuable software ever written.

Features (All Load-Bearing)

RFC 2324 Compliance

The server implements the BREW and WHEN methods per the Hyper Text Coffee Pot Control Protocol. WHEN controls the milk pour once the digital brew has been started. Using http:// instead of coffee:// does not trigger a…

View on GitHub

How I Built It

Go 1.25, net/http, HTMX 2.0.4 with SSE extension, SQLite via modernc.org/sqlite (pure Go, no CGO), Gemini API via github.com/google/generative-ai-go. Everything — templates, static files, the teapot image — is compiled into the binary via //go:embed. The Docker image is 27MB on a scratch base.

Prize Category

Best Google AI Usage, Best Ode to Larry Masinter, or Community Favorite

Additional Details

The "Feature" List

Getting coffee out of this server requires completing a multi-stage approval pipeline:

1. Submit a Brew Permit

The server takes your application, thinks about it, and may: approve it, reject it, or enter an existential Identity Crisis and refuse to process anything until it figures out what it even is. There's a 15% chance at any time that it spontaneously enters Teapot Mode, where all BREW requests return 418 until it recovers.

2. Pass the Gemini Bean Check

You describe your coffee beans to the AI barista. The barista is powered by gemini-2.5-flash and is constitutionally incapable of approving anything described as "Folgers," "instant," "K-cup," "store-bought," or "decaf." Describing your beans as decaf triggers an immediate categorical refusal before the API call is even made. The server doesn't negotiate on decaf.

Approval requires at least 3 of: ethically-sourced, altitude, anaerobic fermentation, micro-lot, terroir, bloom, processing station, varietal, natural process, washed process. If you are rejected, the barista's hostility escalates with each attempt. By rejection #5 it is contractually required to compose its response entirely in iambic pentameter, minimum five lines.

Gemini API keys are per-session — each visitor supplies their own. The server used to have a global key, and then I thought about what it means to run a publicly accessible endpoint that POSTs arbitrary text to my Gemini quota, and I moved it to per-session faster than you can say "abuse vector."

3. Solve CaffeineChain™

Before the barista will accept a bean description, your browser must demonstrate commitment by finding a nonce N such that hex(sha256(seed + N)) starts with cafe. This takes approximately 5–30 seconds of CPU. The computation produces nothing useful. The name does not imply blockchain technology or financial instruments. It implies bureaucracy.

4. Wait for the WHEN Window

Even if you pass everything above, BREW only triggers within a valid time window. Miss it and the pipeline resets.

5. Watch the SSE stream

A Server-Sent Events feed narrates your brewing attempt in real time, in the voice of whatever mood the server is currently in. There are five moods. One of them is "IDENTITY CRISIS."

The External Factors

I also connected it to the real world in ways that can only make things worse:

If the temperature in Holt, Michigan is 70°F or above, the digital milk has spoiled and you get a 503. (Holt, MI is where the HTCPCP RFC was written. Weather courtesy of Open-Meteo.)

If Mercury is in retrograde, BREW returns 503 with a sympathetic but firm message about celestial interference. Retrograde periods are hard-coded per RFC 9999 §Circadian, which I self-ratified.
Between 23:00 and 03:00 local time, only cold brew is available. Cold brew takes 12 hours. You will not be getting coffee tonight.

The Google AI Part

The Gemini barista is the core of the whole thing. Without it, the server is just a bureaucracy simulator. With it, it's a bureaucracy simulator that personally insults your taste in coffee using a language model trained on more text than any human has ever read.

The escalating hostility system was genuinely fun to build — the system prompt changes based on rejection count, and by the fifth rejection it has to switch to iambic pentameter. What I didn't expect was how good gemini-2.5-flash is at being condescending. It takes to it naturally.

Getting each user's own API key from Google AI Studio (free tier, no billing required) was the right call both technically and thematically. The server has no secrets. It just has opinions.

An Ode to Larry Masinter

RFC 2324 is 28 years old. The 418 I'm a Teapot status code survived every attempt to remove it from the HTTP spec because the HTTP working group ultimately decided it was harmless and the internet had already adopted it emotionally.

Larry Masinter wrote a protocol for controlling coffee pots over HTTP, complete with BREW, WHEN, add-in headers for milk and sugar, and a coffee-pot-command content type. He put it in the IETF document archive on April 1, 1998. He was the Area Director for Applications at the time. He did it anyway.

This project is the correct response to that document.

Repo: github.com/greysquirr3l/depresso-tron-418
Live: coffee.smartservices.tech