Why Telling AI to "Make It Better" Fails onWebsites (and the 4 Guardrails That Made It Work)

Telling AI to "make it better" is lazy and often worthless. I recently built a free, guarded version of that loop and used it to redo my running coach's website, and it came out as good as several rounds of my own prompting.

What happened when Nate Herk told Claude to "make it better" 100 times

Nate Herk runs the AI Automation Society community, and he recently tested this exact idea on YouTube.

He gave two Claude models, Sonnet and Opus, an ugly coffee shop website and repeated the exact same prompt 100 times on each: "make it better."

Without guardrails, both loops went off the rails in predictable ways. When an AI is told to improve a project with no stop condition and no outside check, it equates "better" with "more." The stronger model, Opus, ended at 21,000 lines of code and broke its own working features under the weight of new sections, animations, and widgets. Neither model searched the web once to see what a good site in that category actually looks like.

I liked the core idea enough to build a version with guardrails, so you can improve a site's frontend without studying competitor sites for hours or rewriting your prompt over and over.

The 4 guardrails that keep an AI improvement loop from breaking your site

When I packaged the workflow into a reusable skill, I added four rules designed specifically to stop feature bloat, self-congratulation, and hallucinated business claims.

1. Make one change per round, and count deleting as progress

In an unguarded loop, the AI tries to redesign five sections at once so it can claim a big win. When one of those five changes breaks the mobile layout, you have no clean way to separate the good idea from the regression.

In our loop, the maker is restricted to one focused change per round aimed at the weakest score dimension. "No change" is explicitly allowed, and deleting clutter or repeated sections counts as progress. If a round fails to build (npm run build) or breaks a layout check at 320px, 375px, 768px, 1024px, or 1280px, the commit is discarded before it ever reaches the judges.

2. Use a separate judge panel plus Google Lighthouse

The AI making the edits never grades its own work. If the same model writes the code and scores the result, it will praise whatever it just added.

Instead, every version is rendered in a real headless browser across desktop and phone viewports and graded out of 100 by two independent checks:

• Google Lighthouse (30 points): Google's free automated checker scores speed (10 points), accessibility (10 points), and technical best practices (10 points).
• Three independent AI judges (70 points): A separate three-judge panel scores clarity (15 points), visual design (20 points), trust (10 points), conversion path (15 points), and mobile layout (10 points) against a real reference site in the same niche.

3. Ban made-up facts

Left alone, an AI trying to raise a site's "trust" or "conversion" score will invent customer testimonials, star ratings, membership prices, or practice schedules. That looks great in a demo and is unusable for a real business.

The skill enforces a strict fact boundary: the maker can surface real photos, credentials, and logos that already exist in the project repository, and it can delete placeholder text, but it is forbidden from inventing prices, locations, or reviews. When a missing business fact holds the score back, the loop records it as a question for the human owner instead of faking it.

4. Keep every version one click away on a local review page

I only asked for this fourth piece after my first run had already started, and it turned out to be the most useful part of the tool.

A small local review page displays the live site in a frame with a button for Pass 0 through Pass 5, a desktop-versus-phone toggle, the score breakdown, and a plain-English note on what changed and why. Instead of trusting the final round blindly, you can click through every version side by side in thirty seconds and pick the winner with your own eyes.

Testing 5 rounds on my running coach's website

I tested the guarded loop on my running coach's website, a 90-page site with five main pages (/, /about-us/, /ourteam/, /join-us/, and /contacts/).

The original site (Pass 0) scored 65.3 out of 100. Across five rounds, the scores ran:

• Pass 0 (Original): 65.3 (design 9/20, trust 5.5/10, mobile 4.5/10)
• Pass 1: 65.9 - fixed the mobile layout across the site in one commit so content filled the phone width with a 16px gutter instead of a narrow 280px column, and removed an empty homepage section.
• Pass 2: 72.2 - repaired the broken phone sections, turning a 22-photo team list into a two-column phone grid (cutting phone page height from 15,498px to 9,800px), removing a duplicate homepage section (11,352px down to 10,300px), and raising tiny phone text under 12px.
• Pass 3 (Winner): 74.2 - aimed at trust and visual design. Four real team and race photos in the hero had been sitting behind a dark overlay and an old 36% opacity rule. The loop stripped the dark overlay, placed the copy cleanly beside the photos on desktop and below them on phones, surfaced six named team faces from /ourteam/, and displayed the real sponsor logos.
• Pass 4: 73.7 - brought the coach's real credentials from the About page (over 50 marathons, World Master Championships representation, and two-time 800m semi-finalist) onto the home page and cleaned up conflicting reply-time promises on /contacts/.
• Pass 5: 73.2 - shortened 375px phone page heights (11,207px to 9,163px on home and 9,501px to 6,948px on /ourteam/) and converted the four hero photos to 960px WebP files on phones (27-69 KB instead of 176-314 KB).

Round 3 won. Rounds 4 and 5 scored a hair lower (73.7 and 73.2 versus 74.2), and differences under a point or two on a subjective rubric are noise. I picked Round 3 by clicking between the versions on the review page, which is why the visual comparison matters more than the raw number.

The run also stopped short of its target of 80 because of the auto-stop rule (the last two passes gained -0.5, below the 2.0-point minimum gain threshold). The judges kept asking for specifics only my coach knows, like an exact trial-run meeting spot, membership prices, and named runner testimonials. Because the guardrail banned made-up facts, the AI refused to invent those details - and I would much rather it stall at 74.2 and hand me a list of questions for my coach than write a fake review to hit 80.

How to run the free make-it-better skill on your own site

That is one test on one site, and I would not use this loop on backend code, database migrations, or complex business logic. Where it shines is tightening up a frontend or landing page when you do not want to spend hours studying competitor sites and tweaking prompts by hand.

I packaged the workflow as a free, MIT-licensed skill called make-it-better on GitHub. It works with Claude Code, Codex, Cursor, Windsurf, and Gemini CLI, runs 5 rounds by default (you can set any number), and includes the optional auto-stop for when gains flatten out.

If you just want a quick way to improve your site's frontend, give this a try and let me know what you come up with.