Before AI coding tools, building software often meant spending hours debugging, reading documentation, testing assumptions, and discovering that my first approach was wrong.
It was slow and frustrating.
It was also how I learned.
Now I use Cursor, and my development time has dropped dramatically. It can generate code, explain unfamiliar parts of a project, trace errors, write tests, and help me move between backend, frontend, database, and deployment work.
As a solo developer, that is extremely valuable.
But recently I have started asking myself:
Am I becoming a better developer, or just a faster developer with a better tool?
The productivity gain is real
Cursor removes a lot of unnecessary work:
- Boilerplate
- Repetitive code
- Unfamiliar syntax
- Basic tests
- Configuration
- Documentation drafts
- Searching through many files
I do not want to return to doing all of that manually.
The problem is that AI can also remove the kind of struggle that used to build engineering judgment.
Before AI, when I found a difficult bug, I had to form hypotheses, inspect the code, test assumptions, and understand why the system behaved differently from what I expected.
Now the process can become:
Describe the problem
→ Receive a suggested fix
→ Apply it
→ Run the code
→ Ask AI about the next error
The product moves forward, but I may finish without deeply understanding what happened.
Not all struggle is valuable
I do not think developers should preserve difficulty for its own sake.
There is little educational value in writing the same boilerplate repeatedly or spending hours finding one configuration option.
The more useful distinction may be between execution and judgment.
AI is excellent at execution:
- Scaffolding
- Syntax
- Repetitive transformations
- Routine tests
- Documentation drafts
But I should still own the judgment:
- Understanding the real requirement
- Choosing the architecture
- Designing the data model
- Identifying security risks
- Thinking about failure modes
- Deciding whether the generated solution is appropriate
- Validating whether it is actually correct
The danger begins when I outsource judgment while believing I am only outsourcing execution.
How I am trying to use Cursor differently
I am not going to stop using Cursor. The productivity improvement is too significant.
Instead, I am trying to use it more deliberately.
Before asking it to implement an important feature, I write down the problem, constraints, data flow, and risks.
When debugging, I sometimes ask for possible causes before asking for a fix.
For meaningful changes, I try to follow one rule:
I should be able to explain what changed, why it works, and what could still fail.
I also verify important details—especially authentication, security, persistence, and deployment—against official documentation.
For some difficult bugs, I investigate manually for a limited time before asking AI. Not because manual debugging is morally better, but because I still want to practice forming and testing hypotheses.
What does experience mean now?
Before AI, experience was partly built from problems we had personally struggled through.
With AI, we may build more products and encounter more systems, but engage less deeply with each implementation.
That may change what it means to become an experienced developer.
Perhaps experience will depend less on how much code we personally type and more on:
- How well we define problems
- How carefully we validate outputs
- How accurately we recognize bad solutions
- How responsibly we make technical decisions
Cursor has made me a much faster developer.
I am still deciding whether it is making me a better one.
For now, I think the answer depends on which parts of engineering I choose not to outsource.
Top comments (0)