Building an AI-Native Portfolio: A Case Study in Agentic Engineering

Plan, adversarially review, synthesize, implement, verify

Every non-trivial unit of work started as a plan, not a diff. Early on, that meant one planning pass. By the security-hardening phase, I was asking for parallel, multi-persona reviews: four separate security-focused agents running concurrently, each attacking a different surface — the API and Server Action attack surface; cookies, headers, and third-party scripts; dependencies and secrets; and forward-looking hardening requirements for endpoints that didn't exist yet.

I did the same thing later for a piece of writing, not just code: when I asked for the About and Resume page content, I asked for a content-writer persona and a separate interviewing-psychologist persona to land on an interview approach before either one touched a draft. Different domains, same structural instinct — get more than one expert angle before committing to an approach, then fold the findings back into a single plan rather than picking one opinion and discarding the rest.

The loop that ran the whole build, not just the security-hardening phase — sharpened over eighteen PRs rather than designed up front.

A verifier that didn't write the code

This is the load-bearing discipline in the whole process. The first PR that shipped — the Next.js rebuild itself — went out with a plain summary of what was built. I caught myself in that same summary admitting the implementer's own self-report wasn't enough. Working independently, a nested verifier agent found:

• A git-staging bug that would have silently committed the old middleware.ts while omitting the real file
• A PostHog call with no timeout that would have turned a slow third-party API into a full site outage
• An inverted honeypot field that blocked real form submissions instead of bots
• A hamburger button with no menu wired behind it

None of that showed up in a green test suite. From that point forward, every PR of any real size got its own independent verification pass — sometimes two, when the first surfaced enough real findings to warrant checking the fix itself.

PR-stacked review, not one giant diff

The very first PR into the rebuild landed as one large, interdependent commit — the Next.js migration, the theme pivot, and the security hardening were too entangled to split cleanly. I flagged that as a problem the moment it happened: I didn't want to review one 345-file diff — I wanted a stack of small, atomic, independently reviewable PRs on their own branches.

From PR #2 onward, that's exactly what shipped: eighteen PRs total, each scoped to one concern (content-derivation layer, REST endpoints, OpenAPI spec, discoverability, MCP server, About page, Resume page, and so on), sequenced by real dependency order, each with its own branch, its own implementer pass, and its own verifier pass.

Partway through, I made a deliberate call to let the build run autonomously through everything that didn't require a product or content decision from me — with one explicit boundary: surface anything ambiguous, fold small fixes into the PR you find them in, and file a follow-up issue rather than silently expanding scope for anything larger. That's exactly what happened with a CI flakiness bug discovered mid-build: filed as an issue, not patched in place, because chasing it down would have meant guessing at font-rendering nondeterminism between CI runner instances instead of doing the feature work in front of me.

I own my mistakes in the record, not around it

Partway through separating a bug fix from test-infrastructure work across two branches, I ran git checkout -- on four files, intending to discard an accidental carry-over — a command that destroys uncommitted work with no undo. It wiped out real, unrecovered-from-anywhere work: the Playwright configuration, a testing dependency, and documentation that had just been written.

I caught it by verifying the actual project structure in a test run rather than trusting my own memory of what should have been there, reconstructed what could be reconstructed from the parts that survived — the actual test files were untracked and unaffected — and re-verified the reconstruction end-to-end before committing anything on top of it. I'm including that here rather than glossing over it because it's the same discipline the rest of the process runs on: verify against the real state of the system, not against what you assume happened.

A dedicated interview process for content only I could supply

Code has patterns to copy and objective criteria — tests pass, types check, axe reports clean. Career narrative doesn't. For the About and Resume pages, I asked for something closer to a structured interview than a content-generation task: one open-ended prompt designed to avoid résumé-recitation mode, follow-up questions mined from what I actually said rather than a pre-built list, and — critically — genuine pushback when a draft overstated something.

When I proposed "technical and product leadership" as a description of my own work, that got challenged directly: the evidence I'd given supported technical and design ownership, not roadmap or prioritization authority, and the honest recommendation was to not make the stronger claim just because it sounded better. I agreed and cut it. The published About page went through roughly a dozen rounds of exactly this kind of back-and-forth — phrasing, claims, ordering, one clause at a time — because it's the one part of the site where "good enough" isn't a technical question, it's a question of whether it actually sounds like me.

Next.js 16, App Router, next-yak, TypeScript

The legacy site was Express and Gulp — no component model, no type safety, nothing that would age well or move fast. Next.js 16's App Router gives Server Components by default, which matters a lot for a multi-theme site (more on that below), since it means a visitor's browser only ever downloads the code for the theme they're actually looking at. For styling, I passed on Tailwind v4 in favor of next-yak — zero-runtime, styled.div template-literal components that work natively in Server Components without forcing a "use client" boundary just to style something. That choice came directly out of prior experience: I'd used Emotion's styled-components pattern professionally, and I wanted the same authoring ergonomics without paying a client-side runtime tax on every themed component — a cost that matters more here than in a typical app, given there are three complete visual systems to ship.

Three real themes, not a random A/B assignment

The project went through a real pivot here worth walking through, because the reasoning behind it changed the whole shape of the site. The original plan was to build three visual directions — terminal (dark, monospace, hacker-toned), editorial (warm, serif, agency-grade), and circuit (dark slate with an SVG circuit motif built off my logo) — as competing variants in a PostHog A/B/C experiment, and let real visitor behavior pick the eventual winner.

TerminalEditorialCircuit

I liked all three enough that I didn't want to wait for that data, or throw away two-thirds of the design work. Instead, all three ship simultaneously, permanently, behind a persistent switcher in the header — closer to the multi-brand theming problem I'd solved before (supporting distinct brand skins for HBO, Cinemax, TNT, and other properties on a shared platform) than to a conversion experiment.

A visitor without a preference gets a fixed default (terminal) rather than a random assignment, so the choice doesn't get logged as if it were a signal and so search engines see one consistent page rather than a moving target. That same consistency requirement is why the theme lives in a cookie read server-side, not in client-side state or localStorage: the server renders only the matching theme's component tree, so there's exactly one canonical page per visitor, not three competing for indexing priority.

Security hardening as a dedicated, adversarial phase, not a checklist

I asked for a security review run as if by "a superlative staff security engineer," fanned out across four parallel review angles, because I wanted every file and every API call evaluated, not just the obvious ones. The findings were real, not theoretical:

• Zero HTTP security headers existed anywhere on the site, meaning clickjacking was actually possible, not just a missing best practice
• Cookies were missing secure and httpOnly attributes for no defensible reason
• The analytics integration initialized itself and wrote a persistence cookie before a visitor had answered the consent banner — quietly undercutting the banner's own claim that nothing gets tracked until you opt in

Fixing that last one took two attempts: the first fix broke the ability for a returning visitor who'd already consented to re-opt-in, caught by a follow-up verification pass before it ever shipped.

The rate limiter also got rebuilt from the ground up — the original implementation had:

• A spoofable IP key
• Unbounded memory growth
• A body-size cap that trusted a spoofable header

The rebuild shares one bucket between the web contact form and the not-yet-built MCP contact tool, deliberately closing off a "hit both paths to double your rate" gap before that second path even existed.

Some risk was accepted rather than engineered away: full IP-spoofing resistance needs an edge/platform-level solution that's out of proportion to a portfolio site's actual traffic, and the CSP still allows 'unsafe-inline' for scripts because React Server Component hydration has no nonce plumbing to attach a stricter policy to yet — both documented as conscious tradeoffs, not oversights.

A discoverability layer built for both search engines and language models

This is the part of the site that most directly answers the original "agent-ready portfolio" premise. robots.txt takes a deliberate, asymmetric stance: allow every named crawler, including AI training crawlers. The reasoning: the site's whole purpose is to be read and cited by agents, all of its content is already public elsewhere, and allowing a citation crawler is fully reversible while allowing a training crawler is not — a tradeoff worth naming rather than defaulting into either direction silently.

sitemap.xml lists only real, indexable pages, deliberately excluding the machine-readable JSON/text endpoints, which are discoverable through their own channel: llms.txt, a plain-text summary of the site written for both a human skimming it and a model ingesting it, following the community llms.txt convention. JSON-LD structured data is embedded per-page, not globally, so a ProfilePage schema node describes the actual page it's attached to rather than making an inaccurate blanket claim from the root layout.

A validated OpenAPI 3.1 spec and a real MCP server, not a gesture at either

Four static JSON/text endpoints (/resume.json, /resume.txt, /projects.json, /services.json) expose the same content the site renders from, generated once at build time and served with open CORS and long cache lifetimes, since they change only on redeploy. /openapi.json is generated from the same Zod schemas those endpoints validate against, and a test strictly parses each route's live response against the schema its spec claims describes it — so if the document and the actual endpoint ever drift apart, that's a test failure, not a silent gap discovered by an integrator later. The path list is a hand-written allowlist, not a filesystem scan — a structural choice, not an oversight: it means the contact form's endpoint cannot appear in the published spec by construction, because nothing ever walks the routes directory to find it. This case study's own markdown twin is a fifth static endpoint generated from the same content module, but it's plain markdown rather than JSON, so it sits outside the Zod-validated spec above rather than adding a fifth entry to it.

The MCP server was the highest-risk, highest-effort piece of the entire rebuild, for a reason that has nothing to do with the code itself: the protocol had a breaking rewrite in mid-2026 — the session model and initialize handshake were removed entirely in favor of a stateless design — while I was actively building against it. Research surfaced that shift partway through planning, which is why the agent-facing interface leads with a documented REST/OpenAPI surface, with MCP layered on top rather than serving as the whole strategy.

Building it required correcting factual errors in my own research along the way — an error-code range that turned out to be backwards, and header enforcement that was actually strict where I'd assumed it was lenient — and, more usefully, an actual live connection from a real MCP client, which is what surfaced a required server/discover method that was missing entirely and would never have shown up in a unit test.

The finished server exposes five read-only tools over Streamable HTTP with its own rate-limit bucket, a 50,000-byte body cap, and unauthenticated access — deliberately read-only, since a write-capable tool would need a CORS and security review of its own before it could ship, and that work was consciously deferred rather than rushed into the same PR.

Testing strategy: correctness, visual truth, and accessibility as three separate guarantees

• Unit tests (Vitest) cover the theme-assignment logic, the discoverability nudge's dismissal state, the contact form's validation schema, and the content model itself.
• Playwright e2e tests exercise real user flows across all three themes: the switcher persisting across a hard refresh, the mobile popover's keyboard behavior, full contact-form submissions, and every real navigation link.
• Visual regression testing runs only in CI, against Ubuntu runners, because font rendering differs enough from local macOS development that a locally generated baseline would never match what CI produces — baselines are committed to the repo and only ever regenerated by a dedicated CI workflow, never by hand locally.
• Accessibility testing runs axe-core against every page/theme combination, with one deliberate departure from the tool's defaults: axe treats an exact 1:1 foreground/background contrast ratio as "needs human review" rather than a hard violation, on the theory that identical colors might occasionally be intentional.

There's no legitimate design where that's true for real content text, so the suite treats that specific case as blocking. That override is exactly what caught a real, ship-blocking bug: a CSS specificity conflict left every theme's primary call-to-action button hard to read, and in one theme its text was the literal same color as its own background — invisible, and something a default-configured axe run would have passed clean.

A/B/C testing, rejected in favor of permanent multi-theme

Shipping all three themes at once instead of A/B-testing them (see Architecture, above) meant giving up a data-driven, unambiguous "this design converts better" answer, in exchange for a feature — a persistent, switchable multi-theme site — that's more interesting and more representative of the real multi-brand work I'd actually shipped before. I think this was the right call: an A/B test would have optimized for a single metric on a portfolio site where the actual goal is closer to demonstrating range than maximizing one conversion number.

In-memory rate limiting, accepted rather than engineered around

Vercel's serverless model means an in-app rate limiter's state resets across cold starts and doesn't share state across instances — a real limitation for a portfolio site's traffic level, not a hidden one. Rather than build a distributed store (Redis, Upstash, or similar) to close that gap for a site that doesn't need it yet, the accepted mitigation is a single, free Vercel WAF dashboard rule, config over code, layered on top of the in-app limiter as defense in depth. That's a case where the more "complete" engineering solution would have been actively the wrong call — added complexity and an external dependency to solve a problem the traffic level doesn't actually create.

The theme-switcher popover, iterated through three real options before shipping

A late round of feedback flagged that logo, hamburger menu, and full theme dropdown all crammed into one mobile header row read as cluttered and non-standard. Rather than pick a fix by instinct, the response was three actual working prototypes at real viewport widths:

The third option shipped, and building it surfaced real bugs no amount of code review would have found on paper — a Shift+Tab focus trap leaving a phantom open panel behind, and a keyboard path that bypassed a pending-state guard — both caught by testing the actual interaction live rather than reasoning about the ARIA pattern in the abstract.

Cutting a case study rather than describing proprietary work directly

The constraint itself — two substantive recent projects locked behind a former employer's proprietary, active-development repositories — is described in Context & goals, above. What's worth walking through here is what it produced. The centerpiece is an agentic rewrite of a legal-eligibility questionnaire, architected so the agent is structurally prevented from ever hallucinating a legal outcome, with every result tool-derived and every reasoning step persisted for audit. It started as a take-home technical exercise for a company I was interviewing with at the time. I later generalized its framing on both GitHub and the site itself, so it reads as a standalone showcase project rather than revealing which company's process it came from, and built a live, publicly clickable demo of it rather than leaving it as a repository people have to run themselves.

Cutting a personal, vulnerable About-page narrative in favor of a credibility-first one

The first full draft of the About page ran long and personal: a full origin story, an admission of self-doubt across nearly every job, a specific "here's a mistake I made and cleaned up" anecdote. My own reaction was that it was too long and too personal for a public page — I wanted people to be able to scan the highlights, not read a novel.

Dedicated research into how other AI-native consultants and freelancers actually position themselves publicly confirmed the instinct: lead with credibility and capability, not origin story; render career history as a scannable timeline, not narrative prose. And a genuine surprise in that research — the adversarial-review discipline that first draft treated as a minor process detail turned out to be exactly the kind of specific, checkable rigor that reads as a real differentiator in this space, while a generic self-doubt narrative was consistently absent from every credible example I found. The self-doubt material got cut entirely; the review-process material got promoted to a named principle instead.