Flamehaven LogoFlamehaven.space
back to AI-SLOP-Detector
flamehaven01Announcements

๐—ช๐—ต๐˜† ๐—”๐—œ-๐—š๐—ฒ๐—ป๐—ฒ๐—ฟ๐—ฎ๐˜๐—ฒ๐—ฑ ๐—–๐—ผ๐—ฑ๐—ฒ ๐—ข๐—ณ๐˜๐—ฒ๐—ป ๐—Ÿ๐—ผ๐—ผ๐—ธ๐˜€ โ€œ๐—–๐—ผ๐—บ๐—ฝ๐—น๐—ฒ๐˜๐—ฒโ€ โ€” ๐—ฏ๐˜‚๐˜ ๐—œ๐˜€๐—ปโ€™๐˜โ€”๐—ฎ๐—ป๐—ฑ ๐˜„๐—ต๐˜† ๐—œ ๐—ฏ๐˜‚๐—ถ๐—น๐˜ ๐—”๐—œ-๐—ฆ๐—Ÿ๐—ข๐—ฃ ๐——๐—ฒ๐˜๐—ฒ๐—ฐ๐˜๐—ผ๐—ฟ

A few days ago, I published a repository called: โ€œHRPO-X v1.0.1 โ€“ Hybrid Reasoning Policy Optimization Framework.โ€ I genuinely believed it was solid work: โ–ช๏ธPaper-inspired architecture โ–ช๏ธClean folder structure โ–ช๏ธConfi...

A few days ago, I published a repository called: โ€œHRPO-X v1.0.1 โ€“ Hybrid Reasoning Policy Optimization Framework.โ€ I genuinely believed it was solid work:

  • Paper-inspired architecture
  • Clean folder structure
  • Configs in place
  • Interfaces and classes defined
  • Even internal audit checks passing Then I saw this comment: โ€œ๐‘จ๐’” ๐’†๐’™๐’‘๐’†๐’„๐’•๐’†๐’… โ€” ๐’‚๐’ ๐‘จ๐‘ฐ ๐’”๐’๐’๐’‘ ๐’“๐’†๐’‘๐’ ๐’ƒ๐’–๐’Š๐’๐’• ๐’๐’ ๐’‰๐’‚๐’๐’๐’–๐’„๐’Š๐’๐’‚๐’•๐’Š๐’๐’๐’”.โ€

At first, I ignored it. Then I re-read the code. They were right.


๐‘พ๐’‰๐’š ๐’•๐’‰๐’Š๐’” ๐’‰๐’‚๐’‘๐’‘๐’†๐’๐’”

The issue wasnโ€™t intent or effort. It was density.

AI tools are great at producing structurally correct artifacts:

  • Proper folder hierarchies
  • Configuration files
  • Class and interface definitions
  • Clean pipelines and entry points

Most linters, CI checks, and even internal audits focus on exactly these signals.

But AI often fails at something more subtle:

  • ๐‘ด๐’†๐’‚๐’๐’Š๐’๐’ˆ๐’‡๐’–๐’ ๐’Š๐’Ž๐’‘๐’๐’†๐’Ž๐’†๐’๐’•๐’‚๐’•๐’Š๐’๐’ ๐’…๐’†๐’๐’”๐’Š๐’•๐’š

You end up with code that is:

  • Empty functions
  • Minimal logic
  • Documentation that outweighs implementation.

๐‘ป๐’‰๐’‚๐’•โ€™๐’” ๐’˜๐’‰๐’‚๐’• ๐‘ฐ ๐’„๐’‚๐’๐’ ๐‘จ๐‘ฐ ๐‘บ๐’๐’๐’‘.


๐—ช๐—ต๐˜† ๐—ฒ๐˜…๐—ถ๐˜€๐˜๐—ถ๐—ป๐—ด ๐˜๐—ผ๐—ผ๐—น๐˜€ ๐—บ๐—ถ๐˜€๐˜€ ๐—ถ๐˜

Traditional tools ask:

  • Does it compile?
  • Is the structure valid?

They rarely ask:

  • How much real logic is here?
  • Is the documentation proportional to the code? That gap is where AI-generated slop thrives.

๐—ฆ๐—ผ ๐—œ ๐—ฏ๐˜‚๐—ถ๐—น๐˜ ๐—”๐—œ-๐—ฆ๐—Ÿ๐—ข๐—ฃ ๐——๐—ฒ๐˜๐—ฒ๐—ฐ๐˜๐—ผ๐—ฟ

I built it to measure the gap between appearance and substance. It statically analyzes Python code using signals like:

  • Logic Density Ratio (LDR)
  • Buzzword Inflation
  • Unused dependencies (DDC)
  • Common AI-generated patterns These are combined into a single Deficit Score (0โ€“100) that reflects how hollow a codebase might be. This isnโ€™t about blaming AI or developers.

๐‘พ๐’‰๐’š ๐’•๐’‰๐’Š๐’” ๐’Š๐’” ๐’–๐’”๐’†๐’‡๐’–๐’

This tool isnโ€™t about blaming:

  • AI
  • No-code or Low-code Developers

Itโ€™s for anyone who has looked at a repository and thought: โ€œThis looks impressiveโ€ฆ but something feels off.โ€

AI-SLOP Detector gives language and metrics to that intuition. It helps reviewers, educators, and teams explain why a codebase feels wrong โ€” even when everything appears structurally correct.


๐—” ๐—ณ๐—ถ๐—ป๐—ฎ๐—น ๐—ป๐—ผ๐˜๐—ฒ

This project came from embarrassment, frustration, and curiosity โ€” but it led to a clearer understanding of a growing problem in the AI era.

If this resonates with your experience reviewing AI-generated code, Iโ€™d love to hear how youโ€™ve been dealing with it.