Are you using Cursor for software development?
I started playing with Cursor this week to see what all the fuss is about.
It seems like a positive step in the direction of clever LLM integration into the core workflow of software development. Whether Cursor ends up with a large market share is an open question for me as the incumbents are quickly adding LLM integration into their products.
Microsoft of course remains in the catbird seat, with its ownership of Visual Studio, Github, Copilot, OpenAI, etc.
However, dev tools are notoriously fad-driven and engineers are tribal. We will see.
What’s particularly interesting to me about Cursor is that it’s yet another example of the new UX paradigm that I’ve been advocating for a while now, and which all of the “co-pilot” apps we’re developing at Platform are grappling with.
In this paradigm, you have 3 or 4 columns in a “desktop” view. Traditional hierarchical navigation on the left (first one or two columns) and then 1 column for the specific content you’re working on, and another column for an LLM chat, where the LLM is aware of the context of your work.
i.e. the LLM is fed the content you are working on and therefore can make context-sensitive suggestions and answer questions.
Interestingly, some “co-pilots” are featuring the LLM chat in the center (3rd-column) and others, like Cursor, are placing the LLM at the right (4th-column). Is one better or worse? Which will predominate? Is it app dependent?
Things become more complicated on mobile. For our co-pilots, we’re using a top/bottom layout, with the ability for the user to vary the % of the screen used for the LLM chat vs the content. For some apps, you don’t need the content at all on screen; you can simply chat with the LLM to get the information you need and feature it inline in the chat.
Where things seem less bedded-down is how context-sensitive LLM suggestions in the content you’re working on will work. Some of these still seem a bit heavy-handed and reminiscent of Clippy. It feels hard to get these suggestions to be helpful without being annoying and in the way.
It’s going to be fascinating to see which UX patterns become standardized in this new world.
Which patterns do you think will dominate? Which apps are doing it right in your view?
Founder @ Maslow Murphy
I think LLMs are a great tool for developers, but the B2B and B2C application of LLMs will come from creating hundreds or thousands of trained assistants that can work together, maintaining context and tone, without hallucination and drift,
For example, I built PitchToLaunch.com, which uses a dozen daisy chained API calls to specific assistants. It walks startups through a 15-20 investor questions, and returns 10 pages of in depth gap analysis in a supportive and consistent tone of voice:
As a consultant, this helps me support more founders, and prepares them for meaningful conversations with me (so we can spend time talking about the business, not on their role and what they should bring to the meeting).
I'm using Bolt.new and I really appreciate it. Easy to start and prompt.
Founder @ Yosubi
Have you tried using Lovable or v0? We have played some with both Cursor and Lovable with variable success in each.
One thought about the layout is that because you are working with 4 blocks, you could easily allow for a layout setting that lets your users manipulate the base layout to their needs. You could use that early data to base what your default layout setting will look like. I think that way you are not locked into one camp or the other, and can differentiate yourself amongst a sea of players.
I wouldn't do this for an average consumer facing app, but users of these products are technical enough that they will probably appreciate this setup. Think of people that use Photoshop and how they move they sub menus around to match their screen/use preference, I think this will have a similar reception.
@ Mr Jackdaw Company
I think this relates heavily to the LLM's long-term role in an application. If the workflow is dominated by LLM usage, then a two-column approach (i.e. left-column-content/context, right-column-llm, or vice-versa) may be inevitable on larger screens. Mobile could implement a horizontal split, or a swipe-between approach (swipe one way for app content; other way to interact with LLM as described). However I'd wager such workflows are not really made for mobile use (e.g. you can create/edit spreadsheets on a phone, but probably wouldn't build an income statement that way).
In terms of who's doing it right: I've seen at least one browser implementation (Brave) that makes sense. The LLM feature (or "second column") is invisible until the user specifically toggles it on. I assume other LLM browser extensions may have also taken this approach, though I personally haven't used any.
CEO | Founder | Managing Partner @ Platform Venture Studio
Good call on Brave - I haven't checked it out for a while.
Agree on mobile swipe left/right - that's another valid choice for the right use case.
Founder @ Realtor Hop
I appreciate applications that present a visually appealing wireframe of various layout options, enabling users to easily select their preferred initial design. As an early adopter of Copilot, I’ve loved how it streamlines the more tedious aspects of development. However, I’ve noticed that many experienced engineers don’t share my enthusiasm. Providing a way for developers to indicate their experience level could help tailor the user experience to their preferences. For me, as someone more seasoned, I’d prefer no chat window—just code highlighting and keyboard shortcuts. By contrast, a newer developer might benefit from having a more prominent chat interface as they learn.
CEO | Founder | Managing Partner @ Platform Venture Studio
Agree. My sense is that the developers that benefit most from LLMs currently are junior developers coming up to speed and people who are occasionally dipping into codebases that they're not familiar with.
For experienced developers, who really know a language, framework, and codebase, the acceleration seems more muted. But, for things like remembering the name or syntax of rarely used components, or writing boilerplate setup code or test cases, the acceleration is still there.