The latest qwen models are already very useful, and the smaller ones can be run locally on my laptop. These are obviously not as good as the latest frontier models, and that's extremely noticeable for the development workflow, but maybe in a year or two, they will be competitive with the proprietary models we have today, which are incredibly capable. I also expect compute for inference to continue getting cheaper.

The current lock in for me is the UX of Claude Code / codex cli, but this is a very small moat that will definitely be commoditized soon.

This is a pretty common phenomenon in politics, where people have a political view that is obvious to them, but other people actually disagree with that view. This is one way that political discussions go off the rails, because if you think your own views are obvious, you quickly start thinking that people have some ulterior motive for debating that "obvious" view. But the reality is often just that they just have a genuine difference of perspective, that the thing that is obvious to you is just not obvious to them.

BTW, I went to your website looking for this, but didn't find your blog. I do now see that it's linked in the footer, but I was looking for it in the hamburger menu.

Personally, I would not currently expect a fork of RedoxOS that is AI-implemented to become more popular than RedoxOS itself.

Start new projects using LLM tools, or maybe fork projects where that is acceptable. Don't force the volunteer maintainers of existing projects with existing workflows and cultures to review AI generated code. Create your own projects with workflows and cultures that are supportive of this, from the ground up.

I'm not suggesting this will come without downside, but it seems better to me than expecting maintainers to take on a new burden that they really didn't sign up for.

I can see how the cost savings could justify that, but I think it makes sense to bias toward avoiding investing in things that are not related to the core competency of the business.

I think if it were true that the tuning is easier if you run the infrastructure yourself, then this would be a good point. But in my experience, this isn't the case for a couple reasons. First of all, the majority of tuning wins (indexes, etc.) are not on the infrastructure side, so it's not a big win to run it yourself. But then also, the professionals working at a managed DB vendor are better at doing the kind of tuning that is useful on the infra side.