u/prophet1906

I have been noticing a pattern: AI coding assistants (Copilot, Cursor, Claude, etc.) consistently over-generate code. Unused imports, god functions, pass-through wrappers, single-implementor interfaces, files nobody imports — the list goes on. Worse, when the existing codebase is already messy, the AI mimics the garbage and propagates it.

So I am building ai-slop-detector, a tree-sitter-based analysis engine that catches these patterns and nudges AI assistants to fix them mid-session.

How it works:

• Coding Assistants generates code → detector analyzes it → specific feedback sent back → Coding Assistants adjusts
• Uses tree-sitter (no language-specific compilers), so it works across TS/JS/Python/Go/Rust/Java
• Two modes: real-time nudging during generation, and codebase review for auditing existing projects

The second mode is what SAST & DAST tools already cover, real-time nudging is what I am more interested in. I know that LSP integration with most Coding Assistants already exist, but they do not check code quality. LSP only focuses on syntax errors. Please note, I used to maintain PMD in past, so am good with AST walking and tree-sitter is my preference based on past experience. But, I do value your opinions, if you have strong arguments to use something else, please let me know.

What it catches:

• Unused imports/vars/params/exports
• God functions, empty blocks
• Pass-through functions (just delegates with the same args)
• Single-implementor interfaces
• Orphan files, duplicate logic across files
• Unnecessary abstraction layers (the classic Service→Manager→Helper chains)
• ...

Interfaces:

• CLI: detect-slop src/file.ts (works with any coding agent using skills)
• Programmatic API: import { analyze } from 'ai-slop-detector'

I would build a pi extension on top of the programmatic API for myself and maybe(no guarantee) provide skills for other.

The core philosophy: every line must exist for a reason. No speculative code, no "just in case" abstractions, no matching bad patterns from surrounding code.

Still early, would love feedback. Is this something you'd actually integrate into your workflow? What slop patterns annoy you most that I should prioritize? From technical standpoint, do you have any tips?

Will share git repo and keep everyone posted in future.

TLDR: We don’t need more reusable packages. We need better ideas, implementation approaches, and clear tradeoffs (alternatives, pros and cons).

I have been seeing a growing number of reusable Pi packages shared here for relatively simple things like web search and web fetch. It’s great that people are contributing, but I want to offer a slightly different perspective.

When I started with Pi, I quickly realized I needed web search. I initially used a DuckDuckGo MCP setup via Docker, but after digging into it, it felt like unnecessary abstraction since it mostly aggregates results from existing engines. I then simplified things to two lightweight tools: one for search and one for fetch.

As I explored further, I became more conscious of safety and guardrails, especially around fetching arbitrary pages. That led me to use the Perplexity API (sonar pro) for search with citations, and then fetch content only from those citations. This gave me a cleaner and somewhat safer pipeline. The full setup is still roughly ~100 LOC and has been stable for my use cases. I keep a DIY search fallback, but haven’t needed it so far.

This experience shaped my view: if something is simple enough to build in a short amount of time, it may not need to be packaged and distributed as a reusable module.

What originally attracted me to Pi was the ability to tailor things to my own workflow instead of depending on external packages. Reusable packages are useful for complex or hard to implement components, but for simpler building blocks, they can sometimes add unnecessary indirection and dependency overhead.

A constructive suggestion for the community:
Focus more on sharing ideas, design patterns, and implementation strategies. For example, what approach you chose, what alternatives you evaluated, and the tradeoffs involved. This helps others learn and adapt solutions to their own context, rather than just plug in a package.

I still really value this community and the Pi ecosystem. I would just like to see more emphasis on “what to build” and “how to think about building it,” not just “here’s a package.”

I am curious to learn how others here think about this balance.