Show HN: Pyscn – Python code quality analyzer for vibe coders (github.com)

136 points by d-yoda ↗ HN
Hi HN! I built pyscn for Python developers in the vibe coding era. If you're using Cursor, Claude, or ChatGPT to ship Python code fast, you know the feeling: features work, tests pass, but the codebase feels... messy.

Common vibe coding artifacts:

• Code duplication (from copy-pasted snippets)

• Dead code from quick iterations

• Over-engineered solutions for simple problems

• Inconsistent patterns across modules

pyscn performs structural analysis:

• APTED tree edit distance + LSH

• Control-Flow Graph (CFG) analysis

• Coupling Between Objects (CBO)

• Cyclomatic Complexity

Try it without installation:

  uvx pyscn analyze .          # Using uv (fastest)
  pipx run pyscn analyze .     # Using pipx
  (Or install: pip install pyscn)
Built with Go + tree-sitter. Happy to dive into the implementation details!

24 comments

[ 3.5 ms ] story [ 17.5 ms ] thread
(comment deleted)
(comment deleted)
This looks great! Duplication and dead code are especially tricky to catch because they are not visible in diffs.

Since you mentioned the implementation details, a couple questions come to mind:

1. Are there any research papers you found helpful or influential when building this? For example, I need to read up on using tree edit distance for code duplication.

2. How hard do you think this would be to generalize to support other programming languages?

I see you are using tree-sitter which supports many languages, but I imagine a challenge might be CFGs and dependencies.

I’ll add a Qlty plugin for this (https://github.com/qltysh/qlty) so it can be run with other code quality tools and reported back to GitHub as pass/fail commit statuses and comments. That way, the AI coding agents can take action based on the issues that pyscn finds directly in a cloud dev env.

This is an interesting idea but you might be better off marketing it as a tool for software engineers, maybe to help with old code bases. Or even for someone stuck cleaning up vibe coded nonsense.

Vibe coders don't care about quality and wouldn't understand why any of these things are a problem in the first place.

I absolutely love this. Tests and code coverage metrics are still important, but so easy to leave behind as you are running toward the vibe. This is a nice addition to the toolbox.
Current AI is most proficient in java-script and python because of the vast training data. But in the long-run, i feel like languages with good static analysis, static type checks, clear language rules, memory leak detection, fuzzing, test oriented code, and any number of other similar tooling is gonna be the true game-changer. Directed learning using this tooling could improve the models beyond their training set, or simply allow humans to constrain AI output within certain bounds.
I'm surprised you went with go for this, you're going to encounter so much pain with large codebases.
This is pretty awesome! If it's built on tree-sitter, is it fair to assume it's generalizable across languages?
Very cool! I've never seen a cli that opens an html file when it's finished. I kinda like it, hope to see more of that in the future
This is great! Is there something similar for Typescript?
this should be a MCP server the agent can use and optimize on

I have a MCP server that wraps developer tool CLIs (linting, tests, etc), but this would need a textual report instead of HTML.

https://github.com/scosman/hooks_mcp

How does this compare to ruff?
What about Pylint? iirc pylint has code duplication check as well. is it the same thing?
There's no way vibe coders care about this. Focus on real engineers.
I'm going to push back hard on the folks dunking on "vibe coders" -- I have been programming longer than most of you have been alive, and there are times when I absolutely do vibe coding:

1) unfamiliar framework 2) just need to build a throwaway utility to help with a main task (and I don't want to split my attention) 3) for fun: I think of it as "code sculpting" rather than writing

So this is absolutely a utility I would use. (Kudos to the OP.)

Remember the second-best advice for internet interactions (after Wheaton's Law): "Ssssshh. Let people enjoy things."

I ran these on some (non-vibe-coded) large repositories of my code that I'm not too proud of, and it gave me an A. I feel validated.
Looks good to me! The status bar did something weird on my codebase in which 2% was really 100% so it looked like it was gonna take hours but only took a minute or so.

I'll try hooking it into my refactor/cleanup workflow with copilot and see how it works as grounding.

Here are some anti patterns a colleague put in their code.

Prescriptive comment: Comment describes exactly what the following code does without adding useful context. (Usually this is for the LLM to direct itself and should be removed).

Inconsistent style: You have this across modules, but this would be in the same file.

Inconsistent calling style: A function or method should return one kind of thing.

(In the worst case, the LLM has generated a load of special cases in the caller to handle the different styles it made).

Unneeded "Service" class: I saw a few instances where something that should have been simple function calls resulted in a class with Service in the name being added, I'm not sure why, but it did happen adding extra complications.

Those are the ones off the top of my head.

As a senior dev, I think use of these tools can be fine, as long as people are happy to go and fix the issues and learn, anyone can go from vibe coder to coder if you accept the need to learn and improve.

The output of the LLM is a starting point, however much we engineer prompts, we can't know what else we need to say until we see the (somewhat) wrong output and iterate it.

This is super insightful, thank you for sharing. It's a great list of common LLM-generated anti-patterns.

I'd love to look into incorporating checks for these into pyscn. This is exactly the kind of stuff I want it to catch.

I saw this project show up in some newsletters. Awesome project idea. I've been using 'vulture' so far.

But when i try to run analyze or check.

Running quality check...

Complexity analysis failed: [INVALID_INPUT] no Python files found in the specified paths

Dead code analysis failed: [INVALID_INPUT] no Python files found in the specified paths

  Clone detection failed: no Python files found in the specified paths
Error: analysis failed with errors

I'm certainly in a folder with python files.

Wow, was it really in some newsletters? That's awesome to hear, and would definitely explain the recent spike on GitHub!

Thanks a lot for the bug report and for providing the details. I have a hunch—it's possible that you need to explicitly specify the path depending on your directory structure. For example, if your Python files are under a src directory, could you try running it like [your_tool_name] analyze src/?

If that still doesn't solve the problem, it would be a huge help if you could open a quick issue on GitHub for this.

Thanks again for your feedback!

Nice idea, good timing. Any plans to wrap this in an MCP? My Claude Code instance should have this in their toolbox.
Yes, that's definitely something I'm looking into. I've received a few comments about AI coding integrations, so it's becoming a high priority.