AutoDev Xiuper

You will like the consistency. The same engine drives an IntelliJ plugin, a VS Code extension and a command line, so the behaviour you learn in one place transfers to the others and your project instructions are read the same way everywhere. That portability is the deciding daily trait, because most people who switch editors during a week end up maintaining two mental models of the same assistant.

Pick it if your team is split across editors and you want one answer. Pick Junie if you are entirely on JetBrains and would rather have a supported product than a broad one.

Read the README before the marketing. The shared-engine rewrite carries an alpha label, and the older major version is what the project still calls stable, which means the capability list and the thing most users install are two different artefacts. Spreading one alpha engine across six delivery surfaces multiplies the places a regression can appear and divides the attention available to fix any of them.

What it does right: it reads the repository's own instruction file, so project conventions are picked up without a vendor-specific configuration format.

1. Context gathering is tool-mediated rather than index-based: grep and glob over the tree, plus web fetch, which is cheap to reason about and bounded by what the model asks for. 2. Work is delegated to specialised subagents including a dedicated review agent, so verification is a separate context rather than the same one grading itself. 3. Compiling that core to a plugin, an extension, a desktop app and a server is an unusual amount of portability for an agent runtime.

No benchmark accompanies any of it. The observation: the review subagent is the most interesting design decision and the least documented.

Three years of continuous shipping by an individual is a genuine signal, and it is the only signal available. There is no entity, no revenue, no pricing page and no funding event, so the asset is a person's sustained interest and the risk is that it moves. Longevity in this category usually comes from either a company's payroll or a large contributor base, and neither is visible here.

Likely path: continued solo maintenance, or a quiet handoff. Position: fine as a tool, unwise as a platform dependency, and read the commit history before you plan a year around it.

The demo is fine and the invoice is empty. Distribution through two marketplaces means installation is not a rollout project, which saves a memo. The licence is the first stop: a file-level copyleft term is manageable but it is a legal review, not a checkbox, and our template does not cover it. There is no identity integration, no central configuration and no audit trail, because a plugin has none of those.

Onboarding is a day for an engineer already in their editor. Not yet, pending the licence review.

This one goes further off the vendor's path than most. My local model is a listed provider, so inference stays on my hardware, and the command line installs from npm with no account anywhere in the process. It loads skills written for a different vendor's agent and exposes agent-to-agent commands, which means it interoperates with things its author did not ship.

The licence permits a fork and requires modified files to stay open, which is a fair trade. Everything worth changing is Kotlin I can read, and the tool protocol support means my own servers are already compatible.