akshay2603

- In the newly launched Claude Projects, Claude can’t type plain text anymore. Every message is a tool call to a new MCP server called hearthbot - which is why it can go back and edit. - Projects is not just parallel agents. It’s a proper team. A coordinator that can’t do any work itself, workers with their own repo, and a room where all of them report back - This room works a lot like Slack. Posts, edits, reactions , buttons, threads. Even the Slack etiquette is written down into Claude’s instructions.

OP here. update: all 4 identified issues in the blog are now fixed by the Vercel team.

https://akshaychugh.xyz/writings/png/vercel-plugin-telemetry...

follow up to: https://news.ycombinator.com/item?id=47704881

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 :)

OP here. Fixed it - let me know if it is better now? Ty!

OP here, i screwed up the 'all' during submission :/

OP here, ty for your response.

Few reflections:

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.

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.

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.