Building a real portfolio with AI as a co-pilot (not a replacement)

I keep getting the same question in different clothes: could you have built diwakarrai.com without AI? And the follow-up people really mean: so AI did it for you?

Short answer: yes, I could have. No, AI did not “do it for me.”

What AI changed is the cost of the boring middle: the glue, the second draft of a schema, the “why is this metadata doubled” afternoon. What it did not change is product judgment. If you don’t know what you’re building, AI will happily build the wrong thing at impressive speed.

What “the site” actually is

This isn’t a three-page static resume. It’s a small product:

• Next.js App Router, typed end to end
• Payload CMS with drafts/publish
• Postgres (Neon in prod)
• Media on R2
• Deploy on Vercel
• contact hardening, search, admin 2FA, sitemap/robots, the unglamorous stuff

The point of the portfolio, for me, is that the way it’s built is part of the artifact. A pretty homepage with no CMS, no backups, and mystery env vars isn’t the story I want to tell.

How long would this take by hand?

Honest ranges, assuming evenings and weekends (~8–12 focused hours a week), and assuming you already know web work and you’re learning the stack as you go: for (Static IA + design tokens + first pages, React/Next fluency + App Router habits, Postgres + CMS model + admin that doesn’t leak drafts, Media, DNS, prod deploy, restore drill, Spam/auth/SEO polish, search, the last 20%) ~6-12 months as supposed to ~1- 3 months with AI as a copilot.

Those aren’t sales numbers. I’m not counting “I pasted a prompt and got a demo.” I’m counting something you can restore from a dump, publish without redeploying HTML by hand, and not be ashamed of under a recruiter’s phone network.

AI doesn’t delete learning. It compresses the time between “I understand the checkpoint” and “the PR exists.” If you skip the checkpoint, you just get a faster way to accumulate debt.

The methodology that kept it from becoming mush

The useful part wasn’t a magic model. It was process I already trust from delivery work, applied to a personal site:

1. Write the truth down first. Product, requirements, architecture, delivery not a chat thread. Chat is temporary. Docs are the source of truth.
2. Scope fence. v1 is a finite sitemap. Phase 2 is a queue, one item at a time. “While we’re here, add Three.js” is how portfolios die.
3. Acceptance before generation. I write the goal, non-goals, and how I’ll verify. Then I ask AI for a slice, not “build my whole site.”
4. I review like a senior. Security, a11y, empty states, CLS, draft leaks, doubled og:image URLs. If I can’t tell the answer is wrong, I’m not ready to use AI on that layer yet.
5. Teach-back. After something lands, I should be able to explain it without opening the chat. If I can’t, I didn’t learn it; I rented it for a night.

I even wrote myself a topic-by-topic learning roadmap for this stack (HTML → CSS → JS → TypeScript → React → Tailwind → Next → Postgres → Payload → ship/ops). Not because I pretend I started from zero, but because I don’t want the next feature to be “mystery code I can’t maintain.”

Where AI actually helped

Concrete, not poetic:

• Scaffolding repetitive UI once the token system existed
• Turning a clear FR into a first Server Action + Zod shape
• Explaining a confusing Next/Payload boundary when I was stuck
• Drafting tests around pure helpers
• Rubber-ducking incidents (pg_dump version mismatch against Neon 18 is a fun one)

And where it wasted time when I was sloppy:

• Inventing vendors and routes I never asked for
• Looking confident while being subtly wrong about caching/revalidate
• Producing “nice” UI that fails on a 375px phone or ignores prefers-reduced-motion

The failure mode isn’t drama. It’s quiet. You ship something that demos well, and you don’t own.

Manual vs AI isn’t the real comparison

The real comparison is:

Unscoped AI → weekend demo, unclear ownership, hard to extend
 Manual, disciplined → slower, but you understand every seam
 Disciplined + AI → same seams, less calendar time, still your judgment on the gate

I care about the third one. That’s the version that matches how I already think about platforms: constraints first, then acceleration.

If you’re going to try this

A blunt checklist:

• Decide the sitemap and the non-goals before you open a chat
• Keep requirements in a file you own
• One compounding change at a time
• Verify with evidence (browser, View Source, Network, a restore drill)
• Don’t ask AI for architecture you can’t diagram on a whiteboard afterward

AI is a force multiplier for people who can specify and reject. For everyone else it’s a content farm with TypeScript.

I built a library I can operate: backups, CMS, media, deploy, and I used AI to move through the middle faster. The taste, the scope, and the “no, we’re not adding that” calls were still mine. That’s the part I’m willing to put my name on.

The paperwork that saved the build

People romanticize “just talking to the AI.” That falls apart the second the chat forgets what Phase 2 means, or invents a Status page you already cancelled.

I treated the repo like a delivery workspace, not a scratchpad. The AI only gets power inside those rails.

Guardrails (agents read these first)

• AIRULE.md : hard don’ts: no inventing features, no Phase 2 bundling, no alternate stack “while we’re here.”
• STATE.md : what is true right now (live URL, what’s shipped, what’s waiting on me).
• TODO.md : the only queue that matters; one compounding item at a time.

If those three disagree with a chat suggestion, the files win. Chat is not the archive.

Product truth (docs/)

• docs/01-product.md : why it exists, personas, v1 vs later
• docs/02-requirements.md : FRs/NFRs with IDs you can test
• docs/03-architecture.md : routes, ADRs, contracts
• docs/04-delivery.md : sprints, DoD, how we call something done
• docs/README.md : map of the above so nobody “starts coding from vibes”

How to build the accepted piece

• The build runbook (HTML) — commands, schema notes, tokens, deploy steps for in-scope work only
• mockups/ : desktop + mobile so UI arguments end with a picture, not a preference spiral

After it shipped (so future-me isn’t archaeology)

• docs/handbook/ : as-built snapshot: what actually went live, flows, file catalog
• docs/learning-roadmap.html : topic-by-topic path through the stack, with AI as multiplier after checkpoints
• diwakarrai-v1-from-scratch.html : the process chronicle from SoT → sprints → deploy

None of that is bureaucracy for its own sake. It’s how you keep a co-pilot from becoming a second product manager with amnesia. I write the brief into those files; AI implements a slice; I verify against the same IDs and mockups. When something drifts, we update STATE.md and TODO.md : we don’t negotiate with the last chat turn.

That packaging is also the portfolio. Anyone can generate a nice page. Fewer people leave a trail that shows how they decide, constrain, and finish.

I’m not anti-AI, and I’m not selling a fantasy where models replace craft. Good software still needs someone who can define the job, draw the boundary, and refuse the shiny wrong turn, and who writes that down in AIRULE.md, STATE.md, TODO.md, and the docs/ set before the first fancy prompt.

Without that, AI makes you prolific. With it, AI makes you faster at shipping something you can still explain six months later, including the restore notes, the handbook, and the awkward OG bug you fixed at midnight.

That’s the bar for this site. If a tool helps me clear it sooner, I’ll use it. If it asks me to skip the bar, I’ll close the chat and update the SoT myself.