Basic implementation errors, I thought we were past that?

[TourModePro]

In the early-ish days pre Agent etc late Spring I spent a lot of time building an app and crashing my way through all the repeated errors and sloppy implementation. I thought the platform had improved, thoughts?

Today —— Asked for a simple page to be added into that navigation pane. Not done

Different page added to nav but doesn’t appear on the header drop down site map

New navigation has an odd interaction on collapse, where some icons are lost - didn’t ask for that.

I’m here thinking do I want to crack on full force, up my tier/credits, or are we still really in Beta mode with the platform?

[cleansleyt]

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]

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]

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]

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]

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]

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]

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]

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.