6 more days guys...

I’m interested in seeing what vibe coding tools are best. I think the best way to test this is with a group of 5 people. Here’s the idea We test 2-3 vibe code tools. We all sign up for them and complete the same project. I can provide a PRD for a simple website or application of our choosing. Nothing super difficult so everyone can do it. Then we use the same prompts as much as possible as we build through the applications on all 3 services and when complete we’ll have 15 versions of the same application. We can share the results on here and on our own networks to grow the channel and get some valuable insight into what worked. The 2 variables are the vibe coding tool and the individuals ability to produce via the tools. Adding 5 people and 3 tools creates enough variance for a simple test to see what’s best. If we market the results well we could even get the winning service to promote the content Let me know who’s interested and I’ll get us all connected

People are reporting Anthropic warnings/bans when using Claude OAuth (Pro/Max) through third-party tools like Clawdbot (instead of API access). I'm dropping the few links below - anyone here hit by this, and what workaround are you using (API key / different model / different tool)? https://x.com/elijahsystems/status/2016201425273958453

Good news: shipping fast with AI is still the move. Bad news: "it runs" and "it's safe" are two different checklists, and most of us have only been doing the first one. The lead story: a production checklist for apps you vibe-coded SitePoint published a developer checklist this week for taking AI-generated apps from prototype to production, and the reason it exists is the stat buried in the middle: Veracode's 2025 GenAI Code Security Report found that 45% of AI-generated code samples failed security tests, tripping OWASP Top 10 issues. That's Veracode's own benchmark on code samples, not full apps or real breaches, so take it as a signal, not a verdict. Separately, a WIRED investigation from May found exposed data in apps built with popular AI coding tools in the wild. None of this means vibe coding is broken. It means the part where you turn a prompt into a login page and a dashboard was never the hard part. The checklist's actual advice is unglamorous: write down who can see what before you generate more features, ship one feature at a time instead of one giant prompt, and read the auth code specifically because a hidden button on the frontend does nothing if someone can just call your API directly. The example in the article is a classic: an app that lets a user view invoices needs to check that this user is allowed to see that invoice, server-side, every time. Not "logged in," but "logged in and allowed." If you've shipped something with Cursor or Claude Code and haven't gone back to check that every protected endpoint actually enforces permissions per record, that's probably this week's homework. [YOUR TAKE: have you run a security pass on something you vibe-coded, or found out the hard way?] Agent Skills just became official MCP plumbing Bloomberg helped standardize a spec called Skills over MCP, now an official MCP extension (SEP-2640), announced at AGNTCon + MCPCon Europe in Amsterdam. The short version: MCP servers can now serve both tools and the instructions for using them, as skills, from one place. An agent loads just the skill's name and description first, then pulls the full instructions only when it actually picks that skill. Update the skill on the server, every connected agent gets the new version automatically, no re-syncing files to every user. Bloomberg says it hit this problem building ASKB, its Terminal AI tool, once skills needed to scale past one team.

Quick one today, but the lead story is a "stop what you're doing" kind of bug if you run OpenCode on Windows or WSL. Everything else is standards drama and a $65K excuse to vibe code a game. OpenCode's MCP sign-in bug let a server run commands on your machine Here's the setup: OpenCode connects to MCP servers to give your agent outside tools. When you sign in to one of those servers, the server gets to hand you a web address for OAuth — the "go here to authorize" link. On Windows and WSL, OpenCode passed that address into a PowerShell command without escaping it. Pillar Security found that a malicious address could carry a PowerShell payload and run it, with your access, the moment you signed in. The scary part isn't really the bug. Command injection happens. It's how it got fixed. Anomaly (the company behind OpenCode) patched it in version 1.18.33 on September 28, buried inside a pull request labeled as a "refactor" of browser-launch code. No security advisory, no CVE. Pillar reported it privately on August 29 and asked Anomaly to request a CVE; Anomaly's answer, per Pillar, was that a malicious MCP server is "outside our trust boundary." That means your dependency scanner and vulnerability alerts have nothing to match against. The only way to know you're exposed is to go check the version number yourself. Worth noting: your MCP server doesn't need to start out malicious. One you vetted and added months ago could get compromised later, or its domain could lapse and get bought by someone else, and you'd never know until sign-in runs a command on your box. The fix: upgrade to 1.18.33 or later if you're on Windows or WSL. If you can't upgrade today, run opencode mcp list, look at what remote servers you've got configured, and rip out anything you haven't fully vetted. macOS and Linux aren't affected — OpenCode doesn't route the browser launch through a shell there. And this is separate from the OpenCode Console breach reported around the same time, which may have exposed stored API keys.