Honest Review After Six Months of Using Cursor

Half a year ago, I started using Cursor after being influenced by a review. Now, looking back, some of my judgments were correct, some were wrong, and some expectations were unmet, while others brought unexpected surprises. This article shares my honest thoughts without advertising or bashing the tool.

What Made Me Stick Around: Codebase Conversations

What truly convinced me to subscribe long-term was not the tab completion but the Codebase conversation feature.

When opening a completely unfamiliar project, I can ask it to explain the logic of a certain module, find the location of specific functions, or inquire about architectural design ideas. The efficiency boost from this is substantial. Previously, it would take me two to three days to understand the overall structure of a new project; now, I can grasp the general framework in half a day. This efficiency gain is crucial for me, as I often need to quickly familiarize myself with unfamiliar codebases. This alone justifies the subscription fee, even if other features were absent.

Tab completion is indeed useful, but not as magical as I expected. It excels at completing repetitive code (like when I write one function, it can guess what I want for the next similar function), variable naming, and simple conditional checks. However, for truly complex logic, the suggestions often require modifications, so don’t set your expectations too high. Once I got used to it, though, not having completion felt oddly lacking, which was an unexpected psychological dependency.

Agent Mode: Powerful but Needs Taming

The Agent mode is the most powerful yet potentially problematic feature in Cursor. It can autonomously read files, run commands, and modify code without needing step-by-step guidance; it plans its own steps to complete tasks.

This capability is strong but can lead to issues if misused. It might change files you didn’t want altered or plan a significant refactor in the wrong direction. I encountered this once when I asked it to make a small adjustment to a function, and it ended up redesigning the entire module structure. While logically sound, it was entirely not what I wanted, and reverting it took considerable time.

The correct way to use Agent mode is to clearly define boundaries in the task description, specify which files to leave untouched, and outline the expected results. If there are uncertainties after modifications, confirm them before proceeding. Treat it like a very smart but occasionally reckless intern rather than a fully autonomous driver. Adjusting this mindset significantly reduced the frequency of issues with Agent mode.

Some Real Dissatisfactions

After six months, I accumulated a few genuine dissatisfactions, which I will discuss objectively.

Context window still overflows. During large projects, as conversations lengthen, it tends to “forget” earlier content, forcing you to re-explain the background. Using .cursorrules can alleviate this issue but doesn’t solve it entirely. Every new conversation requires rebuilding context, which can be a significant communication cost, especially during tasks that require continuity. For an ongoing refactor, starting a new conversation means re-explaining previous decisions, which is frustrating.

Sometimes it’s overly enthusiastic. If you say, “help me modify this function,” it might also change things you didn’t ask it to, commenting, “I also optimized XXX.” This well-meaning behavior can be annoying, as you then need to spend time reviewing its additional changes to ensure no new issues were introduced. This is especially concerning in collaborative scenarios, where it might alter code with historical significance that you are unaware of.

Network quality significantly impacts experience. When using domestic networks, there are occasional noticeable delays. In scenarios requiring quick responses, like tab completion, this delay can diminish the user experience. This issue isn’t entirely Cursor’s fault, but it does exist; using it in poor network conditions can feel disjointed, with completions often appearing after you’ve already typed the entire line.

Uneven support for commonly used domestic frameworks. While mainstream frameworks work smoothly, when encountering some frameworks or libraries that are popular domestically but not as well-known abroad, the suggestions can be off, requiring additional validation before use.

What Truly Changed After Six Months

After discussing the negatives, let’s talk about what genuinely changed in my work approach.

Faster onboarding for unfamiliar projects. This is the most noticeable change. Previously, taking on a new project required a lot of time reading code, asking colleagues, and sketching architecture diagrams. Now, using Codebase conversations for the first round of exploration can cut that time by more than half. This improvement is quantifiable; onboarding time has decreased from two to three days to half a day to a day, which is a direct efficiency gain for engineers who frequently handle different projects.

Writing test code is no longer painful. Writing unit tests used to be one of my least favorite tasks—not because I couldn’t do it, but because I was lazy and felt the cost-benefit ratio was low. Now, I let Cursor write the first draft, and I check boundary cases, add missing cases, and adjust assertions. This division of labor has significantly lowered the psychological resistance to writing tests, and test coverage has indeed improved. Additionally, by reviewing the tests it generates, I have a deeper understanding of the code’s boundary cases.

Code review efficiency has also improved. When reviewing others’ code, I can share questionable parts with Cursor, asking it to explain the intent behind that code or if it notices any potential issues, helping me catch points I might have missed after several readings.

One Thing That Hasn’t Changed

After six months, one thing remains unchanged: I still need to understand what I am writing.

Those who completely rely on Cursor without looking at the code or reviewing outputs will eventually find themselves helpless in the face of a bug because they lack understanding of what is happening in the system. Tools are amplifiers, not substitutes; this statement is not just a platitude but a genuine feeling after six months of use. It raises the ceiling of what I can achieve, but the prerequisite is that I already know how to do those things.

Recommended for: Developers with engineering backgrounds who frequently handle unfamiliar codebases and write tests and documentation. The benefits of using Cursor are most apparent in these scenarios.

Not recommended for: Beginners learning programming; reliance on AI assistance can hinder foundational skill development. It’s better to use it after acquiring some foundational knowledge. Also, those who do not wish to understand code and only want AI to generate everything automatically will inevitably face problems in the long run.

Overall Rating

9/10. The point deducted is for network latency and context overflow issues. If these two problems are resolved one day, it would essentially be a perfect tool.