miguelspizza

Not even TS. Might as well just start having the agents write minified code from the start if it’s going to look like this…

I can’t even get past the popup on mobile to try it…

I recently took a contract with big tech after working with startups for about a year ( I was at this big corp a year ago)

Maybe it’s the small sample size, but from what I’ve seen, the thing hurting velocity more than anything is the fact that teams have too many “cooks”.

The way work is delegated is a bit broken when in reality the engineer who knows the code base or problem best should scope the work and just delegate it to their agents.

I can’t image how things look on the BI side.

You can easily get under 100ms per decision in browser with a Qwen based decison model: https://alxnahas.github.io/strands-decider-web/?backend=engi... There is nothing about Qwen or Laya that make one or the other better at running in the browser. It is really just: how large is your model and how does KV cache expand as input length increases

I'm surprised I don't hear more people talking about code mode using existing SDKs for APIs like Google Workspace. That works so much better than converting the Google Workspace MCP JSON schemas to Types, then having the model write TypeScript to call those MCPs and then translate those back to JSON RPC calls. Just using that token from the MCP server and using the underlying fetch requests that the TypeScript Google Workspace SDK makes works infinitely better than teaching the model bespoke types. I'm assuming we're going to see a lot more of this as CodeMode gets more widely supported in harnesses

This is a great model. I've been running it on device in chrome extension to filter things like email.

It is just the right mix of size, capability and speed to make it generally useful for adhoc bulk classification tasks.

For those wanting to run it in browser: https://huggingface.co/alxnahas/strands-decider-2B-webgpu

I think it's fair to say I know quite a bit about MCP (I built a company on it) so I'll take a crack at this. TLDR: MCP is an Oauth protocol now

MCP started out as this sudo browser replacement protocol for AI integrations. Similar to how a browser opens tabs and loads in JS, the idea was that MCP hosts load in MCPs and interact with them that way. Thus the original spec shipped as a stateful server client protocol with prompts, resources, a bunch of other stuff... and tools (the only thing anyone really ended up using). If you want to learn more about the original idea behind it, the creators did a pretty good podcast where they go through the conception and their design partnership with the Zed guys.

It became pretty clear early on that that way people wanted to use it was basically "I heard if I download this thing called an MCP the AI can manage my Jira tickets". so it's been almost 2 years now of rolling back all the opinions of the original protocol (statefulness, esoteric features) and bringing it closer to OpenAPI + JSONRPC + OAuth. Since the July spec release, you will start seeing alot more of this: https://redocly.com/docs/realm/content/api-docs/openapi-exte...

The biggest "win" of MCP is that the hype behind it let the Oauth guys swoop and use it to formalize a bunch of Oauth specs into a coherent story for API auth.

SAML is bad, but OAuth and OIDC are showing major cracks with identity and agents. Go to any major company right now and ask them how they are dealing with authenticating agents/what an agent identity even is.

The XSW part of the article was new to me though and kinda shocking

The article misses the point of MCP but he is not wrong that it was a mistake (in some ways)

The mistake of MCP was building it in such a way that it needed to be on a separate process from the API. The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years.

Now that MCP is stateless we can start building what is actually useful: extending API’s for agents.

When people ask me if they should do MCP today, I say absolutely. But because the Oauth protocol side of MCP is very good and is a net positive for all public API’s

This is not a dig at MCP, the original vision of MCP was much different from how the community used it.

Nice write-up. Btw, Codex and ChatGPT desktop support WebMCP in their integrated browser as of yesterday.

One way to think about WebMCP, as the article notes, is as web accessibility for agents. But since it functionally allows developers to expose any function on their website to an agent via RPC, the more interesting use cases are the ones that use the browser as a sandboxed execution environment.

https://duckboard-webmcp.alexmnahas.workers.dev/ is an example of this, and I would love to see more.

Maybe instead of skills that require users to download arbitrary binaries to their computers, the skills could instead point to a domain that comes preloaded with that binary in Wasm and lets the agent interact with it over WebMCP?

The more I use the AIs the more I feel like I did at the end of reading blindsight. The things are undoubtedly “intelligent” by any practical definition of the word, but they are not aware.

This is also why I advocate against using AI as a writing partner. No matter the argument you lay out, a fresh context window will always have the “a few good things and a few bad things” feedback. There is no higher order opinion to align with.

The worst materialization of this are the slew of startups that are going to “watch your employees work so they can learn their job” as if random clicks on a computer can be reversed engineered to automate someone’s job.

This sort of audacity is a large part of the reason people increasingly hate AI

Not sure I understand the point your are making. how is this unique for bots with their own identity? Bots hijacking a user session can also be blocked

AI Session Hijacking is such a dead end and I think this will be the thing that kills it. Just register these things in the IDP and let them sign into their own accounts.

Maybe if we give these things their own identity people will stop letting their AIs post as them in linkedin

I used this for a POC analytics dashboard for a client recently.

Very very good, nice work.

What are your plans for the library?

What’s ironic about this is they technically already shipped a looser version. The entire cf api is exposed as an MCP server which supports OAuth and dynamic client registration.

Not sure why they don’t just support DCR or CIMD for this too

Happy to see WebMCP adoption and a standards first framework.

The argument for react has always been dev velocity and ecosystem. But with AI the best web experiences will be as close to the “metal” as possible

I have been working full time in the MCP (& WebMCP) space for about a year now. Half consulting half spec work.

The article is semi right. Local MCPs that are made by enthusiasts wrapping an api they don’t own? Yes that is dead and should never have been a thing in the first place.

But MCP in its current direction and form is really an OAuth Protocol over http. And it has something other that other agent identity protocols don’t: client adoption

I’m not sure why this is getting so much hate. This is the future people, AI is a primitive of modern software, just be thankful chrome ships this locally

I’ve spent the past few months working with and implementing OAuth.

This might the best collection of resources:

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

We actually have this with the permissions API. The issue is everyone just opts for longer approval times and less intrusive UX with manifest level permissions.

I agree though, runtime permissions should be the default

Hate to say it but this sounds like a skill issue. The reason Typescript monorepos are gaining popularity for building with AI is because of how powerful TS's inference system is. If you are writing lots of types you are doing it wrong.

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.

Clojure is such an underrated language for vibe coding for this very reason.

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

Not sure where you heard this but general sentiment is the opposite.

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

The agent mode is really disappointing. I thought OpenAI would try to be more innovative with how the agent interacts with webpages, but it looks like it's the same DOM parsing and screenshot workflow the rest of the AI browser agents use. Giving the agent full access to the page is a recipe for disaster.

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

WebMCP essentially turns your website into an MCP server. Which means it is kind of like building a UI for the LLM that lives alongside the human UI.

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.

It's more providing permission granularity on the action level rather than the sandbox level. Your script might not be able to make external api calls, but there is no way to gate the ability to take destructive action within the webpage.

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

Hey glad to see Jason getting the credit he deserves! He was grokking WebMCP long before anyone else.

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

> The other part is the cohesive interface for the agent itself to use these selectors

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

I wrote #2 as a result of a web automation tool I a working on. It's easier to show than tell.

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