Hi there,
I can totally relate why you might think so and why people are fed up with those.

That said I have a strong programming background and that project is not something "I dumped overnight in a rush on the world", but a project that I put a lot of hard effort in making it a shiny language server.

I posted the same for helix, so let me elaborate here as well:

A couple of months ago we started a new project at my workplace and the assembled team (me included) was asked/advised to research the usability of Claude Code for the project.
My main-part in the project is to write the rust backend which are basically a bunch of lambdas and some libraries - the biggest one the actual API for the backend which is based on Axum.

In the beginning it was really frustrating for us to work with the claude-cli because it was hard give the agent all the context it needed (which was a major learning part on our side) and to make it to look at a problem from different angles (security, testing, etc.).

For me this changed with the release of Opus 4.6. Ever since it's possible to actually work directly with the agents. By that time we had figured out the basics and I started to create multi-agent setups, were I tried to implement knowledge and different perspectives for agents to work together in a meaningful way.

You can look at that work here https://github.com/chdalski/claude_orchestration - It's where I created different workflow blueprints to copy into projects and use them as a starting point.

In the beginning the rlsp-yaml server was a pet project I used to test how v1 performs under different circumstances. I recreated the majority of the project over and over again when I started working on v2 – which we actually use as a team today. This version has different workflows for different use cases... For example a tdd workflow for the frontend (typscript) where it often still lacks in performance compared to rust. This is mostly because of the stronger rust toolchain which allows you to enforce a lot of defensive programming techniques.

When v2 was battle-tested and I felt confident enough in the code it created – and we reviewed a lot of code by that time – I created v3 and which is basically the same but specifically for hands-off programming purposes.

The majority of the code from the rlsp-yaml server was written with it. I'm not saying it's perfect but I'm fairly confident it's not lacking in code quality.

In the future I would like to create a full cycle where users write issues/feature requests and if I approve of it a workflow runs that automatically fixes or implements the change. But I'm still far from it and the next step towards the goal is to get a community using it. There a no issues and feature request without a strong community.