An AI wrote most of this website's code, infrastructure, and deployment. The LLM produced good code in hours instead of weeks, but only because two things were in place before and after it ran: a detailed plan going in, and enough engineering knowledge to catch what came out wrong.
The plan took longer than the build
"Write the plan first" undersells what "write" means here. The plan did not fit in one document, and it did not come together in an afternoon. It came out of a pipeline with five stages and four different models, and code did not show up until the fourth.
Seven or eight long conversations before any research began, working out what a site like this actually needs to prove, who it needs to convince, and what to go verify before assuming any of it. The output was a research brief, not a design.
The first two stages never produced anything for the site itself. They were about finding the right questions before answering them: what a site like this needs to prove, to whom, and what to verify before assuming any of it. Only once that framing held up did the questions turn into documents specific enough for a model to build from without guessing. The build was the fast part. Everything before it was not.
Structure in, detail out
Those documents ran past three thousand lines, longer than every article on this site put together. They held a defensive CSS checklist, a responsive-first mandate, a DRY and SOLID standard for every component, a content schema for every collection, and a full specification for the nebula background: its palette, its layers, its motion, and its response to the pointer. Behind them sat the documents that never reached the page: research into how a site like this earns trust, and a layout guide for every component, its states, its user flows, and the cases it had to survive.
I did not write most of that detail. I wrote the structure and named the sources. The nebula began as an order: a dense star field, then gaseous point clouds, then wisps, then young stars on top. The defensive CSS rules began as an address: read defensiveCSS.dev and fold it into the document. A refinement pass turned the order into an opacity band for every layer, and the address into a concrete checklist: min-width: 0 on every flex child, object-fit on every image, no fixed heights.
Structure is what turns a request into a spec. "Make a nice space background" gives a model nothing to build from, so it returns a stock particle cloud. A layer order gives it something to fill in. The work was knowing which decisions the plan had to settle, and where the authoritative answer already lived. The detail followed from that.
Those same documents were also the review standard. When the output drifted, I could hold it against a fixed reference instead of a hunch that something was off. Without them, there is no way to tell "different from what I imagined" apart from "wrong."
Know the failure classes
The model ships bugs. Engineers ship bugs too, so this is not a complaint. The point is who catches them. Every bug below surfaced on a phone screen, and each one took a single message to fix because I could name the cause instead of asking the model to guess.
The page scrolled sideways on mobile. The cause was a hidden layer shifted right by a transform. Invisible content still widens the page when it moves toward the right edge. That is a known class of CSS bug, and naming it turned a hunt into a one-line fix.
The fixed background jumped during scroll and snapped back. The mobile URL bar changes the viewport height mid-gesture, and anything sized to the dynamic viewport moves with it. Sizing the canvas to the largest viewport unit ended it.
Text refused to shrink inside flex rows until the columns got min-width: 0. Grid tracks needed minmax(0, 1fr) for the same reason. Defensive CSS is a checklist, and the model applies it well when told, but recognizing the symptom in a screenshot was my job. Here is that exact bug, alive:
min-width: auto (default)The URL cannot wrap, the child cannot shrink, and the row runs off the edge. The dashed border is the clip saving this page.
Tokens are the budget here. A model that has to discover a root cause by trial reads files, proposes theories, and burns a session. A model that is handed the root cause writes the fix. General knowledge is what makes the tool cheap.
Review everything
Every change went through the same pull request process a human contributor's would. A feature branch opened, the diff got read line by line the way I would read a coworker's PR, and only a reviewed diff merged. Deploys trigger off main and dev alone, so an unreviewed branch cannot reach production by accident.
That habit caught things a glance at the running site would have missed. A color palette that looked fine to my eyes failed a contrast check under review and got swapped for one that passed. A "fix" that solved the symptom in one component turned out to duplicate logic that already existed elsewhere in the codebase, and the review caught the duplication before it shipped. Treating the model's output as a draft, not an answer, is what the process is for.
Most of a website is not code
The build reaching "done" was the halfway mark. What followed was two days of short working sessions with the model, spent on the parts of a website that never show up in a screenshot.
The list from those two days: the title and description each page shows in a Google or Bing result. The card a link unfurls into on LinkedIn and Slack. Structured data that validated but carried datetime warnings in Google's testing tool. An accessibility pass. A navbar that wrapped to two rows on Chrome for Android and nowhere else. Dead scroll space under the footer that only existed on phones. Favicons and the web manifest. A Lighthouse score dragged down by the WebGL sky rendering on a CPU inside the test lab. Whether the site still reads when an AI agent browses it instead of a person. Cache policies per asset class at the CDN. Analytics to measure whether any of it works.
The model fixed each item in minutes once asked. Knowing what to ask was the work. No screenshot announces a missing timezone in structured data or an uncached asset. Each surface needed a name, its own checking tool, and the same review loop as the code.
The rule
Judgment in, quality out. That held at every stage of the pipeline, not only the one that wrote code. An AI coding tool multiplies the judgment you bring to it. Bring a plan it can follow, knowledge that names the bug, and a review bar it has to clear. The teams that get pace from these tools will be the ones that prepared for them.