DEV Community: Yuvraj Angad Singh

I scored 15 AI coding tools with a linter. The gap between them is 8x.

Yuvraj Angad Singh — Thu, 06 Aug 2026 18:07:07 +0000

I build vibecheck, a CLI that catches what AI coding tools leave behind. Dead scaffolding, invented benchmarks, fake attribution comments, catch blocks that log and swallow. 39 rules, runs in CI.

Last month I added a score. One number for how much of that a codebase carries, per thousand lines, severity weighted, capped so no single rule can dominate. 50 means typical, calibrated against a corpus of real repos.

Then it occurred to me that I had never pointed it at the tools that write the code.

The numbers

Fifteen AI coding tools and agent frameworks, scanned at HEAD on August 6:

repo	kloc	findings/kloc	score
langchain	328	6.1	87
crewAI	251	13.8	73
adk-python	398	16.8	68
dspy	58	18.6	65
litellm	1864	20.2	63
AutoGPT	694	20.5	62
llama_index	400	23.3	58
codex	47	27.1	53
OpenHands	219	28.8	51
cline	573	37.2	42
LibreChat	763	38.6	41
gemini-cli	591	39.3	40
aider	34	44.0	36
autogen	119	44.1	36
continue	276	50.3	31

Median 53. The calibration says 50 is typical. So as a group these are ordinary. Not cleaner than the average codebase, not worse.

I expected that, honestly. The thing I did not expect is the spread.

8x, in the same room

6.1 to 50.3 findings per thousand lines. These projects are doing broadly the same work, in the same window, against the same problem. One of them carries eight times the density of another.

That is the part worth staring at. It means this is not a property of the domain. Nothing about building an agent framework forces you to the bottom of that table. langchain sits at 6.1 across 328,000 lines and 2,536 files, and I checked that number carefully before believing it: 2,538 Python files in the repo, 2,536 scanned, no config suppressing anything. It is just clean.

Where the findings actually land, across all fifteen:

code-quality      52,569   69%
ai-tell           18,842   25%
error-handling     2,412    3%
security           1,847    2%

Two thirds is code quality, and one rule carries a lot of it. no-deep-nesting hit the per-rule cap in 4 of 15 repos, meaning it alone produced more than 20 weighted findings per thousand lines before the cap clipped it. The cap exists precisely so the score does not quietly become a nesting-depth meter.

What this does not measure

It measures what 39 rules detect. That is not the same as quality, and I would not hire or fire a library over it.

Language mix moves it. Python repos trip no-py-print, TypeScript repos trip no-ts-any. A repo is partly being scored on which rules its language exposes it to.

And three of these fifteen (codex, gemini-cli, adk-python) were in the corpus I used to calibrate what "typical" means. So the median being 53 is partly circular. I could have quietly dropped them and shown you a cleaner story. Leaving them in and saying so is more useful than a number I have already tuned to itself.

Run it yourself:

npx @yuvrajangadsingh/vibecheck --score .

The run found a bug in my own tool

I piped each scan into a script to collect the scores. Five of fifteen came back as JSON parse errors.

The offsets were 65536 and 73628. That is not a coincidence, that is a buffer.

stdout to a pipe is asynchronous in node. process.exit() does not wait for it to drain. I had three exits that run after the report is printed, so vibecheck --format json . | jq on a large repo returned truncated, invalid JSON. Silently. Exit code unchanged.

Scanning adk-python:

output target	bytes	valid
redirected to a file	2,685,887	yes
through a pipe	131,072	no

I introduced it three days ago, in a release whose entire purpose was removing silent failures. The exits were added alongside a feature that reports files the scanner could not read, so that people stop getting a clean bill of health for code nobody looked at. That feature shipped with a new way to lose output quietly.

Every one of my CLI tests already runs through spawnSync, which is a pipe. The mechanism was covered. But every fixture produced output small enough to fit in the buffer, so nothing ever had to drain, and the bug sat in a blind spot the tests had walked past dozens of times.

It is fixed in 1.20.1. The new fixture emits 1,800 findings on purpose.

What I take from this

The leaderboard is the less interesting half.

I set out to measure other people's code and the measurement apparatus broke, in a way that had been shipping for three days, in the exact area I had just spent a week hardening. Not because the tests were missing. Because they all sat on one side of a boundary I had never thought about.

If you want to find out where your blind spots are, run your thing against something large and unfamiliar. Fixtures you wrote share your assumptions. A stranger's 400,000-line repo does not.

github.com/yuvrajangadsingh/vibecheck

I ran my own linter against my own app. All 19 findings were wrong.

Yuvraj Angad Singh — Tue, 04 Aug 2026 20:02:54 +0000

I build vibecheck, an npm CLI that catches what AI coding tools leave behind. Dead scaffolding, invented benchmarks, fake attribution comments, that sort of thing. 39 rules, runs in CI.

Last week I pointed it at a Vite and React app I had been building on the side. Not a fixture. Real code I actually ship.

no-console-pollution fired 19 times.

I went to clean them up and stopped after the first one. It was fine. So was the second. I checked all 19.

All 19 were wrong

Thirteen looked like this:

const json = await rawBrowse(browseId);

if (import.meta.env.DEV) {
  console.debug("[playlist] browse response", browseId, json);
}

That block does not exist in production. Vite evaluates import.meta.env.DEV at build time, the branch becomes if (false), and the minifier deletes it. The console call being warned about is not in the bundle I ship. It never was.

The other six were in scripts/test-player.mjs, a CLI I run by hand. Printing to stdout is the entire point of that file. Calling it pollution is like warning that a print statement is going to print.

So the rule was not slightly noisy. On this codebase it had a zero percent hit rate, and every one of those 19 warnings was asking me to make my code worse.

Why it could not see the guard

Here is the rule as it shipped:

{
  id: 'no-console-pollution',
  pattern: /console\.(log|debug|info)\s*\(/,
  antiPattern: /eslint-disable|\/\/\s*keep|logger/,
  ...
}

The obvious fix is to add import.meta.env.DEV to that antiPattern. It does not work, and the reason is one line in the scanner:

if (rule.antiPattern && rule.antiPattern.test(line)) continue;

line. Singular. The engine hands each rule one line at a time, so antiPattern can only ever see the line the match is on. The guard is one to three lines above. An antiPattern would have caught this:

if (import.meta.env.DEV) console.log("ready");

and missed all thirteen real ones.

This is the part I think generalises. A single-line regex rule cannot express "is this inside something". Any rule about context needs to see the block, and if your engine is line-scoped you will keep reaching for the anti-pattern escape hatch and keep almost fixing it.

The fix, and the case that made it interesting

I moved the rule to the multiline path, where the detector gets the whole file. Track brace depth, note the depth when a build-time guard opens a block, stay quiet until that block closes.

Then this test failed:

if (import.meta.env.DEV) {
  console.debug("gated");
} else {
  console.log("this one actually ships");
}

The else branch is not dev-only. It ships. That console call is a real finding and my fix was swallowing it.

The reason is that } else { starts and ends at the same brace depth. If you only compare depth before the line to depth after, nothing changed, so the guard still looks open. You have to track the lowest depth the line passes through:

function scanBraces(maskedLine: string, depth: number) {
  let min = depth;
  for (const ch of maskedLine) {
    if (ch === '{') depth++;
    else if (ch === '}') { depth--; if (depth < min) min = depth; }
  }
  return { end: depth, min };
}

On } else { the depth dips below the guard's depth mid-line and comes back. The low-water mark is the only thing that reveals the block closed.

One more detail: braces are counted on a lexer-masked copy of the line, with strings, template literals, regex bodies and comments blanked first. Otherwise a } inside a string closes a block that was never open, and every rule downstream drifts.

It happened again two days later

I shipped a scoring feature and CI went red. One error:

src/score.ts:12  error  no-eval  eval() or new Function() allows arbitrary code execution.

Line 12 of that file is a comment. It says:

 *   Severity-weighted. An eval() call and a chatty comment should not count
 *   the same, and averaging them hides the eval().

My security rule flagged my documentation for containing the word it warns about. Writing about eval is not calling eval.

Same root cause, different shape: the rule matched raw text when it should have matched code. The fix was a codeOnly flag that runs the pattern against the lexer-masked line, so strings and comments are invisible to rules that target a code construct.

Deliberately not applied to every rule. no-ai-todo and no-ai-attribution exist to match comment text. Mask comments globally and they never fire again. Both directions have tests now.

That fix also let me delete an ignore line from my own CI config, which had been quietly excluding the rule directory because the rules describing eval kept matching themselves.

What I take from this

The console rule had been shipping since v1.0. Nobody filed a bug. It has real users.

The reason nobody complained is that a false positive in a linter does not look like a bug. It looks like your code being wrong. Most people add the suppression and move on, and the tool never hears about it.

The only reason I found it is that I ran it against something I cared about, where I knew the right answer for every single line.

Dogfooding gets talked about as a discipline thing, a virtue. It is not. It is the cheapest way to get a test set where you already know the labels.

Both fixes are in @yuvrajangadsingh/vibecheck.

npx @yuvrajangadsingh/vibecheck .

github.com/yuvrajangadsingh/vibecheck

5 heuristic bugs that made my design-token tool call a bright cream page "dark and moody"

Yuvraj Angad Singh — Mon, 15 Jun 2026 07:36:19 +0000

i maintain a small cli called brandmd. it points a headless browser at any url, reads the computed css, and writes a DESIGN.md that AI coding agents (Claude Code, Cursor, Gemini CLI) can read so they build on-brand UI instead of guessing.

last week i ran it on cognition.ai's FrontierCode blog post and the output was embarrassing. the page is cream and bright, basically a magazine layout. here is what brandmd said about it:

mood: "Dark and moody"
#F7F6F5 got named "Light Muted Orange" (it is off-white)
#2200FF got named "Dark Blue" (it is the most electric blue you have ever seen)
border radii: 4px, 3.35544e+07px (yes, scientific notation in a design doc)
type scale: 11px, 11.05px, 11.5px, 12px, 12.5px, 12.75px, 13px (seven sizes that are really three)

every single one was a different heuristic bug. here is the anatomy of each, because they are the kind of mistakes that look fine in a unit test and fall apart on a real site.

1. mood from averaging luminance

the mood line came from averaging the luminance of the whole palette, then bucketing: high average is "light and airy", low is "dark and moody".

the problem is averaging treats a tiny dark footer the same as a full-viewport cream background. cognition has a dark footer and a few dark chips. they dragged the average down far enough to flip the whole verdict, even though 90% of the screen is cream.

the fix was to stop averaging and anchor to the dominant background instead. find the background color that covers the most viewport area, judge the mood from that. one color, weighted by how much of the page it actually owns.

Bright, high contrast; off-white background dominates with black text and vivid blue accents

that line is evidence-based now. it names the dominant color and what it does, instead of a vibe word.

2. color names from nearest-RGB

color naming used nearest-neighbor in RGB space against a list of named colors. cream (#F7F6F5) has a slight warm cast, so the closest named color by raw RGB distance landed on a muted orange. technically the nearest point. completely wrong to a human.

RGB distance is a bad model for how we name colors. switched to HSL rules instead:

lightness above ~90% is a near-white. if the hue is warm it reads as cream, if cool it reads as off-white. it never gets a chromatic name.
high saturation in the mid lightness band gets "vivid".
everything else maps hue ranges to names.

now #F7F6F5 is "off-white" and #2200FF is "vivid blue".

3. blue is "dark" by luminance

this one is the most counterintuitive. #2200FF is a bright electric blue, but brandmd called it "dark blue". why? because the tone word was derived from luminance, and blue barely contributes to luminance.

the standard luminance formula weights the channels roughly:

luminance = 0.2126*R + 0.7152*G + 0.0722*B

blue is only 7% of the weight. so a fully saturated blue scores darker than a muted brown. by luminance, #2200FF genuinely is "dark", even though your eye reads it as loud and bright.

the fix is to take tone words from HSL lightness, not luminance. lightness treats the channels evenly, so a mid-lightness blue reads as a mid-tone, and the saturation check adds "vivid".

4. scientific notation in a design doc

3.35544e+07px. that is what getComputedStyle returns for border-radius: 9999px on a pill-shaped button (the browser resolves the "make it fully round" intent into a giant pixel value).

brandmd was printing the raw computed value straight into the markdown. worse, it was feeding that giant number into the shape-language inference, so a sharp-edged site with one pill button got described as "rounded and friendly".

two fixes:

normalize any radius above ~999px to 9999px (pill) for display, keep it CSS-valid.
exclude pill values from the "is this site rounded or sharp" judgment. judge shape from the largest non-pill radius.

5. sub-pixel font sizes are noise

the type scale had seven sizes between 11 and 13px because sub-pixel rendering and zoom produce values like 11.05px and 12.75px. those are not distinct steps in a design system, they are rendering artifacts.

the fix is a clustering pass: round every size to the nearest 0.5px before ranking, then dedupe. seven noisy values collapse to the three real ones.

the lesson that actually mattered

the bug that taught me the most was not in this list directly. while fixing the palette i found that element count is a terrible proxy for visual dominance.

brandmd was ranking colors by how many elements used them. a 6% alpha black overlay sat on dozens of tiny chips, so by element count it outranked the actual page background that lived on one big element. the "primary" color was an overlay nobody consciously sees.

weighting by viewport area share instead of element count fixed the palette ordering in one line. how much of the screen a color owns is a far better signal than how many nodes reference it.

try it

all of this shipped in brandmd v0.12. you can reproduce the before and after yourself:

npx brandmd@0.11.1 https://cognition.ai/blog/frontier-code   # the bad output
npx brandmd@0.12.0 https://cognition.ai/blog/frontier-code   # the fixed output

the full changelog has the side by side. repo is here if you want to point your coding agent at a real design system instead of letting it guess.

I Gave Claude Stripe's DESIGN.md. The UI Stopped Looking Generic.

Yuvraj Angad Singh — Thu, 21 May 2026 14:11:49 +0000

AI coding agents generate generic UI when they do not know your brand: indigo gradients, lavender backgrounds, rounded cards, default checkmarks.

I made a controlled before/after: generic AI-style pricing page vs the same page rebuilt using a DESIGN.md extracted from stripe.com.

This is not a benchmark of Claude Code auto-loading the skill. It is a demo of what changes when the model has the extracted DESIGN.md as design context.

Without brand context

Generic Tailwind aesthetic. Indigo-to-violet hero, lavender background, soft purple "MOST POPULAR" pill. Fine. Shippable. Also indistinguishable from a hundred other AI-generated pricing pages.

With DESIGN.md context

The branded version uses Stripe-like color roles, type, spacing, radius, and CTA hierarchy from the extracted design context:

#533AFD for primary CTAs
#00D66F for success accents
#0D1738 for primary text
sohne-var as the primary font family
a 4px spacing grid
4px, 8px, and 16px radii
a dark featured-card pattern

I did not hand-pick these values from Stripe's site. They came from the generated DESIGN.md.

The command

npx brandmd https://stripe.com --agent

That writes:

DESIGN.md
.cursor/rules/brand.mdc
.claude/skills/brand-style/SKILL.md

DESIGN.md is the design system. The Cursor rule and Claude Code skill point the agent back to that file, so there is one source of truth instead of duplicated prompt text.

Here is the extracted Stripe example: github.com/yuvrajangadsingh/brandmd/blob/main/examples/stripe.md

Why this works

DESIGN.md was introduced by Google Stitch as a markdown format for design systems that LLMs can read. brandmd extracts one from a live website so you do not have to write it by hand.

It works with Claude Code, Cursor, Gemini CLI, Codex, Stitch, MCP servers, and anything that reads markdown context.

Try it

npx brandmd https://linear.app --agent

Then ask your coding agent to build a UI component and follow the generated brand context.

GitHub: github.com/yuvrajangadsingh/brandmd
npm: npmjs.com/package/brandmd

v0.9 shipped today.

I ran my own tool against 100 sites. 1 in 5 returned the wrong primary font.

Yuvraj Angad Singh — Sat, 16 May 2026 19:10:55 +0000

I built brandmd 6 months ago. It is an npm CLI that extracts any website's design system into a DESIGN.md file. The idea: drop the file in your project root, AI coding agents (Claude Code, Cursor, Gemini CLI, Stitch) read it, and they generate on-brand UI instead of generic shadcn-default.

It was working. Stripe, GitHub, Vercel, Linear — primary fonts came back correct. Then a user DMd me last week.

"your tool says my primary font is Inter. it is actually Manrope. the brand is on the hero, not the paragraphs."

Fair. So I ran brandmd against 100 popular design system sites to see how widespread the bug was.

The result

9 of 45 successfully-extracted sites returned the wrong Primary font. 20%.

Site	brandmd said	Reality
mantine.dev	Menlo	Outfit
remix.run	JetBrains Mono	Inter Variable
neon.tech	GeistMono	Inter
valura.ai	Inter	Manrope
railway.app	Inter	IBM Plex Serif (on the hero)
resend.com	inter	aBCFavorit
svelte.dev	Georgia	DM Serif Display
workday.design	Times	(no real brand font, fallback)
htmx.org	Times	(intentionally minimal)

Three different failure modes:

Code fonts winning. mantine and remix had so much code on their homepage that JetBrains Mono / Menlo dominated the font frequency count.
Body text drowning the brand. valura uses Inter on 737 elements (utility), Manrope on 28 (hero). Frequency rank picks Inter.
Fallback Times. Sites with no custom font load Playwright's default fallback. Old logic surfaced Times as Primary.

Root cause

// analyze.js, v0.7.2
const primaryFont = fontList[0]?.[0];

That was it. Primary was just the most-frequent font across all DOM elements. Body text always wins.

The fix (v0.8, just shipped)

// analyze.js, v0.8
const primaryFont =
  pickNonExcluded(displayFonts) ||  // fontSize >= 40px (hero)
  pickNonExcluded(headingFonts) ||  // h1-h6
  pickNonExcluded(bodyFonts) ||     // p, li, span, div
  fontList[0]?.[0];

// excluded from Primary: mono fonts (Menlo, JetBrains Mono, GeistMono, etc.),
// default fallbacks (Times, Arial, Georgia), icon fonts (Material Icons,
// Font Awesome, Heroicons).

Three principles:

Display first. The hero font is the brand font. fontSize >= 40px is where the brand lives, not in h2/h3 subtitles.
Skip mono. Code fonts can win Secondary slot, never Primary. mantine.dev wants Outfit on top, JetBrains Mono in code blocks.
Skip fallbacks. If the site has no real custom font, surfacing Times honestly is fine. But if there ARE real fonts available, use those.

Also shipped:

Quote-aware font-family parser (handles var(--font, 'Inter') and backslash escapes that v0.7.2 split incorrectly)
Per-role cascade (heading falls back to display falls back to body)
Navigation timeout 30s → 45s for slow SPAs

Results

7 of 9 wrong-Primary cases now report the correct brand font. The remaining 2 (railway.app, workday.design) genuinely have no distinct brand font on the hero, so the output is honest.

Install

npm i brandmd
# or run without install
npx brandmd https://your-site.com

Repo: github.com/yuvrajangadsingh/brandmd

If brandmd saved you time, star the repo — it helps other devs find it.

My numpy rewrite was 300x faster in isolation. End-to-end it was slower.

Yuvraj Angad Singh — Mon, 20 Apr 2026 10:07:39 +0000

my CLI search took 4.3 seconds for 5000 files. i swapped the python cosine loop for a numpy matmul. it got slower.

short-lived python CLIs punish optimizing the wrong layer.

this is what happened shipping vemb 0.3.0: what i tried first that regressed performance, and what actually worked.

the setup

vemb is a CLI that wraps Gemini Embedding 2 for text, images, audio, video, and PDFs. vemb search ./files "query" embeds every file, caches the vectors, and returns the top matches by cosine similarity.

the cache in 0.2.0 was JSON:

{
  "version": 1,
  "model": "gemini-embedding-2-preview",
  "dim": 3072,
  "entries": {
    "file.png:size:mtime": { "values": [0.012, -0.034, ...] }
  }
}

the search path looked like this:

cache = json.loads(Path('.vemb/cache.json').read_text())
for f in files:
    values = cache[cache_key(f)]['values']   # python list of 3072 floats
    score = cosine_similarity(query_emb, values)
    results.append((score, f))

cosine_similarity was pure python. a for-loop over a list of 3072 floats. at 5000 files, that's about 15 million float multiplies and adds in python.

the obvious optimization: replace the python loop with numpy.

the first rewrite

i added a batched cosine that takes a query vector and a matrix of document vectors:

def cosine_similarity_batch(query, matrix):
    q = np.asarray(query, dtype=np.float32)
    m = np.asarray(matrix, dtype=np.float32)
    q_norm = np.linalg.norm(q)
    m_norms = np.linalg.norm(m, axis=1)
    return (m @ q) / (m_norms * q_norm)

then i benchmarked it in isolation, numpy already imported:

N	python loop	numpy batch	speedup
100	19.55ms	0.13ms	148x
1000	196ms	0.70ms	278x
10000	1975ms	12.32ms	160x

this was the win i expected. i pushed the branch, bumped the version, ran the test suite, and was about to tag v0.3.0.

then i ran the end-to-end benchmark.

the real test

methodology: time vemb search /tmp/test "query" --dim 3072 in a fresh shell subprocess, not a python REPL. warm cache (all vectors already embedded), best of three runs on Apple Silicon.

N	main (v0.2.0)	numpy branch	result
200	1.32s	1.59s	20% slower
1000	2.34s	2.27s	tied
5000	4.31s	6.96s	60% slower

numpy was winning in the synthetic test by 100-300x. end-to-end it lost at every real scale i cared about.

and the loss got worse as N grew. at N=5000, user CPU on the numpy branch was 5.2 seconds vs 2.9 seconds on main. burning 80% more CPU to go slower.

where did the 4.3s go?

rough breakdown of the main v0.2.0 command at N=5000, warm cache:

json.loads of the 317 MB cache: ~2.5s
gemini API round-trip for the query embedding: ~0.6s
pure-python cosine loop over 5000 × 3072 floats: ~1.0s
file scan, click boot, sort, print: ~0.2s

the loop was ~25% of the command. the thing i was about to optimize was not the thing eating my wall time.

two hidden costs

cost one: numpy import.

python -c 'import numpy' on macOS takes ~180ms cold. that's a lot of native startup work before you touch the actual math.

i added import numpy as np at the top of embed.py. cli.py imports embed.py. every invocation of vemb — even vemb --version, even vemb text "hello" — now paid 180ms just to start.

on vemb --version, user CPU went from 0.77s on main to 2.42s on the branch. for a command that doesn't touch numpy at all.

cost two: asarray conversion.

the cache was JSON. loading it gave me a dict of Python lists. to use m @ q numpy needed a contiguous float32 matrix.

m = np.asarray(matrix, dtype=np.float32)

at N=5000 D=3072 that's 15 million Python floats that numpy has to pull out of a list of lists and copy into a dense array. on my machine that single asarray call took ~2 seconds.

so to save ~1 second of python cosine, i was paying 180ms of numpy import plus 2 seconds of list-to-matrix conversion.

the synthetic benchmark never measured any of this. it measured the kernel in isolation, after numpy was already loaded and the matrix was already built. that benchmark was lying to me.

the real fix

the compute wasn't the bottleneck. the cache format was.

parsing 317MB of JSON takes 2-3 seconds by itself. json.loads is slow. it also produces python objects that numpy has to re-unpack into a contiguous array.

so i replaced the cache with a binary numpy matrix.

.vemb/
  vectors.npy      # float32 (N, D) matrix, pre-normalized
  manifest.json    # {key: row_index, ...} + metadata

the new search path:

keys, matrix = load_cache(directory, dim)       # np.load, milliseconds

query = np.asarray(query_emb, dtype=np.float32)
query /= np.linalg.norm(query)

scores = matrix @ query                          # single BLAS call

three things changed together:

vectors load from .npy in tens of milliseconds instead of seconds. a .npy file is a tiny header plus a raw memory dump of the array. np.load can mmap it if you pass mmap_mode='r'.
they land as a contiguous float32 matrix already, so there's no asarray conversion.
they're pre-normalized on write, so cosine reduces to a plain dot product at query time.

i also moved import numpy as np out of module scope and into the function that needs it. vemb --version doesn't pay the import tax anymore. only vemb search does.

cosine stayed the same for this corpus. this was a storage and execution change, not a model change. top-k results matched the old code in my tests.

what shipped

N	v0.2.0	v0.3.0	speedup
200	1.62s	1.48s	tied
1000	2.34s	1.51s	1.5x
5000	4.31s	1.64s	2.6x

cache size at N=5000 3072-dim:

old: 317 MB cache.json
new: 61 MB vectors.npy + 229 KB manifest.json (5x smaller)

existing .vemb/cache.json caches auto-migrate to the binary format on first load. no user action.

the takeaway

for short-lived python CLIs, the bottleneck is often IO, deserialization, or imports. hot-loop speedups can miss the real cost. the synthetic benchmark said the loop was slow. the real benchmark said the loop ran for 1 second inside a 4-second command.

if you only measure the kernel, you optimize the kernel. if you measure end-to-end in a fresh subprocess, you find the real cost.

the methodology that exposed this:

same input corpus
cold process, not a REPL
real disk cache
best of three runs
measure wall time AND user CPU (they tell different stories)

the numpy branch is still on GitHub. i never merged it. the fix was in a layer i wasn't even looking at.

the principle

measure the whole CLI in a fresh process before touching the hot loop.

pip install -U vemb

repo: github.com/yuvrajangadsingh/vemb

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.