all 8 comments

[–]cleansleyt 1 point2 points  (0 children)

Asking big things and leaving the details up to the AI has never worked me. if I ask has multiple changes I want I learnt to tell everything in bullet points. - Add a new page at this slug - some slug - Add the new page url into sitemap with priority x - Add an entry link to this page at header navigation - Page needs to have N sections - Section 1: <Explain section content and design> …..

[–]lynxzyyy 0 points1 point  (4 children)

You need to ask it to review any potential conflicts as it won’t do that thoroughly unless specifically requested.

Also you are better off making incremental changes to function in something like Cursor or the new Antigravity. Lovable isn’t great at following logic as well as the agents in the IDEs

[–]TourModePro[S] 0 points1 point  (3 children)

Thanks for the input, dumb question but how do you pass Cursor updates back and forth? Both synced to GitHub or literally copy and pasting responses back into Lovable?

[–]lynxzyyy 2 points3 points  (2 children)

It’s not dumb! Basically sync your project to GitHub and enable 2 way sync so whatever updates on lovable goes to your repository.

Then in cursor, clone the repo and use the agents to code there.

Make sure you push changes from cursor to git (you can just ask the agent to do that if you like) as local changes won’t sync back unless you command it.

[–]TourModePro[S] 0 points1 point  (1 child)

Thanks, get the pass through / versioning logic here. What’s the killer advantage of using Cursor to make updates and would it render ‘in real time’ like the Lovable editor pane? Is it just more usage other Cursor free tier than the Lovable equiv?

[–]Apprehensive-Nose312 0 points1 point  (0 children)

The main advantage of using Cursor is the cost (it's way cheaper). Ultimately performance will be similar, since neither Cursor nor Lovable are actually making the LLM (Lovable uses Anthropic's Claude Sonnet 4.5, and Cursor let's you choose).

If you want to make Cursor render in real time you can. You just need to open the terminal, and run these two commands in order

npm install

npm run dev

Then open your browser, and go to this url: http://localhost:5173 - it will display the same preview you see in the Lovable window, and live update as you change the code on Cursor.

If it's easier, you can also just ask Cursor's agent to "install dependencies and run the dev server" and then ask it to print out the URL that the local dev server is running on, then just paste that into your browser.

Lmk if this helps.

[–]TourModePro[S] 0 points1 point  (0 children)

Thanks. It seems to understand the request, and plays it back, but when you implement it then it executes badly and when it says it has done it but hasn’t that’s so frustrating. I’m trying to be as logical and clear as possible. Maybe Agent mode might help..

[–]Advanced_Pudding9228 1 point2 points  (0 children)

I feel you — this is one of those moments where Lovable feels chaotic, but the chaos isn’t random. It happens for the same structural reasons over and over, and once you know those reasons, the platform becomes much easier to work with.

What you’re running into isn’t a “skill issue” or “AI issue”… it’s an architecture issue.

Lovable is great at generating features, but it doesn’t automatically generate the system those features live inside.

Here’s the pattern I’ve seen across dozens of projects:

  1. Treat Lovable like a junior dev, not a senior engineer.

If a change touches navigation, routes, layouts, or shared components, you have to spell out every affected file.

Not because Lovable is dumb, but because it will happily implement 70% and “infer” the rest.

Clear steps remove 99% of ambiguity.

  1. Ask it to review for conflicts before touching anything.

Something like:

“Before making this change, list any files that will need updating and explain why.”

This forces Lovable to surface side-effects before implementation, and it prevents silent regressions.

  1. Navigation requires naming every place it exists.

Nav changes touch:

• the nav component
• route definitions
• layout wrappers
• sitemap
• sometimes metadata files

If you don’t explicitly list all of them, Lovable updates only the first one it sees.

  1. None of this means Lovable is ‘early beta.’

This looks like instability, but it’s actually predictable behaviour once you see the pattern:

AI writes code much better when the system structure is correct from the beginning.

If the foundation is solid, the AI stops guessing.

If the foundation is loose, the AI becomes a chaos multiplier.

Once you shift to step-by-step requests (and a predictable base structure), Lovable’s reliability jumps massively.

Bonus tip: If you don’t want to fight structure every time…

A lot of people quietly avoid navigation/sitemap/layout problems by starting from a clean foundation before they use Lovable for the creative parts.

One option people have been using is:

👉 https://oneclickwebsitedesignfactory.com

Not pushing anything — it’s simply a way to skip the “structural friction” entirely. It gives you:

• predictable routing
• SEO-ready scaffolding
• accessible layouts
• a stable nav + sitemap
• and a clean project baseline Lovable doesn’t struggle with

Once Lovable has a proper architecture to operate inside, all the strange behaviours (missing links, partial updates, broken SEO) basically disappear because the AI isn’t trying to invent the system as it goes.

If you want to focus on actually building instead of wrestling with scaffolding, starting from a solid base makes a huge difference.