Why don't experienced developers hurry to switch to the hot new AI editors like Cursor
And what the companies which create developer tools should do to win them
As a senior EM in a B2B SaaS company, I sometimes talk with engineers about their work experience, different tool usage etc. As a big fan of AI assistants and especially Cursor, I always ask those who don’t use these much why they don’t want to use the tools that should help them in their daily work.
I see the following reasons for the slower AI tools adoption among some people.
Note: we work on the successful and mature product, the team consists of good experienced engineers who know their craft and our stack/services/etc very well. I can imagine that in a company that creates something from scratch, or works in a more dynamic and unstable environment, as well as with less experienced people, the situation will be different.
Initial experience with early versions of AI assistants was subpar. The lack of context and «knowledge» about the coding style, the particular language version and design approaches led to incorrect coding suggestions happening way too frequent. So people preferred to just write code like they always did only asking ChatGPT some specific questions.
Experienced engineers are very good at what they do. They don’t need help with defining a UI layout or writing some DB access code and business logic. The tasks where any (even basic) AI assistant is good is just not useful for them.
Experienced engineers got used to their existing IDEs, they know all the key shortcuts and efficiently use everything. So trying another workflow, or even different IDE (i.e. Cursor instead of IntelliJ IDEA or Rider) causes a significant inconvenience and initial performance hit.
Good engineers actually love their work (or most parts of it:)). So where I, as a non-programmer, am happy that Cursor wrote that JSON parsing function for me, they actually prefer to write it themselves! Because that’s what makes their work pleasant and gives satisfaction. They might use the AI to help with writing tests here though (as it’s less fun part of work).
Telling the AI what to do seems not as simple and straightforward as just writing code yourself if you’re good at it. This is very close to the p.4, but still slightly different. And this point can explain the fact that many indie hackers or managers (including me:)) are so excited with AI-assisted programming and many programmers are more skeptical.
What does it mean for the industry? JetBrains has a good chance of catching up to Cursor, Windsurf and Zed if they find a way to improve their own AI assistant quickly and integrate it with the existing IDE workflows in a smart way. They’ve got many devs who love their tools and do not want to stop using them.
I think it’s also true for any other dev tools creators (MS, Apple, Unity etc), but they need to act fast. Otherwise, the initial hurdles of migrating to another coding editor will be overcome by more and more engineers and the new standard will replace them.
It seems that MS (or any other company) could also fight the new competing AI coding editors by providing rich and consistent AI experience with the extensions for all popular IDEs. However, they do not do this for some reason and deliver the newest preview features only of VSCode. I’m curious if we end with many VSCode forks as a typical editor for almost any programming job in the end:).