A developer opens a file. The cursor lands on a method. The first question, almost always, is the same:
Is this thing actually used?

The IDE will not tell them. So they go looking. They switch to a tracing tool, type a query, scroll through call sites, ask a teammate on Slack, and eventually piece together a half-confident answer. Then they go back to the file and try to remember what they were doing.

The IDE knows everything about the code and almost nothing about the system the code runs in.

The cost of context-switching is mostly invisible

Every developer has built a habit of leaving the editor to understand the editor.

Open a dashboard to check if an endpoint still gets traffic. Open a logging tool to see if a branch ever runs. Open the architecture wiki — which is six months old — to remember which service consumes this queue. Open a chat thread to ask the person who originally wrote the code.

None of these trips is expensive on its own. They are expensive in aggregate. They break flow, they fragment understanding, and they encourage assumptions because the friction of checking is just high enough that engineers stop checking.

So code gets read as text. Decisions get made on intuition. Risk gets discovered later, in production.

Code is not really text

A method is not the lines on the screen. It is the lines on the screen *plus* how it actually runs: how often, on which paths, called by which services, touching which downstream systems, hot or cold or completely dormant.

The text is the same for everyone. The behaviour is what makes one method safe to change and another method a tripwire.

Reading code without production context is like reading a map with the traffic erased.

That context already exists. It exists in traces, in metrics, in deployment data, in service graphs. It is just not where developers work. It lives in tools that were built for operators, on time horizons that were built for incidents.

The shift

The IDE should stop pretending that code is static. It should show, next to the method, whether the method runs. Next to the API, whether anything calls it. Next to the branch, whether it ever executes in production. This is what KarmaLens is built to do — bring runtime behaviour into the place where developers already work, so they can read code with the system running underneath it.

The future IDE is not just smarter at writing code. It is smarter about what the code is already doing.