DEV Community: Yuvraj Angad Singh

I Scanned 31 AI-Built Repos. Each Tool Leaves Behind a Different Mess.

Yuvraj Angad Singh — Wed, 08 Apr 2026 08:26:21 +0000

46% of every issue I found was the same thing: deep nesting. AI models keep stuffing logic into the same function instead of breaking it apart. That pattern showed up in every tool I tested.

I scanned 31 public JS/TS repos with vibecheck, a linter with 34 rules for AI-specific code smells. 10 repos from Cursor, 11 from Lovable, 10 from Bolt.new. Only public repos with real application code, no scaffolds or starters.

This is not a scientific benchmark. But it's a real sample of real repos people shipped. I manually reviewed every error-level finding and noted which patterns were real issues vs template boilerplate. The full repo list and raw scan data are public if you want to verify.

The numbers

Tool	Repos	Issues	Files	Issues/file	Errors
Cursor	10	9,534	1,499	6.36	77
Lovable	11	4,832	1,886	2.56	27
Bolt	10	329	212	1.55	2

14,695 issues across 3,597 files. Cursor had the most issues by far, but also the biggest repos. Bolt looked cleanest by volume but had the smallest codebases.

What broke most often

Three patterns dominated everything else:

Deep nesting: ~46% of all issues. The most AI-shaped pattern in the dataset. Models keep appending branches because it keeps context intact. Humans usually extract functions earlier.
Console.log pollution: hundreds of hits across every tool. No AI coding tool cleans up debug logging.
God functions: the largest was 3,579 lines in a Cursor repo (easy-kanban's AppContent). Lovable's biggest was 1,810 lines. Bolt's was 820 lines.

Here's what nested AI code looks like in practice:

if (newChunkCount === 0 && this.queue.size > 0) {
  if (currentProgress >= 99.9) {
    console.log('[PackageQueue] Progress 100%, no new chunks...');
    this.reset();
    return;
  }

  this.emptyRetryCount++;
  console.log(`[PackageQueue] No new chunks. Retry: ${this.emptyRetryCount}`);

  if (this.emptyRetryCount >= this.maxEmptyRetries) {
    console.error('[PackageQueue] PKG installation failed');
  }
}

Nested control flow plus debug logging left in production. This showed up everywhere.

Each tool had a distinct pattern

Cursor had the highest issue density (6.36/file) and 77 error-level findings. All SQL injection hits came from Cursor repos. It also had the most as any usage (490 in one repo alone). My read: Cursor users were building bigger, more ambitious apps, and the mess scaled with them. This is inference, not proof. Bigger projects have more surface area.

Lovable had innerHTML or dangerouslySetInnerHTML in 100% of repos (11 out of 11). That's a confirmed pattern at scale. It also produced the only eval-class calls:

<code dangerouslySetInnerHTML={{ __html: highlightedCode }} />

const script = new Function(consoleProxyScript);

Some of these are template-level patterns (syntax highlighting, chart CSS) that aren't exploitable in isolation. But they're the kind of code that drifts toward real XSS if someone later feeds user input into the same path. Worth reviewing, not worth panicking about.

Bolt had the lowest issues per file (1.55) but was the only tool that shipped a hardcoded database credential and an error info leak in the same repo:

const pool = new Pool({
  host: '5.75.154.79',
  user: 'postgres',
  password: 'Jk5h...redacted...',
  database: 'postgres',
});

res.status(500).json({ error: error.message });

Bolt looked cleaner by volume but not necessarily safer. Small repo size helped its totals. Batch 2 had zero security findings though, so the batch 1 hardcoded key might be an outlier.

What actually mattered

The tools did not fail in the same way. But the overlap mattered more than the differences.

None of them naturally refactor.
None of them clean up logs.
None of them ask "should this really be one 3,500-line function?"

Scope and review mattered more than tool choice. Small apps were cleaner. Lovable had the single cleanest repo in the entire set (humanise-ai, 0.48 issues/file). Cursor had the dirtiest (easy-kanban, 14.04 issues/file). One of the cleanest Bolt repos was actually a hybrid built with Bolt + Cursor + Cline.

The bad outcome was never "AI touched the repo." The bad outcome was "AI wrote it, nobody looked at it after."

vibecheck flagged patterns, not confirmed vulnerabilities. Some of these findings are real bugs. Some are smells that might never cause a problem. A linter doesn't know intent. It flags what it sees. I doubled the sample from 15 to 31 repos, and the same patterns held.

Try it

If you're shipping AI-generated code, run a check before you push:

npx @yuvrajangadsingh/vibecheck .

34 rules. JS/TS and Python. Also runs as a GitHub Action, VS Code extension, and MCP server for AI coding agents.

I Scanned a 1K-Star Cursor Project. AI Code Doesn't Look Like AI Code Anymore.

Yuvraj Angad Singh — Sun, 29 Mar 2026 14:06:35 +0000

There's a common belief that AI-generated code is easy to spot. Obvious comments, step-by-step numbered instructions, hedging language like "might need to adjust this later."

I built vibecheck, a static analysis tool that detects these patterns. I ran it against ryOS, a 1,100-star web-based macOS clone built entirely with Cursor by Ryo Lu (Head of Design at Cursor). If any project would have AI fingerprints, this one would.

The results surprised me.

Zero comment-level AI tells

None. No "// Initialize the state variable" above a useState. No "// Step 1: Fetch the data." No narrator comments, no hedging, no placeholder stubs. The code reads clean line by line.

AI-generated code has evolved past the obvious tells. The models learned to stop over-explaining. If you're still looking for bad comments as your AI detector, you're looking at last year's problem.

The smell moved to architecture

vibecheck found 4,523 issues across 378 files. Here's where the signal actually is:

God functions. MacDock is a single 2,003-line React component. useIpodLogic is an 1,891-line hook. useKaraokeLogic is 1,798 lines. A human writing incrementally would extract sub-hooks, split components, refactor. AI keeps stuffing logic into the same function because it doesn't have the "this is getting too big" instinct.

Deep nesting. 13 levels deep in ChatMessages.tsx. Callback hell meets JSX spaghetti. When you ask AI to "add a conditional render for loading states" three times in a row, each one nests inside the previous one.

Swallowed errors. 35 empty catch blocks, many in sequence. infiniteMacHandler.ts has 10+ empty catches in a row (lines 790, 797, 804, 827...). This happens when AI wraps every async call in try/catch but has no error handling strategy.

Console.log pollution. 671 console.log statements in production code. AI adds them for debugging and never removes them because no one asks it to clean up.

Error info leaks. 11 API endpoints that send error.message directly in HTTP responses. Internal details (stack traces, DB errors) exposed to clients.

Why this matters

Code review catches line-level problems. A reviewer reads 50 lines of a function and it looks fine. Clean variable names, proper TypeScript, no weird patterns.

But zoom out and the function is 2,000 lines long. The reviewer never sees the full picture because the diff only shows the 30 lines that changed. The AI-generated architecture accumulates invisibly.

This is the new AI code smell: code that passes review but fails at scale.

What to look for

If you're reviewing AI-assisted code, stop looking for bad comments and start looking for:

Function length. Anything over 200 lines is suspicious. Over 500 is almost certainly AI-accumulated.
Nesting depth. 5+ levels means the function is doing too many things.
Empty catch blocks. AI loves try/catch. It hates error handling.
Console pollution. Count the console.logs. AI never cleans up after itself.
Repeated patterns. 10 empty catches in a row? That's a loop, not a developer.

Try it yourself

npx @yuvrajangadsingh/vibecheck ./your-project

vibecheck catches 32 patterns across JS/TS and Python. Works as a CLI, GitHub Action, VS Code extension, and pre-commit hook. All offline, no API calls.

GitHub | npm | VS Code

Your AI tools don't know what your brand looks like

Yuvraj Angad Singh — Thu, 26 Mar 2026 07:49:42 +0000

Every AI coding agent generates the same UI. Gray backgrounds, blue buttons, Inter font, 8px border radius. It doesn't matter if you're building for a fintech startup or a surf shop. The output looks identical because the agent has zero context about your brand.

Google noticed this too. When they redesigned Stitch in March 2026, they introduced a file format called DESIGN.md. It's a markdown file that encodes your design system (colors, typography, spacing, component styles) in a format that LLMs can read. Drop it in your project root and tools like Claude Code, Cursor, Gemini CLI, and Stitch itself will use it to generate UI that actually matches your brand.

The problem is, nobody wants to write one from scratch.

What a DESIGN.md looks like

It has 5 sections:

Visual Theme & Atmosphere - mood, shape language, depth
Color Palette & Roles - every color with a semantic role
Typography Rules - font families, size scale, weights
Component Stylings - buttons, cards, inputs
Layout Principles - spacing scale, base grid unit

Here's a snippet from Stripe's:

## 2. Color Palette & Roles
- **White** (\`#FFFFFF\`) — Page background
- **Dark Blue** (\`#533AFD\`) — Accent background
- **Cyan** (\`#00D66F\`) — Accent background
- **Dark Muted Blue** (\`#64748D\`) — Secondary text

## 3. Typography Rules
**Primary font:** sohne-var
- Headings: 26px, 32px, 48px, 56px
- Body / UI: 14px, 16px, 18px, 22px

Writing this by hand means opening DevTools, inspecting every element, noting down colors and fonts, figuring out the spacing scale. For a complex site that's hours of work.

Extracting it automatically

I built a CLI called brandmd that does this in one command:

npx brandmd https://stripe.com

It launches a headless browser, renders the page, scrolls through it to trigger lazy-loaded content, dismisses cookie banners, then extracts computed styles from every visible element. Colors get clustered (so you don't end up with 50 shades of the same gray), fonts and spacing values get grouped into scales, and everything gets templated into the DESIGN.md format.

No LLM calls, no API keys. Runs entirely on your machine.

What it catches

I ran it on a few sites to test:

Linear - picked up Inter Variable as the primary font, Berkeley Mono as secondary, the indigo accent (#5E6AD2), and identified a 4px base grid from the spacing values.

Stripe - found sohne-var (their custom font), the purple (#533AFD) and green (#00D66F) accent colors, and 4 distinct shadow styles for depth.

The output isn't perfect. It can't read your Figma tokens or understand why you chose a specific color for error states. But it gives you a solid starting point that's 90% there, and you can tweak the remaining 10% in a few minutes.

The workflow

# Extract from your current site
npx brandmd https://yoursite.com -o DESIGN.md

# Drop it in your project root
mv DESIGN.md ./

# Now your AI tools generate on-brand UI

Claude Code, Cursor, and Gemini CLI all read markdown files from your project root automatically. No configuration needed.

Try it

npx brandmd https://linear.app

Source: github.com/yuvrajangadsingh/brandmd

Works on any public URL. If you have a site and you use AI coding tools, try it on your own URL. You'll probably be surprised at how much design information is hiding in your computed styles.

Embeddings shouldn't need a notebook

Yuvraj Angad Singh — Wed, 25 Mar 2026 14:14:09 +0000

I kept running into the same annoyance whenever I needed embeddings. The retrieval part of a RAG pipeline was hard enough already. Generating vectors should've been the easy part.

But every time I needed to embed something, the workflow looked like this:

Open a notebook or write a throwaway script
Import the SDK, set up the client
Figure out the right model name (was it text-embedding-004 or text-embedding-3-small?)
Write the call, handle the response format
Copy the vector out of the output

For text that's annoying. For images or audio it's worse. Different SDKs, different input formats, different response shapes.

I kept thinking: I can curl an API in seconds. I can jq a JSON response without writing a script. Why can't I just embed something from the terminal?

The tool I wanted

Something like httpie but for embeddings. Type a command, get a vector back.

vemb text "hello world"
# {"model": "gemini-embedding-2-preview", "dimensions": 3072, "values": [0.0123, -0.0456, ...]}

vemb text "hello world" --compact
# [0.0123, -0.0456, 0.0789, ...]

Embed an image:

vemb image photo.jpg

Embed a PDF:

vemb pdf report.pdf

Compare two files:

vemb similar photo1.jpg photo2.jpg
# 0.8734

No notebooks, no scripts, no boilerplate. Just the vector.

Why Gemini Embedding 2

I looked at OpenAI's embedding models first. Their embeddings endpoint is text-only. If you want to embed images, you're stitching together separate models and separate vector spaces. No clean way to compare text against images with a single embedding call.

Google released Gemini Embedding 2 (public preview, March 2026). One model that handles text, images, audio, video, and PDFs natively. Same vector space for everything. You can embed a photo and a text description and compare them directly with cosine similarity.

That's what made the CLI possible. One model, one API, all input types.

Building it

The whole thing is ~400 lines of Python. Two files: embed.py (core logic) and cli.py (Click commands).

The interesting parts:

Auto-detection: vemb embed guesses the file type from the extension. JPEGs, PNGs, MP3s, WAVs, MP4s, PDFs all work with the same command.

Batch mode: vemb embed *.jpg --jsonl embeds every file and outputs one JSON object per line.

Directory search: vemb search ./photos/ "dark moody sunset" embeds the query, embeds every file in the directory (with caching), and ranks by cosine similarity.

# search a folder of images by text description
vemb search ./photos/ "dark moody sunset" --top 5

0.8234    ./photos/sunset-beach.png
0.7891    ./photos/evening-skyline.png
0.7654    ./photos/golden-hour.png
0.6123    ./photos/cloudy-morning.png
0.5987    ./photos/overcast-street.png

Example use cases

Retrieval experiments: embed a few chunks, check similarity scores, tune the chunking. No notebook needed.

Image search: I keep a folder of reference mockups. vemb search ./mockups/ "login screen" finds the right ones instantly.

Checking if two files are semantically close: vemb similar draft-v1.pdf draft-v2.pdf tells me how much the content actually changed between versions.

Cross-modal search: embed a text query against a folder of images and get ranked results. One model, one vector space means text and images are directly comparable.

Try it

pipx install vemb
export GEMINI_API_KEY=your_key   # free at aistudio.google.com/apikey
vemb text "hello world"

Source and docs: github.com/yuvrajangadsingh/vemb

The API key is free, the model is free tier. If you're building anything with embeddings and you're tired of opening notebooks for a one-line operation, try it.

Your AI Wrote the Code. Who's Checking It?

Yuvraj Angad Singh — Sat, 21 Mar 2026 11:01:49 +0000

I review a lot of PRs at work. Over the last year, I started noticing patterns in AI-generated code that kept showing up. Same five or six things, every time.

Empty catch blocks. as any sprinkled everywhere. Comments that just restate what the code does. Hardcoded API keys. except: pass in Python. The code works, it passes tests, but it's the kind of stuff you'd flag in a review and ask someone to fix.

The numbers back this up. CodeRabbit found AI-generated PRs have 1.7x more issues than human PRs. Veracode says 45% of AI code samples contain security vulnerabilities.

ESLint catches syntax issues. But nobody's catching the behavioral patterns that AI tools leave behind. So I built one.

vibecheck

24 rules across JS/TS and Python. Zero config. Runs offline. Regex-based, so it's fast.

npx @yuvrajangadsingh/vibecheck .

  src/api/routes.ts
    12:5    error  no-hardcoded-secrets   Hardcoded secret detected
    45:3    error  no-empty-catch         Empty catch block swallows errors
    89:1    warn   no-console-pollution   console.log left in production code

  src/utils/db.ts
    34:5    error  no-sql-concat          SQL query built with string concatenation

  4 problems (3 errors, 1 warning)
  2 files with issues out of 47 scanned (0.8s)

No API keys, no cloud, no LLM calls. It's regex rules that match the patterns AI tools tend to produce.

What it actually catches

Here's the stuff I kept flagging in code reviews:

The silent failure:

try:
    response = api.fetch(user_id)
except:
    pass

Your API call fails and nobody ever knows. vibecheck flags no-bare-except and no-pass-except.

The "I'll type it later":

const data = response.json() as any;

AI tools love as any. It shuts up the type checker but defeats the entire point of TypeScript. vibecheck flags no-ts-any.

The useless comment:

// initialize the counter
let counter = 0;

Your linter doesn't care about this. vibecheck does. no-obvious-comments catches comments that just repeat what the code already says.

The hardcoded key:

const API_KEY = "sk-proj-abc123def456";

This one's obvious but it keeps happening. no-hardcoded-secrets matches common API key patterns.

Diff mode

This is the part I use most. Instead of scanning your entire codebase, scan only the lines you just changed:

vibecheck --staged .

Drop it in a pre-commit hook and it only checks what you're about to commit:

# .git/hooks/pre-commit
npx @yuvrajangadsingh/vibecheck --staged .

In CI, it runs on PR diffs so you're not drowning in warnings from old code.

"Isn't this just ESLint?"

No. ESLint catches syntax and style. vibecheck catches the patterns that come from how AI tools generate code. Your linter won't flag a catch block that only does console.error(err) without rethrowing. It won't flag # type: ignore without a specific error code. It won't flag a function that's 120 lines long because the AI didn't know when to stop.

They're complementary. Run both.

Install

# no install needed
npx @yuvrajangadsingh/vibecheck .

# or install globally
npm install -g @yuvrajangadsingh/vibecheck

# standalone binary (no Node required)
curl -fsSL https://github.com/yuvrajangadsingh/vibecheck/releases/latest/download/vibecheck-darwin-arm64 -o vibecheck
chmod +x vibecheck

GitHub: github.com/yuvrajangadsingh/vibecheck

Open to feedback on what rules to add next. If you keep flagging the same thing in AI-generated PRs, I probably want to hear about it.

Your GitHub Profile Is Lying About You

Yuvraj Angad Singh — Tue, 10 Mar 2026 12:30:00 +0000

I shipped 888 commits last year. My GitHub profile showed 0.

Not because I wasn't coding. I was writing code every single day, reviewing PRs, closing issues, shipping features. But all of it went to private repos. And GitHub doesn't count private repo activity on your public profile.

For almost 4 years, my contribution graph was a graveyard of gray squares.

Why this matters

Recruiters spend about 6 seconds on a GitHub profile. Gray squares = "doesn't code." Green squares = "active developer." It's shallow, but it's real. I've had recruiters literally ask me why my profile looked inactive.

GitHub does have a "show private contributions" toggle in settings. But all it does is show anonymous green squares. No repo names, no PRs, no context. And if your company uses a separate org account (like mine does), those contributions don't show up on your personal profile at all.

What I built

I wrote a bash CLI called greens that mirrors your private work activity to a public repo without exposing any code.

Here's what it does:

Scans your work repos locally (never modifies them)
Extracts commit timestamps for your email
Creates empty commits with matching timestamps in a public mirror repo
Pushes to GitHub

That's it. No code leaves your machine. The mirror repo contains empty commits with only timestamps.

If you have gh CLI set up, it also picks up PRs, reviews, and issues.

Install

brew install yuvrajangadsingh/greens/greens

Run greens and the setup wizard walks you through configuration. Takes about 2 minutes.

How it works under the hood

The key insight is that GitHub's contribution graph only cares about commit timestamps, not content. So greens creates a bare cache of each repo (no working tree, no blobs), extracts dates where your email authored a commit, and creates empty commits with those exact timestamps in the mirror.

Your Work Repos → Bare Cache → Public Mirror
  (untouched)     (no blobs)    (empty commits with your dates)

Your source repos can be on GitHub, GitLab, Bitbucket, or self-hosted. greens scans the local clone, not the remote.

My results

After setting it up:

11 repos tracked
888 commits mirrored
158 active days visible on my graph
Auto-syncs daily via launchd

Before: dead profile that made me look like I stopped coding in 2022.
After: an accurate picture of my actual work.

"Isn't this gaming the system?"

Fair question. I'm not faking open source contributions. The mirror repo clearly says what it is. I'm just making private work volume visible on a platform that ignores it by default.

If your company has a policy against this, check before using it. But most devs I've talked to have the same frustration: their profile doesn't reflect their actual output.

Set up automation

Once greens is working, automate it. On macOS, a launchd plist that runs greens daily at midnight keeps everything in sync without thinking about it. On Linux, a cron job does the same thing.

# cron example
0 0 * * * /usr/local/bin/greens

Try it

brew install yuvrajangadsingh/greens/greens
greens

Or clone manually:

git clone https://github.com/yuvrajangadsingh/greens.git
cd greens && bash setup.sh

GitHub repo: github.com/yuvrajangadsingh/greens

Star it if you find it useful. Issues and PRs welcome.

I'm Yuvraj, building AI systems at August. I write about dev tools and open source when I'm not debugging LLM pipelines at 2 AM.

Your GitHub Graph is Lying About How Much You Work. Here's How I Fixed Mine.

Yuvraj Angad Singh — Fri, 06 Feb 2026 21:49:00 +0000

I work 50+ hours a week writing code. My GitHub profile says I'm barely active.

Sound familiar? If you work on private repos — enterprise GitHub, Bitbucket, GitLab, self-hosted — none of that shows on your contribution graph. Recruiters see empty squares. Your profile looks dead.

I got tired of it and built contrib-mirror — a CLI that mirrors your real commit timestamps to a public repo. No code exposed. No fake commits. Just your actual work activity, finally visible.

Install

brew tap yuvrajangadsingh/contrib-mirror
brew install contrib-mirror

Or use the one-liner:

curl -fsSL https://raw.githubusercontent.com/yuvrajangadsingh/private-work-contributions-mirror/main/install.sh | bash

The setup wizard auto-detects your repos, emails, and org:

contrib-mirror --setup   # configure once
contrib-mirror           # sync anytime

How It Works

Discovers repos in your work directory
Creates bare caches (no source code touched)
Extracts commit timestamps matching your email
Optionally pulls PR/review/issue timestamps via GitHub API
Creates empty commits with matching dates in a public mirror repo
Pushes to GitHub

Zero code is ever exposed. The mirror contains only empty commits with timestamps.

It Also Tracks PRs and Reviews

GitHub counts more than commits — PRs opened, reviews submitted, and issues created all count toward your graph. With gh CLI authenticated, contrib-mirror picks those up too.

Set It and Forget It

Add a cron job or launchd agent and it syncs daily at midnight. Your graph stays green without you thinking about it.

The setup wizard handles scheduling too — just pick launchd or cron when prompted.

yuvrajangadsingh / greens

Your work is real. Your contribution graph should show it.

greens

Your work is real. Your contribution graph should show it.

If you commit to private/org repos all day but your GitHub profile looks empty, greens fixes that. It mirrors commit timestamps (and optionally PRs, reviews, issues) to a public repo without exposing any code.

Install

brew install yuvrajangadsingh/greens/greens

Then just run greens. Setup wizard runs on first use.

Manual install (without Homebrew)

git clone https://github.com/yuvrajangadsingh/greens.git
cd greens
bash setup.sh

What it does

Scans your work repos (never modifies them)
Extracts commit timestamps for your email(s) across all branches
Optionally fetches PR/review/issue timestamps via GitHub API
Creates empty commits with matching timestamps in a mirror repo
Pushes to your public mirror

No code is exposed. The mirror contains empty commits with only timestamps.

Works with any git remote. Your source repos can be on GitHub, GitLab, Bitbucket, or self-hosted. greens scans the local clone, not the remote. The mirror…

View on GitHub

Give it a star if this is useful to you.