jbvlkt

If you have time to do that it is great for you. But most people are application programmers who should be doing programs for end users. I do not understand why we are supposed to stop doing our job and start redefining how we build SW?

For the argument lets say that this approach works and results in high quality apps. But will be users happy that app is updated 3 times a week and all updates add major changes? Because code generation is so cheap and fast it means we should even more thing about what to build to not overwhelm our users and actually solve their problems.

LLM are not designed for that. Unless prompt injection is really solved I would avoid showing LLM untrusted code.

This analogy looks quite good. Heavily processed food is not heathy for your body and heavy use of AI and other dopamine shortcuts like social media are not healthy for your brain. You have to approach both with causion.

Also they can always find another way to make money. Make subscription users product and sell some analytics like "show most trending project being built this week".

Exactly. 30k changes a day look like brute force. No one wants that except the one charging for generating those changes.

My last post was not about writing or processing code at all.

You are right, they fix even most annoying bugs really slowly. I also remember something like 2 years ago when they made pycharm unusable with poetry for several months and the release was like 18th of December (who decided to release tool for work as Christmas gift :-D ). The good thing is that you can always revert to older version and wait for proper fix.

This is not the whole picture. IDE is not just for writing code. What I really like on jetbrains is how strong the platform is. I will show you example which would be great if they implement it.

If you use ideavim you can enable feature which shows you action ID you have currently triggered (Ideavim: Track action IDs). If you click on anything it will show you name of that action and you can setup vim shortcut for that. This way, you can use almost anything by just typing a few letters. But that is just a start.

Now imagine you can use this to create "macro" which will create something like skill for LLM. So in a few seconds to minutes you can create "skills"/runbooks for major refactorings, project updates, git bisections, project deployments, log analysis or whatever you can think of. You will just click on 20 features and it will record what you did with some additional context (files, connected services, build systems etc.). This is the strength of integrated tools.

Of course this is just my imagination but I am not the smartest person in the world and I am pretty sure/hope that someone in jetbrains or in other IDE company is thinking this way.

I think they are trying new things even with "nobody writes code anymore" in mind. Their IDEs are now MCP servers for agents to reason about the code. Imagine your agent will stop wasting tokens using grep to find symbol usages if he can just ask IDE where it is used. They are not the best option for vibecoders right now but who knows what will happen in 1 year.

Integration with other developer tools, code reviews etc. are better than ever. Ideavim is probably the best vim plugin and it gets new features every month. They are also investing a lot in the AI.

I would bet they will survive just fine unless we would write software in slack only using emoji :-)

I do not have strong aesthetic preference for code (I always disable "minimap" in editors which shows it because I think about code as symbols shown in "outline"). I would probably not notice reasonable code formatting change if you would do it during my holiday. My requirements for formatting are purely technical (ie. do not make unnecessary diffs on code change). But I have worked with a few programmers who think about code visually. They actually remember code structure and formatting more than text and use "minimap" instead of "outline". They also strongly oppose any automatic formatting and linters. It is fascinating how different some people are despite doing the same work.

Look at ruff blog, they provide config which disables newly added rules. So you can use that and everything will be the same. I have tried ruff today on multiple projects at work and nothing changed because we already use more rules than default. There was zero discussion about that everyone is ok with using linters, formatters and similar tools like deptry or uv-sort.

I do not trust AI agents to run outside sandbox and use them only in dev container. I always use latest version available when I build container (once or twice a month). In my opinion it is to risky to allow auto update for SW which is released several times a week including weekends and is capable of/willing to do script kiddie pranks :-)

I also do not like if project stays on 0 version to break compatibility with every minor version. This is the problem with many rust tools and libraries. I think it is unfair to do that years after first release and with healthy community. But it is a tradeoff and not using ruff is in my opinion worse.

To your other issues, just do not upgrade. There is no need to upgrade everything a few days after release. I always lock ruff to version I like and upgrade whenever it is convenient.

I would stick to older ruff until team has resources to fix issues and move to newer version. The same think you do with other dependencies.