Thoughts on Cursor
1 comments
I've also used iterative, interactive development for years and I agree, this is a big deal for Cursor.
It is interesting that it works with print debugging rather than breakpoints (as do I). It also points a way forward to finally be done with tools like Figma and Miro which can't roundtrip code; they only create artifacts for someone else to code up.
It is interesting that it works with print debugging rather than breakpoints (as do I). It also points a way forward to finally be done with tools like Figma and Miro which can't roundtrip code; they only create artifacts for someone else to code up.
I had an understanding of what I wanted from the IDEs, but I could not fully articulate it before the launch. Now that it’s here, it makes complete sense.
The way I see the future of programming, everything is going to be live: debugging, coding, designing, etc. Not that the idea is new, but the difference is that now it will be fully autonomous.
Recently, I worked on a feature that required redesigning part of our legacy flow built with Django templates and plain JavaScript for interactivity. In theory, this should not be a difficult task for current models. But they struggled to produce the right output, and I think there are two reasons for that:
Design is inherently hard to express purely in text.
Models are great at generating new code, but not so great at modifying large, existing codebases.
Honestly, the best workflow I found for updating the legacy UI was to operate directly off screenshots. I simply take the screenshots of the existing UI and the expected change, and ask the model to write code that matches that design, given the context of existing design. Models understand the context way faster this way.
With this new Design feature, I imagine this whole process become faster because I can make the edits directly on the browser, and model simply codes the expected outcome. Its what I always wanted - a custom headless Puppeteer running in the background, watching what I am doing, and helping with the design in real time.
And then there’s debugging. I have always preferred logs over a traditional debugger. What I have really wanted is something like an ELK parser at runtime something that just understands my logs as the system runs, and can point out when things drift off the expected path.