Lovable and React: Where the System Becomes a Site

In Part 1, the design system existed only as a decision: four colors, two fonts, a strict scale. A decision is not a website. Part 2 is where that spec became a running React application, and where I learned that "it runs" is the most dangerous compliment you can pay an AI build. Code that compiles and renders feels finished. Most of the time it is only convincing. The whole job here was refusing to confuse the two.

Lovable scaffolded the front end as a React app, with the routing and component library wired up before I wrote any content. That gave me speed. It did not give me a finished product, and treating the difference seriously is the thread that runs through this part.

How Does a Design System Become a Living Site?

Lovable generated the React scaffold and connected every component to a single set of design tokens. That architecture is the part worth understanding. The colors, type sizes, and spacing from Part 1 do not live inside each card. They live in one place, and every card reads from that one place. Change a token once and the change ripples to every card on every section at the same instant.

That single source of truth is also what makes pushback cheap. When the system has one brain, correcting it is one edit instead of forty. The custom project card I built in Part 1, the one that escaped the library's hardcoded text size, is what made that honesty hold at the component level. The architecture rewards being demanding, because every correction lands everywhere at once.

What Do You Do When the AI Builds Something That Runs but Is Wrong?

You name the wrongness specifically, then you fix the cause. The clearest case was the Work section. Lovable rendered my project cards as polished clickable links, except half of them pointed nowhere, because those destinations did not exist yet. A card that promises a click and delivers nothing is a small lie, and a 35 to 65 hiring audience notices small lies. I refused the impressive version. I had it disable the control entirely: render the card, then drop the hover state, the cursor, and the arrow. The reader gets the content and no false promise. Honest beat polished, and the running build was wrong until it was honest.

Why Cut Sections the AI Was Happy to Keep?

The original site carried seven sections. Seven is what you build when you have not decided what matters. I challenged the inventory and forced it down to five: About, Work, Writing, Process, Contact. AI Lab, Portfolio, and Experience were not three stories. They were one story told three times, so they collapsed into a single Work section. The instinct of any generator is to add. The instinct of an editor is to cut, and a portfolio is an editing problem long before it is a building one. The AI never volunteered the deletion. I had to demand it.

Why Split What the AI Wanted to Combine?

Cutting was not the only correction. Lovable's default for the writing section was a blog pattern, every piece stacked on one scrolling page. That is how a blog behaves. It is not how a real publication behaves. The New York Times keeps a dedicated Opinion index; the Financial Times keeps a Companies index, separate pages with their own addresses. So here I pushed the opposite direction and split Writing into two real routes, one for my Stillman Exchange articles and one for personal essays, each its own page rather than a slice of a longer one. Knowing when to combine and when to separate is the entire game. The AI's default was not automatically right in either direction, and matching a premium publication meant overruling it.

Where Do You Force the Tool to Stay in Its Lane?

The last form of pushback was telling the tool what it was not allowed to touch. Lovable is strong at design, copy, and components. It is not where backend logic belongs. When I let it drift toward API and server concerns, it created file conflicts with the work happening in Claude Code, so I drew a hard line: Lovable owns the front end, Claude Code owns the logic and the backend, and neither crosses into the other. I kept the plan-mode discipline from Part 1 here too. For any change touching more than a few files, the tool had to state its plan before it built, so a misread cost one message instead of a twelve-file rollback.

What Does This Part Prove?

A site that renders is the start of the review, not the end of it. The token system handed me a build I could correct in one place. The judgment was knowing what to correct, and being unwilling to stop at "it works." I pushed Lovable to cut, to split, to tell the truth on a dead link, and to stay out of the backend, and the site got quieter and more honest with every pass.

In Part 3, the focus narrows to that single source of truth itself: Tailwind CSS v4, where one configuration file decides how the entire site looks, and where getting a single value format wrong silently breaks everything.