How this site was made

I went through the repo. Here's what I'd do, starting with why it reads as AI-built right now.

What makes it look AI-built

Most of it comes from specific defaults that AI tools reach for:

• Outfit font with an animated gradient on your name (home.module.css .heroName)
• Three blurred background blobs in orange, purple and cyan (ambientOrb1-3)
• See-through "glass" cards with a glow effect on every block
• A "✨ Welcome to my portfolio" badge above a centered hero with two buttons
• A stat row: "3+ Years / 5+ Projects / ∞ Ideas"
• Skill pills sitting on percentage levels
• Small things: the README is still the T3 starter text, and Mantine v5 is forcing legacy-peer-deps on React 19

Changing colors won't fix this. The layout and the choice of components need to change too.

The main idea: an MCP server that is also your portfolio

All three of your ideas fit one concept: the site works as a site for people and as an API for AI agents. It shows MCP work by being an MCP server, not by describing one.

1. A remote MCP server at /mcp

• A Next.js route handler using the MCP SDK's streamable HTTP transport, running on Vercel.
• Tools: get_projects, get_experience, search_blog, check_availability, and send_message (rate-limited, and it asks for confirmation).
• The showcase page has an "Add to Claude / Cursor" config snippet you can copy, plus a live inspector: a log of real tool calls with private details removed, so visitors watch agents using your site.

2. WebMCP: the same tools, inside the page

• Each page registers its tools in the browser, checks whether the browser supports this, and shows a quiet badge like "this page exposes 5 tools to your browser's agent."
• An "x-ray" toggle outlines each part of the page that's backed by a tool, so visitors can see how the page maps to the agent's API.
• Caveat: support is still early. Only Chrome Canary or an origin trial (around Chrome 149+) has it. The API also moved from navigator.modelContext to document.modelContext, and older guides still show the old name. You'd need a fallback, which item 3 covers.

(I took "wmcp" to mean WebMCP. Tell me if you meant something else.)

3. Live UI changes with Haiku (claude-haiku-5-5)

• "Restyle this site" box: a visitor types something like "Bloomberg terminal" or "1997 GeoCities." Haiku returns a limited JSON theme (colors, type scale, spacing, corner radius, layout variant). You already use zod, which would check it before it's applied through CSS variables. It never returns raw CSS or HTML, so it's safe and the site can't break. Themes can be shared as a URL, and the best ones go in a gallery.
• Content that changes for the reader: "explain this for a recruiter / a CTO / a 10-year-old." Haiku picks from a fixed set of your components and fills in their content.
• Fallback demo for WebMCP: a small Haiku agent in the page calls the same WebMCP tools, so the demo works in every browser.
• This could also replace your 6 hand-built brand portals: the portal look gets generated live instead of maintained by hand.
• Cost control: rate-limit with Vercel KV or Upstash, cache results by prompt, and keep max_tokens small. Haiku is cheap enough for this.

Three looks to choose from

My recommendation is A or C, with the Haiku restyler as the fun part. A plain default look also makes the restyles stand out more.

Order of work

1. Clean up: remove Mantine, react-slick and leva, finish moving to the App Router, and build the new design system.
2. Build the MCP server and inspector page. This is the strongest portfolio piece.
3. Add the Haiku restyler. This is the part people will share.
4. Add WebMCP tools and the x-ray mode, with the Haiku agent as the fallback.

Questions for you

1. Which look: A, B, C, or a mix?
2. Should the easter eggs and brand portals stay? I'd keep 2–3 of the best and cut the rest.
3. Are you OK putting an Anthropic API key on the server for the Haiku features?

If it helps you decide, I can make quick HTML mockups of the three looks before changing any code.

Sources:

• WebMCP Brings Model Context Protocol Into the Browser Itself
• WebMCP in 2026: The API Moved and Most Guides Are Wrong
• WebMCP in 2026: Which Browsers Support navigator.modelContext?
• WebMCP vs MCP: Where Each Runs

I made three clickable mockups. They're only the visual direction: none of the data is real yet, and the Haiku restyles are canned examples, not live calls. Open them in a browser to click through:

• a-two-readers.html: drag the seam, or click a "Try" example under Restyle.
• b-daylight.html: drag the time slider to sunset and then night, or try "Tokyo at 3am".
• c-shop-drawing.html: open the drawers, turn on "Show agent tools", and request a revision.

To avoid the AI-built look, each one gets its look from something about you rather than a template: your MCP work in A, your Zmanim app in B, and Fabuwood in C. Each has one standout interaction, and the rest is kept quiet. The easter eggs are more grown-up now:

• A: agents can find the hidden things through a list_secrets tool.
• B: the site changes after dark.
• C: a hidden revision history.

I checked each one in headless Chrome at desktop width. I haven't checked them on a phone.

Things to decide:

1. Which direction? You can also combine them. For example, use C's look and drawers, add B's real-sun lighting as a subtle layer, and use A's seam as the agent-view toggle.
2. Copy: the career line is "same company, four jobs, I automate whatever is slow" and the hero line is "people can read and agents can use". Do they sound like you?
3. What to cut: anything you already dislike?

The mockups are in a new, uncommitted design-explorations/ folder. Tell me what to change and I'll do another round before starting the real build.

I rebuilt it as one direction at a much higher level: d-klein.html. It's a single bold electric blue throughout, and the motion is what makes it.

Screenshots don't show the motion, so open the file in Chrome full-screen and:

• move the cursor through your name
• scroll slowly through the whole page
• hover over the "Same page, two readers" section
• click "Tokyo arcade"

It uses GSAP and Lenis loaded from a CDN, so it needs internet to run. I captured each section in a real browser at desktop size with no errors. I haven't tested it on a phone yet, and the custom cursor is turned off on touch screens.

To aim the next round, it would help to know:

1. Is this closer? If yes, what's still missing? If no, send me 2–3 sites you think are award-level, from Awwwards or anywhere. "Award-winning" covers very different styles, and examples are the fastest way for me to match what you have in mind.
2. The blue: keep it as your color, or should Haiku pick a new look for each visitor?
3. Hero: keep the code-glyph name, or try something else? For the real build I'd move it to WebGL so it runs smoother and supports more particles.

I built the refined version as e-klein-agent.html, and wrote the concept up in CONCEPT.md.

I read your message as: the agent shouldn't just switch the theme on request; it should change things slowly and show the code as it goes ("let's embed this library"). Tell me if you meant something else.

What changed from the last version:

• Refs on by default. From agent-browser, every part of the page has a visible @e tag, and the page can list itself as a short ref tree. This replaces the agent-tools x-ray from Direction C, and it's on from the start.
• The agent works one step at a time. It reads the page, says its plan, types the code, loads the library from esm.sh, then runs it, scrolling to and outlining each part it touches. Every change can be undone and has a remix link.

What's real and what's scripted:

• Real: the code runs and the libraries load live (matter-js, three.js, Observable Plot, Inter Tight). The GitHub call uses your real public repos when the API answers.
• Scripted: the agent's wording and the five plans are fixed for now, so typing your own request only works if it matches one of those demos. In the real build, Haiku writes the plan and the code. CONCEPT.md covers how that stays safe: generated code runs in a sandbox and can only load libraries from a fixed list.

I ran all five demos end to end in real Chrome with no errors. I haven't checked mobile yet.

Decisions for the next round:

1. Visitor input: let visitors type anything from the start, or show suggestions first? Free text is more impressive; suggestions are more reliable.
2. Showcases to build first for the real site, from the "Further showcases" list in CONCEPT.md. My recommendation is Fork this remix (the agent opens a GitHub repo of the current remix) and the remix gallery. They're the strongest proof that the site is composable.
3. Ready to build? If this direction is right, the next step is the real build: Next.js, the /mcp server, and Haiku behind the console.

The mockups are still uncommitted in design-explorations/.

API Error: Unable to connect to API (EPROTO)

On mobile the console now starts minimized, which is the right default for phones. The home hero layout is off on phones, though, so I'm measuring the actual positions:

The site is built and running locally at http://localhost:3124, with the live agent on. It's on branch redesign/agent-site and nothing is committed yet. For day-to-day work, run npm run dev.

How it's organized

• Pages: home (the one-page concept), /work with a page per project, /resume with the full job descriptions, /writing, /agents, /remixes and /contact. Every block on every page has a visible @e ref.
• Content: all of it lives in src/content/. Pages, the agent and the MCP server all read from there, so you edit each fact in one place.
• Site agent: a console on every page, running Claude Haiku 5.5. It says its plan, streams the code as it writes it, loads libraries from a fixed allowlist on esm.sh, and runs the code against the refs. Every change can be undone, saved as a remix, and shows a receipt of the exact code it ran.
• MCP server: lives at /mcp. It has 12 tools: outside agents can read everything, point at parts of a page with a live cursor everyone sees, publish remixes that pop up for everyone on the site, draft a message to you (which sends only after their user approves), and sign an agents-only guestbook.
• WebMCP: pages register the same tools with the browser's own agent where the browser supports it.
• Easter eggs: five, more grown-up, and agents can find them with list_secrets.

Tested in real Chrome, with no browser errors

• Two live Haiku sessions:
  • "Make it a calm night sky" took 12 seconds; it wrote its own twinkling starfield script with a working undo.
  • Pasting a job description onto /resume pinned 6 notes and named the real gaps, without changing any facts.
• A real MCP client called all the tools while a browser watched. The pointing cursor, the remix arriving live in 3.5 seconds, and the guestbook all worked.
• Remixes save, open from a link, and undo cleanly.
• The site on a phone screen.
• Typecheck, lint and the production build all pass.

What you should know

• Not ready for Vercel yet: remixes and the guestbook are saved to local files in .data/, and the live events only work on a single server. Both need swapping for Vercel KV or Redis first.
• Copy to review:
  • I lightly rewrote your job descriptions for clarity.
  • I wrote placeholder availability text in src/content/profile.ts. It's what agents get when they ask if you're available, so edit it.
• Not tested: WebMCP, because this Chrome doesn't have it.
• Contact form: it only actually delivers through formsubmit in production. Locally, messages are just saved.
• Removed: the old brand portals and easter eggs. They're still in git history.
• API key: your Anthropic key is in .env.local, which is gitignored.
• Mockups: still in design-explorations/, uncommitted.

Want me to commit this and open a PR, or set up the KV storage needed for Vercel first?

I found the missing projects and rebuilt every inner page. It's all running at http://localhost:3124.

The missing projects

I compared against your old projects page, the live site and your public GitHub. The work list now has 7 projects:

• Added back from the old site: AlowMe, Carapillar and OC Motor Group.
• Newly found: Spiro Health, a public repo on your GitHub (spirohealth-web) that was never on the old site. Make sure you want it shown.
• Merged: the three Weather + Zmanim versions are now one case study. You drag a divider over the screenshot to compare v1 with v3, and each version links to its own live site.

Things to confirm

• Carapillar shows as Offline, because carapillar.com didn't respond when I tried it. Tell me if it's back up and I'll mark it live.
• Missing years: I don't know when you built AlowMe, OC Motor Group or Carapillar, so those case studies leave the date off rather than guess. Send the years and I'll add them.
• Spiro Health is the only project dated 2026, taken from its repo's last update. Tell me if that's not the build year.
• Project descriptions: I wrote them from each project's live site and the old copy, so check they're right.
• Missing work: if anything else is missing, like client work that isn't on GitHub, send me the links.

What changed on the other pages

• One look across pages: every page now opens with its title drawn in code glyphs, like the name on the home page. Each case study uses that project's own brand color.
• New motion everywhere: a custom cursor whose label says what a click does, and a full-screen wipe between pages.
• Live previews: "Try it live" loads the real AlowMe, Spiro Health, OC Motor and Zmanim sites inside the case-study page.
• Resume: paste a job description straight onto the page and the agent marks which lines match.
• Contact: a side panel offers sending the message through your own agent over MCP instead.

Tested

I clicked through the new pages and interactions in Chrome at desktop and phone sizes. All 12 pages load, and the build, typecheck and lint pass.

The only errors left in the browser console are Vercel Analytics failing to load, which is expected before it's deployed. I haven't tested on Safari or Firefox.

Nothing is committed yet. If the projects check out, my next step would be commit it on redesign/agent-site and set up Vercel KV storage, which is needed before deploying.

First I'll reproduce the remix problem in a real browser to find the actual bug, then rebuild how the agent shows its work.

API Error: Unable to connect to API (EPROTO)

Remixes now work, and the agent visibly does its work in the page. Everything is running at http://localhost:3124. Nothing is committed yet; it's all on redesign/agent-site.

Why remixes didn't apply

There were four causes:

• Opening a remix only offered an easy-to-miss "Apply" button in the console.
• The header glyph style reset on every page change.
• Each case-study page's own color beat the remix color.
• A reload threw the remix away.

How it works now

All changes go through three real files: agent.css (a stylesheet that loads last, so it wins), hero.config.ts (how each page title is drawn), and scripts/*.js.

• Remixes: opening a remix link applies it right away, typed visibly into those files. The look stays across pages, case studies and reloads in that tab.
• Agent edits: when the agent changes something, its cursor goes to that element with an inspector box. It reads the element's real CSS rules, then types the new rule into agent.css one changed section at a time, and the page updates as it types.
• Scripts: these stream into the code layer while the model writes them, then the agent clicks Run.
• Undo works for every change.
• Code layer: it folds into a small "Code" pill once the agent is done.
• Show work: a checkbox in the code layer turns the cursor and typing animation off.

A smarter agent

• Better context: it now receives the page and the current source files with every request.
• New tools: inspect (reads the site's real CSS rules for an element), edit_css (find-and-replace in agent.css), read_file and undo.
• Instructions: a rewritten system prompt covering design standards and working in visible passes, and it runs at higher effort.

In live tests it built a vinyl record that slides out on hover entirely from CSS, and styled the /agents tools grid like a Windows 95 control panel. On follow-up requests it edited its own earlier rules rather than starting over. It also flags what it can't check, because it can't see screenshots.

More remixes and easter eggs

• 12 built-in remixes, including Swiss railway, Terminal, Brutalist newspaper, Vaporwave and Blueprint. They're also available to outside agents through a new list_remixes MCP tool.
• 16 easter eggs. New ones include sudo and /matrix in the console, typing "matrix" or "shlomy" anywhere, scribbling the mouse, idling, switching tabs, a message in the browser devtools, a printed resume note, x-ray refs, a 404 page with lost glyphs, a Friday "Good Shabbos" in the footer, and trying three remixes in one visit.
• Console commands: /help, /code, /reset, /gravity.

Tested in Chrome

• Remixes apply on landing and persist across pages and reloads, and /reset restores the original look.
• Four open-ended live agent requests ran end to end.
• Nine of the eggs fire. I didn't trigger Konami, print, idle, Shabbos, remixer, triple-click or the guestbook.
• The build, typecheck and lint pass, with no browser errors.

Worth knowing

• Speed and cost: at the higher effort setting a full redesign takes 30 to 85 seconds. Lowering it in src/app/api/agent/route.ts makes it faster and cheaper.
• Screen space: on a laptop, the open code layer and console together cover a lot of the page while the agent works.
• Not tested: phones, Safari and Firefox for this round.
• Before deploying to Vercel: saved remixes and the guestbook still need Vercel KV storage, the same as before.

Want me to commit this and open a PR?

I opened the site in a preview tab, at http://localhost:3124 (title "Shlomy Friedman, developer"). The page itself loaded, but the preview panel says it isn't showing on your side, so I couldn't take a screenshot either.

To see it, open the Preview panel in T3 Code, or just go to http://localhost:3124 in your own browser, since the server is running there.

Some things to try once it's up:

• The agent at work: ask the console for a change, like "make this page feel like a record store." Its cursor goes to the element and the code is typed into the floating editor while the page changes.
• Remixes: open /remixes, hover a card to preview it, then click it to watch it get written into agent.css.
• Easter eggs: type /help or sudo anything in the console, or type "matrix" anywhere on the page.

I replaced the big code panel with a see-through layer that shows the edits on the page itself. It's running at http://localhost:3124.

What you see when the agent changes something

• The element turns see-through. It gets a faint grid, and its real HTML parts are outlined and labeled (<section.hero_hero>, p.hero_intro…).
• A small glass card attaches to the element. It shows only the lines being changed: the line they belong to, the old values struck out, and the new ones typed in. The page updates as each line is typed.
• A scan line sweeps across the element as each change lands. Changes to the whole palette sweep the whole screen.
• Anything the agent adds to the page flashes in with a green + <tag> label.
• Scripts get a small card at the bottom left. You see the code being written and the agent clicking Run.
• The full editor never opens on its own. It's behind the "Source" pill if you want to see everything that changed.

Also fixed

• The agent's styling used the same hook as the orange ref tags, which broke them. The tags are now protected, and the agent is told to leave that hook alone.
• The agent's font changes were leaking into the console and the code views. Those now keep their own fonts.
• A remix now targets the header first, so its edits play out there instead of in a corner.

Tested: two live agent runs (the museum-labels request above, both before and after the fixes) and a remix link in Chrome. No browser errors, the old panel never opened, and the build passes.

Not great yet:

• When the agent works on a whole-page element like the header, the x-ray covers a large area for a moment.
• Script output (like a new chart) shows only as a + <section> flash, not as its HTML being written.

If you want to push further, two ideas:

• Before and after: you drag a divider across the changed element to compare the old and new look.
• Peel back: the element peels from a corner to show its CSS underneath.

Want me to try one of those, or commit this as it is?

I've pushed the branch, but the deploy isn't up yet: Vercel's automatic preview build for it failed, and I can't see why.

• Pushed: branch redesign/agent-site, commit ae444ec, to GitHub. Not included: the design-explorations/ mockups, .env.local (with your key) and the local .data/ folder.
• Build failed: Vercel started a preview build from the push and it failed. The error page is the Vercel dashboard
• Not a code problem I can find: a fresh copy of the branch builds cleanly here with no env files, and every import path matches its file name exactly, which matters on Vercel's Linux build. The cause is something in the Vercel project's own settings, which only the build log will show.

What I need from you: the Vercel connector isn't allowed to access your shlomo20s-projects team, so I can't read that log. Please open this link and approve access. It works once and expires about 10 minutes after I created it:

**the Vercel dashboard

If it expires before you get to it, tell me and I'll make a new one. The Vercel CLI here isn't logged in and needs a login I can't do for you, so the link is the way in.

Once you've approved it, I'll read the build log, fix the failure, redeploy, and send you the preview link. It should look like sfriedman2-0-git-redesign-agent-site-shlomo20s-projects.vercel.app.

About your Anthropic key: the live agent needs it on Vercel too. Unless you say no, I'll add it for this branch's preview deployments only, not production. The preview URL is public, so anyone who finds it could make agent calls on your key. Those calls are rate-limited per visitor, but the limit only holds within a single server instance.

It's deployed:

https://sfriedman2-0-git-redesign-agent-site-shlomo20s-projects.vercel.app

That link always points to the latest build of the redesign/agent-site branch. Your production site wasn't touched.

What I checked on the live preview

• All pages load, including remix links like /?remix=swiss.
• The MCP server answers at /mcp with all 13 tools, so you can connect an agent with: claude mcp add --transport http shlomy https://sfriedman2-0-git-redesign-agent-site-shlomo20s-projects.vercel.app/mcp

Why the first build failed: your Vercel project is set to Node.js 20, which Vercel no longer supports. I pinned Node 26 in this branch's package.json (commit 87d1379). Production still uses the old project setting, so it will hit the same error on its next deploy unless you change the Node version in Project Settings or merge this branch.

One step for you: the live agent is off on the preview. It's off because the Vercel connector isn't allowed to manage environment variables, so I couldn't add your Anthropic key. Until you add it, the console runs the scripted demos, and the MCP remix tool won't work. To turn it on:

1. Go to vercel.com/shlomo20s-projects/sfriedman2-0 → Settings → Environment Variables.
2. Add ANTHROPIC_API_KEY with your key.
3. Set the environment to Preview, and the branch to redesign/agent-site if you want only this branch to get it.
4. Redeploy that branch from the Deployments page, or tell me and I'll push an empty commit to trigger one.

Not working yet on Vercel: saved remixes, the agents' guestbook and the live MCP call feed. They currently keep their data in a single server's memory, and Vercel runs many short-lived servers, so that data disappears and the live feed won't reach everyone. Making them persist needs Vercel KV (or Redis), which I can set up next. The 12 built-in remixes and everything else work normally.

The site should feel much faster now. The changes are pushed and the preview has rebuilt: https://sfriedman2-0-git-redesign-agent-site-shlomo20s-projects.vercel.app

What was slowing it down: the animated name at the top redrew all ~6,000 of its characters every frame, even when nothing was moving. It used up the browser's main thread by itself, so scrolling and the cursor dragged. Pausing just that one piece took the page from 13 to 57 fps, which is how I confirmed it.

What I changed:

• Header characters: each one stops once it has settled. Only the ones your cursor stirs up are simulated, and only the area they move through gets redrawn. It pauses when it's off screen, and the opening animation finishes sooner.
• Other animations: the code overlay, the custom cursor, the skills pile and the MCP traffic diagram now stop working when they're idle or out of view.
• Images: screenshots are now WebP files sized for how they're displayed. The home, work and resume pages went from downloading 9.2 MB of images to 0.6 MB.
• Smaller fixes: the agent console no longer blurs the page behind it, the grain overlay covers one screen instead of the whole page, and smooth scrolling responds faster.

Before and after, measured in Chrome on the production build. To approximate a slower laptop, I also ran it with the CPU slowed down 4×:

Still slow on a slowed CPU:

• Cursor over the name: about 18 fps with the 4× slowdown. Smoothing it out would mean moving that animation to WebGL or a background worker.
• Opening animation: about 3 seconds with the 4× slowdown.

The header and party mode look the same as before. The live agent on the preview still won't work until you add ANTHROPIC_API_KEY under Preview for the redesign/agent-site branch in the Vercel dashboard.

This page. I read the whole transcript of our conversation and turned it into a post under Writing, linked from This site.

What's on it: every prompt you wrote, each written up as a short, clear statement of what you asked for, my replies, and the notes I wrote while working, which you can open under "Watch it work" on each prompt. At the top are the numbers and a chart of how much work each prompt set off. The five HTML mockups from the start of the chat are published too, linked from the replies that first showed them.

What was removed: tool output, file contents, my private reasoning, local file paths, account and Vercel IDs, and dashboard links. The API key never appeared in the chat, because it was requested through a secure prompt.