When working with other engineers using IDEs like VSCode, while I was using vim, I ran into a similar dynamic. I relied on grep to find and trace code, whereas

When working with other engineers using IDEs like VSCode, while I was using vim, I ran into a similar dynamic. I relied on grep to find and trace code, whereas they were right-click go to definition. That ease of navigation made them insensitive to the amount of indirection in the code base that didn't need to be there. It was an uphill battle, and honestly, for that time, I just switched to the editors they were using. Otherwise, I'd just be seen as being less productive. For my own personal projects, I could spend more time just keeping things simple, and using vim. Though recently, I've switched to VScode based Cursor. I've found that it works best when I use it as a guide, rather than as a code writer. I'm often working on an atypical stack, and the code it generates just uses a wrong or outdated API. Even cursor is terrible at pulling in the right context and documentation. The mental habit of thinking it'll "just solve the problem" is wrong too, and wastes my time. It's much better if I think of it as a guide, and I ask it to explain everything I need to do step by step, so I'm following along, rather than expecting it to one-shot it all for me. So, in some sense, you'll probably need to go with the flow. Using some sourcegraph or other tooling to help you navigate will help in the short term. But I think in this sense, I agree with the handmade people--that keeping things short, simple, and fast will be a business advantage over time. But that's given that you've validated the need. And find companies that understand that AI won't be able to one-shot tasks (beyond very typical junior programming tasks) for a while to come.