field notes
// field notes / build log

jazzelle@thehotpath ~/field-notes $ cat built-this-with-claude.mdx

i built this site with claude in one sitting

i built this site with claude in one sitting

2026-06-03 · 6 min

if you're reading this on thehotpath.dev, you're standing inside the build. that's the whole joke. this post is the field note for the site it lives on.

i built it by directing claude code. not "i asked an ai to make a website" the way a tweet means it. i mean i ran it like a production job: defined the floor, planned before building, shipped full-stack, and put a working agent inside the thing. the part people show is the pretty result. this is the part they don't.

// the long way around. as usual.

first move: i wrote down what i would never accept

before a single component, i wrote the refusals.

most people start a build by describing what they want. i start by describing what i won't tolerate. the CLAUDE.md, the file the agent reads first, opens with a no-list:

→ no tailwind default colors or radii
→ no lucide-react icon dump
→ no gradient hover states
→ no em dashes in any copy
→ lowercase headlines, one italic ember word, max

here's why that matters more than the wishlist. an agent will happily give you the average of everything it's ever seen, and the average is generic. the no-list is the taste. it's the part of my judgment i can hand to the model so every later decision inherits it. constraints first, vision second. the floor is what keeps the build from drifting into beige.

if you only take one thing from this post: the most useful thing you can tell an agent is what you refuse.

second move: plan before you let it touch anything

i didn't let it build. i made it plan.

plan mode first, every time. outline the file tree, name every component, flag anything ambiguous before a line of real code exists. it costs ten minutes and it buys you a build with no surprises in the first commit. the version of me that skips this ends up untangling three wrong assumptions at hour two. the version that doesn't, ships.

this is the boring discipline nobody films. it's also the difference between vibe coding as a punchline and vibe coding as a method.

third move: i put an agent inside the site

the part i'm actually proud of: there's an agent on this site. ask the path. you can ask it about my work and it answers, in this voice, and it will not lie to you.

that last part was the entire design problem. a portfolio agent that invents a project i never built is worse than no agent at all. so i didn't build a clever one. i built a grounded one.

the rules i gave it, in plain terms:

one source of truth, and if a fact isn't in it, the agent doesn't have it. no inventing numbers, no guessing dates, no hallucinated links. when it doesn't know, it says so, in voice, and points you somewhere real. i designed against one specific failure: confident wrongness. that's the failure that would actually cost me.

i also kept it narrow on purpose. it's not an open-ended tool-using system, because it didn't need to be; it's short, grounded question-and-answer. matching the shape of the thing to the size of the job is most of the work. the strongest move was the restraint, not the ambition.

and the voice is a spec, not a coat of paint. lowercase, dry, no em dashes; the agent has to satisfy the brand rules every single turn, same as the factual ones. how it says no is most of the product. ask it something off-topic and it'll tell you you're in the wrong terminal.

// it refuses in character. that took more iterations than the css.

the thing that broke

the first version of the agent made something up.

i asked it a softball about my work in testing and it confidently described a project that does not exist. it sounded great. it was fiction. that's the moment the whole feature could have died, because a lying portfolio is a liability with a nice font.

the fix wasn't a smarter model. it was a tighter cage: one explicit knowledge base, a hard rule against invention, and an honest fallback for "i don't know." the lesson stuck. building with agents isn't about how much you let them do. it's about how precisely you bound what they can't.

the scroll animation also tanked my lighthouse score on the first pass, because i animated the wrong property and the page started repainting on every frame. moved it to transform-only, gated it behind reduced-motion, and got the score back into the 90s. fast is a brand value here. a slow site that brags about engineering is just irony.

what this actually proves

you're not watching someone who can code. plenty of people can code.

you're watching someone who can direct. who knows that the refusals come before the features, that the plan comes before the build, that a grounded agent beats a clever one, and that the failure mode you design against matters more than the demo you show. the site is the resume. the build log is the proof. the agent is the closing argument.

i built it the long way around, on purpose. that's the only way i know that's mine.

ask the agent yourself. it's right there. it won't lie to you, and it won't pretend to like you either.

// the hot path
// the long way around

$

ask the agent yourself