Reading the leaked prompts made the failure mode pretty obvious: the agent is optimized to get its feature working inside local context, not to improve the codebase as a whole. So it makes defensive patch fixes, leaves old paths around, avoids holistic cleanup, and slowly fills the repo with debt. My take is that it's intentionally designed to one shot new projects/features but you have a aggressively prompt it to write maintainable code.

I've been writing typescript for a number of years now (and startups and large companies) and have pretty strong opinions how to do it sustainably. The fact that we code with agents hasn't changed the fundamentals as much as vibe coders will have you believe. Hopefully others find this skill helpful.

Comments URL: https://news.ycombinator.com/item?id=47619825

Points: 4

# Comments: 2

This might the best collection of resources:

https://github.com/ryanspletzer/oidc-oauth-spec-graph

Comments URL: https://news.ycombinator.com/item?id=46701675

Points: 1

# Comments: 0

I agree though, runtime permissions should be the default

I've been using browser automation instead of TDD (agents over-mock tests), but needed to solve the token bloat. So I forked the Chrome DevTools MCP server to execute WebMCP tools from client-side JavaScript.

It's a drop-in replacement for the Chrome DevTools MCP server but with two added tools (`call_website_tool` & `list_website_tools`). Initial benchmarks show a roughly ~90% decrease in token usage, but other benefits which are harder to measure are speed and determinism (both of which are significantly improved).

Benefits:

- Free WebMCP support for your website, tools work for in-page or browser agents (in addition to agents using CDP) - Semantic tool definitions improve accessibility - Built on a web standard, no lock-in to my libraries - You can use this as part of your hard-coded E2E tests and make them significantly less flaky and faster

All the benchmarks and technical details are in the linked repo or in links at the bottom of the linked repo.

On a side note:

Much has changed since I wrote the [MCP-B](https://news.ycombinator.com/item?id=44515403) proof of concept a while back. WebMCP is very much on track to be standardized and I've joined the community working group to help form it. My implementation was used to introduce WebMCP at TPAC, I left my job at Amazon to work on it full time, and I found a co-founder to work on it with. I've built a bunch of stuff around WebMCP (much of which I think people can get real utility out of), but have not done a great job of sharing it, so expect to see more WebMCP-related content over the coming days. You can try out WebMCP from meetchar.ai (still very early) but we are looking for alpha testers for an inpage agent.

Comments URL: https://news.ycombinator.com/item?id=46223714

Points: 4

# Comments: 2

You declare your schema with a good TS ORM then use something like TRPC to get type inference from your schemas in your route handlers and your front end.

You get an enforced single source of truth that keeps the AI on track with a very small amount of code compared to something like Java.

This really only applies to full stack SAAS apps though.

Makes me wonder what a theoretical “best possible language for vibe coding” would look like

There was recently a conference which was themed around the idea that typescript monorepos are the best way to build with AI

We have better tools for this now. This is a draft video I put together for the W3C demoing WebMCP. It blows their agent mode out of the water, and you can even use in-browser models for inference (see the end of the video)

https://screen.studio/share/hbGudbFm

I've been working on this full-time after putting out the MCP-B/WebMCP Hacker News post.

https://news.ycombinator.com/item?id=44515403

It's also a contract for how LLM's interact with a website, they can do no more than the tools allow them to do. When you are running javascript on the page, the entire website is an attack surface.

Let's take gmail, for example. There is no way to protect your webpage from an agent running a script that sends an email by triggering the send email button. But with WebMCP, you can explicitly disable the "send_email" tool when the agent interacts with gmail.

With something like WebMCP you get elicitation and the ability to disable tools from the client.

If anyone wants to test out WebMCP, you can go to: https://webmcp.sh/ (this is a WebMCP server)

With the MCP-B chrome extension (this is a WebMCP client): https://chromewebstore.google.com/detail/mcp-b-extension/dao...

and use it to call WebMCP tools

We are incubating this over at the WebMCP web standard proposal. You can see the current draft of explainer for the declarative API. https://github.com/webmachinelearning/webmcp/pull/26

Also, great work on the browser agent, this is the best of the DOM parsing/screenshot agents I've used. I was really impressed with the wordle example

This is a video of me "vibe-coding" a userscript that adds a darkmode toggle to hacker news: https://screen.studio/share/r0wb8jnQ

The actual purpose of the vibe-coding userscripts feature is to vibe code WebMCP servers that the extension can then use for browser automation tasks.

Everything is still very WIP, but I can give you beta access if you want to play around with it

While building that, I basically wrote a modern version of Tampermonkey with its own marketplace built in. So you can vibe code any userscript and publish it to the marketplace all within the extension.

The automation stuff is still the core value-prop, but this is a fun bonus feature while I work on solidifying the automation features.

I'm writing a HN post for it. Excited to show everyone in a couple weeks here.

https://news.ycombinator.com/item?id=44515403

I’d love to give your beta access and get your thoughts if you are up to give it a run on the task you want automated.

Shoot me an email if you are interested

alex(at)mcp-b.ai

Totally agree. This was the thesis behind MCP-B (now WebMCP https://github.com/MiguelsPizza/WebMCP)

HN Post: https://news.ycombinator.com/item?id=44515403

DOM and visual parsing are dead ends for browser automation. Not saying models are bad; they are great. The web is just not designed for them at all. It's designed for humans, and humans, dare I say, are pretty impressive creatures.

Providing an API contract between extensions and websites via MCP allows an AI to interact with a website as a first-class citizen. It just requires buy-in from website owners.

It's being proposed as a web standard: > https://github.com/webmachinelearning/webmcp