Audit the codebase your AI just shipped.

Why vibe-coded codebases need this

AI builders are great at producing the next prompt's worth of code. They're not great at remembering the previous one. Each iteration appends; nothing prunes. After a week of prompting, a Lovable or Cursor project typically has the same Button component re-implemented four times under three different names, a handful of orphan files no route imports, and a function that type-checks against a library API that quietly changed three versions ago.

ESLint won't catch this. The TypeScript compiler won't catch this. The preview looks fine. The bug surfaces in production.

What Anatoly finds

Four of the seven axes hit vibe-coded projects hardest:

• Duplication — RAG-powered semantic search across the whole codebase finds copy-pasted logic even when variable names, file paths and prop shapes differ. Two components that look different but solve the same problem get flagged with the source of each.
• Utility (dead code) — the pre-computed usage graph proves which exports are actually imported anywhere. Orphan components, half-wired routes and abandoned experiments get listed by file with a confidence score.
• Correction — bugs that pass the type checker but misuse a library API. Anatoly re-reads the README of each declared dependency to verify findings before reporting them.
• Overengineering — single-call-site factories, adapter folders with one file, premature abstractions the AI generated "just in case". Flagged with a recommendation to inline.

One command, drop into the repo

$ npx anatoly run --plain
→ scanning · 184 files · TS · TSX
→ axes · 7/7 · estimated $6.40
→ deliberation · 71 raw → 38 confirmed
✓ verdict: NEEDS_REFACTOR · 38 findings · $5.92

# typical first-run breakdown
duplication · 14 semantic duplicates (Button x4, Card x3, fetcher x3, ...)
utility · 11 dead exports (orphan routes, unused hooks)
correction · 7 NEEDS_FIX (stale Supabase + Stripe API usage)
overengineering · 6 OVER (single-use factories, wrapper components)

Findings come with file, line, the offending snippet, and — for duplicates — a pointer to the canonical version Anatoly recommends keeping.

What the report looks like

Tell Anatoly which builder you used

Drop an ANATOLY.md at the repo root to tune the audit to your stack and your builder's quirks. Anatoly reads it on every run.

# Project context

Stack: Next.js 15 · Supabase · Stripe
Generated with: Lovable, then iterated in Cursor.

## duplication
- The builder re-creates form components per page.
  Flag any <Form>, <Input>, <Button> defined more than once.

## utility
- Routes under app/(legacy)/* are expected to be dead — confirm and recommend deletion.

## correction
- We're on Stripe API 2025-04-30.basil.
  Re-check any payment intent / subscription usage against current docs.

Use it as a cleanup map

The report isn't read-only. Each finding names the file, the line, and the canonical version (for duplicates) or the recommended action (for dead code, overengineering, bugs). Hand the report back to your AI builder as the next prompt and it will grind through the list — Anatoly observes, your builder executes.

Re-run after the cleanup. SHA-256 cache means unchanged files cost $0; you only pay for what was touched. The verdict moves from NEEDS_REFACTOR to CLEAN over a few iterations.

Who this fits

• Founders — who shipped a Lovable, v0 or Bolt MVP, picked up real users, and now need to know what's actually under the hood before scaling.
• Agencies & freelancers — inheriting a vibe-coded codebase from a client and needing a defensible remediation plan, priced by the finding.
• Indie devs — pair-coding daily with Cursor or Windsurf, who want a second opinion on what their AI just merged.