Async IDE

The deciding trait is that the editor actually knows your code. Language servers back the intelligence, a file index and symbol search sit underneath the agent, so when it goes looking for a definition it finds the definition rather than a string that resembles one.

What you are trading is maturity. This is a young editor and it feels like one, in the small places where an older editor has already answered the question. Pick it if the agent is the point and the editor is the container. Pick an established editor with an agent extension if your setup has to come with you.

Starting fresh is the decision everything else follows from. A fork inherits an extension marketplace, a settings format and a decade of muscle memory; this inherits none of them, which means every capability a developer already relies on has to be rebuilt here or done without.

The scope makes it worse: the agent stack, the tooling and the editor all have to be built and maintained by the same small team. What it does right is the argument itself, which is coherent: if the agent is the centre of gravity, a chat panel bolted to a fork is the wrong shape.

1. Naming the stages is more than presentation. A loop with an explicit Observe step commits the design to checking results before continuing, which is the distinction between an agent and a sequence of hopeful calls. 2. Making the stages interruptible puts the correction point where it belongs, before the next action rather than after the transcript.

2. What Observe actually checks is not specified: whether it reads test output, compiler diagnostics or only a tool's return value changes the claim entirely. The structure is documented and the semantics are not, and no evaluation accompanies either. Auto model selection is asserted on the same terms.

Editors are where developer-tool money goes to be spent. The companies that succeeded in this category raised heavily, hired teams and still lost people to acquisition; this is the same undertaking with no funding, no revenue line and no hosted surface. Moat: none, and building one would require exactly the resources that are absent.

Likely path: the interesting parts get lifted into an extension for an editor people already use, which is the cheapest way for anyone to acquire this without acquiring anything. Position: watch it, borrow the ideas, and do not move a team's daily editor onto a project with no way to pay for a bad quarter.

There is no packaged build in the row. Distribution is a clone and a dependency install, which means sixty engineers each compiling their own editor, each on a different commit, with no way for me to say which version is deployed. That alone ends the conversation before security asks a question.

When they do ask, the answers are the usual ones: no single sign-on, no directory sync, no audit export, and nothing that runs in a pipeline. Licence cost is zero, which is the only number in my favour. Not yet: bring me a signed installer and a version I can pin, and I will look again.

Naming vLLM alongside Ollama tells me somebody actually runs local inference, because vLLM is what you reach for when one model on one laptop stops being the setup. Any OpenAI-compatible endpoint works, so my serving stack is a config value rather than a feature request.

The per-agent allowlist is the other detail worth having: each toolchain gets its own model, its own workspace and its own permitted tools, which is the granularity I want and rarely get. Apache-2.0 keeps a fork viable. Grudging respect for a young editor that got the model question right before the polish.