Building a Portfolio Web App: Agents, HITL, and 99 RES

Most portfolios are templates with content dropped in. Mine used to be too. A static site that worked fine until it didn't. When I started working seriously with AI agents, I needed something malleable. A real web app with structure, routing, typed data models, and a codebase an agent could navigate without getting lost.

So I rebuilt it. Properly.

The rebuild: what changed

The old site was presentable but rigid. Every change was fiddly. Adding a new case study meant touching multiple files by hand, keeping formats in sync across different sections, hoping nothing broke. It wasn't something I could delegate to an agent or iterate on quickly.

The new site is a Next.js app with typed data layers, MDX content pipelines, a design system (MDS), and enough structure that I can describe a change to Claude Code and have it land cleanly. Often on the first pass.

That structure is what makes the HITL loop work. I'm the Human In The Loop: I set direction, review decisions, redirect when the model drifts. The agent does the construction. The separation of concerns is deliberate.

The 80/20 pattern in practice

Working this way, I hit a wall at the same place every time.

The first 80% of a feature moves fast. The agent reads the codebase, matches existing patterns, wires things together. Efficient. Work that might take a few hours to spec, scaffold, and implement drops to under an hour. Sometimes much less.

Then I hit the 20%. The visual tweaks, the edge cases, the copy that needs to sound like me and not a competent generalist. These take the other 80% of the calendar time. Not because the agent can't help (it can), but because the refinement work is inherently iterative. I'm narrowing in on a specific outcome, which requires short feedback loops and judgment I can't fully delegate.

This isn't a criticism. It's the honest shape of the collaboration. The 80% I get back on construction is real. The 20% is just what craft looks like.

Owning the performance

Hosted portfolio platforms make the performance choices for you. You get whatever rendering strategy they decided on, their asset pipeline, their JS budget, their font loading approach. If it's slow, that's the trade-off for convenience.

Owning your stack means making different choices. Aggressive static generation. next/image for every image. next/font for zero layout shift on typography. Code splitting that actually reflects how people navigate the site. No third-party scripts that block rendering.

I added Vercel Speed Insights after the initial build. Real field data, not synthetic lab scores. The insight is different when it's measuring actual visitors.

The results

The overall Real Experience Score sits at 99 on desktop. P75: more than 75% of visits had a great experience. The headline metrics:

Home, work entries, and individual studio posts all score 100. Contact hits 99. The content-heavy routes need more work: /studio (87), /about/resume (86), /approach articles (70). That last one is next.

The number that matters isn't the score. It's that performance is measurable, owned, and improvable, not something that just happens to the site.

What the site is now

It's a portfolio that's also a product. Versioned, tested, monitored. I run agent sessions against it regularly: adding range entries, shipping posts like this one, iterating on components. I make every decision, but I'm not doing the mechanical work.

A Squarespace template can't give you that. Neither can AI assistance alone. It takes both: an agent that builds and an owner who decides.

That's the portfolio I wanted to build.