I Fixed the Same Bug Eight Times. Then I Realized I Was Fixing the Wrong Problem.

I fixed the same problem eight times.

Not eight similar bugs. The same bad assumption, showing up in different parts of the product.

The first few times, I treated each one as a separate bug. I found the problem, asked AI to fix it, checked the result, and moved on.

Then it happened again.

And again.

By the eighth time, it was pretty obvious that the individual fixes weren't the real problem.

The AI was doing exactly what I asked. What it didn't have was the context behind all the previous decisions.

Vibe coding makes fixing things almost too easy

I'm a product and UX designer, not a software engineer.

I've spent more than 15 years designing interfaces, so I usually know when something feels wrong and I have a pretty good idea why. What changed with AI coding tools was my ability to do something about it myself.

I could find an issue, describe it, paste a prompt into an AI coding tool, and see the fix running minutes later.

That still feels a little ridiculous.

But speed introduced a problem I didn't expect.

When a fix takes five minutes, you don't spend much time thinking about what that fix needs to teach the rest of the product.

You fix it and keep moving.

That works surprisingly well at first.

Then the site gets bigger.

The bug wasn't in the code anymore

Imagine I find a CTA that is too easy to miss.

I fix the contrast and hierarchy. It looks better. Problem solved.

A week later, I add another page. The AI generates a CTA using the old pattern.

So I fix that one too.

Later, another component gets changed and the weak CTA comes back somewhere else.

From the AI's point of view, none of this is particularly strange. Each request is a new task with the context available at that moment.

From my point of view, however, we'd already made this decision.

That's where I started seeing the difference between a fix and a rule.

A fix says:

Make this button easier to notice.

A rule says:

Primary conversion actions on this site must maintain stronger visual hierarchy than secondary actions, including sufficient contrast, consistent sizing, and a persistent focus state.

The first fixes a button.

The second becomes part of the product.

That distinction sounds obvious now. It wasn't obvious while I was building.

This is where AI-built sites accumulate UX debt

Traditional technical debt is easy enough to understand. You ship something quickly, accept an imperfect implementation, and pay for it later.

Vibe-coded products can accumulate another kind of debt.

Call it UX debt.

A page can work perfectly well from a technical standpoint and still slowly drift away from decisions you've already made elsewhere.

The CTA hierarchy changes.

Spacing becomes inconsistent.

A component that was fixed for accessibility gets recreated without the fix.

The pricing page describes something differently from the homepage.

An old conversion pattern quietly returns.

Nothing crashes.

That's what makes these problems annoying.

A website conversion audit or UX audit can catch many of them after they appear. But if you're continuously shipping changes with Lovable, Cursor, Bolt, v0, or another AI coding tool, finding the problem once isn't enough.

The correction has to survive the next build.

I initially thought better prompts would solve it

My first reaction was predictable: write better prompts.

More context. More constraints. More detailed instructions.

That helped.

It also became ridiculous.

I was manually carrying decisions from one conversation to another, trying to remember which rules mattered and why we had made them.

At some point I realized I was becoming the memory layer between the AI and my own product.

That doesn't scale very well, even for a solo founder.

And it led to a question that ended up changing how I'm building UXtion:

What if an audit didn't just find problems? What if it remembered what we learned from fixing them?

An audit should know what happened last time

Most website audits are snapshots.

Run an accessibility audit. Get a report.

Run a UX audit. Get another report.

Run an AI SEO audit or website conversion audit. Get another list.

Useful, but each run basically starts from zero.

That made less sense to me the longer I worked on UXtion.

If an audit previously found that a primary CTA had poor contrast, and I fixed it, that history should matter when the same pattern appears again.

If we intentionally chose one interaction pattern over another, a future audit shouldn't casually recommend reversing that decision without context.

And if a resolved issue comes back after a new release, that's more interesting than a completely new issue.

It's a regression.

This is why I've been working on persistent design memory inside UXtion.

The idea is simple: a useful audit shouldn't only know what is wrong today. It should retain enough context from previous audits and fixes to understand what the product has already learned.

I'm still building this, so I'm not going to pretend I've solved the whole problem.

But I no longer think a bigger prompt is the answer.

The same problem shows up in AI search and accessibility

Once I noticed this pattern in design, I started seeing it elsewhere.

You can improve heading structure for SEO and AI search optimization, then create a new page with the old structure.

You can correct an accessibility issue, then introduce a new component that makes the same mistake.

You can improve a conversion path and accidentally restore the old friction two releases later.

This is one reason I'm increasingly skeptical of giant one-time audit reports.

A 60-page report can tell you a lot about your website on Tuesday.

It knows nothing about what you ship on Friday.

For a site being changed constantly with AI, the more useful question may be:

Did today's change bring back something we already fixed?

That is a very different kind of website audit.

A small habit that helps right now

You don't need UXtion to start dealing with this.

When AI helps you fix something important, don't only save the code change.

Save the reason.

Instead of:

Changed CTA to green.

Keep something closer to:

Primary CTA must remain visually dominant over secondary actions. We changed the previous dark CTA because it disappeared into the hero background.

The second note gives a future AI session something much more useful than a styling instruction. It contains the decision and the reason behind it.

Do the same for recurring accessibility fixes, conversion decisions, component behavior, and design-system exceptions.

You're essentially building a small memory for the product.

I wish I'd started doing that before bug number eight.

What I'm building from this

UXtion started as a way to audit AI-built websites for design, conversion, accessibility, SEO, and AI search problems and turn the findings into fixes you can paste back into your builder.

I'm starting to think the more interesting problem comes after that.

The first audit finds the mistake.

The next audit should know you've seen it before.

And eventually, the product should help stop the same mistake from coming back at all.

That's what I'm working on now.

I'll write about what works, what doesn't, and probably a few more things I manage to break along the way.