Personalizing Websites at the Edge

United Airlines’ flight search shows you every result in a wall of identical-looking rows. No filter for departure time. No way to collapse or dismiss flights you’ve already ruled out. You scroll through dozens of results, mentally tracking which ones you’ve rejected, squinting at the same five fare columns over and over.

This is a solved UX problem. Every modern search interface has filters. United just… doesn’t.

So I had Claude write a bookmarklet that fixes it.

The Bookmarklet

One click, and every flight row gets a dismiss button. Click it, and the row collapses into a thin summary line showing the route, times, and prices — all struck through so you know you’ve rejected it. A sticky counter at the top tracks how many flights you’ve dismissed. A “Restore” button on each collapsed row brings it back if you change your mind.

11 flights dismissed, and I can finally see the ones I care about without scrolling past the ones I don’t. The collapsed rows still show me the key info — departure, arrival, price per fare class — so I can scan quickly if my criteria change.

This isn’t a browser extension. It’s not a Greasemonkey script. It’s a bookmarklet: a blob of JavaScript saved as a browser bookmark that runs against whatever page you’re on. No install, no permissions, no updates. Click and go.

What AI Changes About This

Bookmarklets aren’t new. Power users have been writing them for decades. What’s new is the speed of creation.

I gave Claude the HTML structure of United’s search results (scraped from the page), a screenshot of what it looks like, and a description of what I wanted. After some iteration, it produced the full bookmarklet — DOM traversal, CSS animations, fare extraction, the collapse/restore toggle. The whole interaction, from “here’s what I want” to working code, would take an experienced front-end developer an hour or two. With AI, it’s a conversation.

And that changes who can do this. You don’t need to know how to traverse a React-rendered DOM with CSS-module class names. You don’t need to reverse-engineer United’s component hierarchy. You describe what you want, hand the AI some HTML for context, and get working code back.

Hyper-Personalized Consumption

This points at something bigger than fixing one airline’s search page.

Every website you use was designed for the average user. The layout, the information density, the controls — they’re all compromises made by a product team optimizing for the broadest audience. Your specific workflow, your specific preferences, your specific needs are almost never the priority.

What if you could reshape any website to fit how you actually use it?

• Too much information? Collapse the sections you never read.
• Missing a filter? Add one that operates on the DOM directly.
• Wrong sort order? Re-sort the elements client-side.
• Need a calculation the site doesn’t offer? Extract the data and compute it inline.

This has always been theoretically possible with browser dev tools. In practice, it required enough JavaScript knowledge to be out of reach for most people. AI closes that gap. You describe what you want in plain English, point the AI at the page, and get a bookmarklet or user script that does it.

The personalization happens entirely in your browser. No server changes. No API access. No waiting for the company to prioritize your feature request that’s been sitting in their backlog for three years. You just… fix it yourself, at runtime.

Throwaway Prototyping for Developers

There’s a developer angle here too. If you’re a web developer considering a UX change, the traditional path is:

1. Design review
2. Write the feature
3. Wire up state management
4. Write tests
5. Deploy to staging
6. Get feedback
7. Iterate

For exploratory work — “would it even be useful to add a dismiss button to search results?” — that’s a heavy lift for an idea that might get killed in step 6.

The bookmarklet approach inverts this. You skip straight to a working prototype that runs against the live site with real data. No build step. No deployment. No state management beyond what the DOM gives you. You can hand someone a bookmarklet URL and say “try this on the actual search page and tell me if it’s useful.”

It’s throwaway prototyping in the most literal sense — the code exists as a bookmark, does its job, and you never think about it again unless you want to iterate. If the idea is bad, you delete the bookmark. If it’s good, you’ve already validated it with real users on the real product before writing a single line of production code.

Computing at the Edge, Personally

There’s an analogy here to edge computing. The industry spent years moving computation closer to the user — from centralized data centers to CDN edges to service workers running in the browser. The pitch was always about latency: compute closer to the user, respond faster.

What AI-powered bookmarklets do is something similar but for personalization. The “edge” isn’t a Cloudflare POP or a Lambda@Edge function — it’s the user’s browser, and the “computation” is reshaping the UI to fit one person’s needs.

Call it personalizing at the edge. The website serves its standard experience to everyone. The personalization layer runs locally, in the browser, written by an AI to your specifications. No server round-trips. No A/B testing infrastructure. No feature flags. Just your browser, modifying the DOM based on what you want to see.

The interesting thing is that this is zero-coordination personalization. The website owner doesn’t need to support it, enable it, or even know about it. Once built, the personalization layer runs locally in the browser and stays under the user’s control. It’s the most decentralized personalization possible — every user can have their own unique version of every website, generated on demand by AI.

The Limits

This only works for UI-level changes. You can’t add server-side filters, access data the page doesn’t already load, or modify API responses. If United doesn’t load flight data for a date range, no bookmarklet can show it.

It’s also fragile. Bookmarklets that target specific CSS classes or DOM structures break when the site ships updates. The United bookmarklet targets class names like app-components-Shopping-GridItem-styles__flightRow--QbVXL — that hash at the end changes with every build. You’d need to regenerate the bookmarklet periodically, or write more resilient selectors.

But for the use case of “I need this to work right now, for this session, for this specific task” — fragility doesn’t matter. You’re not building infrastructure. You’re solving a problem in front of you, and tomorrow you’ll solve it again if you need to. The cost of regeneration is a conversation with an AI, not a sprint of engineering work.

What Comes Next

Browser extensions with AI built in are the obvious evolution. Imagine a browser sidebar where you can say “hide all flights departing before 8 AM” and it just… does it. No bookmarklet generation step. No copying JavaScript into a bookmark. Just natural language to DOM manipulation, live.

Some of this exists today in prototype form. But the gap between “AI can generate a bookmarklet” and “AI can safely modify any page in real-time” is mostly about trust and guardrails, not capability. The capability is already here — I watched it build a fully functional flight search UI enhancement from a screenshot and a paragraph of instructions.

The web was always meant to be a platform where the user has the final say over how content is rendered. We just didn’t have tools that made exercising that control practical. Now we do.