← Field Notes
Published Last updated 5 min read

Cleaning Up an AI-Generated Site

What it took to turn an AI-assisted Astro starter into a site I understood, trusted, and could maintain.

In this article
  1. The first version solved the wrong problem
  2. AI can write code faster than I can evaluate it
  3. Cleanup happened through small commits
  4. Some mistakes appeared only after deployment
  5. Design cleanup mattered too
  6. What I use AI for
  7. The standard is not “written without AI”
  8. Key takeaways
  9. What I would do differently
  10. AI transparency

Field Notes did not begin as a handcrafted website built one line at a time.

It began with an Astro starter, AI assistance, and a clear goal: get something working, then make it mine.

That approach was useful, but it came with a responsibility that is easy to skip.

Generated code is not finished code.

It still has to be read, tested, corrected, and understood by the person who intends to maintain it.

The first version solved the wrong problem

The first version proved that the site could exist.

It had pages, articles, a header, a footer, and a deployment path. That was enough to move the project out of planning.

It also carried the usual signs of a starter and generated implementation:

  • Generic copy
  • Placeholder branding
  • Features added without a consistent system
  • Duplicate labels and headings
  • Configuration values left at defaults
  • Components that worked but did not fit the actual site

The site was functional before it was coherent.

That is not necessarily a failure. A rough working version can be easier to improve than a perfect design that never gets published. The mistake would have been treating the first output as complete.

AI can write code faster than I can evaluate it

This is where the risk appears.

AI can generate an entire component in seconds. Understanding how that component interacts with the rest of a project takes longer.

A generated change may look convincing while making a bad assumption about:

  • The current framework version
  • The content schema
  • The deployment environment
  • Existing CSS variables
  • Mobile behavior
  • Accessibility
  • Whether a referenced file or environment variable exists

The code does not know whether it belongs in the project. It only knows whether it resembles a plausible answer.

Speed on the generation side has to be balanced by patience on the review side.

Cleanup happened through small commits

I did not replace the entire site in one rewrite.

I worked through it in small, visible changes. The temporary logo was replaced with the actual Eldritch IT asset. The homepage was restructured around published content. The article layout gained categories, tags, reading time, series navigation, related posts, a table of contents, and ad space that moves into the article flow on smaller screens.

I also added pieces that are easy to overlook when the focus is visual:

  • Privacy and terms pages
  • An editorial policy
  • AdSense verification and ads.txt
  • Canonical URLs and a real sitemap domain
  • RSS discovery
  • A custom 404 page
  • Keyboard navigation and visible focus indicators
  • Reduced-motion support

Each change removed another assumption inherited from the template or generated code.

That process depended on the more deliberate Astro build workflow that grew around the site.

Some mistakes appeared only after deployment

A locally convincing implementation is not the same as a successful production build.

When topic pages were added, Cloudflare failed during prerendering because slugify was not defined inside the route’s getStaticPaths() execution. The file looked reasonable, but the bundling context exposed the mistake.

Another issue was less dramatic but more damaging to search engines: Astro’s site setting still pointed to https://example.com. The pages loaded, but canonical URLs and the sitemap would have advertised the wrong domain.

Those are exactly the kinds of problems polished-looking output can hide. The fix was not to stop using AI. The fix was to test the result against the actual environment and use Cloudflare’s build logs as evidence.

Design cleanup mattered too

Generated design often tries too hard.

It adds labels, repeated explanations, decorative blocks, and copy that announces how honest or useful a site is instead of simply being honest and useful.

I removed a lot of that.

The publication did not need a separate fantasy-style sigil when Eldritch IT already had a logo. It did not need a boxed “Business site” button when a normal link communicated the same thing. It did not need repeated layout-level claims that every article was real.

The strongest version was usually the one with fewer layers between the reader and the writing.

What I use AI for

AI has been useful for:

  • Drafting and revising components
  • Explaining unfamiliar Astro behavior
  • Spotting likely causes in build logs
  • Generating repetitive metadata structures
  • Editing articles for clarity
  • Exploring layout options quickly

What it does not replace is ownership.

I still have to decide whether a feature belongs, whether the copy sounds like me, whether the implementation is maintainable, and whether the final result works.

If I cannot explain a piece of code well enough to troubleshoot it later, it is not ready just because it compiled once.

The standard is not “written without AI”

The standard I care about is whether the result is accurate, reviewed, and supportable.

A manually written site can still be careless. An AI-assisted site can still be thoughtful. The difference is the review process.

For Field Notes, generated work should survive four questions:

  1. Does it solve a real problem?
  2. Does it fit the existing structure and branding?
  3. Can I explain how it works?
  4. Has it been tested where it will run?

If any answer is no, the work is not finished.

Key takeaways

  • Generated output is a starting point that still needs technical and editorial ownership.
  • Small, focused commits make assumptions easier to find and reverse.
  • Production builds expose framework and configuration problems that visual review can miss.
  • Removing unnecessary generated design can be as important as adding features.

What I would do differently

I would establish the review standard before generating the first large batch of changes.

That means defining the content schema, naming conventions, accessibility expectations, deployment check, and visual system first. AI could then work inside known boundaries instead of inventing a new pattern for each request.

I would also stop stacking new features on code I had not yet read. Fast generation feels like momentum, but unreviewed layers only make the eventual cleanup harder.

AI transparency

AI played a significant role in the site’s initial implementation and continues to assist with code, troubleshooting, and editing. I reviewed the changes described here, corrected failed builds and design problems, and made the final decisions about what remained in the site.

JO

Written by

Jessie Owens

I run Eldritch IT and write about the systems, repairs, infrastructure decisions, and business lessons behind the work.