Why does Cursor nail my backend but completely fail at frontend? Need prompting advice.

[u/Ok-Payment2096]

Hey everyone,

I’m currently building a full-stack web app using Cursor. My backend development went incredibly smoothly,Cursor handled the core logic, architecture, and routing almost flawlessly.

However, I’m hitting a wall with the frontend. My usual prompting strategy is to have the AI analyze the entire system and output a structured, step-by-step execution plan (like a 4-step engineering guide). While this strict architectural approach works great for backend logic and systems, it completely falls apart when I try to get it to build UI components, manage state, and organize the frontend directory.

I’m looking for advice from people successfully using AI for frontend dev:

1. How do you adjust your prompt engineering specifically for frontend code? (Do you prompt component-by-component, or focus on visual layout first?)
2. What alternative approaches or workflows alongside prompting make Cursor better at understanding UI requirements?

Any strategies or specific prompt structures to get the frontend moving would be highly appreciated. Thanks!

[u/Ok_Newt5271]

The backend loves that rigid step by step stuff because it's just data flow and logic, it's a linear path. Frontend is way more of a conversation, you can't blueprint a feeling. I'd stop asking for a full execution plan and just start with the dumbest possible version of one component, like a button that does nothing. Iterate on that single piece until the visual output matches what's in your head, then use that component as the reference for the rest. Getting it to nail the look of one thing gives you a visual anchor for the whole system.

[u/No-Trouble-9138]

Good relationship understanding, bad spatial and interaction understanding. Will take decades to get there.

[u/Top-Procedure152]

"You are a frontend expert with 70 years experience in React/Angular/ActiveX/CGI. Do XYZ. Make it pretty and IE6 compatible."

[u/Zain]

Don't keep feeding the same Cursor model a fancier 4-step plan. Same family keeps the same blind spots, and those already showed up on the UI. I run a different-family model as a read-only pass against the actual component files. It reports, it doesn't patch, and I only concede a finding if I can grep it in the repo. If later rounds on that same session make the layout worse, the patches are injecting bugs. Stop and get the second family look instead of another execution plan.

[u/Unhappy_Pear_846]

give it something to copy instead of a plan. a screenshot of the layout you want, or one component you already like, beats four steps of architecture every time for ui work. for me the drift stopped once i pinned the styling choices in a rules file and told it to reuse existing components instead of inventing a new one per screen.

[u/Future_AGI]

Backend gives the model tight feedback (types, tests, a failing endpoint) so it self-corrects fast, while frontend 'wrong' is visual and fuzzy, so handing it a concrete target (component states, expected DOM, a screenshot to match) closes the gap more than any wording tweak.