I want to talk about grief.
Not the kind where you lose someone. The softer kind. The kind where something you loved, something that felt like yours, slowly stops being necessary. And you watch it happen in real time, and you are not sure whether to mourn or celebrate, and the confusion itself is the most unsettling part.
I have been writing code for eleven years. And for eleven years, my IDE was my kitchen. I knew where everything was. The fridge (IntelliJ). The knife drawer (VS Code shortcuts). The particular squeak of the third cabinet (whatever Git integration I was using that month). I could navigate it half asleep, which, for the record, I often was.
Then came Cursor. Then Claude Code. Then Windsurf and whatever else is landing while you are reading this. And now I sit here in what used to be my kitchen and it has been renovated while I was out, the walls are gone, a robot chef showed up, and it is frankly making better pasta than I ever did.
What Actually Happened
Let me be specific, because specificity is the only thing that separates insight from vibes.
Cursor arrived and people thought it was a fancy autocomplete. It was not. It was the first tool that genuinely understood the shape of what you were trying to build, not just the syntax of the line you were on. You could describe a function in plain English and it would write something that was, uncomfortably often, exactly right. Not "here is a template, good luck," but actually right. Like it had read your codebase, your comments, your variable naming habits, your sins.
Claude Code went further. It went agentic. It does not just sit in your editor waiting for you to type. It runs. It edits files. It reads errors. It tries again. At some point last February I gave it a vague description of a background job I needed and came back twenty minutes later to find it had not only written the job but also found a bug in an adjacent file it had no reason to look at. I stared at my screen for a moment and then I went and made tea because I needed to do something with my hands.
Windsurf, Zed with AI baked in, GitHub Copilot that has quietly gotten much better, the Anthropic API being directly embedded into workflows by people who cannot wait for products. The space is genuinely chaotic right now in the way that suggests something real is happening, not just hype.
The Thing Nobody Is Saying Out Loud
The conversation online is mostly about productivity. Ten times faster. Fewer bugs. Ship more. And yes, fine, that is true.
But there is a quieter thing happening that productivity discourse does not capture.
Your IDE used to be where you thought. Not just where you typed. The act of writing code was the act of understanding the problem. You would write a function, realize it was wrong, delete it, understand why it was wrong, write it differently. The friction was the point. The friction was the thinking.
These tools have removed most of the friction. And now I notice that I am faster, yes, but I am also sometimes less sure what I actually built. I read the output. I check it. I approve it. But the understanding came a different way. Less by doing, more by reviewing.
This is not a complaint. It is an observation that feels important. We shifted how understanding enters our heads, and we have not fully reckoned with that yet.
In Defense of the IDE, Briefly
VS Code is not going anywhere. IntelliJ is not going anywhere. Every single one of these AI tools lives inside an IDE or is built to look like one. Cursor is literally VS Code with a different coat.
The IDE as a concept, the place where you read and write and navigate code, is not dead. It has been colonized. Which is different.
The IDE as a workflow, where you are the primary author and the tool is a passive assistant, that version is in serious trouble. Maybe already gone for certain categories of work. If you are writing boilerplate, glue code, tests, configuration, anything that has a well-understood shape, the "you write, IDE suggests" model is genuinely over. You describe, the AI drafts, you review.
The question is whether "review" is a skill that can sustain a career. I think it can. I think it might become the primary skill, actually. Reading AI-generated code and knowing what is wrong with it, knowing what it missed, knowing the three failure modes it did not consider. That is not nothing. That is, arguably, the thing that takes years to develop.
The Emotional Part, Since We Are Here
I want to be honest about something.
There are days when I open Cursor and describe a problem and the thing comes back and it is good, genuinely good, and I feel a small cold wind. Not fear exactly. More like watching a magic trick where you almost understand the mechanism, and understanding it would ruin everything, and not understanding it also ruins everything.
I have met developers in their late forties who are anxious in a way they were not three years ago. Not because they are not good. Because they spent a decade getting very good at something specific and that specific thing is now roughly eighty percent automatable and they do not know what the remaining twenty percent looks like yet.
I have also met twenty-two year olds who have never worked without these tools and who are building things at a speed that would have seemed delusional five years ago. They are not smarter. They are just starting from a different baseline. Same way someone who grew up with GPS is not better at navigation than someone who learned to read maps, but they are faster at getting to the destination and they do not care about the distinction.
Both of these things are true at the same time. The anxiety is legitimate and the acceleration is legitimate.
What the Smart Money Is Doing
The people I watch who seem to be navigating this well are doing a few specific things.
They are learning to prompt with precision. Not "write a login function" but a detailed description of the edge cases, the expected behavior, the constraints, the existing patterns in the codebase. The quality of the output is directly proportional to the quality of the input. This turns out to be a real skill, not a trivial one.
They are investing in system design. The AI is very good at filling in boxes. It is still not great at knowing which boxes to draw, how they should connect, what the whole thing is trying to accomplish. Architecture, data modeling, API contracts, deciding what to build versus what to buy. These remain human problems for now.
They are reading more code than before. Which sounds counterintuitive but makes sense. If the AI writes the first draft, your value is in reviewing it well. You cannot review what you cannot read. Reading a lot of code fast and accurately is getting more important, not less.
And they are staying uncomfortable. Not panicked, but not settled. The people who have convinced themselves that their particular workflow is fine and needs no updating are, I suspect, wrong, but they will not find out for another two years and by then the gap will be substantial.
The Answer to the Question I Asked in the Title
No. IDEs are not dead.
But the way you used them, the rhythm of it, the keyboard shortcut for "extract method," the twenty minutes you spent configuring your linter, the pride you took in having a particularly clean setup, the sense that the environment itself was a reflection of your expertise, that is going through something.
Whether what comes out the other side is better is a question I genuinely cannot answer yet. I think it probably is, in aggregate, for most people. I think the floor of what a single developer can build has risen dramatically. I think the ceiling might be higher too, for people who adapt well.
But I also think something real was in that friction. Something about how difficulty creates understanding and understanding creates ownership and ownership creates care. Whether we can keep that care without the difficulty, I do not know.
The kitchen has been renovated. The pasta is better.
I am still not sure how I feel about it.
This is not a takes piece. I have no conclusion to sell you. I am just a person who has written a lot of code and is watching the ground shift and finding the honesty about uncertainty more useful than the confident proclamations on either side.
Top comments (0)