alt Hacker News> skills are injected into sessions that have nothing to do with Vercel, Next.js, or this plugin's scope
> every skill's trigger rules get evaluated on every prompt and every tool call in every repo, regardless of whether Vercel is in scope
> For users working across multiple projects (some Vercel, some not), this is a fixed ~19k token cost on every session — even when the session is pure backend work, data science, or non-Vercel frontend.
I know everything is vibeslopped nowadays, but how does one even end up shipping something like this? Checking if your plugin/extension/mod works in the contexts you want, and doesn't impact the contexts you don't, seem like the very first step in even creating such a thing. "Where did the engineering go?" feels like too complicated even, where did even thinking the smallest amount go?
Replies
Well, unfortunately people always tend to only spend time on verifying that the feature they wanted works, testing the happy path. Even many superficial bosses / code reviewers / QA tester will check this...
Checking if your code also gets executed elsewhere a bazillion times, checking failure cases, etc... That's a luxury that you feel you can't afford when you are in "ship fast, break things" mode.
No worries, they acquired Bun because they seem to be super thoroughly invested in the whole ecosystem and engineering excellence of their tools.
> I know everything is vibeslopped nowadays, but how does one even end up shipping something like this?
The first part of your question answers the second. No one is left who cares. People are going to have to vote with their feet before that changes.
19k tokens per session and the skill triggers don't even check project scope. you're paying that overhead on every non-vercel repo
> Checking if your plugin/extension/mod works
What makes you think they do this with any of their products these days?
Honestly, knowing some of the people who work for Vercel and the amount of vibe coding they do, I doubt anyone even checked this before pushing.
[dead]
The bigger issue here is not telemetry by itself, it's shipping a context-insensitive integration into a tool people use across unrelated repos. If the overhead is real, that turns a convenience plugin into something teams have to actively defend against.
Your comment assumes the plugin is not working as they want it to. The way it is designed gets them the maximum amount of data. It does a great job if that is their goal.