Wow. Just read the full policy. It's not just 1D. Section 2D says plugins "must not intentionally call or coerce Claude into calling other external software... unless requested and intended by a user."
The consent flow literally instructs Claude to run echo 'enabled' on your filesystem. And 1D says plugins "must not collect extraneous conversation data, even for logging purposes." Full bash commands from non-Vercel projects are extraneous :)
1. Asking for prompts permission is a big big no - i still don't understand why you need it. The greenfield example feels like a stretch but I get that it is a business call and Claude Code enables you to do this today. I am just more pissed with them here. I am not at all comfortable with any plugin getting this info, no matter how much I like them.
2. The way you ask this permission feels like a solid dark pattern. I understand it is a harness limitation and Claude code should fix it (as I mentioned in the post) but you choosing to ship this is just wrong. Thank you for agreeing to rethink the wording.
3. Basic telemetry being default on and plugin collecting data across non vercel projects made me super uncomfortable. Again, i understand it's a business call but I guess I had higher hopes from vercel.
For sure, I can see from your perspective how some of the measures we took were a little aggressive. And we're currently working on making it more explicit.
I promise you we've had user's data privacy in mind since day 1 of building the plugin.
Everything we collect is only used to improve the Vercel plugin, eg: seeing when skills are being triggered too often, when certain skills are not useful, when certain context is taking up too much room.
The complete flip side of this where we ship with no instrumentation and the plugin is useless - then we have no way to iterate and make it amazing.
I understand but nobody's asking for zero instrumentation.
The ask is: make base telemetry opt-in, disclose what you're collecting in plain language, and scope it to Vercel projects.
You keep the data you need to improve the plugin - from users who chose to share it. Everything else is what's making people uncomfortable in this thread.
I am one of those PMs at a big tech that just shipped a PR in prod:
My take:
1. Doing this moves my team faster. I now use sourcegraph MCP all the time to file much better bugs. And when the actual bug fixing TAT is larger than bug filing TAT, I rather just do it myself. My engineers appreciate it, truly.
2. This not only helps me do bug filing but just get comfortable with code. And this improves my PRDs, my MVPs and my overall thinking. There is no way that I can do this in isolation. I have to get comfortable with code and that involves shipping the occasional PR.
3. This improves my craft. I am obsessively shipping on the side. The codebase for my personal side projects is manageable. I would love to ship at work as well but that's not doable because of codebase complexity and the inability to read code. However, traditional product management is collapsing and this is the new normal.
If you can't read code and don't understand the codebase, you have no business anywhere near a text editor.
I work with a PM that's also learning to program. I assume just like you, they probably feel they'll otherwise will be pushed out. While it's far from the most productive thing I could be doing, I'm always happy to answer questions from a beginner programmer, or walk them through how something works, or how it should work but doesn't, help them debug it, etc.
Even though they're more or less ripping off the company, and are being paid a six-digit salary to be an intern programmer, I have infinitely more respect for them, as they're actually putting a good effort into learning the craft, and they're honest about what they're doing.
You can argue all you want that throwing vibe-coded PRs at your team improves your MVPs, PDRs, AVBs, DRTs, SVGs, BMPs or whatever un-measurable metrics you come up with, the reality is you're creating more work for everybody.
It takes a great amount of hubris to believe that although you may be unable to read code, surely your understanding for the product will lead to a diff that's an overall net positive. Your team will pat you on the back and then quietly clean up your mess.
If you want to program; great; learn the craft like the rest of us did. I'm sure you'll find many people happy to share knowledge and help you along if you put in an earnest effort.
Spicy response but nevertheless, thank you for taking the time.
You are right that I can't understand code. But what I can do is identify the right problem, and identify the right solution to solve that problem. Coding agents are GREAT enough now to complete the last leg of solution -> code implementation.
It helps that my PRs are small, typically frontend heavy, I can test all I want, and almost all of them get merged without any major comments. If this is happening , then surely we can agree that no one is cleaning up my mess or I am not generating something that is not net positive.
I have zero worries about being pushed out - all of this is barely 5% of my work time ++ weekends, happening out of interest (and the other reasons I mentioned) and not because I have to.
And sure, I could invest in learning the craft. But this is exactly that from my pov. I am sitting in terminal, I am asking Claude to explain what changes it is making, thoroughly testing everything to ensure nothing breaks. Just because I am not typing the actual code doesn't mean I am not putting an earnest effort.
Code is extremely evil because you can accidently write ++a instead of a++ and create a bug so severe and so hidden you bring down the whole company.
I work at a company that does payroll software. Its not atypical for me to spend an entire week to write one singular line of code. Because in order to write that line and be confident it's correct, will always be correct, and cannot have any side effects, I have to read and understand so much other code.
The older the codebase is, the worse it gets. The larger the codebase is, the worse it gets. The more valuable your customers are, the worse it gets. That's why free consumer software is riddled with bugs and nobody cares.
https://akshaychugh.xyz/writings/png/vercel-plugin-telemetry...