Tines The single, secure environment for agents, apps, and automations.
Promoted
Launching today
LoupeKit
See what any page is built with and how much of it is AI
83 followers
See what any page is built with and how much of it is AI
83 followers
A developer's inspector for the page you already have open. It names the technologies behind it and shows the evidence for each, extracts the palette, fonts and assets, and scores how much of the page reads as raw AI output. It reads one tab, when you ask.
LoupeKit
Hey Hunters 👋
There is a lot of vibe-coded software out there now — and I could not tell what was what.
Not in a judgy way. I ship fast too. But I kept opening pages where something was off: forty classes on one div, eleven nested
wrappers around a single paragraph, an aria-label on a button that already had a name. You feel it before you can point at it.
So I went looking for a way to check. What I found was either a linter I had to wire into a repo I do not own, or a paste-your-code
box, or a model asked to guess. All of them answer a different question. I am not holding the codebase — I am looking at a page.
So I built LoupeKit: the check, on the page, in one click 🔍
1. A 0-100 score across five weighted categories — markup, CSS, runtime, copy, accessibility
2. 66 heuristics, each finding saying exactly what it measured and what to change
3. Click a finding and the page scrolls to that element and selects it — you look at the thing, not at a line number
That third one is what I actually wanted. A number on its own is an opinion. A number that walks you to the element it is talking
about is a review.
The hard part was calibration, in the direction nobody expects: getting it to leave careful hand-written work alone. A tool that
flags good code is worse than no tool — you stop reading it, and then it never catches the real thing either.
One decision I would defend loudest: no website permission at install. Empty host_permissions in both builds. It reads the tab you
are on, when you click, and nothing in the background.
Free tier is 3 audits, everything else unlimited. Chrome, Edge, Firefox and others.
Enjoy!
— Jan
the click-to-element part is probably my favorite. much easier to judge a finding when you can actually see what triggered it.
LoupeKit
@yosun_negi Thanks, that was exactly the reasoning. A count with no address makes you go hunting, and half the time you end up arguing with a number you can't see. The finding carries the elements the collector saw while it was counting, and the total stays the rule's own count rather than the length of that sample list — otherwise six highlighted elements under a finding that fired on four hundred would read as "fix six."
Softorino 💻📲
The site I do SEO for has dozens of near-identical format pages, MKV to MP4, MOV to MP4 and so on, templated on purpose rather than written by a model. Does your score separate formulaic-by-design from actually generated, or would a page like that light up red?
LoupeKit
@yelyzaveta_kibets Thanks for the comment
Scoring is single-page. Nothing compares one URL against another and there's no crawl, so a family of near-identical pages never registers as a family. Your MKV-to-MP4 page is judged on what's inside it alone.
Within a page, the repetition rules have deliberately high floors. Repeated markup blocks doesn't start counting until 4, and long identical sibling rows not until 8, because lists and card grids are repetition by design. The sibling rule goes further and refuses to claim copy-paste over a loop — a rendered DOM genuinely cannot tell those apart, so the finding says "this run is long, go look at the source" instead of announcing a verdict it has no evidence for.
The one that could plausibly fire on a converter page is thin copy: 8 or more text blocks averaging under about 14 words each. That isn't a templating penalty, it's the wireframe-that-shipped shape, and it's the same thing a normal SEO audit would flag. If each format page carries real copy, it reads clean.
Every finding also names its own number and points at the elements it counted, so you can check what it actually hit rather than trust a colour.
Softorino 💻📲
@jan_tursky_apptiary That is the right call, and the sibling rule refusing to claim copy-paste over a loop is more honest than most detectors bother being. The gap it leaves is the one Google actually looks at though, since sitewide sameness is a pattern no single page can show you. Is a cross-page mode something you would ever add, or is one tab when you ask the whole point?
LoupeKit
@yelyzaveta_kibets Thanks
Sitewide sameness is the real question and one tab genuinely cannot answer it. I'd rather say that than stretch what the score covers.
The constraint is deliberate: the extension holds activeTab and nothing else, and ships with empty host permissions. It reads a page only when you ask, and has no ability to reach a URL you aren't looking at. A crawler needs either broad host access or a server-side fetcher, and the first is a permission I don't want to ask for.
The shape that fits is the one that stays inside that: pages you actually open get audited and kept, and a compare view diffs the reports — heading sets, block structure, copy volume per format page. Sameness across the twelve pages you care about, without anything crawling the other three hundred. Less than Screaming Frog, honest about which pages it saw.
A real crawl is a different product and belongs on the server, not in a tab. Worth doing, but not by quietly widening what the extension can reach.
Softorino 💻📲
@jan_tursky_apptiary Holding activeTab with empty host permissions is the actual product, not a limitation, and I would not trade it for a crawler either. From the other side of it though, with a set of format pages I never need to be told they are similar, because that is the point. What I want is the outlier, the page where somebody quietly changed the heading structure eight months ago, so how would you rank the compare view when twelve reports come back nearly identical?
Forty classes on one div is Tailwind working as intended, not evidence of a model. That's my worry with the AI score specifically: the signals you opened with measure sloppiness, and sloppiness only correlates with AI, so a careful Tailwind page and a lazily prompted one land in the same band. The markup and accessibility findings are defensible because each one walks you to a real element you can go argue with. A score for AI authorship is the one number nobody can check, which makes it the one most likely to be quietly wrong.
LoupeKit
@asadmalik901 You're right, and Tailwind is the exact case that breaks it: utility density is evidence of a framework, not of an author. Sloppiness correlates with lazy prompting, and correlation is not what a number presented as a verdict implies.
What I'd push back on is only the framing of the score as a classifier. Every finding names the signal that produced it and the rule behind it, and the Findings and Signals views exist so the score can be taken apart rather than trusted — that's the same "walk me to the thing" property you're crediting the markup findings with. Where you're right is the aggregate: one number on top is the only output in that tab nobody can falsify, and it's doing the most rhetorical work.
Two changes I'd rather make than defend it. A framework-aware baseline, so a page that fingerprints as Tailwind isn't charged for utility class density. And demoting the single number, because the defensible artefact is the list underneath it.
Which signals would you drop first? If they're the ones I suspect, that's a short list and a good afternoon's work.
@jan_tursky_apptiary Utility class density first. It's a framework fingerprint and nothing else, and it's probably the single loudest false signal you have. I'd also drop anything keyed on comment style or emoji in headings, because that's house style, not authorship. Keep the findings that have a fixed right answer, like missing alt text or heading levels skipping, since those are wrong no matter who typed them.
LoupeKit
@asadmalik901 Sure, understand.
You picked the loudest one correctly, and the budget numbers make it worse than you'd guess. Utility class density is 35 points, the largest single rule in the engine, and the "one div carrying forty classes" rule is another 10. The whole CSS category is 55. So a Tailwind page starts the CSS half of its score down 45 points before anything about authorship has been measured. That isn't a signal with a weighting problem, it's a framework detector wearing a verdict.
Comment style and emoji in headings aren't in there, and can't be: the collector reads the rendered DOM, so source comments never reach it. The nearest thing to what you're describing is em dash density at 14 points, and I think you'd file it the same way. It's a habit, and a writer with a taste for dashes is charged for someone else's tell.
What survives your test is smaller than the current scoring implies. Builder globals left in the bundle — a v0 or Lovable object still present at runtime — is direct evidence with no innocent explanation, and it's worth 20 against Tailwind's 35. That ratio is backwards.
So: utility rules zeroed when the stack fingerprint says Tailwind (the Tech tab already detects it, the audit just doesn't ask), em dash density demoted, and the weight moved onto the signals that can't be explained by a framework or a house style. That leaves a shorter list and a smaller number, which is the correct outcome.