Skip to content

Next.js · Gemini API · TypeScript · Vercel · 2026

This Site

A portfolio that doubles as a live AI playground.

Product owner & AI-guided delivery lead

Live
working in-browser AI demos
Server-side
model credentials stay out of client code

Sanitized implementation diagram

Diagram · implementation view

Protected structured-output request path

A simplified architecture view of the text analyzer demo.

  1. Request

    Validate a bounded prompt in the browser UI.

  2. Server guardrails

    Gate the server route with shared or fallback rate limits. Call Gemini only from the server-side integration seam.

  3. Structured output

    Validate typed model output before the analyzer renders it.

Sanitized architecture diagram. This view covers the structured-output analyzer path; streaming chat follows a separate response path.

My contribution
Positioning, UX direction, security requirements, and AI review
Hard constraint
A public demo must protect credentials and quota
What changed
Visitors can test working AI patterns directly

Most portfolios describe AI work. This one lets you use it. Alongside the project write-ups, the site runs two live LLM demos in the browser: a streaming chat and a structured-output text analyzer. Both call the model through server-side routes that keep credentials out of client code and apply rate limits to constrain abuse and quota exposure.

Outcomes

  • Two live, working AI demos visitors can run directly.
  • Model credentials kept server-side, with rate limiting on every demo route to reduce abuse and quota risk.
  • A strict, typed, accessible front end that demonstrates the standard I require from AI-generated work.

Evidence & claim boundaries

Security evidence
This repository architecture keeps model configuration server-only and tests both route validation and rate-limit behavior.
Human and AI roles
I guided Claude and Codex by defining requirements and acceptance criteria, directing iterations, reviewing results, and deciding what was ready to release.
Rate-limit boundary
Every demo route applies a limit, but shared enforcement across serverless instances depends on Upstash configuration; the documented fallback is instance-local.
Demo scope
The demos prove two bounded integration patterns and their failure handling; each remains intentionally small in scope.

Problem

Claims about AI-guided work are easier to evaluate when visitors can try the result. I required the public demos to protect the API key and constrain quota use, then reviewed the AI-generated implementation against those requirements.

Delivered scope

A streaming Gemini chat that renders the response token by token, so the interface visibly progresses while the model responds.

A text analyzer that returns typed, structured JSON using structured-output mode, giving the UI validated data it can render reliably.

Serverless route handlers that keep the API key server-side, with rate limiting on both demos.

Key decisions & trade-offs

Server-side route handlers keep model calls behind a protected server boundary. Direct browser calls are faster to build, but they expose the key and quota. Routing through serverless functions cost a little more plumbing and established the right credential boundary for a public demo.

Structured-output mode over free-text parsing. Asking for typed JSON constrains what the demo can show, but it lets the server reject malformed model output before the UI attempts to render it.

Try the AI integration lab

Technology Next.js · React 19 · TypeScript · Google Gemini · Vercel

Scope UX direction · AI-guided web delivery · Release review