The Front End Is Back

Aug 2026 · 8 min read

I have always loved the front end. Part of it is where I come from, a design and interaction background, and the front end is the one layer where that background actually pays off, because it is the layer you can hold in your hands. You draw the thing, you wire the thing, you decide how it behaves, and then you hand the app to the client and it just works. No environment to provision, no fleet to babysit, it runs on the machine the user already has open.

The part I love most is that the browser is a canvas. For a very long time now, instead of writing a spec for somebody else to read and interpret and hopefully build, I prototype the real thing. And a real prototype has so much more to give than a Figma one. You get to make actual decisions about how it looks on a phone and on a wide monitor, how the same code adapts to each without duplicating anything. It hands you constraints, and figuring out how to still deliver great UX inside those constraints is, honestly, the fun part of the whole job.

The one thing I always faked

There was always one cheat in those prototypes, though. The data. What I used to do was write a little dummy retrieval layer, awaits and all, serving hardcoded JSON, so the artifact would read like a real application and a developer could pick it up and recreate it while wiring it to an actual backend. Handy, and I still think it was the right call at the time. But it left gaps. Perfect data came out of that layer every single time, so it never forced me to react to the things that go wrong the moment you touch a real source: the errors, the half-empty responses, the dataset that arrives missing exactly the field your design was leaning on. You could build something beautiful and get blindsided the day it met production.

AI takes that problem and makes it a lot harder, because now the data barely comes back in the same shape twice. AG-UI cleans up a good part of that mess, it gives you a real contract for how an agent streams its state and its tool calls into your UI, so at least the wire between the model and your components stops being a guessing game. But it standardizes the wire, not the boundary. The tools and the data it reaches for still live behind a server, which means you are still designing against something you have to go stand up first. And that was the bigger wall underneath all of it: to prototype an AI app properly, the kind where you can actually design around the awkward cases, you always needed some server-side implementation standing behind it. The front end on its own could not get you there.

An architecture simple enough to catch my eye

Then a few weeks ago my friends at runtype.ai showed a demo of agents built on an architecture so simple it stopped me cold. No MCP server anywhere. Just a Cloudflare worker sitting in front of an LLM as a proxy, there so you are not shipping an API key back and forth on every call, wide open and insecure as it was, and a system prompt doing the guardrailing. That was it. And the piece that made it all click was WebMCP.

WebMCP is a spec still very much in development, the kind of thing that will eventually land in Chrome, but the idea is so sound that you do not really need to wait for it. Use the web infrastructure you already have to talk to machines, the same way you use it to talk to people, and polyfill the spec while the rest of the industry catches on. That is the whole idea. I read it and I knew it was right, the way you sometimes just know.

Convincing the room

So I jumped on it, standard or not. My org was, understandably, skeptical about shipping something to production on a spec that is not finished, and I fought those reservations pretty fiercely, because the objection did not hold. You do not need the browser itself to understand WebMCP for any of this to work. My agent never touches document.modelContext directly, it talks to a small adapter I own that sits in between, so the day the spec renames a field or changes how a tool is registered, I edit one module and nobody upstream feels it. The risk everyone was worried about, the spec moving under us, was a risk you could wrap in one file and put away.

The skepticism held anyway, so I did the only thing that ever really convinces anyone. I built it. A fully working shopping agent on WebMCP, dropped onto a test store, a project that does not just run but runs extremely well, and does it without asking our MCP team to go build a whole server-side MCP solution first. The proof was in what I got to delete. The orchestration server, the tool transport, the schema-shuffling, all the code whose only job was to shuttle a tool call across the network and pour the conversation back in to resume, around five hundred lines of careful machinery, just gone, and the thing worked better without it. That prototype changed the conversation. It convinced a lot of people that this is not only possible but fast, that you can stand up this kind of bundled agent, the chatbot that actually does things, in a matter of days, because it leans on what you already have and have been building for years, your REST and your GraphQL, instead of a brand new stack.

The industry did not wait long

And the rest of the industry did not take long to arrive at the same spot. The team behind the technology frames it mostly as a way to handle what is happening on the front end, which, to be clear, is a genuine plus. But the first real impact I saw was a different one: people wrapping their existing APIs in it to do, client side, exactly what MCP does today on the server. Cloudflare is offering precisely that. We sat down with them, and they had just launched a product that takes your MCP and serves it on the front end by flicking a switch that injects it into your site. Smart, and concise.

Then this week OpenAI announced that Codex can work with WebMCP tooling too, and that is about as clear a signal as you get that this one is going to stick. The nice thing about an idea this sound is that you can recognize it now. There is no prize for waiting until everyone else has agreed on it.

What this changes for the way I build

Here is what it means for my actual product work, which is the part I care about most. I can now prototype and build AI applications that do not run on mocked data and fake endpoints. They use the technology they are supposed to use to drive real, meaningful interactions, which means I finally get to design around all those cases I never used to see coming, the errors and the gaps and the weird shapes, because now they actually show up. The old blind spot closes on its own.

It also leaves a gift for the engineers. A working front-end agent is a live reference for how the application and its tools should behave, so if a team wants to expose the same tools over a real MCP server later, they have something concrete to copy instead of a document to interpret. I did exactly that. I handed our MCP team the full toolset we run on the storefront assistant, every tool, so they know precisely what we need, can replicate it on the server side, and tie it back to the other agents that work across our stores. The prototype stopped being throwaway and became the spec.

How far the browser goes now

And once you start pulling on this thread, the browser keeps giving. I went further and built tools around it that I would not have bothered with a couple of years ago: vector embeddings running on WASM, local databases like DuckDB sitting right there on the page. The Prompt API, still young, still not all that powerful, already lets you run small language models locally and work out which use cases can live entirely on the client, saving you the round trip to the server and even the trip to that little LLM proxy, which now lives on the front end too.

It is a wonderful time for client-side technology, and I have not even mentioned the pile of things you can build inside an Electron app once you take all of this and ship it as a desktop application. The browser stopped being the thin end of the stack a while ago. We are only now catching up to how much it can actually carry.

I know exactly how this sounds

I know how this reads. A guy who always liked the front end is thrilled to death that the front end matters again, how convenient for him. And sure, guilty. But it is more than a vindication, it is a change in where the leverage actually sits. For a decade, if you wanted to build the ambitious half of a product, the part with the real systems in it, you had to walk over to the server, because that is where our industry had quietly moved all of it. That walk is not required anymore. Somebody who knows the page, the session, the DOM, the CSS, the small intricacies of how a browser really holds a user, can now build a complete AI agent on their own, end to end, in the one place they already understand better than anyone.

Which brings me back to the canvas. For years that canvas could only hold the paint, a convincing picture of an app with fake data sitting behind it. Now it holds the whole thing, the model included, talking to real endpoints and breaking in the real ways, and you get to design for all of it in the same place you were already working. You do not need a finished spec, you do not need permission, and you do not need to wait for the browser vendors to bless it. You need to recognize a good idea while it is still early, which, if I am honest, is the part of this job I have always liked best.

If you want the receipt, it is a case study on this site: the merchant companion, in The Spec Is a Working Agent. I wrote about the same shift from the drawing side in Getting the Whole Self Back, about AI handing back the parts of yourself the org had filed away. This is the engineering side of the same gift. The front end was never the junior end of the job, it was a capable place we let ourselves get talked out of taking seriously, and the agents, of all things, are what handed it back. I have not enjoyed the work this much in years.