Top
Best
New

Posted by Heavykenny 2 hours ago

Show HN: AISlop, a CLI for catching AI generated code smells(github.com)
Hi, I’m Kenny, I’ve been building aislop. I starting working on this after using Claude Code, codex and opencode several times and noticing some slops. They aren’t syntax and passes most tests, they are patterns like empty catch blocks, useless comments, duplicated helpers, dead code and many more. So I built a tool to scan and check for these patterns and wired it into hooks so after each tool call, the agent checks for the slops.

You can try it out with npx aislop scan.

It’s all local and no code is transferred. Thank you.

61 points | 51 commentspage 2
throw03172019 1 hour ago|
> I’ve been building aislop.

This made me chuckle.

Cool tool, the dead code checks can be very helpful. I’ve seen Claude leave unused functions when iterating which always frustrates me.

Heavykenny 1 hour ago|
haha. I love the name - aislop
Retr0id 1 hour ago||
Forgot to switch accounts?
beart 1 hour ago||
OP seems to be an AI account.

> Don't post generated comments or AI-edited comments. HN is for conversation between humans.

Heavykenny 14 minutes ago||
It get hard trying to proof that I’m human.
eithed 1 hour ago||
Can you explain the benefits of running this over rector / eslint? (and to certain degree phpstan / deptrac)
oefrha 1 hour ago||
Apparently https://github.com/scanaislop/aislop with AGENTS.md is not AI slop, but projects of mine last modified before 2016 all contain critical AI slop. So very accurate.
hootz 2 hours ago||
Ran it in my codebase, detected some good stuff, was able to pass the issues to my agent so they can be validated and fixed. Good job!

I'd love for it to have flags for Pi and Crush too :)

Heavykenny 2 hours ago|
Thank you, really appreciate.
sync 1 hour ago||
I tried it on my codebase. There's a lot of overlap with tools like Oxlint / ESLint, I'm not sure that's too valuable vs. a more focused tool that actually focuses solely on 'slop' signals. These lint rules tend to get very opinionated which is why those tools expose so many configuration options.

One real bug tho:

> [ERROR] Imports "mdast" but it's not declared in package.json

A type-only import like `import type { Blockquote, RootContent } from 'mdast';` is actually acceptable if `"@types/mdast": "^4.0.4"` is included in the package.json.

Heavykenny 1 hour ago|
thanks for this catch, really appreciate. Can you create an issue on GitHub so you can easily track when I resolve this?
vinnymac 1 hour ago||
I tried it but see a lot of false positives.

One funny thing I see it doing is deleting seemingly random comments lines, for example if a file has a comment that spans multiple lines but doesn’t use a multi line comment syntax. It just chooses one at random transforming the once useful comment into slop.

tolawuwo 1 hour ago|
Thanks for the feedback, we’ll check that out
maddhruvhn 1 hour ago||
awesome work, someone is caring about using less token :clap:
Der_Einzige 2 hours ago||
Related, we made "Antislop", a framework for removing repetitive phraseology from LLMs: https://arxiv.org/abs/2510.15061
explosion-s 50 minutes ago|
This is a super cool paper! The only thing I'm a bit skeptical of is the detection of 'slop' to begin with - it would be very exciting to see some sort of way to steer a model more towards human-like output more generally. Here I imagine a bit of a challenge is that you're 1) creating the measurement for 'slop' and then 2) reducing it, so yes, you can have amazing results in the detection of the slop you've found (the methodology may be novel - a slight improvement over DPO), but this is a chicken and egg problem, as each new model would suffer differently based on training, RLHF, etc. It's not a very useful method to improve an LLM's writing quality, but rather just reducing the symptoms of said bad writing.

I'm additionally concerned about removing the LLM's voice to begin with, as though an LLM may far overuse specific words and phrases, so too do individual authors. Reducing an LLM towards the average author would result in an 'average' voice, paradoxically unlike any specific author.

I am currently doing research on something very similar over the summer but more towards the detection as opposed to the generation side - I'd love to discuss this with someone in the field if you had a few minutes sometime!

cumshitpiss 1 hour ago|
[dead]
More comments...