We Built Linters to Catch Our Own Mistakes. Now We Need Linters to Catch the Robot’s.

A new category of tools has appeared almost overnight: linters that scan your codebase specifically for the mess AI coding agents leave behind. I think they tell us something uncomfortable about how we work now.

There is a tool making the rounds right now called AISlop. The name alone made me laugh out loud the first time I saw it on Hacker News, because it is so honest it almost hurts. It is a command-line linter, and its entire job is to scan your codebase for the specific patterns that AI coding agents leave behind when they are optimizing for “make the prompt pass” instead of “keep this code alive for the next three years.”

Six months ago “AI slop” was a meme. A thing you complained about on a Friday. Today there is a whole little category of software being built to detect it, score it, and block it from shipping. And I cannot stop thinking about what that says about all of us.

What this tool actually does

Let me describe it plainly, because the concept is more interesting than any one product. AISlop runs locally. You point it at your repo with something like npx aislop scan, and it goes hunting for a very particular list of crimes. Swallowed exceptions, the kind where an agent wraps something in a try/catch and then quietly does nothing in the catch block so the code “works.” Narrative comments, those little tour-guide lines that explain what the next line obviously does. Dead helper functions that got generated, used once, and then orphaned. Unsafe type casts shoved in to make the compiler stop yelling.

It scores all of that on a zero-to-one-hundred scale, and you can wire that score into your CI so a pull request fails if it dips below a threshold. The version I read about had grown to something like forty-odd rules across most of the languages you would actually care about — TypeScript, JavaScript, Python, Go, Rust, Ruby, PHP, Java. And here is the part I genuinely respect: it does not phone home to a model. No LLM calls, no tokens, no data leaving your machine. It is just old-fashioned static analysis, fast and local, pointed at a brand-new problem.

It is not alone, either. There is a Python-flavored cousin floating around that hunts for over-engineering, hallucinated APIs, and dead code. And the bigger players — the ESLints and SonarQubes of the world — are reportedly circling the same idea. When the incumbents start eyeing a category, you know it has stopped being a joke.

The tell that gives the robot away

What fascinates me is how recognizable the list is. If you have reviewed any meaningful amount of AI-generated code in the last year, you read those rules and nod along like you are looking at a wanted poster of a criminal you have personally chased.

The narrative comment is the one that gets me every time. You ask an agent to write a function, and it hands you back something that is genuinely fine, except every third line has a comment narrating itself. // loop through the users. // check if the user is active. // return the result. Thank you. I can read. A human engineer learns to stop writing those comments somewhere around their second year, because they realize the code already says it. An agent never learns, because it was trained on a billion tutorials where the comments were the whole point.

And the swallowed exception is the dangerous one. It is dangerous precisely because it is invisible. The agent was asked to make something work, the empty catch block makes the error disappear, the demo runs, everybody claps. Six weeks later something fails silently in production and you spend a day discovering that the error you needed was caught and thrown into a void back when nobody was paying attention. That is not a style nitpick. That is a real bug, wearing the costume of working code.

So I get why these tools exist. They are codifying the gut feeling that experienced reviewers already have. They are taking “this smells like a machine wrote it” and turning it into a rule you can actually enforce.

The thing that actually bothers me

Here is where I have to be honest with myself, because the easy version of this post is “ha ha, AI writes sloppy code, here is a tool to catch it, the end.” That version is lazy and I do not believe it.

The thing that actually bothers me is that none of these patterns are new. Swallowed exceptions, dead code, comments that narrate the obvious, casts that paper over a type problem — humans have been committing every one of these sins since before any of us typed our first prompt. I have written empty catch blocks at 2am. You have too. The difference is not that the machine invented new bad habits. The difference is volume and confidence.

When I wrote a lazy catch block, I knew I was being lazy. There was a little voice. The agent has no voice. It produces the sloppy version and the careful version with exactly the same cheerful tone, at exactly the same speed, in exactly the same quantity. It will generate a thousand lines before lunch and every one of them looks equally finished. The slop is not worse than human slop in kind. It is worse in scale, and it arrives pre-laundered, looking clean.

That is why a linter for it suddenly makes sense in a way it never quite did before. We did not need a dedicated “human laziness detector” because human laziness throttled itself. We could only produce mediocre code so fast. The machine removed the throttle. And the moment you remove the throttle on output, you need a new throttle on quality, because the old one — the simple fact that writing code takes effort — is gone.

The trap I am watching people fall into

So tools like this are good. I want to be clear about that. Anything that drags a vague feeling into the daylight as an enforceable rule is, on balance, a gift. But I can already see the trap, because I have watched our industry walk into the exact same trap with every quality tool that came before.

The trap is this: we will use the score to stop thinking.

I have seen it with test coverage. The number was supposed to be a proxy for “this code is well tested.” Within a year it became the goal itself, and people wrote useless tests that touched lines without asserting anything, just to push the percentage up. The map became the territory. I have seen it with linter configs that teams turn off rule by rule until the linter agrees with whatever they were already doing.

An AI-slop score is going to be irresistible in exactly this way. A green ninety-four out of one hundred feels like permission to merge without reading. And that is precisely backwards. The whole reason this category exists is that AI-generated code looks finished when it is not. A tool that gives that same code a confident green number is, if you are not careful, just a second machine agreeing with the first machine that everything is fine. Two robots nodding at each other while the human signs off.

The score catches the mechanical slop — the empty catches, the narration, the dead helpers. It cannot catch the slop that matters most: the function that is beautifully clean and solves the wrong problem. The architecture that is locally tidy and globally wrong. The code that does exactly what the prompt said and nothing the project actually needed. No static analyzer on earth flags “technically correct, strategically pointless,” and that is the failure mode I lose the most sleep over.

What I actually think we should do with it

I am going to run one of these on a couple of my own repos this week, and I will tell you what I expect to find, because I think the expectation is the interesting part. I do not expect it to find robot code. I expect it to find my code — the corners I cut, the catch blocks I left empty when I was tired, the helper I wrote in March and forgot to delete. I think the most useful thing about an AI-slop linter is that it does not actually care who wrote the slop. It just finds the slop.

And maybe that is the healthiest way to hold it. Not as a robot-detector. Not as a way to feel superior to the agent. But as a mirror that happens to have gotten very good at spotting a specific kind of carelessness, no matter whose fingers — or weights — produced it.

Here is the rule I am settling on for myself. The score is allowed to make me look closer. It is never allowed to make me look less. If the linter flags ten things, I read those ten things and I fix them. But a clean score buys the code exactly zero trust it has not otherwise earned, because I have been burned too many times by code that looked finished. The tool is a smoke detector. A smoke detector is wonderful. It is also not the same thing as knowing how to put out a fire.

The bigger picture

Step back far enough and there is something almost poetic about this moment. We spent two years building machines that write code faster than we ever could. And the very next thing we built was a machine to check up on the first machine. The hype cycle promised that AI would let us write less software. Instead it let us write more software, and now we are urgently building more software to manage the software the software wrote.

I do not say that cynically. I think it is just what tools do. Every leap in how fast we can produce something is followed, almost immediately, by a leap in how we inspect what got produced. The printing press gave us proofreaders. The assembly line gave us quality control. The compiler gave us the linter. The coding agent is giving us the slop detector. It is the same story, told again, faster.

So no, I do not think AISlop and its cousins are a sign that AI coding is a failure. I think they are a sign that it is real. You do not build quality gates for a toy. You build them for something you have decided to depend on. The fact that we are bothering to police this output at all is the loudest possible signal that the output is now load-bearing.

The robots are writing our code. We are writing the tools that watch the robots. And somewhere in the middle, still, is a person who has to decide whether to hit merge. That person is still you. No score is going to take that decision off your hands, and the day you let it is the day the slop wins. Use the tool. Read it as a mirror, not a verdict. And then go read the code anyway.