DEV Community: Yevhenii

I got 140 downloads on day one. Then I found out who they were.

Yevhenii — Fri, 06 Nov 2026 15:46:17 +0000

ok so a little story.

I published a small package to npm. Nothing crazy. Next morning I open the stats page and see... 140 downloads. In one day.

And for like 10 minutes I genuinely thought "wow, people actually need this??" 😅

Spoiler: they didn't. Nobody did. It was robots.

where do those downloads come from

Turns out every time you publish a new version, registry mirrors and security scanners grab it right away. Usually that's somewhere around 100-150 downloads per version, doesn't matter if a single human ever touched it.

Plus there's a constant "background noise", bots pulling every version of every package every week. Plus CI pipelines reinstalling stuff on every commit.

So the "weekly downloads" number on npm is basically just "how many times the tarball got served". Not users. Not even close sometimes.

And this kinda bugs me, because we all look at that number. When picking between two libs, when checking if our own project is going anywhere, when writing "used by thousands" in a README...

so I built a thing

It's called humanloads 👋

You type any package name and see the npm number next to an estimate of real installs. The idea is pretty simple:

cut the spike every new version gets from mirrors in the first days
subtract the flat floor that bots download from every version each week
show what's left as a range with a confidence level

Important: it's not a "number of people". Nobody can count that, npm included. CI and dependency installs are still in there. But it's way closer to reality than the raw number.

No signup, everything is computed right in your browser.

stuff that's fun to poke at

compare mode: react vs vue, jest vs vitest, moment vs dayjs. Holy wars, but with cleaner data
per-version breakdown, so you can see which versions people actually use
category lists: best ORMs, test frameworks, bundlers and so on
and my favorite rabbit hole: why does is-number have so many downloads? 🙃

try it on your own package

Seriously, put your own package in there. It might hurt a little 😄 but at least it's honest.

Code is open on GitHub. The methodology is here if you want to argue with my math (please do, that's how it gets better).

What's the biggest gap between npm and humanloads you've found? Drop it in the comments, I'm curious 👇

Why Your AI Agent Is Reading 10x More Data Than It Needs

Yevhenii — Sun, 12 Jul 2026 20:14:14 +0000

Everyone wants smarter AI agents.

We compare models.
We tweak prompts.
We experiment with system instructions.

But after spending months working with MCP tools like Playwright and Figma, I realized something surprising:

The biggest bottleneck wasn't the model. It was the data we were feeding it.

The Hidden Problem

Imagine asking an AI agent a simple question:

"Is the Login button visible?"

That sounds like a tiny task.

Yet many browser tools respond with something closer to this:

the complete accessibility tree
every DOM node
dozens of element attributes
hidden elements
unrelated page metadata
viewport information
screenshot metadata
repeated values from previous snapshots

Instead of receiving the few bytes actually needed to answer the question, the model often receives hundreds of kilobytes.

The same thing happens with design tools.

Ask for the color of a button in Figma, and you might receive an entire page hierarchy containing thousands of nodes.

The AI only needed one component.

It received the entire design.

Bigger Context Doesn't Mean Better Results

There's a common assumption that giving an LLM more information always improves accuracy.

In practice, the opposite often happens.

Large tool responses introduce:

irrelevant context
duplicated information
longer reasoning time
higher token usage
increased latency

The model spends part of its context window understanding data that has nothing to do with the user's request.

That's not intelligence.

That's overhead.

The Snapshot Problem

Browser snapshots are one of the biggest contributors.

Imagine an agent performing this workflow:

Open page
Click Login
Wait
Fill email
Fill password
Click Continue

After every action, the browser sends another complete snapshot.

But what actually changed?

Usually only a handful of nodes.

The rest of the page is identical.

Yet the entire snapshot is transmitted again.

It's similar to downloading an entire Git repository after changing a single line of code.

We solved this problem years ago in software engineering with incremental updates and diffs.

Many AI tools still don't.

Noise Is Expensive

People usually calculate the cost of AI using model pricing.

For example:

GPT costs X per million tokens.
Claude costs Y per million tokens.

But those calculations ignore something important.

Every unnecessary byte produced by a tool also becomes part of the model's input.

If your tools generate 10× more data than necessary, you're effectively paying for that noise.

And you're paying for it repeatedly throughout the conversation.

The model has no way to know which information is useful until it has already processed it.

Smarter Tools Beat Smarter Prompts

Prompt engineering gets a lot of attention.

Tool engineering gets almost none.

But if your agent only receives relevant information:

responses become faster
token usage drops
context stays cleaner
reasoning becomes more focused

Sometimes the best optimization isn't changing the prompt.

It's changing what reaches the model in the first place.

Lessons Learned

Working with browser automation and design MCP servers taught me that most optimization opportunities exist before the model even starts thinking.

Instead of asking:

"How can I make the model smarter?"

a better question might be:

"Why am I sending it all this data?"

Once you start looking at tool responses instead of prompts, you'll often discover that most of the context window is occupied by information nobody actually needed.

Final Thoughts

Large language models are becoming increasingly capable.

But they're still constrained by the quality of their inputs.

As AI agents become more common, I think we'll spend less time optimizing prompts and more time optimizing the tools that feed those prompts.

Because sometimes the fastest, cheapest, and most accurate model isn't the one with the largest context window.

It's the one that never had to read hundreds of unnecessary kilobytes in the first place.

Have you ever inspected the raw responses your AI tools send to the model?

The results might surprise you.

I Built an MCP Proxy That Reduces Playwright and Figma Context for AI Agents

Yevhenii — Thu, 09 Jul 2026 15:35:18 +0000

Over the past few months I've been using Claude Code heavily with Playwright and Figma.

At first everything worked well, but after longer sessions I started noticing a few recurring problems:

Playwright browser snapshots were consuming hundreds of KB of context.
Figma responses often contained much more information than the agent actually needed.
Browser sessions occasionally crashed, forcing the agent to start over.

None of these problems were caused by the MCP servers themselves.

They were simply returning everything they were designed to return.

The issue was that AI agents pay for every token they receive.

The Idea

Instead of modifying every existing MCP server, I wondered:

What if there was a transparent proxy between the AI agent and the MCP server?

That idea became PlayGuard.

AI Agent
    │
    ▼
PlayGuard
    │
    ▼
Playwright MCP / Figma MCP / ...

The proxy intercepts requests and responses before they reach the agent.

This makes it possible to optimize them without changing the original MCP server.

What PlayGuard Does

Current features include:

Response optimization for Playwright
Response optimization for Figma
Automatic Playwright session recovery
Response caching
Configurable optimization rules
Plugin architecture for additional MCP servers

The goal is simple:

Make existing MCP servers more efficient for AI agents.

Why It Matters

Large language models have limited context windows.

If an MCP server returns 300–500 KB of data every time the agent asks for a browser snapshot, that context disappears quickly.

By removing unnecessary information before it reaches the model, the agent can spend more of its context on reasoning instead of processing redundant data.

Design Philosophy

PlayGuard is intentionally transparent.

It doesn't replace MCP servers.

It doesn't require modifying existing tools.

It simply sits in the middle and optimizes communication.

That also means new optimizations can be added over time without requiring changes to Playwright, Figma, or other MCP implementations.

Roadmap

Some ideas I'm currently working on:

More MCP integrations
Better optimization pipelines
Performance benchmarks
Custom optimization plugins
More intelligent caching

Feedback Welcome

The project is open source, and I'd appreciate any feedback or ideas.

GitHub:
https://github.com/ZenyaDAR/PlayGuard

Website:
https://playguard.dev/

If you find the project useful, consider giving it a ⭐ on GitHub. It helps other developers discover the project.