How to Build a Better IDE

Integrated development environments (IDEs) are essential tools for developers, but there’s always room for improvement. This article outlines a wishlist of features I’d like to see in future IDEs. Some of these features already exist, some are almost across the finish line, and others I’ve never seen before.

Queryable Debugger Expressions

How often have you been in the middle of an intense hour-long debugging session only to realize you KNOW that some piece of data exists SOMEWHERE IN MEMORY but you just can’t seem to locate it in a deeply nested object or array?

This feature would allow you to iterate through reflectable objects for a given value or key/value pair and break at that point. This should also extend to support searching for a given key, value, or key value pair through complex objects while paused.

Because we’ve all been here:

Ghost and Replay

Automatically saves the last debugged run of arguments passed through any given function (effectively a replay history) such that even when not debugging, you can see faint overlays of the last actual concrete values that passed through various functions / variables. It could even keep series of snapshots or just keep the last debugging run. I’d wager this would be even more useful in weakly typed languages such as javascript.

Coloration of Tagged Comments

Being able to distinguish between different levels/categories of comments would be very handy. For example TODO (DEVELOPER INITIALS) could appear in a different color to make it easy to find remaining work specific to you, and we could use others for things like STEP, or GROUP that lets a highlighted line stand out.

The steps are now highlighted a custom color:

Embedding Images as Comments

We all know the imminent out-of-sync dangers of separating documentation from code, but comments are still relegated to text only which just seems terribly inadequate where a UML diagram would go much further in explaining certain pieces of logic.

Allow pasting of pictures that fold into smaller thumbnails and on hover display larger picture for code flow that can be checked in. So the normal text code file has a

The vertical chevron indicates that this image is currently collapsed, which when expanded:

Adding an image as a comment would be as simple as copy-pasting directly into the desired line in the IDE which would copy the file to an checked-in assets folder as well as adding the appropriate markdown. And of course being standard markdown (as a comment) means it wouldn’t negatively impact any IDE that doesn’t support this concept of embedded media.

Even better would be the ability to embed renderable mermaid UML diagrams which would make them searchable as well as editable in-situ.

Save To Assistant

Full disclosure - I’ve seen enough cautionary tales of handing off your entire codebase to an agentic system that I’ll likely never be sold on Karpathy’s definition of vibe coding.

I think they can induce a dangerous sort of passivity among developers since they can shift the role from an active participant to more of the passive role of a code reviewer (reading vs writing). However, I think there is a place for individualized LLMs connected to knowledge graphs of your own code base, your standards, your best practices, etc.

This feature would enable a developer to highlight a section of code and add it to a personal code vault. This code vault would work in concert with an offline modest LLM model (such as 7b codestral). Over time the LLM would be able to act as an intelligent snippet manager - autosuggesting and modifying the snippets on the fly to fit the applicable area you are currently working in.

Commit Masks

How many times have you brought down a repo where you needed to run it locally but due to a combination of factors beyond your control, you have to patch some object instances to get it to run past that point, e.g.

// only accessible behind a VPC gateway and blows up locally
x = fooBar() 

// create non-committable interception mask
x = fooBar() => { return { memberId: 4 } }

// code can continue executing

Masking sections of code (similar to bookmarks) as “non-committable”. This allows you to setup temporary hot patching style code, but never have to worry about it being accidentally committed as it is overlaid by the IDE at runtime only.

Think of this like a IDE specific equivalent to using a jest style spyOn/mock but with less overhead and usable anywhere.

This is going to be heavily controversial as it could introduce incredibly subtle variations where you don’t realize your local/remote branches are divergent. I still think it could have value if the IDE made it extremely obvious what portions of the code were masked.

Furthermore, I’d love to see a type of “pre-commit” lint check that analyzed any of the files for sensitive looking data like API keys, secrets, etc.