I scanned 10 popular vibe-coded repos and found 4,513 issues. So I built a linter for the AI coding era.

Six months ago I noticed something weird across my projects. I build with Claude Code across 8 different repos, and every single one had the same problems: functions that were 300+ lines long, catch blocks that swallowed errors silently, any types scattered across TypeScript files, console.log left in production paths.

I wasn't writing these patterns. The AI was. And I was approving them because the code worked.

The data that pushed me to build this

Andrej Karpathy coined "vibe coding" in February 2025. Collins Dictionary made it their Word of the Year. By August 2025, code assistant adoption hit 72.8%, up from 49.2% in January. 25% of the Y Combinator Winter 2025 batch had codebases that were 95% AI-generated.

But the quality side tells a different story:

• GitClear tracked 153 million lines and found a 41% increase in code churn (code written then deleted within 2 weeks)
• AI pull requests average 10.83 issues versus 6.45 for human PRs (1.7x worse)
• Veracode found 62% of AI-generated solutions contain design flaws or security vulnerabilities
• 96% of developers said they don't fully trust AI-generated code (Stack Overflow 2025)

There's a gap between how fast AI writes code and how well anyone checks it. Traditional linters (ESLint, Biome) catch syntax and style. LLM-based review tools (CodeRabbit, Codacy) use AI to review AI, which is non-deterministic and cloud-dependent. Neither category targets the specific structural antipatterns that AI coding assistants generate.

What I built

vibecop: 22 deterministic detectors built on ast-grep (tree-sitter AST parsing). No LLM in the loop. Fast, local, reproducible.

The name is exactly what it sounds like. If you're vibe coding, you need a cop.

What it catches:

Quality (12 detectors): God functions, god components, N+1 queries, unbounded queries, debug console.logs in production, dead code paths, double type assertions, excessive any types, TODO comments in production, empty error handlers, excessive comment ratios, over-defensive coding.

Security (5 detectors): SQL injection via template literals, dangerouslySetInnerHTML, auth tokens in localStorage, placeholder values in production config, insecure defaults (eval, hardcoded credentials).

Correctness (3 detectors): Unchecked database results, undeclared imports, mixed concerns (UI + DB in same file).

Testing (2 detectors): Trivial assertions (expect(true).toBe(true)), over-mocking.

Real-world benchmarks

I tested vibecop against 10 popular open-source projects that are widely known to be vibe-coded:

| Project | Stars | Files | Findings | Standout issues |
|---------|-------|-------|----------|----------------|
| context7 | 51.3K | 68 | 118 | 71 console.logs, 21 god functions |
| dyad | 20K | 970 | 1,104 | 402 god functions, 47 unchecked DB results, 12 placeholder values |
| bolt.diy | 19.2K | 398 | 949 | 294 any types, 9 dangerouslySetInnerHTML, 24 N+1 queries |
| screenpipe | 17.9K | 362 | 1,340 | 387 any types, 236 empty error handlers |
| browser-tools-mcp | 7.2K | 12 | 420 | 319 console.logs in 12 files (avg 26 per file) |
| code-review-graph | 3.9K | 94 | 410 | 6 SQL injections, 139 unchecked DB results, 71 N+1 queries |

4,513 total findings across 2,062 files. Most common: god functions (38%), excessive any (21%), leftover console.log (26%).

I also scanned my own projects. CodeLedger (one of my other open-source tools): 30 findings including 13 god functions and 6 SQL injection patterns. Nobody's immune.

The build

Stack: TypeScript, ast-grep (@ast-grep/napi), Commander, Zod, Bun.

Why ast-grep: Tree-sitter based AST parsing. It understands code structure, not just text patterns. When I say "god function," the detector measures actual cyclomatic complexity, line count, and parameter count against configurable thresholds. Not regex matching. This means it's fast (processes thousands of files in seconds) and accurate (no false positives from comments or strings).

GitHub Action: vibecop ships with a GitHub Action that runs on every PR and posts inline review comments on the changed lines. Four modes: comment-only, request-changes, label, or auto-close. You can set severity thresholds and max findings per PR.

Config: .vibecop.yml in your project root. Disable detectors, change severity levels, ignore directories. Standard stuff.

Time to build: About 3 weeks. Phase 1 (7 detectors, core scanner) took 1 week. Phase 2 (15 more detectors, GitHub Action, real-world validation) took 2 weeks.

Numbers

• Revenue: $0. Open source, MIT licensed.
• Version: 0.1.0 (first public release)
• Detectors: 22 across 4 categories
• Languages: TypeScript (all 22), JavaScript (18), Python (10)
• Output formats: text, JSON, HTML, SARIF, GitHub
• Cost to build: $0 out of pocket

Why open source, why free

This is my second open-source dev tool (the first is mcp-quality-gate, a quality gate for MCP servers). My thesis: the tools that define code quality standards for the AI coding era will have outsized influence. I'd rather be the person defining what "good enough" looks like than compete on price.

If vibecop becomes the default quality check for AI-generated code, that creates a foundation for everything else I'm building.

What's next

• Phase 3: Cross-file analysis (duplicate code detection across files, repeated constants)
• Phase 4: LLM-powered deep review mode (separation of concerns, semantic duplication)
• npm publish on npm registry
• More language support

What I'd tell my past self

• Test against real repos first. My initial detectors were too aggressive. Running against popular open-source projects forced me to calibrate thresholds to real-world code.
• The name matters more than you think. "aiqt" (the original name) meant nothing to anyone. "vibecop" gets an immediate reaction. People remember it.
• Ship the GitHub Action early. That's what makes it sticky. A CLI people run once. A PR gate runs on every commit.

npm install -g vibecop
GitHub: https://github.com/bhvbhushan/vibecop

If you're building with AI coding assistants, what does your code review process look like? Are you reviewing every function, or just checking that tests pass? Genuinely curious how others are handling this.