NOTES ↑ PUBLISHED: APR 3. 2026

Cursor Impressions

General impressions of building with Cursor. What worked well and areas for improvement.

I recently finished the build-out of this site and thought it might be useful to jot down my thoughts on what it was like to work with Cursor.

[↑] Cursor allowed me to build out this site and custom components on top of Astro.

Why Cursor?

I wanted to have a high degree of control over the look and feel of the site. Cursor incorporates a web browser, which makes it easy to see the changes you’re making as you go. The browser makes it easy to point directly at the UI element you want to change so that Cursor understands what you’re referring to. I had a good deal of familiarity with VS Code, which also made Cursor a good choice.

Overall impressions

My experience of building with Cursor and AI was overwhelmingly positive. I had very few hiccups along the way. A good deal of this is due to the underlying capabilities of the models. The ability of today’s LLMs to understand natural language is shocking.

I think the CMS I used as the basis for this site helped a good deal too. Astro is highly structured and modular, and is made of the stuff LLMs have been trained on, so I think it was a great first AI-assisted project to work on. It also helped that I knew exactly what I wanted to have in the end, which made it easier for me to ask for what I wanted.

The overall impression I had of building was one of momentum. Normally when I build something my progress is pretty choppy as I tend to bump into the limits of my knowledge and ability pretty quickly. On this project, my progress was shockingly smooth.

Typical usage pattern

Here’s the basic usage pattern that seemed to work the best for me:

Step	Mode	Note
1	`Ask mode`	Ask what would be involved in making a change I have in mind. Point directly at the thing to change in the browser or file list. Add screenshots if needed.
2	`Ask mode`	Ask for options along with pros and cons. Continue asking questions until I’m confident I understand what was at stake.
3	`Plan mode`	Ask to make a plan based on the conversation.
4	`Plan mode`	Add any additional adjustments and clarifications to the plan.
5	`Agent mode`	Build the plan.
6	`Agent mode`	Review the results. Make additional manual adjustments and tweaks with the inspector, or in the code.
7	`Agent mode`	Follow up with additional related enhancements until feature is complete.
8	`Git`	Commit changes.

What worked well

I had surprisingly few hiccups along the way, and none that stopped me from building the site out in the way I wanted. It’s hard to articulate just how smooth the process was relative to me having to manually build this out. Here’s what worked for me:

Tactic	Note
Vanilla Cursor	I used vanilla Cursor in order to assess what it could do. No skills. Cursor seemed to have a good understanding of how Astro is structured just from examining the code.
Incremental building	Building up interfaces one component at a time worked far better than one-shotting an entire page. This enabled me to build up the site one key component at a time, and ensured that the changes I made did not degrade the site over time.
Making small changes	Numerous, smaller rounds of changes also helped me better understand how to effectively ask for bigger changes.
Screenshot references	Uploading screenshots of the features I wanted to build seemed to work better for me than through Figma’s MCP server. I found that when sending Figma links to Cursor, the resulting CSS code would be messier than through screenshots.
Debugger	Debugging mode was very helpful in a few spots where Cursor would make a change I had requested, confidently assert that it was successful, but clearly was not. Debugging mode would take into account the plan that I had asked for when the original changes were made, and this reduced the amount of framing I’d need to do in my debug request.
Stack trace copy-and-paste	Pasting Astro error stack traces into the debugger easily resolved any breaking changes.
Explain this feature to me	When starting with a new agent or context window, I’d ask Cursor to explain a feature of the site for me. This enabled me to utilize the same descriptive language Cursor was using, which improved the results.
Natural language	Using natural language requests when operating with shared context was astonishingly effective. No different than if I were art directing.
Example websites	Pointing Cursor at example websites to understand how a certain feature was constructed. Use this as a jumping off point for feature development.
Documentation review	Having Cursor review Astro’s documentation to understand the best way to build a specific feature.
Ask Claude	Asking Claude for an explanation of how a typical feature would be constructed and then using this as a spec to feed into Cursor.

Issues

The issues I encountered while building with Cursor were relatively minor, owing primarily to my unfamiliarity with working with AI-assisted coding. I encountered no major blockers.

Issue		Resolution
Styling errors when translating a screenshot	→	Minor manual tweaking
Too many changes at once	→	Start over and constrain the ask
Cursor over-systematizing	→	Clearer scoping in my requests, minor refactoring/cleanup stage
Cursor under-systematizing	→	Point Cursor to examples in code to follow.
Cursor makes a change that breaks Astro	→	Copy the error message into debug mode.
Styling changes that wouldn’t take	→	Adding screenshots of problem and desired result to the debugger.
Cursor attempts to do too much at once	→	Constrain the problem, reduce the scope of the change.
Poorly or partially executed feature	→	Roll back, reduce scope, be more specific and organized in the ask.

Areas for improvement

Agent integration with UI

From time to time, Cursor got stuck in plan mode or ask mode and would not switch over to agent mode when it came time to build. Near as I can tell, this behavior is session-specific and tied to an agent. My workaround was to start a new conversation, make reference to the plan file created by the original agent, and then continue. Not a huge issue but definitely would take me out of the flow and reduced my confidence in Cursor.

This gave me the sense that the integration between the underlying models and the UI isn’t quite solid. Is this an artifact of the weirdness that must come with connecting LLMs to software that wasn’t designed for this use case? Or is this the weirdness that comes with an Electron based application that isn’t natively written for Macs? Hard to tell.

Cursor’s lack of awareness of its own UI

I was surprised by how limited access Cursor’s agents have to the state of Cursor’s UI. Just as I can ask questions around the codebase I’m working on, I expected to have the same ability when it came to Cursor’s UI. For instance, I might ask “how can I do X in Cursor”, and I’d get an explanation, but no ability to have Cursor enact the change directly.

Code autocomplete gets in the way

Code autocomplete was particularly useful when repeating the same edits in multiple places, but annoying in it’s always-on nature. I felt as if it interfered with my ability to make code edits more often than not. I don’t quite know what the solution is for this. There were a number of occasions where I’d ask a question about the code, get a response that included the code in the application, but Cursor wouldn’t consistently provide links to the specific line in the codebase. I could not find an easy way to tell Cursor to do this.

Browser inspector bugginess

There was a fair amount of bugginess on the browser and inspector side. I had to learn to open the inspector panel to activate the object selection control. Inspector panel resizing could also be buggy in that when dragging a panel border to resize, the mouse release event wasn’t registered, resulting in the panel width following the mouse as you move across the screen.

General text lagginess

Cursor’s UI would often get laggy during longer sessions. I’d notice it when typing summaries for git commits, even when Cursor wasn’t working on a task. Not a deal breaker, but performant text handling should be a given in a code-based tool for software developers.

Thoughts about Cursor as a product

VS Code is a double-edged sword

I think it was smart for Cursor to utilize VS Code from an adoption standpoint. The barrier to entry is much lower for developers who are already accustomed to working with it. Perfectly reasonable approach to take. With this said, I wonder whether the reliance on VS Code — and all the product-level assumptions that might come with it — might prevent Cursor from evolving towards something that is more specific to the needs of developing applications with AI.

The most important parts of Cursor feel like they are shimmed into VS Code’s UI. It may very well be that this is what works best for experienced developers, but I found this to be awkward from a product design perspective. The UI to choose which agent mode you’re in seems hugely consequential, but not very prominent. I suspect a new user would be hard-pressed to tell just how important it is to the functioning of Cursor.

Single document focus

There’s also something about the nature of building with AI that seems different than the kinds of development work that typically happens in VS Code. So many of the changes that Cursor helped me make to this site were global and systematic in nature. By contrast, VS Code seems largely oriented around the idea of viewing and editing just a handful of documents at once, and the browser is oriented around viewing and interacting with one web page at a time.

Significant interpretability challenges

While I’m still early days of working with and understanding AI, it seems to me that one of the strengths of LLMs is that they have a way to see complex relationships and patterns that makes it possible for them to be used to make coherent, systematic, global changes across an application. To do this well requires bringing humans along for the ride. I think there’s a great deal of work yet to be done around visualizing the structure of the code you’re working with and visualizing the changes the model intends to make. The better AI can help humans understand complex structures and changes, the better humans will be at using AI to make complex but understandable software.

Better communication of planned changes

Similarly, the interpretability of planned changes, or changes that have been completed feel like an area for exploration that could use some more interface real estate than what the chat or document panels can easily accommodate.

Systematic software views

I suspect that we’re going to need more systematic ways to present and view the entirety of a piece of software, along with the changes planned or implemented by LLMs. An example of this could be a kind of “super-browser” that utilizes an infinite canvas, just like in Figma. This super-browser would allow all the pages or states of an application could be arrayed on the canvas, and any changes planned or executed could be displayed and highlighted on this canvas. Object selection could also work globally as well - so when you select one instance of an object on a page, you have the ability to select all of the other identical objects throughout the site or application. Surely people are already working on this.

Room to evolve when code isn’t the thing?

As we become more comfortable with the idea of building software with LLM’s I think it’s likely that the code view may become less important as time goes on. People will care more about what the code does, and less about how it is organized. I wonder what it will mean for Cursor’s long term evolution as we figure out what AI native software development norms should look like. I suspect that they will be organized more around system-level interactions and visualizations and less around code views and file structure. This might be a hard thing to pull off for a product experience that’s so closely tied to VS Code.

Using Cursor to customize Cursor

I have a sneaking suspicion that we’ll eventually see AI harnesses that are by default open to the same kinds of customizing and tweaking as the code they are meant to operate on. I don’t know what this is going to look like in practice, and this would impose significant challenges for maintaining and updating the software, but I get the sense that the boundaries between the models and harnesses will be a lot blurrier than how today’s Cursor seems to be organized.