It's now been a few weeks since I started using #Cursor, the AI-augmented IDE.
Here are my first impressions after several dozen hours of use, along with some thoughts on the big question: can a tool like Cursor replace a developer?
My feedback
I used Cursor for debugging, refactoring, and writing various bits of code, and I clearly saved time. My workflow was centered around Cursor-no more Stack Overflow, no more Google (or only marginally). It’s simpler, and everything goes much faster.
What really impressed me is that it’s sharp even with fairly recent frameworks: Langgraph, Streamlit, ADK, CrewAI.
Like all AIs, however, it hallucinates. What’s unsettling is that when it does, it does so with disconcerting confidence. I quickly realized the need to keep some distance from what’s generated, to take nothing at face value, and not to hesitate to reject suggestions, otherwise I’d risk being led astray.
On average, I rejected about a third of the generated outputs. By using very precise prompts that illustrated a clear and directive approach, and by carefully reviewing what was proposed, I validated almost all generations. Another reason not to underestimate the impact of prompt engineering.
In a debugging context, after reviewing each suggestion, I rejected at least half of them.Still during debugging sessions, I noticed that the AI iterates through the few solution paths it knows, and when none fit, it loops and starts the same sequence over again. Several times, I almost let it turn my codebase into spaghetti, without actually solving my original problem.
I also noticed that the longer the "prompt/generation" threads are, the less precise the generations become. After two or three generations in the same thread, the suggestions started to become somewhat questionable. The solution? Start a new thread.
After a few weeks of practice, I realized that where Cursor saved me the most time was in a very specific context: I knew how I wanted the AI to help me, I had a clear idea of the result I wanted, and I was able to explain the different steps I wanted the AI to follow. So, it was far from “vibe coding,” but rather a structured and directive approach. The idea for me was to stay one step ahead of what would be generated and not get lulled by the click-button effect.
Conversely, every time I let the AI run free with prompts like “Optimize my project,” I was disappointed-my code was rewritten haphazardly, and I had to go back over what had been injected, only to end up back at square one.
So, what do I think?
For 20 years, I coded the old-fashioned way, as some now say. With a tool like Cursor in hand, I think that if I’d had access to AI earlier, it would have completely changed how I worked. In particular, I would have delivered much faster.
On the other hand, I realize that the reason I saved time with AI today is because I already knew what result I wanted and how I wanted to get there. In fact, it’s because I struggled for all those years, with nothing but Stack Overflow and Google to help, that I developed the ease that now lets me see clearly how I want to orchestrate the assistance Cursor offers, and I don’t suffer from the compromise between speed and quality.
Without this experience, I would probably have too easily fallen into the “vibe coding” trap-I would have produced code quickly, sure, but I’m sure with a very questionable level of quality.
In any case, I can’t imagine working without my assistant anymore. So I recommend it 1000%. I don’t use it by default yet, but only when I need it. It mainly helps me with the following tasks:
Code review
All kinds of conversions (e.g., docker run → docker compose)
Debugging
Tedious implementations
Code refactoring (to be used with caution)
By using it only when necessary and not more, I stay within the monthly limits of the free account. So, everyone’s happy :)
So, can AI replace the developer?
For now, in my opinion, that’s still a utopia.
Generative AI will help developers, as a coding assistant, and save a considerable amount of time. That much is certain.
However, in a business context where quality, performance, and security of code cannot be compromised, the use of AI for coding must be guided. The developer necessarily remains in the loop, but more as the conductor of the implementation than as a mere executor.
So, AI does not (and probably will not) replace the developer. However, we are undoubtedly witnessing a transformation of the developer’s work and the role they will play in the software production chain in the coming months.
And vibe coding?
I hear a lot of people getting excited about “vibe coding.” In my view, today it’s great for bootstrapping an interface, making a POC, or putting together a demo-the idea being to get a result with minimal time and effort. That’s the deal, and I think we should stick to it, at least for now.
Now, things are moving so fast that we shouldn’t rule out being surprised by the ever more impressive capabilities of upcoming models. While waiting for that, can we imagine vibe coding in a business context with all the constraints and requirements that entails? There’s still work to be done; for me, we’re not there yet, even if it’s a dream.