2025-08-30
Turn off Cursor, turn on your mind
A case against agentic coding
Two approaches to using AI
I believe that AI can make you smarter. It can help you grow faster, especially when it comes to gaining new knowledge or developing new skills. It is the perfect learning companion and a great language tutor, and it’s ability to browse the web and surface relevant links far exceeds my own. Heck, I’ve even used it – albeit very modestly – to polish this draft so it’s bearable to the native speakers.
However, I would call this way of using AI – for the sake of this essay – approach one.
- Use AI to learn faster and understand the whole system better.
That’s not the main way people – especially software engineers – use or are expected to use AI. Let’s call the other emerging paradigm approach two.
- Using AI to tackle problems for you (so, at the end of the day, you neither learn much nor deepen your understanding of the system).
I think that approach 2 is the most straightforward – or let’s say, the laziest – way to use AI tools, especially agentic coding tools like Cursor or Claude Code.
And I think it’s a trap. Unless AI systems can completely replace us, we shouldn’t let ourselves get lazy – even for promised efficiency gains.
Not only coding
There’s a spectrum when it comes to outsourcing tasks to AI. For example, I could:
- Ask AI to draft this essay based on the title.
- Ask AI to rephrase my essay to make it ChatGPT-esque.
- Ask AI to fix the draft’s grammar.
- Ask AI to list grammatical or stylistic issues in this essay and suggest improvements.
Of these four choices, the first two are detrimental to my essay; option 3 fixes it but doesn’t help me learn; and option 4 not only helps the essay but also makes me a slightly better writer in English.
I believe the same logic holds for coding. Because coding is an ongoing learning process, even those in senior positions shouldn’t think they have it all figured out. Let me elucidate this point.
What makes you a faster, more skilled programmer?
Let’s start with something we can probably all agree on.
A new hire generally won’t perform at the same pace as someone who is fully onboarded into the project and has been working in it for some time.
(Holds true when comparing people of similar skills and drive).
Let’s say you are new to the project: you pick up a task and it takes you Y1 to complete. Some time passes, you implemented a huge chunk of the project. Then you take a different task of the same complexity as the first, and it takes you Y2.
If you’re like me, you’ll agree that Y2 is smaller than Y1.
You see, programming a large project is not a repetitive task but an ongoing learning process.