There are certainly a lot of alternatives that are plugins(!), but our differentiation right now is being a full open source IDE and having all the features you get out of the big players (quick edits, agent mode, autocomplete, checkpoints).
Surprisingly, all of the big IDEs today (Cursor/Windsurf/Copilot) send your messages through their backend whenever you send a message, and there is no open source full IDE alternative (besides Void). Your connection to providers is direct with Void, and it's a lot easier to spin up your own models/providers and host locally or use whatever provider you want.
We're planning on building Git branching for agents in the next iteration when LLMs are more independent, and controlling the full IDE experience for that will be really important. I worry plugins will struggle.
Claude Code (neither IDE nor extension) is rapidly gaining ground, it's biggest current limitation being cost, which is likely to get resolved sooner rather than later (Gemini Code anyone?). You're right about the right now, but with the pace at which things are moving, the trends are honestly more relevant than the status quo.
What makes you say that? From what I’m observing it doesn’t seem to be talked much about at all.
I've been reaching for Claude Code first for the last couple weeks. They had offered me a $40 credit after I tried it and didn't really use it, maybe 6 weeks ago, but since I've been using it a lot. I've spent that credit and another $30, and it's REALLY good. One thing I like about Claude Code is you can "/init" and it will create a "CLAUDE.md" that saves off it's understanding of the code, and then you can modify it to give it some working knowledge.
I've also tried Codex with OpenAI and o4-mini, and it works very well too, though I have had it crash on me which claude has not.
I did try Codex with Gemini 2.5 Pro Preview, but it is really weird. It seems to not be able to do any editing, it'll say "You need to make these edits to this file (and describe high level fixes) and then come back when you're done and I'll tell you the edits to do to this other file." So that integration doesn't seem to be complete. I had high hopes because of the reviews of the new 2.5 Pro.
I also tried some claude-like use in the AI panel in Zed yesterday, and made a lot of good progress, it seemed to work pretty well, but then at some point it zeroed out a couple files. I think I might have reached a token limit, it was saying "110K out of 200K" but then something else said "120K" and I wonder if that confused it. With Codex you can compact the history, I didn't see that in Zed. Then at some point my Zed switched from editing to needing me to accept every change. I used nearly the entire trial Zed allowance yesterday asking it to impelement a Galaga-inspired game, with varying success.
The big giveaway is that everyone who has tried it agrees that it's clearly the best agentic coding tool out there. The very few who change back to whatever they were using before (whether IDE fork, extension or terminal agent), do so because of the costs.
Relevant post on the front page right now: A flat pricing subscription for Claude Code [0]. The comment section supports the above as well.
We think in 1-2 years people will write code at a systems level, not a function level, and it's not clear to us that you can do that with text. Text-based tools like Claude Code work in our text-based-code systems today, but I think describing algorithms to a computer in the future might involve more diagrams, and terminal will not be ideal. That's our reasoning against building a tool in the terminal, but it clearly works well today, and is the simplest way for the labs to train/run terminal tool-use agents.
There's a reason why fully creating systems from them died 20 years ago - and it wasn't just because the code gen failed. Finding a bug in your spec when its a mess of arrows and connections can be nigh impossible.
Go image search "complex unreal blueprint".
I don't imagine people will want to fully visualize codebases in a giant unified diagram, but I find it hard to imagine that we won't have digests and overviews that at least stray from plaintext in some way.
I think there are a lot of unexplored ways of using AI to create an intelligent overview of a repo and its data structures, or a React project and its components and state, etc.
> hard to imagine that we won't have digests and overviews
100% agreed here.
Disclosure: I'm the author of the project below.
Sounds exactly like what DeepWiki is doing from the Devin AI Agent guys: https://deepwiki.com
Hey by the way I hear all communication between people is going to shift to pictograms soon. You know -- emoji and hieroglyphs. Text just isn't ideal, you know
We used to know better
I think editing just a part of the file is what Roo calls diff editing, and I'm asking if this is what the person above means by line edits.
edit: ahh just saw that it is also a fork of VS Code, so it is indeed OSS Cursor
And Zed: https://zed.dev
Yesterday on the front page of HN:
Are you sure? I have some expertise with my IDE, some other extension which solve problems for me, a wide range of them, I've learnt shortcuts, troubleshooting, where and who ask for help, but now you're telling me that I am better off leaving all that behind, and it's better for me? ;o
Their use base is completely different. And we’re both in a bubble, I reckon. IntelliJ people also only know a few VSCode users!
Their tools are wildly popular in many spaces. It isn't for everyone though. It's totally believable in your circle no one uses their tools, but it isn't niche.
Let’s say I make a few changes in the code that will require changes or additions to tests. I give the agent the test command I want it to run and the files to read, and let it cycle between running tests and modifying files.
While it’s doing that, I open Slack or do whatever else I need to do.
After a few minutes, I come back, review the agent’s changes, fix anything that needs to be fixed or give it further instructions, and move to the next thing.
Context switching is not the bottleneck. I actually like to go away from the IDE/keyboard to think through problems in a different environment (so a voice version of chatgpt that I can talk to via my smartwatch while walking and see some answers either on my smartglasses or via sound would be ideal… I don’t really need more screen (monitor) time)
I do this all the time, and I am completely fine with it. Sure, I need to pay more attention, but I think it does more good than harm.
For well trodden paths that AI is good at, you're wasting a ton of time copying context and lint/typechecking/test results and copying back edits. You could probably double your productivity by having an agentic coding workflow in the background doing stuff that's easy while you manually focus on harder problems, or just managing two agents that are working on easy code.
At it's most basic, agentic mode is necessary for building the proper context. While I might know the solution at the high level, I need the agent to explore the code base to find things I reference and bring them into context before writing code.
Agentic mode is also super helpful for getting LLMs from "99%" correct code to "100%" correct code. I'll ask them to do something to verify their work. This is often when the agent realizes it hallucinated a method name or used a directionally correct, but wrong column name.
Senior engineers are not necessarily old but have the experience to delegate manageable tasks to peers including juniors and collaborate with stakeholders. They’re part of an organization by definition. They’re senior to their peers in terms of experience or knowledge, not age.
Agentic AIs slot into this pattern easily.
If you are a solo dev you may not find this valuable. If you are a senior then you probably do.
1) Authority (whatever a prominent evangelist developer was peddling)
2) The book I was following as a guide
3) The tutorial I was following as a guide
4) The consensus of the crowd at the time
5) Whatever worked (SO, brute force, whatever library, whatever magic)
It took a long ass time before I got to throw all five of those things out (throw the map away). At the moment, #5 on that list is AI (whatever works). It's a Rite of Passage, and because so much of being a developer involves autodidacticism, this is a valley you must go through. Even so, it's pretty cool when you make it out of that valley (you can do whatever you want without any anxiety about is this the right path?). You are never fearful or lost in the valley(s) for the most part afterward.
Most people have not deployed enough critical code that was mostly written with AI. It's when that stuff breaks, and they have to debug it with AI, that's when they'll have to contend with the blood, sweat, and tears. That's when the person will swear that they'll never use AI again. The thing is, we can never not use AI ever again. So, this is the trial by fire where many will figure out the depth of the valley and emerge from it with all the lessons. I can only speculate, but I suspect the lessons will be something along the lines of "some things should use less AI than others".
I think it's a cool journey, best of luck to the AI-first crowd, you will learn lessons the rest of us are not brave enough to embark on. I already have a basket of lessons, so I travel differently through the valley (hint: My ship still has a helm).
Or, most software will become immutable. You'll just replace it.
You'll throw away the mess, and let a newer LLM build a better version in a couple of days. You ask the LLM to write down the specs for the newer version based on the old code.
If that is true, then the crowd that is not brave enough to do AI-first will just be left behind.
This is peak AI, it only goes downhill from here in terms of quality, the AI first flows will be replaceable. Those offshored teams that we have suffered with for years now will be primarly replaced (google first programmers). And developers will continue, working around the edges. The differences will be that startups wont be able to use technology horading to stifle competition, unless they make themselves immune from the ai vacumes.
I can appreciate the comments further up around how AI can help unravel the mysterys of a legacy codebase. Being able to ask questions about code in quick succession will mean that we will feel more confident. AI is lossy, hard to direct, yet very confident always. We have 10k line functions in our legacy code that nests and nest. How confident are you to let ai go and refactor this code without oversight and ship to a customer? Thus far im not, maybe i dont know the best model and tools to use and how to apply them, but even if one of those logic branches gets hallucinated im in for a very bumpy ride. Watching non-technical people at my org get frusted and stuck with it in a loop is a lot more common then the successes which seem to be the opposite of the experienced engineers who use it as a tool, not a savour. But every situation is different.
If you think you company can be a differentiator in the market because it has access to the same AI tool as every other company? We'll well see about that. I believe there has to be more.
Im an experienced engineer of 30+yrs. Technology comes and goes. AI is just a another tool in the chest. I use it primarily because i dont have to deal with ads. I also use it to be a electrical engineer, designing circuts in areas i am not familiar with. I can see very simply the noivce side of the coin, it feels like you have super powers because you just dont know enough about the subject to be aware of anything else. Its sped up the learning cycle considerably beacause of the conversational nature. After a few years of projects, i know how to ask better questions to get better results.
Not even, devoured might be more apt. If I'm manually moving through this valley and a flood is coming through, those who are sticking automatic propellers and navigation systems on their ship are going to be the ones that can surf the flood and come out of the valley. We don't know, this is literally the adventure. I'm personally on the side of a hybrid approach. It's fun as hell, best of luck to everyone.
It's in poor taste to bring up this example, but I'll mention it as softly as I can. There were some people that went down looking for the Titanic recently. It could have worked, you know what I mean? These are risks we all take.
Quoting the Admiral from Starcraft Broodwars cinematic (I'm a learned person):
"... You must go into this with both eyes open"
Not sure if you drew the right conclusion from that one.
The joys of dependency hell combined with rapid deprecation of the underlying tooling.
Do we really want that? To be beholden to the hands of a few?
Hell, you can't even purchase a GPU with high enough VRAM these days for an acceptable amount of money. In part because of geopolitics. I wonder how many morerestrictions are there to come.
There's a lot of FOMO going around, those honing their programming skills will continue to thrive, and that's a guarantee. Don't become a vassal when you can be a king.
That's like saying "I'll just burn down my house because I can replace it. Anyone who repairs their house will be left behind."
It's true, you can replace it, so I can't put my finger on what has been stopping people from burning their houses down instead of, say, spring cleaning
> that's when they'll have to contend with the blood, sweat, and tears. That's when the person will swear that they'll never use AI again.
I'm not using AI and I'm still an incredibly high velocity engineer because I own my codebase. I've written each line ten times over, like a player who has become highly skilled at one particular game.
I actually flip things - I do the breakdown myself in a SPEC.md file and then have the agent work through it. Markdown checklists work great, and the agent can usually update/expand them as it goes.
Now that I think about it, I might have only ever used agents for searching and answering questions, not for producing code. Perhaps I don't trust the AI to build a good enough structure, so while I'll use AI, it is one file at a time sort of interaction where I see every change it makes. I should probably try out one of these agent based models for a throw away project just to get more anecdotes to base my opinion on.
With humans there is this point where even the most patient teacher has to move on to do other things. Learning is best when one is curios about something and curiosity is more often specific. (When generic one can just read the manual)
The main reason I think there is such a proliferation is it's not clear what the best interface to coding agents will be. Is it in Slack and Linear? Is it on the CLI? Is it a web interface with a code editor? Is it VS Code or Zed?
Just like everyone has their favored IDE, in a few years time, I think everyone will have their favored interaction pattern for coding agents.
Product managers might like Devin because they don't need to setup an environment. Software engineers might still prefer Cursor because they want to edit the code and run tests on their own.
Cursor has a concept of a shadow workspace and I think we're going to see this across all coding agents. You kick off an async task in whatever IDE you use and it presents the results of the agent in an easy to review way a bit later.
As for Void, I think being open source is valuable on it's own. My understanding is Microsoft could enforce license restrictions at some point down the road to make Cursor difficult to use with certain extensions.
Another YC backed open source VS Code is Continue: https://www.continue.dev/
(Caveat: I am a YC founder building in this space: https://www.engines.dev/)
I'm working on an agnostic unified framework to make contexts transferrable between these tools.
This will permit zero friction, zero interruption transitions without any code modification.
Should have something to show by next week.
Hit me up if you're interested in working on this problem - I'm tired of cowboying my projects.
I know some folks like using the terminal, but if you like Claude Code you should consider plugging your API key into Void and using Claude there! Same exact model and provider and price, but with a UI around the tool calls, checkpoints, etc.
That is until I started using Claude Code.
It’s not about the terminal. It’s just a better UX in general.
https://techcrunch.com/2024/09/30/y-combinator-is-being-crit...
Most common these days is to make the paid product be a hosted version of the open source software, but there are other ways too. Experienced founders emphasize to new startups how important it is to get this right and to keep your open source community happy.
No one I've heard is treating open source like a bait and switch; quite the opposite. What is sought is a win-win where each component (open source and paid) does better because of the other.
I think there’s a general misconception out there that open sourcing will cannibalize your hosted product business if you make it too easy to run. But in practice, there’s not a lot of overlap between people who want to self-host and people who want cloud. Most people who want cloud still want it even if they can self-host with a single command.
sudo chmod 755 path/to/Cursor-0.48.6.x86_64.AppImage
path/to/Cursor-0.48.6.x86_64.AppImage
The setuid sandbox is not running as root. Common causes:
* An unprivileged process using ptrace on it, like a debugger.
* A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...)
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
bin/appimage/Cursor-0.48.6-x86_64.AppImage --no-sandbox
The effort required to start Cursor is the reason I don't use it much. VS code is an actual, bona fide installed app with an icon that sits on my screen, I just click it to launch it. So much easier. Even if I have to write code manually.
Edit: asked gemini2.5 to make the script for you. Copy, chmod and run. (maybe check if I am not trolling you first).
#!/bin/bash
echo "Cursor AppImage Desktop Integration Script" echo "-----------------------------------------"
# --- Configuration --- # Default application name DEFAULT_APP_NAME="Cursor" # Directory to store AppImages APPIMAGE_DIR="$HOME/Applications" # Directory for .desktop files DESKTOP_ENTRY_DIR="$HOME/.local/share/applications" # Directory for icons (optional, if you want to copy the icon) # ICON_DIR="$HOME/.local/share/icons/hicolor/scalable/apps"
# --- Ensure target directories exist --- mkdir -p "$APPIMAGE_DIR" mkdir -p "$DESKTOP_ENTRY_DIR" # mkdir -p "$ICON_DIR" # Uncomment if you choose to copy icons to a standard path
# --- Get AppImage Path --- read -e -p "Enter the full path to your Cursor AppImage file: " APPIMAGE_PATH
if [ ! -f "$APPIMAGE_PATH" ]; then echo "Error: AppImage file not found at '$APPIMAGE_PATH'." exit 1 fi
# --- Get Application Name --- read -p "Enter the name for the application menu shortcut (default: $DEFAULT_APP_NAME): " APP_NAME APP_NAME=${APP_NAME:-$DEFAULT_APP_NAME}
# Sanitize APP_NAME for use in filenames (lowercase, no spaces) DESKTOP_FILE_BASENAME=$(echo "$APP_NAME" | tr '[:upper:]' '[:lower:]' | tr -s ' ' '_' | sed 's/[^a-z0-9_-]//g') if [ -z "$DESKTOP_FILE_BASENAME" ]; then DESKTOP_FILE_BASENAME="cursorapp" # fallback fi
# --- Define Target AppImage Path --- # Use the sanitized app name or the original AppImage name for the stored file # For simplicity, let's use a generic name like AppName.AppImage TARGET_APPIMAGE_NAME="${APP_NAME}.AppImage" TARGET_APPIMAGE_PATH="$APPIMAGE_DIR/$TARGET_APPIMAGE_NAME"
# --- Move and Prepare AppImage --- echo "Copying AppImage to '$TARGET_APPIMAGE_PATH'..." cp "$APPIMAGE_PATH" "$TARGET_APPIMAGE_PATH" if [ $? -ne 0 ]; then echo "Error: Failed to copy AppImage." exit 1 fi
echo "Making AppImage executable..." chmod +x "$TARGET_APPIMAGE_PATH" if [ $? -ne 0 ]; then echo "Error: Failed to make AppImage executable." # Consider cleanup or proceed if non-critical for .desktop creation itself fi
# --- Get Icon Path (Optional) --- ICON_ENTRY="Icon=$DESKTOP_FILE_BASENAME" # Default icon name, system might find it if themed read -e -p "Enter the full path to an icon file (e.g., .png, .svg) (optional, press Enter to skip): " ICON_PATH
if [ -f "$ICON_PATH" ]; then # Option 1: Use the direct path in the .desktop file ICON_ENTRY="Icon=$ICON_PATH" echo "Using icon from '$ICON_PATH'."
# Option 2 (More advanced, if you want to copy it to a standard location):
# ICON_FILENAME="${DESKTOP_FILE_BASENAME}.png" # Or get extension from ICON_PATH
# cp "$ICON_PATH" "$ICON_DIR/$ICON_FILENAME"
# if [ $? -eq 0 ]; then
# ICON_ENTRY="Icon=$DESKTOP_FILE_BASENAME" # Or $ICON_FILENAME without path if in theme path
# echo "Copied icon to '$ICON_DIR/$ICON_FILENAME'."
# else
# echo "Warning: Could not copy icon. Will use direct path if available or default."
# fi# --- Create .desktop File --- DESKTOP_FILE_PATH="$DESKTOP_ENTRY_DIR/${DESKTOP_FILE_BASENAME}.desktop" echo "Creating .desktop file at '$DESKTOP_FILE_PATH'..."
cat > "$DESKTOP_FILE_PATH" << EOF [Desktop Entry] Version=1.0 Name=$APP_NAME Comment=AI Powered Code Editor (AppImage) Exec="$TARGET_APPIMAGE_PATH" --no-sandbox %U $ICON_ENTRY Terminal=false Type=Application Categories=Development;IDE;TextEditor;Utility; StartupWMClass=Cursor # Often helps with icon association in docks/taskbars. May need adjustment. EOF
# Try to guess StartupWMClass if possible (more advanced, requires running the app and using xprop) # For Cursor, "Cursor" is a likely candidate. If window grouping issues arise, this might need to be # identified using a tool like `xprop WM_CLASS` on an open Cursor window.
if [ $? -ne 0 ]; then echo "Error: Failed to create .desktop file." exit 1 fi
# Make .desktop file readable (and executable for user, as some guides suggest) chmod u+rwx "$DESKTOP_FILE_PATH" # User read, write, execute chmod go+r "$DESKTOP_FILE_PATH" # Group and Other read
# --- Update Desktop Database --- echo "Updating application database..." update-desktop-database -q "$DESKTOP_ENTRY_DIR" # -q for quiet
echo "" echo "-----------------------------------------" echo "Success!" echo "'$APP_NAME' should now be available in your application menu." echo "If it doesn't appear immediately, you might need to log out and log back in or restart your desktop environment." echo "" echo "To launch, you can now search for '$APP_NAME'." echo "The AppImage is stored at: $TARGET_APPIMAGE_PATH" echo "The desktop shortcut file is: $DESKTOP_FILE_PATH" echo "" echo "If you encounter issues with the icon not showing up, ensure the path in '$ICON_ENTRY' is correct or place an icon named '${DESKTOP_FILE_BASENAME}.png' (or .svg) in ~/.local/share/icons/ or a system icon theme directory." echo "-----------------------------------------"
exit 0
I'm still in vim with copilot and know I'm missing out. Anyway I'm also adding to the problem as I've got my own too (don't we all?!), at https://codeplusequalsai.com. Coded in vim 'cause I can't decide on an editor!
For real. I think it's because code editors seem to be in that perfect intersection of:
- A tool for programmers. Programmers like building for programmers.
- A tool for productivity. Companies will pay for productivity.
- A tool that's clearly AI-able. VC's will invest in AI tools.
- A tool with plenty of open source lift. The clear, common (and extreme?) example of this being forking VSCode.
Add to that the recent purchase of VSCode-fork [1] Windsurf for $3 billion [2] and I suspect we will see many more of these.
[1]: https://windsurf.com/blog/why-we-built-windsurf#:~:text=This...
[2]: https://community.openai.com/t/openai-is-acquiring-windsurf-...