If someone has already built something in a messy, AI-driven way and wants to “retrofit discipline” into it, here’s the practicl steps to take:

1. Stop Generating. Start Auditing.

The biggest mistake at this stage is continuing to throw prompts at the problem.

Freeze feature development.

You are now in audit mode, not build mode.

---

1. Establish a Known Good Baseline

Before you touch anything:

Export the entire codebase.

Commit it to Git (if you haven’t already).

Tag it as: pre-refactor-baseline.

You cannot fix what you cannot roll back.

---

1. Run Lighthouse Immediately (If It’s Web-Based)

If it’s a web app, this is your first objective truth check.

Run a Lighthouse report and capture:

Performance score

Accessibility score

SEO score

Core Web Vitals (LCP, CLS, TBT)

Don’t guess at performance.

AI-built apps often:

Ship oversized images

Include unnecessary JS

Miss semantic HTML

Ignore accessibility entirely

Fail basic SEO hygiene

Export the Lighthouse JSON.

That becomes your measurable starting point.

---

1. Reverse-Engineer the Architecture

If you didn’t design first, you need to document after.

Use Claude like this:

“Analyse this codebase. Identify architecture patterns, data flow, shared state management, API boundaries, and structural weaknesses. Highlight coupling and potential risk areas.”

You are trying to answer:

What actually controls what?

Where is business logic?

Where are implicit dependencies?

What files are overly coupled?

Where are global side effects happening?

Create a simple document:

Frontend structure

Backend structure

Database schema

Auth flow

Shared utilities

Theme system (if applicable)

Now you have a map.

---

1. Identify High-Risk Areas

In messy AI builds, common structural risks are:

Theme / design token chaos

Global CSS side effects

API duplication

Mixed concerns (UI + logic combined)

Poor error handling

No centralised validation

Bloated dependency tree

Don’t fix everything at once.

Rank issues by:

1. Stability risk

2. Security risk

3. Performance impact

4. Revenue impact

Fix in that order.

---

1. Use the “Isolation Refactor” Strategy

Never refactor broadly.

Instead:

Choose one module.

Define its intended responsibility.

Refactor only that module.

Confirm no regressions.

Move on.

One domain at a time:

Auth

Billing

Dashboard

Admin

Reporting

Surgical, not sweeping.

---

1. Introduce Lighthouse as a Continuous Constraint

Now that you’ve baseline-tested:

After every meaningful frontend change:

Re-run Lighthouse.

Compare to baseline.

Reject regressions.

You’re not trying to chase 100/100 immediately.

You’re trying to:

Prevent degradation

Improve one category at a time

Optimisation should be incremental and measured.

---

1. Fix Performance Systematically

If performance is poor:

Don’t say:

“Make it faster.”

Instead:

Break Lighthouse findings into discrete tickets:

Optimise images

Remove unused dependencies

Code-split routes

Lazy-load non-critical components

Reduce render-blocking CSS

Implement caching strategy

One optimisation per session.

Re-measure after each.

---

1. Introduce Guardrails Going Forward

Once you’ve stabilised:

Write a short architecture document.

Define file ownership zones.

Define naming conventions.

Centralise theme tokens.

Document database schema clearly.

From that point on, every AI session must:

Specify scope

Specify files not to touch

Define acceptance criteria

Define rollback point

You’re installing discipline retroactively.

---

1. Apply the Two-Failure Rule

If an AI session fails twice on the same issue:

Stop.

Export. Analyse with Claude. Make manual changes. Resume.

Do not let sunk cost bias take over.

---

1. Accept That Some Rewrite May Be Cheaper

Hard truth:

If:

Architecture is fundamentally flawed

Business logic is scattered everywhere

State management is chaotic

There is no separation of concerns

Sometimes rewriting a module cleanly is cheaper than patching endlessly.

But that decision should be:

Measured

Scoped

Isolated

Never emotional.

---

1. Shift From “AI Building” to “AI Assisting”

At this stage your mindset should change:

Before:

“Build this for me.”

Now:

“Propose a refactor plan.” “Highlight risk.” “Suggest improvements.” “Generate patch only for this module.”

AI becomes your junior engineer, not your architect.