I did not find AI most useful as a page generator.

I found it useful as a product engineer that could hold context across planning, design, content, implementation, debugging, deployment, and documentation.

Start with product shape, not pages

The useful question is not what pages the site has. It is what the site needs to hold, expose, explain, and preserve over time.

For this site, the shape became clearer once it had to work for several readers at once:

• people skimming quickly
• collaborators checking what is current
• agents retrieving public project and profile data
• search engines and social previews
• future me, editing without rebuilding the whole thing

That moved the work away from a flat website and toward a lightweight content system.

Create shared working memory

The fastest part of an AI-assisted build is also the riskiest part. The model can produce pages before the product has a shape.

The better pattern was to create working memory first: product direction, information architecture, design notes, implementation assumptions, deployment notes, and a session log.

Those documents were not ceremony. They let the work stay coherent as it moved between content, design, frontend implementation, production bugs, DNS, analytics, and Open Graph.

Structure the content underneath

The visible site can stay sparse, but the content underneath should be explicit.

That structure made the site easier to build and easier to explain. It also made later content review safer because project pages, indexes, API routes, metadata, and agent references all had a shared source of truth.

type ThoughtBlock =
  | { type: "text"; body: string }
  | { type: "image"; src: string; alt: string; caption?: string }
  | { type: "code"; language: string; code: string; caption?: string }
  | { type: "table"; rows: string[][] }
  | { type: "embed"; url: string; title: string };

Design as a system

Paper was useful because it preserved the visual direction outside the codebase. The implementation then became a process of matching the system, not copying a screenshot.

The important parts were not decorative. They were rules:

• sticky headers where scroll is possible
• left-side title panels on desktop
• compact rows rather than cards
• full-width media on mobile
• dark mode by default
• visible focus states
• agent references that do not block touch targets

PaperDesign artboards used to preserve visual direction and review responsive patterns.paper.design

Review loops create the quality

The first pass is rarely the final product. Most of the quality came from repeated loops: inspect, compare, adjust, rebuild, test, and commit.

Useful checks included:

• browser screenshots
• mobile interaction checks
• production builds
• runtime error fixes
• design audits
• content review
• DNS and Vercel deployment checks

Make deployment part of the product

Deployment was not cleanup. It shaped the implementation from the start.

The site needed environment variables, analytics, favicons, Open Graph images, robots, sitemap, stable API routes, and production asset paths. Treating those as product requirements prevented a local-only build from becoming the false finish line.

VercelProduction hosting, environment variables, previews, and domain wiring.vercel.com

Design for agents as readers

Websites are read by more than people. They are read by crawlers, social platforms, search engines, LLMs, and autonomous agents.

That does not mean the human site should become busy. It means the underlying structure should be stable and explicit.

Useful surfaces include `/llms.txt`, JSON endpoints, semantic HTML, concise summaries, structured metadata, and stable detail routes.

Capture the build while it is fresh

The session log became useful because it captured the awkward parts, not just the final decisions.

It preserved the content changes, design corrections, broken CSS moments, production build failures, image handling decisions, DNS setup, and deployment checks.

That log is now raw material for the next build and for this thought.