Context

I’m a product designer, not a developer. I majored in computer science in undergrad with a specialization in software applications and I’ve tinkered with various small projects over the years, mostly static sites like this one. I’m quite technically literate by designer standards, but I’m not at the coding proficiency of a professional developer and I wouldn’t consider myself to have the same goals as one.

I’ve seen a lot of hype recently around Cursor (a very trendy AI code editor) from people in various roles, and I’ve been using it myself almost daily for about a month now. I usually take a while to settle into my opinions on things, but so far, it’s pretty good and has enabled me to accomplish a lot of things that would have taken me much longer before.

I’ll dive into some specific things I’ve found helpful when using Cursor, but before I do so, I want to address my overall opinions on how Cursor “should” be used, the impacts of its usage, and its audience.

There are two main uses for AI-assisted development:

  1. Building prototypes: I typically use v0 for this (Cursor requires too much fine-tuning and attention to detail). This is great for communicating intended interactivity/functionality, exploring options quickly, and playtesting with users, but you can’t really ship this to production or easily integrate it into a real codebase. Existing code ecosystems are simply too complex. They come with pre-existing libraries, frameworks, design systems, data models, infrastructure, etc. etc. that prototypes simply don’t account for.
  2. Daily development tasks: code autocompletion, cleanup, refactoring, generating tests, using it as a pair programmer (I quite like this one), etc. Cursor’s pretty good at this.

This excerpt from an article from The Pragmatic Engineer sums up my thoughts pretty well:

Non-engineers using AI for coding find themselves hitting a frustrating wall. They can get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns.

This “70% problem” reveals something crucial about the current state of AI-assisted development. The initial progress feels magical: you can describe what you want, and AI tools like v0 or Bolt will generate a working prototype that looks impressive. But then reality sets in.

…[Non-engineers] lack the mental models to understand what’s actually going wrong. When an experienced developer encounters a bug, they can reason about potential causes and solutions based on years of pattern recognition. Without this background, you’re essentially playing whack-a-mole with code you don’t fully understand.

…Here’s the most counterintuitive thing I’ve discovered: AI tools help experienced developers more than beginners. This seems backward. Shouldn’t AI democratize coding?

The reality is that AI is like having a very eager junior developer on your team. They can write code quickly, but they need constant supervision and correction. The more you know, the better you can guide them.

…Seniors use AI to accelerate what they already know how to do. Juniors try to use AI to learn what to do. The results differ dramatically.

This has lined up with my experience as well. My existing coding experience and current coding tasks typically both concern styling the front-end, so when I run into obstacles while coding, I usually have enough prior knowledge to figure out how to unstick myself (or if not, ask a more knowledgeable developer how to do so). If I had to figure out how to build an API, I don’t think I would be able to write a prompt more specific than “please fix this” (which works with v0 but not very well with Cursor, at least after the first time).

This doesn’t mean I think people who aren’t senior devs should be banned from using Cursor or something. Just be mindful of its limitations—I’ve found it more useful as a thinking partner than a black box that magically spits out your desired output. And consider the goals you’re trying to accomplish, and whether this is the tool best suited to that.

Some advice on getting the most out of Cursor

If you’re modifying an existing file or otherwise reliant on it, ask Cursor to explain the file to you. It can be kind of overwhelming to open a file and see a few hundred lines of code you’re not familiar with. Cursor does a pretty good job explaining how the file is structured and its variables and functions and what they’re doing, which will help give you an idea of where to get started. You can do this for multiple files, not just one.

You can also mention the exact thing you’re interested in, e.g. “Please explain to me how this file spaces the grid elements in componentX.” A lot of coding is figuring out what existing code you’ll need to change.

And of course, look at the code yourself so you understand what’s going on.

Go in with a plan of what you’re trying to build. Most of my initial prompts to Cursor are maybe 3-5 sentences long, and very, very specific about what I want it to do. You don’t necessarily need the whole UI built out in Figma already (I sometimes don’t, but it can be helpful), but you should have a pretty clear picture in your head. Here are a couple examples of opening prompts I’ve written recently:

Moderately specific:

[For creating a multiselect component in Storybook] using the dropdown files i attached as a template, make a copy and replace the dropdown with the MUI autocomplete component, specifically the multiple-value freeSolo one here: @https://mui.com/material-ui/react-autocomplete/#multiple-values . call this customized MUI component Multiselect
match the styling used in the dropdown component

Really specific:

[For adding an animation to a collapsible panel] ​​Hi! The collapseSection here is a right-side panel with a list of tasks that opens very abruptly, so I’d like to add a transition animation. Here’s how I’d like it to work. When I click the expand button, the following should happen:

1. The left side of the page is in the MemberProfileComponent. I DO not want it to have an animation. It should collapse / decrease its size immediately with no transition.

2. After it collapses, the task panel should expand to 40% width with an 0.3s transition.

3. The content of the task panel should not appear until AFTER the panel has already expanded (you may need a delay) and there should be no transition, it should just appear immediately. You may need to create a container for the task panel that’s separate for the content so you can separate step 2 and 3.

(This is a lot more specific than I’d be when prototyping; this is with the intent of writing code that can, with some modifications/review, be shipped to production. Much of good development is just understanding what you’re trying to accomplish and having a plan for it.)

When possible, suggest existing solutions from your framework/library/package over building it from scratch. Also, Cursor’s pretty good at reading documentation. If you send it a link to e.g. the documentation for the specific MUI component you want it to use, it will read the documentation and use that component. The same goes for using existing components in your codebase over building new ones.

Example of asking Cursor to use built-in MUI behavior

Relatedly, Cursor will read other people’s solutions if you suggest them. Sometimes when I’m really, really stuck and can’t figure out another approach, I will look up my problem on the Internet and have Cursor read some unorthodox approach from StackOverflow I know it hasn’t tried yet.

Cursor will sometimes accidentally mess up something that previously worked. It’s not the best about making sure it retains everything from previous edits—check your code carefully and review any changes it suggests. It can be helpful to find the previous version of the changed files and send those to Cursor, specifying what has been lost between versions and needs to be restored.

If you get an error from your compiler or console, copy the exact error and send it to Cursor. More specificity is always better. “This broke” doesn’t often work as a troubleshooting prompt. If the error message itself is vague but you have your own theory about why it’s broken or where the error is coming from, Cursor usually finds that helpful too.

If it’s not working, suggest a couple of different approaches. Cursor can provide its opinion on the pros and cons of each approach, or just try them all one by one if you like. (e.g. “Should we try aligning these elements with a built-in Grid or with CSS flexbox? Here is how I want it to look…”)

On UI work specifically

Cursor is okay at reconstructing UI from images, but it requires a lot of work to make it pixel perfect. Depending on the complexity of the code and your own level of front-end competency, it’s usually not too difficult to fine-tune it to pixel perfection yourself, but it can take some time. Having a reference image/Figma design for Cursor to understand the UI it’s building can be helpful, but it’s not going to get the layout perfectly without more specific instruction.

Inspect element is your best friend. I use it to check (1) CSS changes I made went through and (2) understand what CSS classes I need to target/override to customize components. If you aren’t able to style your UI as expected, I’ve sometimes had some luck with screenshotting the code in my Inspect Element and asking Cursor if it looks as it should.

Related reading