> You just say, "Go Build me x - it should have y,z features - and build it in golang for me" - and that's it - the 3-4 page Plan comes back - usually pretty credible - and then you click "build.".
What you're describing seems like a workflow for building toys only. There's currently no reality in which someone would actually know what the y,z features are before making them. A plan generated in 5min would likely suggest a suboptimal solution compared to what a good solution would look like (which might take a year or two to figure out, for a human, so still a week or so for SOTA models if at all possible). Building something in golang is cute, but hard to be convinced until more novel applications are being generated from prompts.
The data submitted by Cursor's users tho, that seems to be very valuable.
I have this line completion feature in koieditor.com as well, and it's hard to suggest "safe"/good completions at a low latency. Best approach I could think of is a second pass to verify first pass, but adds to latency, or change to better model, which often also impacts latency.
I think this approach is more common than the hype for actual work. I do something similar, many back and forth, then settle on something often with now known tradeoffs, written by hand to spot issues as a final guard/ keep consistent naming etc.
Is this like a popup? which most people actively accept without blinking
I think plugin/extensions should be a bit harder to run by default. I get the user friction from extra hurdles before using their plugins etc., but I don't think there is an actually safe way to execute arbitrary code, unaudited, without sandboxing, or other restrictions.
This is what makes me continuously doubt and rewrite the local-first approach to inline chat in my editor. Next edit/ code complete makes more sense due to latency advantage. But chat is hard.
It's fast and feels good to run locally, but output quality is just not ChatGPT etal.
> How else are you going to have “a quick glance at code” across project files without using a new view for that?
By showing the text around match inline with the search result in the tree. Especially useful if you do not expect to edit every search result. If you do expect to edit every search result, then Zed's multibuffer is arguably better/ faster.
I think VSCode use ripgrep and Zed has its own ripgrep-like search. Zed likely still do more work per match due to the multibuffer. A normal nested tree-based result should be faster.
I think multibuffer can be good in edit/renaming use cases, but it's very annoying for fast lookups/navigation across different files (as mentioned elsewhere).