AI Tool Review - Working with Cursor as a Non-coder
My personal experience with Cursor
Previously, I described my experience in using Cursor for rapid prototyping. In this post, I share updates on my Cursor experience with building a webapp - about both its pleasing and frustrating properties.
✅ Developer friendly
From what I know, Cursor is designed with developers in mind and that speaks to the standard of its outputs. Instead of a no-code editor, it is better seen as a developer’s assistant that takes over basic or repetitive tasks. For me (a non-coder), it certainly brought me efficiently from 0% to 60%.
✅ Clear step-by-step explanations
Cursor guided me through the initial setup beautifully. It told me I needed Github and Vercel, and recommended Firebase as my database (I later migrated to Supabase due to Firebase changes). Cursor also guided me through how to set up the local environment, down to key strokes required to bring up my local terminal. No questions are too stupid for AI, a relief for a non-coder. In fact, I have learned to read codes along the way, thanks to Cursor’s patient explanation - talk about a bonus!
❌ No Chat Memory
Now onto the frustrating bits. Chat memories are limited to the active session, so if you close the chat accidentally as I once did, you will need to re-provide context. There is no chat history.
❌ Careless outputs
As mentioned, Cursor quickly built from 0% to 60% - but then more errors appeared as I started fine-tuning the app. If Cursor were human, I would call these mistakes “careless” - because it “forgot” what it had done. It broke what was working as it tweaked other features. Soon I realized that even within the same chat session, it was important to provide very detailed context; I learned to show the current file along with my prompt so Cursor would edit instead of writing something completely new.
Final Thoughts
Cursor is a powerful tool, packed with features appreciated by professional developers. It is probably an overkill for a non-coder but I truly enjoyed my experience and have even figured out how to deal with its quirks. As mentioned, I also learned to read some codes thanks to Cursor’s great explanations. Its dark-themed interface is not the most pleasant to work with, but that may just be a personal bias. With its reasonable subscription price, I think it’s worth checking out if you are looking for a robust AI code editor.
the cursor's chat memory still sucks but here are few things u can do:
1. Bring your previous chat to the next by mentioning it on the files. This helps to provide context.
2. Build project plan and save it as MD files on your project root and repo. This will help AI to understand where u are and what your problems are. Ensure to ask AI to checklist everytime you make some progress.
3. In case you have huge bugs, create temporary MD files on your project to provide broader context and some hypothesis how AI will fix it.
4. There are other things you can do such as leveraging cursor general and project rules if you like to explore more.
This is a great hands-on review of working with Cursor as someone coming from a non-coding background. Your point about documentation being "a lot" resonates deeply. When I started building with AI coding tools, I found myself in this strange position where the AI could generate working code, but I still needed enough context to know if what it produced actually made sense for my use case.
What shifted things for me was treating the AI less like a code generator and more like a collaborator I needed to guide. Instead of just describing what I wanted, I started being explicit about constraints, edge cases, and how components should fit together. The documentation load didn't disappear, but it became more targeted. You learn which parts actually matter for your specific project versus the sprawling "everything you could ever need to know" approach most docs take.
The cursor-as-writing-analogy you mentioned is apt. I've been exploring this exact tension between vibe coding, which is fun and fast, and structured approaches that produce maintainable results. Found that the sweet spot shifts depending on whether you're prototyping versus building something that needs to run reliably. I wrote up some thoughts on why building feels enjoyable again with these tools at thoughts.jock.pl/p/cursor-vs-vibe-coding-tools-2025 if you're curious about that particular rabbit hole.